Skip to Content
Introduction
This is my first real installment of my ERP2004 Upgrade diary. If you didn’t catch ERP2004 Upgrade Diary, I suggest that you read it for the background on this project.

In this installment we will look at the all activities that took place in the month of March.

WebAS Upgrade
For a project that hasn’t even had its official kickoff meeting yet, the core team is already hard at work. Although most of the implementation team won’t be pulled in until April; Basis, ABAP and Project Management have been busy all the same. We have been trying to come up with a basic timeline that will fit our needs. The direction from the business is to try and complete the Upgrade and Unicode Conversion by the end of the calendar year. So we are working backwards from there and planning to upgrade our first Sandbox in April.

But before we can even look at ERP2004 we have another system we wanted to address first. We have a stand alone WebAS system (620) that runs on Win2K3 and MSSQL. We added this a few years back in order to begin doing BSP development without having to upgrade R/3. We decided that our first step in our ERP upgrade project should be to upgrade this standalone system.

Advantages
We see several advantages to doing this. First we know that once we upgrade R/3 it will be running on WebAS 640. By upgrading our standalone system first, that gives our development and Basis group that much more time to learn new technical functionality before we really have to use it in the upgrade project. We hope to do ABAP delta training (46C to 640) in house on this standalone system in April or May while the Basis group is busy doing Sandbox upgrades of R/3. The next major advantage is that it gave us a chance to practice the upgrade process itself. The upgrade of the WebAS uses the same Upgrade Assistant that the R/3 Upgrade will use. Better to learn and make and mistakes with the much less visible standalone WebAS system, rather than mess up on one of our much larger R/3 systems. Finally we needed experience with the J2EE personality of the WebAS before we go there with R/3. Although we have a standalone WebAS system for several years, we have completely ignored the Java side of the WebAS – going as far as not even patching it. Actually on production we have the J2EE personality disabled. However we didn’t want to close this door any longer. We needed to get our WebAS J2EE personality up to date and begin to learn to administer and patch it.

Upgrading Dev
So we had a little more than 3 weeks in which to upgrade our entire landscape of the WebAS (Dev, QAS, Production). In addition to the core upgrade we also needed to add a MSSQL Schema (for the J2EE Add-in) and change the Collation (in preparation for Unicode). During the first week we were going to upgrade Development in a Resource Minimized Upgrade. First of all we have very little physical memory on this system (just 2 Gig) so we couldn’t afford to do a Downtime Minimized. But we also wanted to see what the time difference would really be between Downtime Minimized and Resource Minimized on a system with such a small database (just about 7.8 Gig). The upgrade and post steps went well and we had a total of about 8 hours of downtime.

Upgrading QAS
The following week we upgraded QAS. This time we were working on a system that had just as much memory as Production (4 Gig). We did a Downtime Minimized upgrade here and cut our total downtime to just a little over 5 hours. Now I should say that SAP’s definition of downtime (Time till R3Up returns control and your can begin productive operations) and our definition (we wanted to include many of the post steps such as the J2EE Add-In Installation) were very different. The actual downtime in the Upgrade Assistant was closer to 2.5 hours.

Oops!
However it was in the following days after the QAS upgrade that they had a very valuable lesson. With the Schema split for the ABAP+JE22 system (each personality has its own schema) the system no longer runs under DBO in MSSQL. Instead a user is created with the name of your ABAP system SID. A well-meaning Basis Admin granted this SID user System Administrator access in MSSQL. Unfortunately according to some documents we later found on MSDN, granting System Administrator effectively makes a user appear as though they are DBO to the database. The database user the WebAS system was running under could no longer see any of the database tables in the ABAP Schema. We started to notice that when work processes would die, they couldn’t restart. Unaware of the implications of the errors or the change that had been made, the system was restarted in an attempt to correct the work process problem. Of course the system wouldn’t come back up at all. After wasting a valuable day on the problem, we finally ran across the System Administrator article. After removing the access, the system restarted just fine!

Production Prep
Our testing in Dev and QAS during these two weeks went quite well. 640 SP10 was our upgrade target. We had used the SR1 release of the 640 upgrade media and bound in just the SP10 support stack. We encountered very few problems in our custom development (most BSP applications). I still have a few minor OSS problem notes open around the BAPI Browser and a strange dump in generated F4 help programs (SAPGui Transactions). However we felt that we were ready to go with the Production Upgrade. We had been given the OK for a 1/2 hour of downtime on Wednesday to patch the Kernel and perform the SQL Collation switch. The plan was then to begin the Upgrade Prepare phase and give it nearly a week to finish. We weren’t going to start the downtime phase of the main upgrade until next Tuesday at Midnight (we had a total window of downtime for the upgrade of Midnight to 6:00 AM). Unfortunately the day of the Kernel swap was the same day that we starting having the before mentioned System Administrator problem. Unsure of what was causing the error at that point and not wanting to introduced the problem into Production, we decided to cancel the Kernel Swap.

Production Upgrade
Not wanting to introduce any additional variables into our Upgrade we waited until the following Monday to perform the Kernel Swap and the Collation Maintenance. Immediately following we began our Upgrade Prepare Phase. We were starting Prepare at 10:30AM and we wanted to start downtime at Midnight. Talk about cutting it close! I wouldn’t recommend doing this again. We sat all evening staring at the Upgrade Assistant hoping that the Prepare phase would end in enough time to complete the upgrade in our downtime window. Luck would have it that the Prepare did finish with about 1 1/2 hours to spare.

The upgrade (and J2EE Add-In installation) at this point really went off without a hitch. We returned the system to the users about 6 minutes early. Unfortunately we weren’t given enough time to perform a SGEN before production time, so the first 2 hours or so were a little slow on the system. But we have been live nearly a week now and things seem to be clicking along nicely. I should be careful what I write though. I have night support this week and I don’t want to jinx myself.

Upgrade Assessment
There was one other major activity we did in March for the Upgrade – we had SAP come in and do an Upgrade Assessment. This was a two day event. The first day the two SAP consultants that were in asked us questions about our system landscape, custom development, etc. The second day they gave us their recommendations and an overview of some of the upgrade tools.

Looking back I have mixed emotions about this Upgrade Assessment. I think that for some customers (especially those who have never been through a major upgrade) this is a good offering. However our Basis group had just finished the technical upgrade of our standalone WebAS. They were already familiar with the Upgrade Assistant and the Downtime vs. Resource Minimized options. Much of what the consultants were describing we had just experienced the week before. Also several key members of our team already went thought what should turn out to have been a much more difficult upgrade – 31H to 46C. So from the functional side I don’t think we are looking at nearly the difficult transition as what people passing over 46C from older releases will see.

Also I didn’t have a very high opinion of the two people that SAP sent in. My mother taught me that if I can’t say something nice about someone, then I shouldn’t say anything at all. Therefore that’s all I have to say on that matter…

In the end we did get a nice look at the RBE (Reverse Business Engineering tools) and other tools available on the Service Market Place from SAP. I would say that if you have been through an upgrade and feel comfortable searching OSS and the Service Marketplace, you might be better served spending these two days on research rather than paying for the Upgrade Assessment. On the other hand if you have a lot of modifications or have the need for any special features during the upgrade (SAP doing the Upgrade or Modification Adjustment for you) I would definitely start the discussions through this Upgrade Assessment.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply