Imported Authorisation Roles are generating correctly but not taking effect

[martin_E]

I'm after some advice on a problem on an old release - R3 Enterprise on 6.40 basis SP15

I have some functional consultants that are changing Authorization Roles in DEV and transporting them to QAS. When we view the Role in PFCG in QAS, the changes are present and the Role shows as being successfully generated. However, testers are getting Authorisation checks that reflect the PREVIOUS status of the Role. When we check their SU53 output, it shows (for example) that the correct Authorisation Profile, correct Role and correct Authorisation Object is being checked, but the Values shown in SU53 are the old values that were (supposedly) replaced by the import of the role .

1. Creating brand new Authorization Roles in QAS works,

2. It does not appear to matter whether the roles are transported via TMS / CTS or by exporting / importing via PFCG,

3. RHAUTUPD_NEW is running daily,

4. We've tried resetting the user buffer using RSUSR405,

5. We've tried RSET command in SU01/SU10

6. We've ran PFCG_TIME_DEPENDENCY manually

7. We've run SCUL again from the CUA master

8. We've run Function Module SUSR_RESET_ALL_USER_BUFFERS

If it was only one Role having a problem, I'd be inclined to say deal with it. However, there are approximately 850 master roles that may be affected, and the Derived Roles (via Structutral Authorisation) could number in the 1000's. Unfortunately, the implementation team are new to the customer and they can not tell me when the transport of Roles last worked, or if it ever did.

What profile parameters and settings do I need to check ?

What impact could CUA be having on this (I vaguely remember the standard CUA configuration taking a long time (more than a day) to detect and replicate a newly created role.) ?

thanks

[Bernhard_SAP]

Hello Martin,

sounds like a handling problem.

Please try the following:

1. change a role in DEV and generate the profile

2. only afterwards create a new transprot and enter that role

3. import it to QAS and assign the role

4. profile comparison(fo risntance in PFUD

5.test the new authroiaztions

I suppose, your admins updated the authorizations in DEV after they inserted the role into the transport. then auth-changes are not caught in the transport....

b.rgds, Bernhard

[martin_E]

Thanks, Bernhard,

  This was exactly the problem. I've seen this before, and it was one of the first things I suggested. The consultants insisted it didn't matter, and it wasn't till I walked them through the process as you described above that they realized I knew what I was talking about

thanks again.

[Former Member]

Exactly. This is because the keys of the authorizations are entered into the transport when you record the role and not when you release it.

But with 7.41 this has changed and you can also use "locks" on roles which are in transports which are not released yet, so that they cannot overtake each other in the import queues of upstream systems.

Big bummer for composite roles (may the fleas of a thousand camels infest their armpits...) is that a change to a single role locks all composites containing that single role until the tp is released, so you need "golden transports" or you need to transport in shorter intervals (not that that is all bad - I do that anyway).

I will see if I can find my notes on this, but probably Bernhard has lots of Post-It's on his monitor as well.. 😉

Cheers,

Julius

[Matt_Fraser]

Thanks, Julius, that's welcome news, although I'm not sure when we'll actually get to 7.41. "Overtakes" on roles is not too much a problem here, but it does require careful consideration when creating role transports to ensure you haven't missed something.

[Former Member]

See SAP Note 1614407 and the related notes.

ps: It seems they backported it as well to lower releases since I last looked but the connection to tp is porbably kernel dependent and there are also subsequent notes. But on 7.41 it works for sure.

Cheers,

Julius

Message was edited by: Julius von dem Bussche

[Matt_Fraser]

Wow. That is actually already in our system (we're on 7.01 sp13), and I just didn't realize the change in behavior. We've been continuing to treat transport of roles in the old way. Oops!

[varunkumar_pathapati]

Hi,

Process the user master comparison in PFUD and reset buffer in su53.

There may be a chance that consultants are not generating the profiles for the respective roles.

Regards,

Varun.