Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

SU25 after an upgrade - should you complete step 3?

Former Member
0 Kudos

Excerpt I found that helped somewhat

You must perform the following steps after an upgrade, if you were already using the profile generator before the upgrade.

u2022 Choose steps 2A to 2C if you made a large number of modifications in transaction SU24 in the last release. Step 1 (Initial Filling of Customer Tables) should only be executed in transaction SU25 if you made no changes in transaction SU24 in the previous release. The system overwrites tables USOBT_C and USOBX_C (Customer u2013 or our custom objects) when it executes step 1, and the values that you maintained in the last release are lost. In steps 2A and 2B, a synchronization procedure is performed.

My question is about transporting in Step 3, exactly what does it transport, I believe these two are a given

USOBT_C

USOBX_C

but our BASIS person thinks these may go as well

PRGN_STAT

TCODE_MOD

Do we want to create a transport in DEV and move to QA/PROD, or just run the steps 2A to 2C manually in QA/PROD?

What is best practice? thanks

1 ACCEPTED SOLUTION

Former Member
0 Kudos

In an initial task (before any of the 2 or 3 steps in SU25) you should verify that the system's SU24 data is in sync (Do not run step 1!). Release all transports relating to it through and if need be synchronize them manually after consolidating what is correct. Also check in tcode AUTH_SWITCH_OBJECTS whether anything is globally OFF or inconsistent in the landscape. Believe me... these steps are worth while to do!

After step 2 (be carefull in 2b if you have made many changes! Do not mass accept the "SAP file" otherwise your job in 2C will be hell...) you should run step 3 to transport the new entries through the landscape.

This will also transport PRGN_STAT to let the other systems know that PFCG was upgraded and TCODE_MOD so that if you do happen to have other roles being maintained in QAS or even TEST then they can be upgraded there as well - because they will only exist there usually.

Do NOT run SU25 steps in QAS or PROD. You do not need to and this will very easily toast your roles, check indicators or turn everything red all over again...

Cheers,

Julius

Edited by: Julius Bussche on Sep 28, 2010 10:52 PM

(Do not run step 1!) added, just incase some basis admins find this thread

6 REPLIES 6

Former Member
0 Kudos

In an initial task (before any of the 2 or 3 steps in SU25) you should verify that the system's SU24 data is in sync (Do not run step 1!). Release all transports relating to it through and if need be synchronize them manually after consolidating what is correct. Also check in tcode AUTH_SWITCH_OBJECTS whether anything is globally OFF or inconsistent in the landscape. Believe me... these steps are worth while to do!

After step 2 (be carefull in 2b if you have made many changes! Do not mass accept the "SAP file" otherwise your job in 2C will be hell...) you should run step 3 to transport the new entries through the landscape.

This will also transport PRGN_STAT to let the other systems know that PFCG was upgraded and TCODE_MOD so that if you do happen to have other roles being maintained in QAS or even TEST then they can be upgraded there as well - because they will only exist there usually.

Do NOT run SU25 steps in QAS or PROD. You do not need to and this will very easily toast your roles, check indicators or turn everything red all over again...

Cheers,

Julius

Edited by: Julius Bussche on Sep 28, 2010 10:52 PM

(Do not run step 1!) added, just incase some basis admins find this thread

0 Kudos

Thanks this helps immensely!

0 Kudos

For more background why I mentioned first checking the consistency, please see this thread:

Particularly the SAP Note mentioned by Bernhard is very usefull as a tool, instead of working out the huge tables.

I would additionally also check table TOBJ_SAV. If you have any entries in there, then you certainly have a "global" inconsistency (though the table is client dependent).

If you do want to run SU25 in different systems (technically of the transport group(s)) because roles are maintained there locally then you have to be very disciplined and know which role has which source.

You must sync the tables and ensure that all previously upgraded roles remain "green" (so your transport sequences are also important!). This is no easy task and very error prone.

Cheers and good luck with the upgrade,

Julius

0 Kudos

Hi Julius,

Thanks for the detailed explanation.

I have one doubt over STEP 3 of SU25 where I need your expert views.(EHP 4.0 to EHP 6 ECC 6)

We have performed the SU25 steps(Only 2A,2B and 2C) and follow below approach:

1. After running above steps we make changes in role manually and capture them in TR.

2. Changed SU24 manually and stor ethem in TR.

3.Move SU24 Tr and Role Tr in quality.


Question is we did not move Step 3 transports and testing is completed in quality is it wise to move Step 3 transports and sync Quality and Dev. now or it will create Impact which required tetsing?

0 Kudos

Now isn't a good time to sync them up while they are in Quality

0 Kudos

Thanks for reply,

After lots of analysis and research(Comparing table dumps Dev. & Quality) I concluded that there is no impact as upgrade role analysis and change in Dev. is done using Dev. data(customer table) and moving same changes should not impact roles in quality and if it impacts then there is analysis error not impact of moving customer tables.

After moving them to quality  completed 1 system analysis with no impact