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: 

What is SAP best practice for SU24 "no check" indicators

Former Member
0 Kudos

Hi Experts,

Let's say during testing if we find a t-code needs some authorization objects for end to end execution, and those objects are maintained as "CHECK" "NO" in USOBX_C.

Please suggest the best practice...

Should we change the proposal in USOBX_C to "CHECK" "YES" and populate specific values in USOBT_C or we can insert those authorization objects manually in the roles without changing proposals??

As far as I know, it makes upgrade activities more difficult when there is more customization in these tables....However manual insert of auth objects are not impacted during upgrade and also any SU24 maintenance of custom t-codes.

Thanks,

Deb

Edited by: Julius Bussche on Feb 8, 2012 10:31 AM

Subject title made more meaingful.

4 REPLIES 4

arpan_paik
Active Contributor
0 Kudos

Hi Deb,

If the "check no" is affecting lot of task (business process or roles you can say) then it is good to change SU24 change indicator. But if that particular check is affecting very small part of task and other task for the same transaction is good without that then a manual approach is better.

During upgrade there will be some task on step2B. And to make changes customer table has been introduced as SAP probably knew that their standard definition might not be same for all the organization.

Edited : In latest version upgrade SAP standard changes been automated in STEP 2A itself so that is a relief during upgrade.

Regards,

Arpan Paik

Edited by: P Arpan on Feb 8, 2012 4:42 PM

Former Member
0 Kudos

Normally there is some thought which went into the "no check" flag so you should put some thought into it before testing it to turn it on. It might force you to grant access for that transaction context but have the implication that in other transactions the user can access too much again.

There are however some authorization objects which were added with support packs with this "no check" in the hope of adding the authority-checks into the code to make them possible, but deliver them as backward compatible with existing roles. This is a work-around for not being able to deliver it as deactivated globally in transaction AUTH_SWITCH_OBJECTS.

You can find the candidates by sorting the + 12k entries in USOBX_C by object name and finding those which were dealt with in a very liberal way. Check the docs and OSS notes for them.

Other than that I can only say that a best practice which I believe in is to remove some of the odd things in SU24 immediately after the installation. This means that you later (and as required) only need to add proposals and checks. That is much less error-prone than removing proposals and checks again!

Cheers,

Julius

0 Kudos

Hi Julius,

Thanks for your inputs,

But I was wondering if there is anything called SAP Best Practice when it comes to changing Proposals.

I believed, it is not wise to touch SU24 unless we have the following scenarios:

1. Mapping of Custom t-codes to auth objects or custom auth objects to t-codes.

2. If a standard t-code is used in many roles and that t-code checks for quite a lot of auth objects which have proposal NO. In that case, for our simplicity, we can turn ON Proposal and populate values there, so that effort of inserting many objects manually in many roles can be subsidized.

I am seeing scenarios where SU24 is changed very frequently for each and every t-codes and auth objects it checks, with an intention that no role should have manually inserted auth objects, which I feel is not very correct and Best Practice...What do you think??

0 Kudos

SU24 is an artform as you should add meaningfull proposals to minimize the manual authorizations as much as possible.

BUT... you should not over-do it and then have to start setting proposals as inactive again in other roles. This is particularly accute as there is no "unmerge" function after the authorization instances have been merged.

No manual authorizations is a very ambitous target and there is nothing wrong with that at all IF it is done carefully. If you can still survive an upgrade in about 1 day of work in SU25 then you know that you did a good job to find the balance...

Cheers,

Julius