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: 

SU22 - Issue

Former Member
0 Kudos

Hi,

Good day!

SAP: ECC 6.0 (Upgraded from 4.7 EE)

I need your help to gain understanding over SU22. I did a little research on this topic and hit one of the posts which stated that SU22 values are not for customers to edit but for SAP to update. I understand that the SU22 values directly relate to the tables USOBT and USOBX and on executing SU25 the values from these 2 tables are copied over to USOBT_C and USOBX_C which can further be tailored for the customer's requirement using SU24. The profile generator uses the proposals in SU24 to present the relevant authorization objects while creating a role.

QUESTION:

- Are the tables USOBT and USOBX updated by SAP using different support packages in the event of any security related updates?

- If so, should we import the new values updated by the SPs to the customer tables(USOBT_C and USOBX_C) using SU25 and we later edit the new authorization objects in SU24?

-Are only the new values included in the SPs are transferred to the customer tables while we execute SU25 or are all the authorization objects transferred and we end up re-doing the customization in SU24?

Thanks for your time!

Cheers!

4 REPLIES 4

Former Member
0 Kudos

You are on the right track.

If you read the documentation (and popups) in Su25 then it will be clearer for your doubts. Also see the FAQ thread at the top of the forum.

What I can recommend additionally taking into is the difference between "Original" data and "SAP" data in SU22. It is generally unlikely to find real "Original" data in SU22 on release 4.7 (see the documentation in RZ11 on parameter auth/authorization_trace) but some SAP data was not always "anonymized" and the system interprets this to be from the customer's own trace. Depending on which 4.7 basis SP you are on, you should consider this and fix it before the upgrade.

If you have made use of SU24 to tweak the proposals from SAP, then I also recommend checking the Sticky thread posted by Bernhard Hochreiter.

There are also other tables in addition to USOBT and USOBX - if you want to use the table display route. This is particularly usefull if you want to synchronize your landscape for the settings - something which I can also recommend checking before the upgrade....

After the upgrade procedures, you can also make use of table TCODE_MOD and PRGN_STAT.

> To have an impression, of which/how many t-codes are affected, you can get this information in your system directly, after you have started SU25->step 2a.

--> http://wiki.sdn.sap.com/wiki/display/Security/BestPractices-HowtofindTCodeschangedafterupgraderegarding+SU24-data

The tables have been around for a while already, but are not well known.

Cheers,

Julius

0 Kudos

Hi Julius,

Thanks for your reply. Pls correct me if I am wrong.

1) Use of SU22: The tables USOBT and USOBX are updated by SAP using SPs. Once the authorization changes are in the tables USOBT and USOBX, we can use SU22 to edit them and later transfer them to USOBT_C and USOBX_C. Therefore, eliminating the need to maintain proposals using SU24.

-


In our dev system, there are a few t-codes for which there are no SU22 values but we have authorization object proposals for these t-codes in SU24(Which were maintained by us). Should we ensure that SU22 and SU24 entries are synchronized ?

Thanks for your time.

Cheers!

0 Kudos

> Pls correct me if I am wrong.

You are on the wrong track now. Please read the documentation!

1) Use of SU22: The tables USOBT and USOBX are updated by SAP using SPs. Once the authorization changes are in the tables USOBT and USOBX, we can use SU22 to edit them and later transfer them to USOBT_C and USOBX_C.

No. Never touch SU22. At most you can collect original data from it and transfer it to SU24.

You should only ever change Su24.

> Therefore, eliminating the need to maintain proposals using SU24.

Thereby creating a big mess!

> In our dev system, there are a few t-codes for which there are no SU22 values but we have authorization object proposals for these t-codes in SU24(Which were maintained by us).

Good.

> Should we ensure that SU22 and SU24 entries are synchronized ?

No.

You need to concentrate on the fields indicating the modifier (SAP?) and the modified date. That is what SAP does so that it knows what to suggest to you in Su25.

> Thanks for your time.

Please spend some of your own to read the documentation before making changes.

Cheers,

Julius

Edited by: Julius Bussche on Apr 5, 2010 7:23 PM

0 Kudos

Hi Julius,

Thanks!!