Role transports - strange behaviour which I would like to understand

[arpan_paik]

Dear All,

I have seen that after capturing a role, make any changes then without recapturing the role again released. This transport all the update made in that role after capturing the role. Surprizingly the CTS does not show updated table entries for changes made after role capture. But in target system it move with all the update.

SNOTE 571276 also say that recapture is required. But practically it is not. Is there anything I don't know. Well I know there is something. What is that?

Dear Moderator : I know it could suit in playground the most. But there I might not get attention for all security guys. Sorry to post here.

Regards,

Arpan Paik

Edited by: Julius Bussche on Feb 2, 2011 2:24 PM

Subject title improved

[Former Member]

Hi Arpan

I'll risk appearing in the playground with you...

I've never really trusted the transport message as it does seem to move all changes up to the release step.

Bring a bat and ball...

Cheers

David

[Former Member]

Take a look in the FAQ sticky thread for infos related to transporting roles. Keep a special eye out for what happens when you release the role which is what is confusing for many people. Actually most people do not even know about this nor notice it.

A symptom is often that they need to regenerate profiles in the target systems "because the CTS does not always work" ... which is bollocks...

Cheers,

Julius

[arpan_paik]

Dear David,

 I've never really trusted the transport message as it does seem to move all changes up to the release step 

This is what I thought is wrong so far. But it is the case :-). And more over the TR details (table entry) is misleading

Yeah Bat & Ball...Let's play. Anyway world cup is almost close.

Dear Julius,

I have captured the role with profile (old version). This what the SNOTE says.

 a) Changing the authorization data for the role
Every time you change the authorization data of a role and regenerate the profile, you must create a new transport request. This is also the case if the role is part of older requests that have not yet been released. Otherwise, the transported profiles are not current. 

So ideally the new profile (Edited : Means updated profile) should not be transported. Regarding profile generation in target system, it say below.

 You can also transport the roles without profiles (see above). In this case you must regenerate them in the target system after every import. 

This I never tried.

Am I missing something in this note?

Regards,

Arpan Paik

Edited by: P Arpan on Feb 2, 2011 8:32 PM

[Former Member]

When you change the menu or role data and generate the profiles, it does not change anything in existing transport requests.

When you (re)record the role into a transport request, the system will load the profile related data (USR* and UST* data) into the transport requests at the time of recording into the request.

When you release the request, the system will not add the existing profile data again (so any changes are not included) but will now only add the role related data (AGR* tables) to the transport file.

--> Before releasing, they will look different.

If you make changes to roles entered in transport requests, then you MUST re(record) the role into the request before releasing it.

You can also transport the roles without profiles (see above). In this case you must regenerate them in the target system after every import. 

This is like the silly-mid position in cricket. It is only for those who are fearless, very fast, well insured and somewhat naive... Certainly your SU24 settings must be perfectly in sync throughout the system landscape.

Cheers,

Julius

[mvoros]

Hi,

it's important to understand how customizing transports work.

the system will load the profile related data (USR* and UST* data) into the transport requests at the time of recording into the request.

This is not exactly true. When you add a new record into transport then it contains a primary key that identifies the record. When transport is released SAP reads record from DB using primary key and values at time of release are transported into target system. Therefore the system loads only primary keys into transport. That is the confusing part. According to this description transport of roles after change should work because the values are read when transport is released. The problem is that profile might contain new records and records might be in different order. The program for transporting roles is really simple. It reads all related records to role and it adds primary keys of each record into transport. After re-generating transport these records are deleted and generated from scratch. Hence you get into troubles if you don't update primary keys in your transport.

Cheers

[Former Member]

it's important to understand how customizing transports work.

I'll raise you a six pack, 2 cuban cigars and one Panama hat that it is selectively different for roles...

Take a carefull read through this context --> [I didn't always know this difference with role transports either, and had to learn the hard way via lots of irrate helpdesk calls|] and the notes mentioned.

If this were not the case, then you could not delete roles selectively and SAP would not have to clean up orphaned profiles A.S.A.P!

Cheers,

Julius

[mvoros]

I don't see how the note contradicts my description. I agree with you that you have to create a new transport after modifying role (point 1a in that note). What I am just saying that it does not load complete records into transport. It loads only primary keys into transport and these keys are changed after modifying role. Hence you have to create a new transport.

Cheers

[mvoros]

Update. I think we are both right. I just checked UST12 definition and all fields in this table are part of primary key. Hence loading primary key only and loading all values into transport is same thing. In that case the values are loaded when role is added to transport. I still think that my description is more precise

Cheers

[Former Member]

Take a look at:

a) What happens when you release the transport. (a.k.a. what is visible in the target system).

b) After import eventsin the target (.e.g. profile name collisions, objects do not exist yet, value ranges are incomplete,etc).

Roles are a hybrid of customizing, repository objects, master data and application data plus some kernel logic.

The transport tool reflects this nicely in the SAP note - just try it out and read it carefully.

You can tune it a bit in table PRGN_CUST - particularly the "application data" part --> transporting user assignments and blocking certain objects.

Cheers,

Julius

Edited by: Julius Bussche on Feb 3, 2011 12:40 AM

[Former Member]

okay

In the words of Lelu Dallas (Fifth Element) WOW!! Even the seemingly basic steps in SAP are complex...

Let me see if I get this correctly? (Col. O'Neil - Stargate - shoot until all dead and then ask questions mode)

Change a role (i.e. add a transaction which adds a new object (optional))

Add to a new transport

Then think - bugger I needed to add another transaction to that role - add in PFCG which may (or may not) add a new object

From what I have followed we need to then re-add that role to its existing transport before releasing?

If it's as simple as that then I'm a convert and will always re-add the role before releasing the transport.

Cheers

David

Two cubans and a panama aren't enough - add a bottle of Jamiesons

Edited by: David Berry on Feb 3, 2011 12:05 AM

[mvoros]

David,

usually, what I do is that I create a transport when I want to release it to avoid this issue.

Cheers

[Former Member]

Also see question # 27 in the interview questions sticky thread.

Cheers,

Julius

[Former Member]

Looking at the answers given it seems I'm not alone in thinking it's okay to make changes until the release step and then the barn door is shut.

Looks like the horse already bolted now - I'll change my way of working and create a new transport if a subsequent change is needed to a role.

Cheers

David

[arpan_paik]

Drelease the CTS is reading data from DB (from long time thought to learn ABAP, just missed everytime :-(. Else I could have better understanding on what is happening.

When I gave it a try in sap system (before posting this thread) then I found that the role migrated was same in both the system (source & target) though I did not recapture the role in CTS.

Still sap advice to recapture the role as to keep the CTS data up to date. However in executing I did not found any difference. Few days earler my habit was to recapture the role each time I do change. But now I don't do that sometimes (when I don't feel to). Still it is working.

Pardon my ignorence to the sap note but it is working. By the way I never capture role without the profile.

Regards,

Arpan Paik

[Former Member]

Still it is working.

No it's not.

The roles will look the same and feel the same on the surphase (menu and authorizations tab) but the one in the target systems DEV and later PROD will have the old profiles transported with it unless you re-capture the role into the transport request before releasing it .

This is the most common cause of the phenomena that sometimes you have to regenerate the profiles in PROD because they mysteriously are not working...

Cheers,

Julius

[arpan_paik]

Humm.... That means old is good. And I was following right thing so far. However i shall check back in the system to see the difference in underlying authorization.

[Former Member]

I am always impressed when people notice this little feature, as you have.

Those who try to defy it typically end up maintaining their roles directly in production in the end because they have no clue where what is going on anymore when they transport out of sequence and profile name collisions block the correct profiles anyway. See the section on table AGR_NUM_2 in the same SAP note.

This is particularly accute for single roles built at individual task or process step levels, or as building blocks... and then clubbed together into a myriad of combined composite roles or confusing menus with unintuitive transaction codes.

You might as well have still been using composite profiles as they have the same survival chance as composite roles.... --> Fools, the system will destroy them all!

Cheers,

Julius