Transaction Missing

[Former Member]

Hi All,

I have a typical issue in my ECC system.

In June i have added a Customized transaction to a master role and derived to all the child role and moved the changes to QAS, tested and then moved to production. Everything was working fine since then for the user.

Suddenly the user reported saying he could not access the transaction.

I have check the role now and surprised to see that the transaction is missing in the master as well as the child roles.

I have checked to see if any change documents for the role. But could not find anything.

Strangely i have noticed that the role came back to the same status to which i have done modifications in June.

Please share your knowledge on how to find the root cause for the issue.

Thank You all for your responses.

Best Rgds,

Jaravuy

[jurjen_heeck]

Any chance an older transport request holding these roles has been re-imported?

[Former Member]

Sounds like an old transport overwriting your change - check tables E070 and E071

[Former Member]

Please let me know how to check the tables E070 and E071 to get if any other Transport request contains these roles?

[Former Member]

Start with table E071, and enter the affected roles in the "Object Name" field. In the "Object Type" field,  enter ACGR, for roles.

When you execute that you'll get a list of transport requests / tasks that contain your roles (the list might be quite long depending on how many times the roles have been transported in the past. If you have a lot of roles, you could probably get away with just checking the master parent role in this case, so you have less output to worry about).

Copy the list of transport requests / tasks, and enter them in the Request / Task field of table E070.

This will show you - among other things, the release status of the requests, and the date they were imported. You should be able to see your transport in which you added the new custom transaction. If there is another request that has been imported after this, but with an older sequential request number, that's your culprit.

[Former Member]

You can do this search directly in SE10. Hit the hammer/spanner icon on the toolbar and choose "Search for Objects in Requests/Tasks". Then search for object type R3TR/ACGR, and the role name. That should show you all of the requests that include that role.

Steve.

[Former Member]

Good point Steve, thanks - or you can do it directly in SE03 if you don't have SE10

[Former Member]

Hi

Thank you for your patient response.

I have done exactly the same way you have told me.

I found only one request after my request was imported on 21.05.2012.

But the sequential request number is not an old one.

DM1K964417	W	R	/ALL/	CUST	21.05.2012 13:40:20
DM1K965985	W	R	/ALL/	CUST	19.09.2012 15:11:44

When i check the authorization tab for last changed On/by it shows 30.08.2011.

Now i'm back to were i started.

Any advise.

[Former Member]

I always treat digging through tables as a last resort - with the complications of SAP's table structures it is either too hard/long a job, or too easy to miss something, or both.

I didn't know about SE03! 14 years using SAP and I'm still finding transactions I didn't know about

[Former Member]

Steve Rumsby wrote:
I'm still finding transactions I didn't know about 

I think that applies to all of us

[Former Member]

Very good comment (about tables) Steve!

Note that it is not just the release and import dates / sequence which is important for roles. The profile data is recorded into the TP only once and that is when you select the role in PFCG and add it to the transport (again).

When you release the transport, only the AGR* table data of the role is recorded into the Transport again, not the UST* generated profile data.

Cheers,

Julius

ps: One of my alltime favourite interview questions is: What is the difference between SE09 and E10?  😉

[Former Member]

Just to check the obvious - could anyone have made a change directly in production?

Does anyone have upload authorisations?

[Former Member]

In that case there would have been change documents (unless those were archived...).

Transport (recording) sequence is more likely IMO and common cause.

Cheers,

Julius

[Former Member]

I was thinking that Jaravuy might have checked the change docs in Dev only. But yes, I see your point on the recording sequence, and it is definitely more likely

[Former Member]

yes, i have checked changed documents in dev, qas and prd.

But in change docs i could only find the change that i made in may.i:e; adding the transaction.

that too i can find these changes only in dev system.

no changes done in prd directly,

No upload either, because the role has the same profile in 3 environments.

[Former Member]

If the tcode is still in the menu in PROD, but the user is not authorized, then the profile is probably old.

Another possibility is that the role on it's own is not enough to start the tcode and use it, and some other role has some additional required access and that one was removed from the user's assigned roles (or manual profiles).

For this reason (to prefevent "surfers") you should test roles when only that role is assigned. They should ideally be able to survive on their own. This way you also have more robust roles and less of them and they are easier to find when requesting access for a certain job and not a certain tcode.

If you join my company and the request form says "Same access as Julius please" instead of being able to easily identify a small number of roles for your job, then I am a looser..  🙂

Cheers,

Julius

[Bernhard_SAP]

Julius von dem Bussche wrote:
Very good comment (about tables) Steve!
Note that it is not just the release and import dates / sequence which is important for roles. The profile data is recorded into the TP only once and that is when you select the role in PFCG and add it to the transport (again).

In such cases it is useful to check the Action Log of the transport (if activated) (display transport->menu->Goto->Action Log showing the time stamp when the transport has been created.

Improved of course with note 1614407....

b.rgds, Bernhard

[Former Member]

Hi Jaravuy,

One of the most common issue faced by any security admin. Your changes in the roles may have probably owerwritten by some old change.

Goto SE03 

click Search for Objects in Requests/Tasks 

Select object type R3TR/ACGR  provide your parent role in text field against it

hit search

This will enlist all the transport created for the role including yours. Check transport logs of few transports above your TR (old TRs) one by one, after few hits you will find one (former) TR which was imported after your (later) transport which is the culprit.

Solutions:

1. You create a fresf TR from Dev for all roles and move it to PRD asap
2. You can get your TR reimported again to PRD if no other transport for the same role(s) has made it to PRD since your TR`s last move to PRD

Hope that helps.

Regards

Amit