How to handle modification adjustment during an upgrade.

Concept

During the ADJUSTCHK_PRE_UPG/ADJUSTCHK_PRE_EHP phase of the upgrade or an EHP installtion, the upgrade tool scans for modified objects in the system. It compares the modified objects identified in the system to the NEW objects coming via the upgrade software. The modified objects consist of the repository and the dictionary objects. Modified objects mean SAP standard objects which are modified by the customer to suit their need. The tool make a list of these objects and sorts then into type SPDD and SPAU. Objects classified under SPDD are dictionary objects( tables , structures, views ect ). Objects classified into SPAU are repository objects ( Screen elements , reports, programs ect ) .

When to handle what

During the upgrade or EHP installation, a shadow system is created during the uptime. During the shadow import phases, the new objects coming from the upgrade or EHP media are used to create a shadow repository. During the DIFFEXP* phase of the upgrade or EHP installation, the modified objects from both dictionary and repository are transferred to the shadow repository. Now the shadow system will hold new objects as well as the modified objects. During the SPDD phase, we have to login to the shadow system to do the SPDD adjustments. It is mandatory for the customer to perform the SPDD adjustments at this point of time. The structure that will be chosen as now in SPDD will be taken as into account. This structure activated in the following ACTUPG phase. If SPDD is not adjusted then SAP standard will take as default and customer modifications will be lost. Whatever decision is taken during SPDD phase should be locked in a transport request and the tasks should be released. This request can be re-used in the upgrade of subsequent systems.

After performing SPDD operation in the shadow system, the transport request generated for SPDD will only be re-used in the subsequent systems only if we click on the “SELECT FOR TRANSPORT” . Here we have to mention the SPDD request. The SPDD request will be written into the file umodauto.lst which would be created in the <DIR_TRANS>/bin/ directory.

How the SPDD request is chosen by the tool

During the upgrade in subsequent system, during the phase ADJUSTCHK_PRE , the tool scans the <DIR_TRANS>/bin/ directory for the file umodauto.lst and understand the request for SPDD. The tool scans the request and compares the objects in the request with the objects identified for SPDD. If the comparison is an 100% match, then SPDD is handled automatically with our manual intervention. If there is an object miss-match, then tool will prompt the same and these objects have to be handled manually in SPDD phase. In case is we have not performed the “SELECT FOR TRANSPORT” and identified a request, the file umodauto.lst will not contain an SPDD request. In such cases, the latest version of the tools currently available give us the flexibility to provide a transport request for SPDD at the time of upgrade .

Additional features

In the recent time the SUM/SAPup tools are made very flexible for handling the adjustment modification requests. Let me discuss some scenarios here

1) In some cases the activation of customer objects fail during ACT_UPG phase. The reason behind the failure could be that the dependent SAP structure attributes are changed. Now these custom objects are corrected in the shadow system and a transport request can be generated. Now to save time in the next system upgrade for these objects, we can create a transport of copies by combining the SPDD request with this request holding the corrections generated in the ACT_UPG phase. This request can be manually being given to the tool during the ADJUSTCHE_PRE phase.

2) Some time there could be multiple requests created during SPDD phase. We can use the same concept as I described above to accommodate the requests.

About SPAU

The same principles apply for SPAU. It is created and handled same as SPDD. The only major difference here is SPAU is handled at the end of the upgrade. SPAU can be handled with in 14 days after the upgrade . So after the upgrade, you may choose to import a transport request in to the system in case you have not furnished a request for automatic handling of SPAU modifications during the upgrade. After 14 days, we can handle SPAU but a developer key is needed. It is not possible to extend the time in SPAU as SAP would not support such move to modify some tables to extend SAPU.