cancel
Showing results for 
Search instead for 
Did you mean: 

SPDD SPAU

Former Member
0 Kudos

Hi,

I am upgrading R3 4.7 to ECC 6.05, doing a UC conversion and migrating to new version of OS in a new box. Eg: My DEV is copied to DV1, upgraded, and then moved to DV2. This part is done and i have 2 SPAU requests (1 for customizing and another for workbench), and 1 SPDD request. The developer has released the tasks and the request, and most likely did not tick the transport to be used in SPDD/SPAU.  On top, the QA2 system is not in the transport path either as its a copy of the existing QAS. I have the data and cofiles for the 3 requests.

My questions below:

1) I read in Note 68678 that i can only use 1 SPAU and 1 SPDD request, & I am not supposed to use the customizing request. To clarify, is this the way I need to do it? So, when will I import the customizing SPAU request?

2) Can i copy the data and cofiles to QA2, and mention the SPAU (workbench) and SPDD requests when the upgrade prompts?

3) Out of the area question, can i just complete the upgrade and import SPAU/SPDD requests at the last? Will that be ok?

I have checked the link - http://scn.sap.com/message/9062500#9062500, but i wanted to clarify my questions before i import a customizing request and have chaos in production.

Many thanks

Accepted Solutions (1)

Accepted Solutions (1)

0 Kudos

Hi, The idea Ratnajit mentioned is ideal. If you did not follow these steps, or had to move to a different system which is not connected to transport path, you can always do the following :

1) Release your SPDD and SPAU transports from DEV

2) copy the transport files to the new host (new QA) - before upgrade

3) Add the transports to your STMS queue in QA

4) Mention the SPDD and SPAU transports during your upgrade. You can have only 1 transport for SPAU, and one for SPDD.

5) While upgrade runs, you have an option to review the changes made by the transport. So, you know whether your transport got imported or not.

Mehfil

Former Member
0 Kudos

Well, this is what we did, and it worked for us. Thanks

Answers (1)

Answers (1)

former_member189725
Active Contributor
0 Kudos

You can have only 1 SPDD transport request and 1 SPAU transport request. Both SPDD and SPAU are workbench requests , they cannot be customizing requests. When you do SPDD in you DEV system, create a transport request and add all the adjustments made to dictionary objects in the single transport request. Release the task. Then in SPDD , there is an button "Select for transport ". Click it , it will prompt with an option , select the option relevant (either Upgrade/EHP update or SPAM update) . Then select the transport request.

Do the above for SPAU as well. Make sure you have only 1 transport request each for SPDD and SPAU. After you do the above , the SAPup would release the 2 requests and put the transports in a file umodauto.lst under /usr/sap/trans/bin

The next upgrade will search for SPAU and SPDD transports from this file from the same location /usr/sap/trans/bin. Make sure you copy this file umodauto.lst to the location /usr/sap/trans/bin if you have different transport directories along with the data and cofiles. If you have same transport directory , you are good to go.

You cannot import the SPDD and SPAU requests at the last . The best practice is to bind them to the upgrade. For SPAU you can import the request when SPAU adjustment phase is reached but for SPDD you will have to bind. Better follow the best practice of binding both the requests to the upgrade.

Regards

Ratnajit