RE: Objects in SU24

[sreekanth_sunkara]

Hi all,

I went through lot of SU24 threads in SDN and also wikipedia but everytime when i think about SU24 i still get some questions in my mind.

For EX: i had a look at SU01 program code and searched the code with 'AUTHORITY-CHECK' and it contains the following 5 objects.

S_DEVELOP

S_USER_AUT

S_USER_PRO

S_USER_GRP

S_USER_SYS

but in SU24 it is showing the below 53 objects. where do these objects come from and why they are in there

if they are not even hard coded or needed in the prorgam.

i thought all the Objects that are in the program will be in SU24 and based on the navigation/flow or requirement we activate and deactivate them.just confused whats the wrong here with me in understading this?

B_ALE_MODL

B_ALE_RECV

P_ABAP

P_ORGIN

P_ORGXX

P_PCLX

P_PERNR

P_TCODE

PLOG

S_ADDRESS1

S_ADMI_FCD

S_ALV_LAYO

S_APPL_LOG

S_ARCHIVE

S_BCSETS

S_BDS_DS

S_BTCH_ADM

S_BTCH_JOB

S_BTCH_NAM

S_C_FUNCT

S_CTS_ADMI

S_DATASET

S_DEVELOP

S_DOKU_AUT

S_GUI

S_IDOCCTRL

S_IDOCDEFT

S_IMG_GENE

S_LDAP

S_OC_DOC

S_OC_ROLE

S_OC_SEND

S_OLE_CALL

S_PACKSTRU

S_PRO_AUTH

S_PROGRAM

S_PROJECT

S_RFC

S_SPO_DEV

S_TABU_CLI

S_TABU_DIS

S_TCODE

S_TRANSLAT

S_TRANSPRT

S_USER_AGR

S_USER_AUT

S_USER_GRP

S_USER_PRO

S_USER_SAS

S_USER_SYS

S_USER_TCD

S_USER_VAL

S_WFAR_OBJ

Thanks in Advance,

SS

[Former Member]

Sun,

Only check maintain objects will be present in the program.

Thanks,

Sri

[sreekanth_sunkara]

thanks Sri for your helpful response.

Thanks,

SS

[Former Member]

Sun,

check maintain objects / check will be present in the program. you need to understand the difference between check and check maintain other than the definition given in the book.

but in SU24 it is showing the below 53 objects. where do these objects come from and why they are in there

if they are not even hard coded or needed in the prorgam.

SAP delivered tables USOBT and USOBX (USOBT_C / USOBX_C).

Thanks,

Sri

[sreekanth_sunkara]

Sri,

i understand what you are saying and from where we get those values in SU24. but what i am asking is why we have 53 objects why isn't more or less?

what is there in having only those 53 objects. is that something SAP designed the program in a way suchthat based on the scenario we can use those 53 objects in combinations?

Thanks,

SS

[Former Member]

Sun,

Pls dont close this question/ticket. Lets wait for other group members share their views on this topic

what i am asking is why we have 53 objects why isn't more or less?

Thanks,

Sri

[sreekanth_sunkara]

Ok Sri lets wait

thanks,

SS

[Former Member]

Hi Sun,

Just to make it clear why dont you enable one object from your list in DEV environment, go back to the program and check it if the object enabled shows up.

I always think all transactions reside in a repository , all the activated and underlying objects are called by the programs based on the transaction we call.

[sreekanth_sunkara]

thanks Franklin for your response,

so everytime when we make some object from no check to check or from check to check / maintain will the program change automatically and insert those changes in the program?

Thanks,

SS

[Former Member]

Hi Sun,

Did you try that on your system/Sandbox?

you will have a realtime answer.

Remember when you save the changes in SU24 it will ask for a transport etc..... follow all the steps.

[sreekanth_sunkara]

Franklin,

you are right everytime when i change something in SU24 it asks for transport but i never checked the program. i will look in to the code when i get a chance next time to maintain the object in SU24

so finally this means that there is some invisible code in ABAP which we cannot see unless we activate those objects.

Thanks,

SS

[Former Member]

Hi ,

Regarding your question about the number of objects:

SAP has delivered the transactions with default settings: Allowing the customer to make necessary check/Maintain based on the business requirement.

"Its like a look up "DICTIONARY" for the programs which execute the transactions by checking on the objects which are enabled"

[sreekanth_sunkara]

ok thanks Franklin

[Former Member]

The reason for it is not easy to spot at first... but is logical:

In SAP's own development systems the RZ11 parameter transport/systemtype is set to "SAP". In customer systems it is set to 'CUSTOMER'.

When the system type is SAP, the system ignores all authority-check statements until there is a check indicator set in SU22. This "forces" the developers to maintain the objects - indicating that a user in the transaction context could have the capability of navigating into the workbench or jobs or file system etc. Therefore these objects all appear in virtually all transactions. It is only those objects for which there is a consistent intended use of the transaction that SAP activates the "Proposal" flag (previously "Check/Maintain") and add as many usefull values to the fields so that customers do not need to re-trace everything. This process is also automated to a large extent in these systems.

In CUSTOMER type systems, it is different. AUTHORITY-CHECK statements are independent of the "check" flag in SU24, but the values are still there to indicate the transaction's capabilities and those of the ABAP development workbench in particular. This arises to the urban legend that if the object does not have a "check" indicator, then it is not checked. This is only the case in SAP type systems.

In customer systems you can globally deactivate some of the objects for all transactions in AUTH_SWITCH_OBJECTS or override the return-code (sy-subrc = 0) in SU24 for specific transaction contexts only using the "no check" indicator.

Hope this helps you understand the origin of the 53 objects. For day-to-day purposes in customer systems you can just think of them as documentation which you will very seldom need.

Cheers,

Julius

[sreekanth_sunkara]

Hi Julius,

Thanks a million for your good explanation.

Thanks,

SS

Edited by: sun on Aug 6, 2010 4:35 PM

Edited by: sun on Aug 6, 2010 4:36 PM

[Former Member]

Hi Sun,

The reason why they differ is that SU24 is utilised for the role administration process and has no bearing on the actual authority checks.

SU24 is utilised by the profile generator (PFCG). It enables you to add or remove objects to the USOBT_C and USOBX_C tables. When utilising PFGC, you choose TCodes to create roles. When you select TCodes in the u2018Menuu2019 tab in PFCG, SAP refers to these two tables to propose the objects in the u2018Change Role: Authorizationsu2019 screen (visible via the u2018Authorizationsu2019 tab). As such, you can use SU24 to alter the objects proposed by the profile generator to make the role administratoru2019s jobs easier.

The authorisations checked by the actual TCode are embedded in the program as the authority-check statements which you have mentioned.

An example would be if you create a custom TCode called ZPOST with underlying program ZPOSTPROGRAM. The ZPOSTPROGRAM has three authority checks in it for objects Z_OBJ_CUST1, Z_OBJ_CUST2, and Z_OBJ_CUST3. However, SU24 was used to update the USOBT_C and USOBX_C tables so that ZPOST is linked to Z_OBJ_CUST1 and Z_OBJ_CUST2 only. This means that when PFCG is used for role maintenance only Z_OBJ_CUST1 and Z_OBJ_CUST2 will be proposed as objects to maintain for the role. However, you would still need all three objects to be able to utilise ZPOST transaction as this is dictated by the ZPOSTPROGRAM. Without all three you cannot carryout the ZPOST transaction as you will fail the authority checks.

This is why there is always a potential for the SU24 objects to not match the objects actually required by the TCode or program. I normally use SU03 when trying to identify the objects required for a TCode or program by building bare roles and adding one object and value per authority check failing. Though this is more time consuming, it is the most accurate way to identify the correct auth checks (short of reading through all the ABAP code).

SU24 is normally a good place to start to identify the correct objects but as you can see, it may not be accurate.

Hope this helps,

Jamie

[Former Member]

> has no bearing on the actual authority checks

This is not true, particularly in the SU22 data of "SAP" type transport systems.

The "check" indicators are then transfered to SU24 in "CUSTOMER" type systems and before the authority-check searches for the object or even the values in the user buffer, it first checks in TOBJ whether the object is globally inactive and then in USOBX_C whether it is context-sensitively inactive.

In both cases sy-subrc is set to zero and a "reason code" is written to the ST01 trace.

Cheers,

Julius

[Former Member]

Please elaborate... I have never heard that SU24 can change the authority checks in a program.... how is this possible?

[Former Member]

Hi Jamie,

Take a look in the FAQ thread at the top of the forum page - there is a thread called which explains the deactivation of authority-checks despite being in the program code and how this works.

Other checks are also independent of the authority-check statement itself - such as those in table TSTCA when starting the transaction or embedded in the program language itself:

dataset

Checks S_DATASET.

submit

Checks S_PROGRAM if found.

leave to transaction

Checks S_TCODE.

Etc.

Julius

Edited by: Julius Bussche on Aug 8, 2010 3:36 PM

Formatting corrected.

[Former Member]

Right, I think you are talking about tracing not the called authority checks which I was referring... you may have misread my statement? What I am referring to in the statement that 'SU24 cannot be used to alter authority checks' refers to authority checks in the ABAP program (which you are intending to trace). Meaning the authority checks called by the program in order to enable you to perform an action (e.g. posting as in my example) cannot be later with SU24. I am not referring to the tracing. My statement was correct... unless you have identified some nifty back door you can elaborate on hat allows the alteration of ABAP program authority checks by SU24?

The point of my reply was to distinguish between tracing authority checks and what the program calls (e.g. what is required to perform the action/transaction in SAP). I find this is very hard for my trainees to understand this and thought it was a good point to elaborate on as it had not been mentioned in the thread.

Please advise if you have identified how to alter authority checks via SU24. I do agree with your points on the other page regarding the ST01 transactions which is why I mentioned only using SU53 myself as I find it more reliable.

[Former Member]

Sorry, but you are wrong and this is nothing new nor a nifty hack as you have suspected. It is just often misunderstood.

Read the threads again carefully and try it for yourself to disable the check on F_BKPF_BUK for FB01 and see what happens.

Alternately write a program which opens a dataset on the file system and try run it without authorizations.

The documentation on SU24 describes the "no check" indicator or consider taking training course ADM940 or 950 which covers the topic as well.

> I do agree with your points on the other page regarding the ST01 transactions which is why I mentioned only using SU53 myself as I find it more reliable.

You are joking, right?

Cheers,

Julius

[sreekanth_sunkara]

Thanks to Everyone who responded to me.

Thanks,

SS

[Former Member]

Hi Julius,

I stand corrected, you can suppress the auth checks via SU24 for most items I have tested. This was something I did not know so thank you for that.

However to point out that I was partially correct, you cannot use SU24 to suppress the check indicators on basis objects. I even did this on the backend (with &SAP_EDIT for SU01 and S_USER_GRP). Though it looked as if the check was set to u2018No Checku2019 in SU24, I was still stopped prior to processing in SU01 for lack of S_USER_GRP objectu2026 as such basis objects cannot be suppressed.

Most likely you knew this but though it important to point out that the SU24 deactivation has some caveats.

Thanks,

Jamie

[Former Member]

Your partially correct answer is only partially complete --> you also cannot deactivate checks on objects in the HR object class

Regarding your test with editing the DB table, this feature has been disabled in the standard system now. It had something to do with foreign keys and application buffers - but I'll save that story for a rainy day.

Cheers and also welcome to SDN,

Julius

[Former Member]

Hi

In SU24 you got whole objects related to TCode SU01 but in authorization check only Yes mention object is included only by default which satisfy minimum requirment, Rest displayed Authorization object may be included by pfcg>Authorization> add manually if any specific requirment is there.

Thanks

Manish Gupta

[Former Member]

>

> Hi
> 
> In SU24 you got whole objects related to TCode SU01 but in authorization check only Yes mention object is included only by default which satisfy minimum requirment, Rest  displayed Authorization object may be included by pfcg>Authorization> add manually if any specific requirment is there.
> 
> 
> Thanks
> Manish Gupta

Hi Manish,

If the auth object is required then updating SU24 is usually the best approach, not entering auths manually in the role.