Skip to Content

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.

To report this post you need to login first.

24 Comments

You must be Logged on to comment or reply to a post.

  1. Navdeep Nandrajog

    Hi,

    The question is about – SUM tool handling the transport in quality and Production system.

    When we release only the tasks – the SUM tool does not accept the transport, and when we release the transport – and the SUM tool is moving the transport to Quality and Production systems, then the log of the transport is not updated, and STMS queue still shows,.. the transport pending, and we cannot move the SPDD transport later..

    Please suggest.

    Regards,

    Andy

    (0) 
  2. Abdul Hakim

    Hi

    Our BASIS team has applied the support pack in Development system and we(ABAP) have performed the SPAU / SPDD adjustments and captured the changes in a separate Transport request and released the TRs..

    Now our BASIS team is trying to apply the Support pack in Quality system. They are not sure of when to move the SPDD / SPAU transports while applying support pack in next systems.

    Can you please share some insight on this…

    Thanks

    Hakim

    (0) 
      1. Dennis Beausoleil

        Varum,

        My team has created 2 SPDD transports in our development system.  One was not released at all and the second had both the tasks AND the requests released.  Unfortunately, I am discovering this only now in the PostProcessing Phase.  How can I address this??

        (0) 
  3. Dennis Beausoleil

    Varum,

    My team has created 2 SPDD transports in our development system.  One was not released at all and the second had both the tasks AND the requests released.  Unfortunately, I am discovering this only now in the PostProcessing Phase.  How can I address this??

    (0) 
    1. Varun Varma Pinnamaraju Post author

      Upgrade will only take the transport request you furnish during the configuration phase. We can only furnish 1 transport request. If you have 2 requests , u need to merge then a single transport of copies request and furnish it . If you have furnished only 1 tr then if the objects which are part of the second TR and flagged for SPDD , the tool will prompt you to adjust them manually as no automatic adjustment request would be found for them .Now see how this was taken care during the upgrade.

      (0) 
      1. Dennis Beausoleil

        Thanks so much for the reply Varun.

        We are at the end of the post-processing phase (post update activities) of our QAT system now and we are being prompted because there is ‘No SPAU transport imported’.  Neither one of our SPDD transports have been furnished.  Can we manually merge these SPDD transports now?  Will we be prompted for the new merged tranport later in this install or should we restore and start over?

        Looking forward to your response on this.

        (0) 
        1. Varun Varma Pinnamaraju Post author

          I would ask you to read the blog once. It is possible to perform SPAU manually all over or transport the SPAU request created in the DEV system. SPAU should not be a problem. But SPDD adjustments only have to be done in the Pre-Processing phase. At this point of time , If SPDD adjustments are not performed via an adjustment transport request or manually in shadow system in the Pre-Processing phase , the objects flagged for SPDD will be reverted to SAP standard and customer changes will be lost .

          (0) 

Leave a Reply