SU24 gone!

[Former Member]

Hello Gurus ,

As i was working on Friday i noticed while i was performing a role change , that the role had many missing objects. From further analyze i realized that the values and the objects mapped to Transactions in SU24 where deactivated. Except the values of the custom Transactions which were not changed.

We have SAP R/3 4.7 with three systems : Development , Quality and Production . SU24 is only maintained in Development and all role changes as well , after they are transported in Quality for testing and finally in Production.

Unfortunately i didnt had a copie of the SU24 and now we want to make a restore of the tables USOBX_C and USOBT_C from our database which is Oracle 10.2. Cant go in any details in this field since i am not the dba.

I think the Su24 was changed because of Enterprise Role Management (GRC 5.3) which was currently installed and setup . Did any one had this problem before ?

Until we can restore the Su24 we cant do any role changes since no objects are assigned to the SAP stadard Transactions. I suppose an alternative solution is to Initialize Su24 with SU25 and get back the stadard values . (But not permanently since i dont know if any changes where done in the past in SU24)

But important for me is to find the cause , we dont want to have this problem again since it has a big impact. Ofcourse next time there will be a backup from Su24.

Cheerz ,

david

[Former Member]

Hoh! That sounds strange.

Probably the best route to take (if you always transported to QAS) is to synchronize the SU24 from QAS back to DEV as these should be (or should have been) in sync anyway. There is an upload / download tool described in [SAP Note 1265929|https://service.sap.com/sap/support/notes/1265929].

I have forwarded this to one of the other moderators from SAP to take into:

> I think the Su24 was changed because of Enterprise Role Management (GRC 5.3) which was currently installed and setup . Did any one had this problem before ?

Cheers,

Julius

[Former Member]

Hi Julius ,

thanx for your fast reply . Unfortunately the Su24 was maintained only in our DEV system . I am not really sure why the changes where not transported in the other systems..but know i see the impact .

The download upload tool i also descovered on Thursday when we had the problem ..so i know for next time what to do.

As i said..i am not sure if the ERM was the cause to losing the su24..hope not .

Cheerz,

david

[Former Member]

Ahh... I initially understood that you had transported the SU24 changes as well.

In that case, if you are lucky, then the application table logging has been active in this development system. Check param rec/client in RZ11 to see whether it has the value 'ALL' or at least the client from which you have been making these changes is listed.

If so, check in SE13 whether table log is active for USOBT_C.

If so, then you can recover the changes from tcode SCU3.

Otherwise, a restore from the DB will be the only other option I can think of, in addition to DB audit logs on the tables if kept for such a long time.

Cheers,

Julius

[Former Member]

That was a really good information , but unfortunately the logs for this table were not active .

Another possibility would be to check the Virsa tables of the ERM . Maybe the SU24 values are still there and i can export the table values and upload to SU24. Any ideas how i can lookup the java virsa tables ? or specific the table with the SU24 values ? then i could use the CC debugger to export it with SQL .

Cheerz,

david

[Former Member]

Hello Julius,

as i am currently analyzing the problem i just find out with transaction se16n on the table USOBX_C that one extern colleague did somehow make the change in SU24. Its a mass change ,because its within the same time.

You can see the transaction name , the Type , Auth Object , Changed by, date , time checkflag and the name . But not the values , only the objects , so there is still information missing .

Talking with my supervisor i found out that our Su24 was never really maintaned..so the solution just to initialize over SU25 and upload the rest Z* transactions seems correct .

In addition i could compare some fields from ERM table to the SU24 in R/3 and transport the tables to all systems so we always have a "backup".

Thanks again for the good support

greets ,

david

[Former Member]

Hi David,

Is there any info on the changes in table USOBT_CD?

[Former Member]

Hi Alex ,

thanx a lot . I can see which objects where changed and their values. This is good. So when i initialize the SU24 , i can see differences between the new SU24 and the history and perform the changes so we are in the same point like before.

[Former Member]

This is an interesting problem. Our present design is also SU24 changes in DEV only and not transported to QA & PROD. Our reasoning was we don't want anybody making changes directly in QA or PROD, we want security transport instead.

We might have to revisit our current process and make some adjustment to avoid this situation. I'm interested to find out the resolution.

[jurjen_heeck]

I think your fastest safety net will be to regularly download the relevant tables. SU24 has a download/upload facility for this.

[Former Member]

>

> I think your fastest safety net will be to regularly download the relevant tables. SU24 has a download/upload facility for this.

I just tried it and it works! Sorry to go off topic, I'm not trying to hijack the thread. I wish I can give you points for this Jurjen Thanks.

[Former Member]

>

> I think your fastest safety net will be to regularly download the relevant tables. SU24 has a download/upload facility for this.

That would mean regularly having to open the client for changes as well.

SU24 is "development work" and should ideally be done together with "development of the application coding" by the developer. Particularly if the developer decides to use authority-checks which for specific contexts are turn off, then you will have to keep SU24 in sync otherwise the application won't work (or at least, not work as designed by the developer).

The note which I mentioned above clearly intends to promote and restrict the same...

Cheers,

Julius

ps: Another thought I had: If someone did a mass upload and wiped your SU24, then they (hopefully) did a download before that. Try to find that file on the users PC or network drive where they might have kep the original. Just a thought.

Edited by: Julius Bussche on Feb 23, 2009 7:52 PM

[Former Member]

Hi Julius,

i think the person that cleared the SU24 didnt do it in purpose and therefore no backup exists .

I will talk with him when he arrives later .

Until now i initialized the SU24 and uploaded the Z*transactions , which were not touched , and with a cross check over table USOBT_CD and USOBX_CD i will maintain the objects . There are around 580 transactions ..so plenty of work .

Too bad that there is so less information overall .. but good that i get ideas and solutions from the forum

@John : The second post in the thread already mentions the upload / download function So just a backup from there is enough. But i will transport anyway these tables to Q and to Production.

cheerz ,

david

[Former Member]

> i think the person that cleared the SU24 didnt do it in purpose and therefore no backup exists .

> I will talk with him when he arrives later .

Of course if the external (and all others) who are not trained to use SU24 nor intended to make changes to it were also not authorized for it, then this might not have happened...

Sorry for not resisting the temptation of being a "smart ass"

Cheers,

Julius

[Former Member]

The SU24 has been fixed . We created a custom program in the Development system which could upload the data in the tables USOBT_C and USOBX_T.

We based our upload file on the Change history (USOBT_CD and USOBX_CD) of the objects and the transaction . Ofcourse the change logs where modified so it matches the USOB*_T tables .

Until now everything is smooth and working fine

Edited by: David Damaskinos on Feb 25, 2009 1:44 PM