ERP2004 Upgrade Diary
Introduction
I know that it has been a little while since I added an entry to my ERP2004 upgrade diary. In fact my last entry was for ERP2004 Upgrade Diary: March 2005. Although our team hadn't made much progress on the upgrade, I'm afraid we didn't just all take vacation for the summer. Before really starting into the upgrade in force, we wanted to clear up some open development and configuration issues. So we took the months of May-July to do just that.
While the business and ABAP teams were busy finishing up some of these tasks, the Basis team was focused on doing sandbox test runs of the upgrade to get the process down. After doing a couple of these practice upgrades, we have come to the conclusion that the upgrade assistant has a mean streak. It seems like no matter when you start the upgrade, it will run during the work day without user interaction. However it always seems to want human intervention at about 3:00AM on a Saturday morning. 🙂
Getting Started
The month of August finally brought an official start to our Upgrade Project and solidification to our Upgrade timeline. The plan is to upgrade a good copy of Production as a Sandbox Server in the month of August. The users will then spend the month of September on that Sandbox doing their discovery. They will be looking for bugs, missing functionality, new functionality, etc. About two weeks into this discovery phase we will activate several of the Extension Sets (EA-HR, EA-GLTRADE, EA-FINSERV, and EA-APPL) in order to get an idea of what impact they might have on our system configuration. Only after this phase will we make the decision of when we plan to turn these own for real.
The first week of October we will upgrade our Development system. We will then spend the rest of October and a good bit of November fixing and updating custom ABAP Programs (more on that later), updating our config, and performing lots of Unit Testing.
Our Integration testing will start in November after the upgrade of our QAS system and run through most of December. The hope is that formal training for the end users will not be necessary. We will involve the power users during the integration testing. The thought is that any critical new functionality will be learned by the power users by taking part in the testing.
We will have a production go-live date near the beginning of February 2006.
We then go immediately into Unicode Conversion Mode. We don't have the exact timelines for these steps yet, but we know we want to be live on Unicode by May of 2006.
CTS Cleanup
On of the other things that we have been concentrating on during the month of August has been CTS clean up. We have nearly 200 old CTSs (mostly from people who don't work for us any longer) that were never even released from our Development system. Our concern is two fold. First this represent configuration or development that is not in sync with production. This can cause difficulties when testing. More important is the fact that technically we don't feel comfortable with keep these old 46C transports around after we have been through the upgrade. We would like everyone to start fresh with an empty transport log.
It has been a considerable effort to analyze what is in each transport and then manually remove those changes. For configuration we have been carefully undoing the configuration settings from these orphan CTSs by hand. For development objects, we created a Graveyard development class. This development class is a local development class so objects in it will not be transportable. We copy any retired or orphaned development object into this Graveyard using a special naming standard. Then we delete the associated open CTS. This way our code is in sync with the rest of the landscape, but we still have access to view or retrieve these old programs.
My advice would be not to wait for an upgrade to do this exercise. It has been a valuable experience of its own and one that we wish that we done on an annual basis.
HR CE
Currently in our 46C system we have the HR-CE (Central Europe) package installed. Unfortunately the way this works in 46C is that the HR-CE is modification based. This means that the application of HR-CE packages modify the standard HR programs. Every time you apply standard HR support packages these modifications get overwritten. You then must reapply HR-CE specific modifications as well as LCP (Legal Change Packages).
This whole process has been a bit painful to say the least. With the introduction of many of the Central European countries into the EU, the rate and importance of the patches has increased.
Now with ERP2004, the HR-CE becomes a modification free add-in. From what we have seen of our sandbox upgrades, the new HR-CEE will be much easier to maintain. However anyone using HR-CE going through this upgrade, be prepared to still see a lot of objects in your modification adjustment log after the upgrade. There are some programs that you run before the upgrade starts that are supposed to pull most of the objects out of SPAU (and it did remove most of them). We still spent about a 1/2 day returning many of the previously modified HR programs back to original after the upgrade. Hopefully this is the last time we will ever have to mess around with the Modification Adjust and the HR-CE!
ABAP Program Changes
I know this is the part that most developers are going to be interested in - exactly how many programs broke! The good news is that there are some excellent tools for scanning your custom code looking for syntax errors and Unicode adjustments that need to be made.
During our scans, we had almost 2,000 custom objects. Of those 2,000 we only had 27 custom programs that had syntax errors after the upgrade. Of those 27, 10 had the same syntax error that revolved around the SAP class CL_GUI_FRONTEND_SERVICES. In 46C this SAP class is not marked as final. Therefore we had sub classed it and added some methods of our own. Now after the upgrade this class is marked as final. As a consequence any program that uses our subclass will not now syntax check. Really though, this is a simple problem to fix.
All the other errors seem to revolve around changes to data dictionary structures. SSFCOMPOP (SmartForms Transfer Options) is no longer a Flat Structure. It now has an internal table as one of its elements. Depending upon how you use this structure, this might lead to syntax errors. The other major structure change was also related to SmartForms. The structure SSFCRESCL, which is returned from the generated SmartForm Processing Routine ( parameter job_output_info ) no longer has separate elements for XSFDATA, XSLDATA, or CSSDATA. The functionality these elements provided are now restructured under the element SSFXMLOUT. So it looks like our custom SmartForms processing programs will need some work to getting them running again.
Now to the Unicode changes. I am afraid that the list of programs that need changes for Unicode was significantly larger than our syntax error list. We had 187 objects that were flagged as needing changes. For years we have used a set of function modules/classes to do nearly all of our Application Server File Access (open dataset, transfer, etc). This has helped tremendously as the syntax is slightly different. By having one central location with this code, we were able to update many programs that use file access with a single change.
Some of the other common problems were the concatenate of character and hex fields. This was almost always done to add in Horizontal Tabs or Carriage Returns. Now that we are upgraded we can use the class CL_ABAP_CHAR_UTILITIES instead. This should be a simple find and replace change.
Another common Unicode error is with the use of DESCRIBE LENGTH. For Unicode programs you must specify if you want to use IN BYTE MODE or IN CHARACTER MODE. This should also be a quick fix.
The biggest Unicode problem has to be the following:
style="WHITE-SPACE: nowrap">Upload/Ws_Upload and Download/Ws_Download are obsolete
This too is quite easy to fix by switching to cl_gui_frontend_services. In fact that is something that I would recommend that you do now even on older releases in preparation for future upgrades/Unicode Conversions.
The good news about the Unicode conversion problems is that we don't see anything that looks too difficult to fix. It appears like many of items can be fixed with a Find and Replace. We expect to spend about 2 days updating the listed programs.
Closing
So far our upgrade is going quite good and is staying right on schedule. Our workload to update custom ABAP programs (even for Unicode) seems quite manageable. However I am sure we will find other surprises once we begin our testing. Tune in next month to find out how that phase of the project turns out.
