Difference between SU24, USOBT_C and USOBX_C. Plz Honestly reply.

[Former Member]

Please do not lock or delete without providing valid answer.

I have searched through this forum , but could not find. So, i have posted this. Please do not give vague excuses.

[jurjen_heeck]

SU24 represents the contents of the two tables you mentioned and lets you edit them.

Honest.

Now please tell me why you wanted this information.

[Frank_Buchholz]

All of this deals with authorization proposals which are used by transaction PFCG to create authorization roles.

SU24 is the transaction to maintain authorization proposals.

Table USOBX_C contains the authorization proposal flags which define the authorization objects which are relevant for a transaction.

Table USOBT_C contains the authorization proposal data which contain the authorization data which are relevant for a transaction.

(The transaction SU22 and the tables USOBX and USOBT are used by SAP development to create and deliver authorization proposals.)

See Online Help for the [Preparatory Steps|http://help.sap.com/saphelp_nw70/helpdata/en/52/671456439b11d1896f0000e8322d00/frameset.htm] of role management and for the [Check Indicators|http://help.sap.com/saphelp_nw70/helpdata/en/52/671470439b11d1896f0000e8322d00/frameset.htm].

Kind regards

Frank Buchholz

[Former Member]

No response? Or are you still none the wiser because some fundamental knowledge is missing.

I would honestly recommend that you get some training on SAP and the fundamentals of SAP security. It does not make a guru out of you overnight but will provide immediate relief to the d'oh feelings which we all have sometimes.

Imagine if everyone loaded them into SDN without doing a basic search (this also includes the F1 key on your keyboard and help.sap.com

You will know that it makes sense when you try...

Please respond (and ask Frank a more trick question about "original data"...

Cheers,

Julius

[Former Member]

>

> No response? Or are you still none the wiser because some fundamental knowledge is missing.
> 
> I would honestly recommend that you get some training on SAP and the fundamentals of SAP security. It does not make a guru out of you overnight but will provide immediate relief to the d'oh feelings which we all have sometimes.
> 
> Imagine if everyone loaded them into SDN without doing a basic search (this also includes the F1 key on your keyboard and help.sap.com
>
> You will know that it makes sense when you try...
> 
> Please respond (and ask Frank a more trick question about "original data"... 
> 
> Cheers,
> Julius

Dear Sahoo,

my answer could have been rude and not the right thing to do. but it jots down to what Julius mentioned earlier

[Former Member]

Dear Frank,

thx for your reply.

conider an example of ME21N. USOBX_C contains A_A_VIEW as X(i.e authorization check takes place). But it does not appear in profile , when ME21N is added in role menu, which you have mentioned.

my opinion on SU24: The authorization objects on which authority check is to be carried out are in this table.

my opinion on USOBT_C: Contains only those authorization objects, whose default values we want to appear in the profile.So, the no. of Auth. objects(for authority check) in SU24 can be gretaed than those in USOBT_C.

Correct me , if i am wrong.

Dear Shekhar,

t-code is a representation of a program name.So, it answers your first post.

On your 2nd post, you have told you agree with Julius. Please tell, has my question been answered at all?

This has been a long thread, but has this simple question been answered yet? you tell you could have been rude. So, go ahead and do it. Who has stopped you.

Dear All,

Why cannot a question be simply answered instead of insulting and posting stuff that hurt others.

If someone does not know an answer, then plz do not post irrelevant stuff on the question. Should not this be followed.?

[Former Member]

Dear Shekhar,

Please do not mind my previous reply to you. This thread has been too long, without any proper answer. Hope you understand.

I regret , if it was unpleasant to you.

Regards

[Former Member]

No, you are wrong.

Actually I suspect you are maintaining the menu in SE43 or your authorizations are already all in "changed" status.

Being hurt here is only the system and the next person to work on roles in it...

[Frank_Buchholz]

>

> [...] This thread has been too long, without any proper answer. [...]
> Regards

Well, up to now I've tried it twice to give a answer including links to the documentations.

>

> consider an example of ME21N. USOBX_C contains A_A_VIEW as X(i.e authorization check takes place). But it does not 
> appear in profile , when ME21N is added in role menu, which you have mentioned.
> Regards

Well, that's correct, the field OKFLAG in USOBX_C has the value X for transaction ME21N and authorization object A_A_VIEW. This has the meaning that an authorization check is somewhere in the ABAP code, but no authorization proposal will be added to the role. This is the case if OKFLAG = Y. Please have a look to the F1 help and the F4 value help of this field which explains the different values. Or use SU24 which explains it, too.

Kind regards

Frank

[Former Member]

Tables USOBT_C and USOBX_C are customer copy of Tables USOBT & USOBX & copied while implementation (via SU25).

Tables USOBT & USOBX are standard tables delivered by SAP.

USOBT_C defines for each transaction and authorisation object, which default values should be used in the profile generator for the transaction(s) entered in a Role Menu.

USOBX_C defines (a) which authorisation checks should occur within a transaction and (b) which authorisation checks should be maintained in the profile generator.

We can use transaction SU24 to maintain individual check indicators.

Through SU24 we can maintain cheks for Authorization Objects rleated for particular Transaction Code.

The relationship maintained (through SU24) for a T-Code & Object can be seen with Table USOBX_C.

Regards,

Bipin

[Former Member]

>

> USOBX_C defines (a) which authorisation checks should occur within a transaction and (b) which authorisation checks should >be maintained in the profile generator. 

Not quite true. The ABAP code + various other bits & pieces (e.g kernel level checks) define which checks should occur. We have the facility to influence some of them through the standard tools.

[Former Member]

Dear Bipin and All,

thx for your reply. But it is not clear for USOBX_C & SU24.

my opinion- Every auth. object that is being checked , should appear in the profile.So, plx expalin your point(a) of USOBX_C.

if Auth. object checking is maintained by USOBX_C, then why is SU24 required.or Vice-versa.

A profile can contain more Auth. objects than USOBT_C. The auth. objects that appaer in a profile are picked up from SU24. Plz correct if wrong.

Plz give valid answers.

[Former Member]

Very good question - Dont give up, keep trying

to add to what you asked , i have a question too.......if you have VA01 why do we have the program SAPMV45A, if we have the program why have VA01???? - Point to ponder.......

[Frank_Buchholz]

>

> USOBT_C defines for each transaction and authorisation object, which default values should be used in the profile generator for the transaction(s) entered in a Role Menu. 

correct

>

> USOBX_C defines (a) which authorisation checks should occur within a transaction and (b) which authorisation checks should be maintained in the profile generator. 

An authority check take place if the system executes an AUTHORITY-CHECK statement in the ABAP code. In addition, some other ABAP statements trigger authority checks, too, like OPEN DATASET or LEAVE TO TRANSACTION.

An entry in USOBX_C is not required to perform an authority check.

Using the specific setting "No" in USOBX_C you can switch off authority checks in the ABAP code (except for software component Basis and HR). However, this option is only used in rare cases.

The main purpose of USOBX_C is to list authority objects per transaction which are added to a role if the transaction is entered in a role menu. Authorization values in the role are included, too, if coressponding entries in USOBT_C exist.

Kind regards

Frank

[Former Member]

Shekar's post is not irrelevant and points to one of the important exceptions to the rule you are trying to caste in iron.

You create tcodes which point into nirvana to represent batch jobs. You can then built the menu in the sequence of the steps and maintain usobt_c and usobx_c so that they become building blocks.

This is the only reasonable way IMO of securing and documenting batch job processing - most notably S_DATASET itself.

If you went for some basic training, then you could ask more specific ans less generic questions... and the threads wouldn't ramble on like one is.

The forums are also not a substitute for training.

Cheers,

Julius

[Former Member]

Julius,

Are SU24 changes cross client? In other words, changes in dev client 100 - will they show up in dev client 110, or will they need to be transported?

Thanks,

Santosh

[Former Member]

When you look at the relevant tables, do they have MANDT as the first field? If not then they are client independent and changes are x-client. The USOBT* & USOBX* fall into this category

[Former Member]

You should always transport them, but generally you can wait until a "no check" indicator is made or before release upgrades or support packs.

Then you must release the transport.

Cheers,

Julius

[Former Member]

Are SU24 changes cross client?

Yes

Thanks,

Himadama

[Former Member]

Alex...any exeption to this rule? Table "T000"

Thanks,

Himadama

[Former Member]

I don't know about any exceptions - it's not really my area. DD02L will tell you for a particular table.

[Former Member]

This message was moderated.