When to apply SPAU changes in succeeding sap servers?

[Former Member]

Hi,

We have finished applying patches in our development server and we have some SPAU trnasports generated. Now when we apply the patches in the Test server, when is the right time to import the SPAU transports?

should it be

(a) before the patch?

(b) when SPAU is prompted?

(c) after the patch queue is confirmed?

thanks,

kbas

[paul_power · Accepted solution]

Hello Kbas,

Here is an overview of the procedure to perform modification adjustment

in the transport landscape when importing support packages.

Development system:

- apply the support packages on the development system until you run

against the RUN_SPPD or RUN_SPAU step

- developpers call transaction SPDD or SPAU, modify their objects and

release their tasks.

separate SPDD and SPAU transports because they have to be imported at

different times (SPDD transport after the DDIC import of the queue and

SPAU transport after the main import of the queue).

One should not collect the modifications of several SPAM queues in one

modification transport, except one plans to apply all the Support

Packages of the several queues in one big queue.

- you finish SPAM by ignoring the RUN_SPAU phase

Quality assurance/production systems:

- apply the support packages on the next system where SPAM might stop

in RUN_SPDD step, leave SPAM

- Import the SPDD transport (you might face activation errors during

this import, because it's possible that the DDIC objects from this

transport refer to DDIC objects from the Support Packages which are

not activated yet)

- start the SPAM queue and ignore the RUN_SPDD step

- if SPAM next stops in the RUN_SPAU step, ignore it and finish the

SPAM queue

- Import the modification adjustment (SPAU) transport

I hope this answers your concerns.

Best regards,

Paul

[Former Member · Accepted solution]

Thanks Paul.

[volker_borowski2 · Accepted solution]

Hi,

sorry, but this is NOT correct.

Importing a SPDD Transport manually CAN destroy your system

in normal mode and it WILL destroy your system when in downtime

minimized cenario, because your manual import will not be fed to

the related shadow tables.

You MUST either include your SPDD transport to the queue

or do it manually (as it has been required before SPAM was able

to include an adjustment transport).

Volker

[Former Member · Accepted solution]

Dear All,

am into the same phase.

what is the standard & correct way. should we import the transport created during Support Pack in DEV or should we do manula correction.

am little bit confused with the answers of Mr.Volker & Mr. Pal.

kindly suggest.

Regards!!

[Former Member · Accepted solution]

Hi Paul Power,

Your post is very helpful to me.

I have one more doubt here.

As you told

- Developers call transaction SPDD or SPAU, modify their objects and  

    release their tasks.   

Only the tasks should be released and start the SPAM or TR should be released and then start the SPAM ?

[former_member230888 · Accepted solution]

Hi All,

the correct way to hadle modificaton adjustments is as follows.

1) You are applying SP's in your DEV system.

2) It would stop at SPDD. Now perfrom the SPDD and lock the changes in the SPDD transport request(TR).

3) In the same SPDD screen, click on the button "SELECT FOR TRANSPORT" . The button may change in systen with higher release. It would be "ASSIGN TRANSPORT".

4) Once this button is clicked, assign the transport and click the tick mark. It will ask you the transport is for SP import or upgrade. Click on SP import.

5) Now the intresting part is once this transport is assigned as SPDD here, a file called umodauto.lst will be crreated in the <DIR_TRANS>/tmp directry with an entry for SPDD transport request. Same should be donw wth SPAU tr also.

6) No finish off the SPDD in DEV

7) I n QAS when you will be defining the queue , then you will be prompted to include the adjustment modification request . Now you will have only the option to slect the TR which the SPAM tool would read from the   umodauto.lst file. Includue the TR .

😎 Your SPDD adjustments will be automatically handled in QAS.

Never import a TR at SPDD phase in a QAS system. This will damage the SPAM tool internally.

SPDD should be hadled or automatically adjusted when it is prompted. If skipped, then the customer modifications will be lost completley and SAP standard will take over. SPAU can be handled after the upgrdae or SP activity.  SPAU will incluse repoositary objects .So we can juggle with the versions as version management is present . So nothing is lost.

If you want to know how to handle modifications during the upgrade , check the link

http://scn.sap.com/docs/DOC-44106

i will create one for SP import also shortly.

Cheers,

Varun.

[Former Member · Accepted solution]

hi volker can you please elaborate a little more into this? as it is contrary to the thread owner best answer, i want to know what is the correct approach.

thank you

JK

[former_member183044 · Accepted solution]

Hi Paul,

// Import the modification adjustment (SPAU) transport//

Can u please explain how to do this?

Regards

Praveen

[Former Member]

Hello Varun,

The scenrio that you mentioned - does it hold good only while using SUM or is it the same for SPAM/SAINT as well. In our client environment, we added the SPDD transport number when it prompted in SPAM, but it was not imported automatically. Manual import (using STMS ) had to be permformed.

If the SPDD changes are already captured in a TR and the TR is added in SPAM, shouldn't the adjustments be automatically applied by SPAM or SAINT tool? Or doesn't the SPAM/SAINT tool have the capability ? Any idea ?