Preserve Modifications

During the upgrade processes, several phases are assigned to the task of preserving the customer-created and generated objects. The following steps are performed in sequence:

(1) Lock development workbench – This step will lock the option for developers to create, adjust, and delete objects in the SAP system. The Repository Switch method requires a stable SAP system. That is, a SAP system that is not changed during the upgrade.

(2) Collect all modified DDIC objects in SAP name range – This list will later be used by the SPDD transaction.

(3) Collect all modified ABAP programs in SAP name range – This list will later be used by the SPAU transaction.

(4) Collect all generated objects – All objects that are generated by SAP, for example, FI verification or substitution rules, are collected and put into a single command file

(5) Collect all ABAP programs and DDIC objects in the customer name range – These objects are also put in a command file

(6) Object export – Export all these objects to a DATA (dump) file at the OS level and use the previously created command files for these. This step is performed by the standard SAP transport tools “R3trans” and “tp export

<COMMANDFILE>.”

(7) Run transaction SPDD – This will offer the ability to clarify what table fields, field domains, and data elements should be kept or overwritten by the upgrade.

(8) Object import –- Import all previously exported objects back into new target release.

(9) Run transaction SPAU – This step can be performed after the upgrade is finished. It will allow you to make decisions on what ABAP program (version) should be kept.

During the PREPARE phase, the ADJUSTCHK will check whether there are adjustments made to the SAP system. The most important ABAP report that is used for this is RDDGETMO, which can also be used by the customer to list all modifications. The ADJUSTCHK phase writes all found modifications to the file named “/usr/sap/put/log/UMODPROT.<SAPSID>.”

TIP Modifications to objects that are part of the Basis layer are always returned to SAP standard. This is to increase upgrade performance. There is no option to save these modifications. If you would like to keep these modifications, you just have to reapply them after the upgrade is finished.

8.14.2 SPDD

The SPDD transaction needs to be performed by the customer in order to keep all modifications done to Data Dictionary objects after the SAP release upgrade. The SPDD transaction uses ABAP report RSUMOD02, which lists all modifications of tables, views, indexes, match-code objects, and structures.

Figure 8.17: Transaction SPDD. ©Copyright SAP AG.

After SPDD lists all DDIC modifications to the customer, the customer needs to decide what to do with these modifications. There are three options:

(1) Keep the modification, which means the field addition is kept as a table append.

(2) Return to SAP standard, which will lead to its original layout of the table.

(3) Choose SAP recommendation. SAP will show a recommendation, which you can follow. Decisions around domains and data elements are not always that clear. Therefore, check yourself whether the suggestion make sense.

When all decisions have been made, you can mark all entries as “being done”

and you can add all modifications into a single transport request. This transport request should be created in the Development system (usually the first upgraded system) and released for further SAP systems in the landscape.

After the SPDD phase has been finished, the ACT (Activation) phase can be started. All Data Dictionary modifications will be activated, which means that the table structures will be used for the creation or adoption of “real” database objects.

TIP There are several tools in SPDD for helping you out with the decision-making process.

The layout-delta screen shows you the difference between the “new” SAP delivered layout of the table and what’s currently the layout. You should definitely use this tool.

It’s important to understand the consequences of your choice during modification adjustments in SPDD. It’s very possible that the wrong decision leads to the loss of fields and therefore of data. This is applicable to tables, domains, and data elements. For other Data Dictionary objects, such as match code and lock objects, structures, and views.

8.14.3 SPAU

Transaction SPAU, which runs the ABAP report RSUMOD04, is similar to SPDD, except it’s applicable to ABAP Repository objects rather than the Data Dictionary.

Transaction SPAU lists all modifications done to:

 Reports (includes module pools, ABAP reports, queries. and function modules)

 Messages and texts

 Menus

 Screens (Dynpros)

Figure 8.18: Transaction SPAU. ©Copyright SAP AG.

Like transaction SPDD, the SPAU transaction offers the ability to process modification adjustments to standard SAP repository objects. To collect all modifications made in the SAP system, report RSUMOD04 checks table TADIR for repair flags and tables E070 and E071 for all objects in transport requests. And Table TDEVC is checked to see whether objects belong to SAP or customer name range. Although this information is also available in table ADIRACCESS, which contains all object keys per modified object, the SAP upgrade tool does not take this table into account.

Figure 8.19: Latest warning from the system before change to SAP coding is made.

The list of modified objects is shown per transport request. It’s up to the customer to decide whether the modification should be kept or not. The option

“Return to SAP Standard” means whether the modification made to the ABAP code will be overwritten by a new delivered object. If the source code modification is done on behalf of an SAP note, it’s relatively easy to make a decision. Usually the code fix is part of a Support Package or fixed in the upgrade, therefore, “Return to SAP standard” is the most common choice. If the modification should be kept it gets more complex. If the modification was made to implement additional functionality, this functionality needs to be integrated into the coding that is delivered with the upgrade. If the particular program is not changed between the source and target release, the modified code can be kept. However, if the programs do differ, a complete reimplementation of the modification is required.

The SPAU list is stored in table SMODILOG, which has the following layout (only the most important fields are shown here):

Field Type (dimension) Description OBJ_TYPE CHAR (4) Object type (as in TADIR)

OBJ_NAME CHAR (40) Name of object

OPERATION CHAR (4) How to deal with modification

UPGRADE CHAR (1) Upgrade relavant

UPG_MODE CHAR (1) How to deal in case of upgrades

SPAU CHAR (1) Shown in SPAU

TRKORR CHAR (20) Transport request/task SPAU_CODE CHAR (1) Current status in SPAU The OPERATION field can have the following values:

OPERATION field status Description PRE Exit at start of modularization unit POST Exit at end of modularization unit NEW New modularization unit

ALL Overlay unit

REPA Modification without support TRSL Translation entry

IMP Business add-in implementation MOD Modification to source code

If you look at the content of table SMODILOG during SPAU, you will see that most SPAU entries are of type OPERATION=”MOD.” You will also see that table SMODILOG is not normalized; the whole- and subobject relationship is stored in this single table.

Figure 8.20: Relationship between R3TR PROG and LIMU REPS in SMODILOG.

Where the SPDD list needs to be solved during the upgrade, the SPAU list can be processed after the upgrade is finished. Issues around SPAU can be solved up to several weeks after the upgrade. Because of the fact that all ABAP Repository changes are kept in the version management database, it’s relatively easy to reverse changes made to the system.

TIP If you want to know what changes are made to the system before the upgrade or PREPARE is started, refer to table ADIRACCESS to start with. Another good option is the ABAP report RDDGETMO, which is also used by R3up. This report shows all modifications made to the system per transport request.

During the upgrade, table UMODOBJ is refreshed regularly with information about modified objects and their adjustments. The UMODOBJ table (Upgrade Monitor Information of Objects) has the following layout:

Field Type (dimension) Description

SAPRL CHAR (4) SAP target release

PGMID CHAR (4) Object ID (see TADIR)

OBJECT CHAR (4) Object type (see TADIR)

OBJ_NAME CHAR (110) Name of object

UPGRMODE CHAR (1) Session of upgrade

MODART CHAR (1) Modification type

STATUS CHAR (1) Edit status

PATHTRID CHAR (20) Support Package name

SAPKORR CHAR (20) Transport request/task

This table is used to support phases BIND_PATCH, CONFLICT_CHK, SPDD, and SPAU in order to solve object modification conflicts. The field UPGRMODE contains information about the session of the upgrade and in what phase objects are identified and should be fixed. The MODART field contains information about the type of modification and the STATUS field contains information on the current status of the modification for the object performed in SPDD or SPAU. Possible values of this STATUS field are:

STATUS value Description

If objects reside in Support Packages or Transport requests, the appropriate information about this is stored in fields PATHTRID and SAPKORR.