Although the SDN has excellent resource for most SAP stuff, I believe there is room for a developer’s point of view on a SAP technical upgrade. Now having worked through two upgrades myself I thought it would be a good idea to put forward the same. For someone who has never worked on an upgrade before, this article should go to some distance in giving the developer confidence to say that he/she knows more or less what to expect from the project.
SPAU, SPDD, ABAP Dump etc are some of the things an ABAP developer will come across in a SAP Upgrade project. I will try and give a small but comprehensive bulleted list of the various phases a ABAP developer may need to get involved in a logical and chorological sequence below.
- SPDD – Without duplicating information already on SDN, a good link to SPDD is http://wiki.sdn.sap.com/wiki/display/SI/Understanding+SPDD
Assuming that you have read the Wiki page above I will only summarize by saying that SPDD is the first Basis activity and lists all changes to SAP Data Dictionary objects from your current SAP version to the one you are upgrading to. Most of it should be taken care of by the Basis Team themselves but will require an ABAP developer to take a call on some repository objects being used or referenced in custom programs/repository objects. E.g. SAP change length of a domain say matnr from 18 to 15 characters. SAP will take care of all standard programs where they have referenced the domain matnr but as a ABAP developer it will be your call as to what impact the change will make to all your custom programs or tables where you have referenced the domain matnr. Depending on your analysis you may go ahead and accept the changes or keep the original version of the domain. The impact of not accepting the changes could be huge and out of the scope for me. The sensible decision should be to accept the changes and modify all your custom stuff accordingly. (Matnr is just an example I have used as it a common domain and should be known to most developers.)
- SPAU – Again a good explanation of SPAU is
SPAU is another Basis activity immediately after SPDD. I would say that SPAU is an extension of SPDD to all SAP repository objects i.e. programs, function groups, OSS notes etc. In SPAU the developer has a larger role to play than in SPDD. Firstly the list is generally much bigger than SPDD and more importantly it requires some research on the impact of the changes in the SAP repository objects to the custom Repository objects. E.g. SAP changes the interface of a function module say CONVERSION_EXIT_ALPHA_INPUT. SAP will take care of all standard repository objects where they have referenced the Function Module but as an ABAP developer it will be your call as to what impact the change will make to all your custom programs made a call to CONVERSION_EXIT_ALPHA_INPUT. The impact of accepting or not accepting the changes is more or less as in the case of SPDD objects. (CONVERSION_EXIT_ALPHA_INPUT is just an example I have used as it a common function module and should be known to most developers.)
Now the system has been upgraded and is ready for testing by the functional or testing team.
- The ABAP work coming out from here on is more like supporting a system. There will be lots of incidents and issues coming out of testing e.g. transactions not working as they did in the original SAP system or ABAP dumps. Solving them will involve lots of debugging and the same approach one uses for support incidents.
The above might look like a overly simplistic view but that’s what I feel an SAP technical upgrade is, a simple project with lots of support like issues and incidents for the ABAP developer. So if you have a good problem solving approach and have worked on support before, the SAP technical upgrade should be bread and butter for you.