SAP Technical Upgrade and SPAU/SPDD

TECHNICAL UPGRADE

Technical Upgrade is the fast upgrade without additional functionality but with minor user interface changes to ensure business continuity. All objects modified by a customer have to be manually re-modified during an upgrade. Modifications are either automatically adopted or the system provides you with an assistant for adjusting your modifications to the newly upgraded configuration using transactions SPAU and SPDD

SPDD: This transaction allows you to adjust modifications to ABAP Dictionary objects during an upgrade. Using this transaction we can adjust the Domains, Data elements, Tables, Structures, Transparent tables, pooled and cluster tables including their technical settings, indexes of transparent tables. If you adjust data elements that have been changed with modification assistant in an earlier release, the changes can be copied automatically.

Steps to run SPDD:

1. Start transaction SE03 as user DDIC and choose Administration -> Set system change option
2. Select modifiable in the Global setting dialog box
3. Choose to continue
4. Choose Edit->Select All
5. Save your changes
6. Then log on as a normal user since DDIC may not perform any repairs

SPAU: This transaction allows you to adjust programs, function modules, screens, interfaces, documentation and text elements after an upgrade. After you adjusted or edited an object, you can use User/Status function to modify the status of the object. Before doing this, you can also add other developers or testers that are allowed to edit the object and create the short note.

Steps to run SPAU:

1. Start transaction SE03 as user DDIC and choose Administration -> Set system change option
2. Select modifiable in the Global setting dialog box
3. Choose to continue
4. Choose Edit->Select All
5. Save your changes
6. Then log on as a normal user since DDIC may not perform any repairs

Other Important topics in Technical upgrade

Upgrading the Development System: Perform adjust in the development system using SPDD and SPAU transactions and assign the transport requests. The upgrade control program R3up exports the transports that you have marked in a later upgrade phase.

Upgrading the Production System: During this phase R3up upgrade control program check for whether there are any change requests registered for transport from the development system to the production system. If this is the case, R3up offers to import the transport automatically, instead of you carrying out adjustments with transactions SPAU/SPDD. If you choose this procedure, you still have the option of stopping SPDD/SPAU to check the changes accepted automatically before they are activate.

STEPS IN TECHNICAL UPGRADE

Ø  Basis team will do the prepare activities. (Unix, BASIS, DBA etc)

Ø  Need to run the transaction SPDD which provides the details of SAP Standard Dictionary objects that have been modified by the client. Users need to take a decision to keep the changes or revert back to the SAP Standard Structure. More often decision is to keep changes. This is mandatory activity in upgrade and avoids data losses in new system.

Ø  After completing SPDD transaction, we need to run SPAU transaction to get the list of standard SAP programs that have been modified. This activity can be done in phases even after the upgrade. Generally this will be done in the same go so that your testing results are consistent and have more confident in upgrade.

Ø  Run SPUMG transaction for Unicode Conversion in non-Unicode system. Note: SPUM4 in 4.6C.

Ø  Then we need to move custom objects (Z/Y). Need to do extended programming check (EPC), SQL Trace, Unit Testing, Integration Testing, User Acceptance Testing etc.

Important Tables in Technical Upgrade

Ø  SMODILOG: This table has the record of all modifications to the objects. This includes customized objects and SNOTE corrections. These objects usually can be found in SE95 if the change is not obsolete.

Ø  TADIR: Very important system table. This table is the directory of all repository objects. All ABAP reports, classes, function groups, etc are recorded in this table. Usually during upgrade to keep track of lost objects.

Ø  TRDIR: Not very often used. It has the information of all ABAP reports.

Ø  TSTC: It has the information of all transaction codes, like the corresponding programs and screens.

Ø  ADIRACESS: It has the access code information of all the objects in TADIR.

Ø  TFDIR: The information all function modules.

SPAU and SPDD

When you apply a package, a large number of objects are changed. If you have applied any OSS notes to objects in your system, the hot package may overwrite these objects. 

SPDD is used to identify dictionary objects and SPAU (repository objects), will identify any objects where the hot package is overwriting changes you have made through OSS notes. 

You must check all objects identified in SPAU and decide whether you need to reapply the OSS note or reset the code to the original SAP Code.  If, for instance, you are applying hot package 34, SPAU identifies an object where you have applied an OSS note.  You must check the OSSs note and see if SAP has fixed that note in a hot package. 

If the OSS note has been fixed in hot package 34, then you should reset the object to its original source code.  This means that there is no repair flag set against this object again and it is now SAP standard code.  If, however, the object is not fixed until hot package 38, or there is no fix available you have to reapply the OSS note, otherwise users will encounter the problems they had before the note was applied.

You must transport all reapplied notes and Reset to SAP Standard objects after you apply your hot package to your QAS and PRD systems.

FAQ

1. What objects will come in SPAU and SPDD?

All the objects which are modified, after transporting to the current system, will be listed in SPAU and SPDD.

SPDD contains the list of all modified Data Dictionary objects, like tables, data elements, domains, view etc. The rest of all the modified repository objects will be listed in SPAU.


2. What happens to the modifications done in the older version when we upgrade the version? (with Modification assistant and w/o)

After the initial upgrade happens, we have to do adjustments from SPAU/SPDD to maintain or reset the changes. That is, from the list of objects in SPAU/SPDD, you have to either carry forward the changes to the new version, by choosing the option ADOPT CHANGES (available on right click) or RESET TO ORIGINAL (available on right click).

3. Will they come in these transactions?

Yes, they will be listed in these transactions, after the BASIS upgrade activity.

4. What if we apply some patches (Notes) to the system? What is the impact of these patches to the SPAU transaction?

Patches will be supported by the version upgrade. In case of notes, we have to verify whether these notes are supported by the new version (you can go into http://www.service.sap.com/notes to verify this. Also, we have to analyze whether the code in the note is already incorporated in the new version. In this case you can ignore the changes choosing RESET TO ORIGINAL option.

ABAP Remediation

The objects that are needed to be upgraded, they are:

Includes
Function Groups / Function Modules
Programs / Reports
OSS Notes
SAP Repository Objects
SAP Data Dictionary Objects
Domains, Data Elements
Tables, Structures and Views
Module Pools, Sub Routine pools
BDC Programs
Print Programs
SAP Scripts, Screens
User Exits

Note: This part I will send in separate document which includes error fixes, solution description, OSS note and other related info.

How to adjust the SAP Objects in SPAU and SPDD phase:

Click on ‘Adopt Modification’
Left side – new system code
Right side – old system code

Text in ‘blue’ indicates that corresponding code is not present in another version.

We have to refer to old system (right side in split editor) texts in blue which means that particular block is missing in new system.

1) Press button ‘modify’ button to scroll through modifications

2) To copy code of old system, place your cursor against modification (right side of split screen) and press ‘Copy’ to accept modifications. The text would be stored in buffer.

3) Place cursor in left side of split editor and clink on ‘insert’. It will paste the old system block in new system.
To: add ‘insert’ block of old system, press ‘insert’,
add ‘replace’ block of old system, press ‘replace’
add ‘Delete’ block of old system, press ‘delete’.

Keep the previous Transport Request number in ‘Comments’ for future reference.
When you say ‘copy’, only the code between ‘insert’ block is copied in buffer.

Do:
- Syntax check after each modification adoption.
- Compare both the versions at every block of modification.
- After successful modification, activate the object.
- Sometimes, changes would be adopted automatically. (mostly for objects where traffic light ‘green’ is indicated), but you could follow the same steps as above for adjustment if it is not adjusted.

A typical SAP version version upgrade has two phases:
1 - technical upgrade (installing the new version of SAP and migrating all the current objects to the new system)

2- adjusting the modifications.

SPAU/SPDD comes in the second phase.
Once we install the new version and migrate all the active objects into the new version, you can see the list of modified objects (including OSS note applications) in SPAU and SPDD.

SPDD contains all the data dictionary objects and SPAU the rest.

You need to drill down from SPAU and do a versin comparison with the active version in the existing system (the system with SAP's older version). If you come across changes with OSS notes,
firstly, you need to check in service.sap.com/notes the releases it supports. If it does not support the latest version, you will need to find a replacement note for this and implement the same. Else, if it is supported in the new release, you need to carry forward the changes in previous version to the new version. For this you need only to right click on the object in SPAU and select "adopt changes".

You are recommended to follow the procedure below to make your programs US-compliant: The UNICODE task in transaction SAMT performs first an NUS and then a US syntax check for a selected program set. For an overview of the syntax errors by systems, programs and authors, consult the following document in SAPNet: Alternatively, you can start the ABAP program RSUNISCAN_FINAL to determine the Unicode-relevant syntax errors for a single program. Before you can set the Unicode flag in the NUS in the attributes of the program concerned, all syntax errors must be removed. Having enabled the Unicode flag in the NUS, you can run the syntax check for this program. To display a maximum of 50 syntax errors simultaneously, choose Utilities -> Settings -> Editor in the ABAP Editor and select the c