S_CTS_ADMI :-TABL

[Former Member]

Hi All,

I have a problem,

We had created new plant in our business scenario.

When end-user creating purchase requisition it showing

authorization missing, when the end - user executes an Su53, basis

object S_CTS_ADMI (transport admin) is checked for the TABL

object.

However, this object is not required to execute the

functional transaction, but it doesn't make sense as to why a functional transaction would

check for a basis object (for transporting a table!).

Thanks in advance.

Thanks & Regards

Dilip Pasila

[Former Member]

This happens because SU53 shows the last failed authority-check, and not necessarily the correct missing authority.

You can temporarily add it, to find the correct (or actually, the next previous) failed check and run SU53 again, or, run an ST01 trace and ignore this checked object when it is not required.

Cheers,

Julius

[Former Member]

Hi Dilip,

Yeah I agree with Julius as this happens a lot of times.

I would suggest you can run the trace ST01 to get the correct picture about missing authorizations.

Best ,

Suchitra

[Former Member]

This authorisation poping up in SU53 often happens at the moment a transport is comming into the system and thus should not be givven (although it does not hurt).

Best advice: wait an hour or so and retry if same Su53 report assign the S_CTS_ADMI authorisation and keep on trying.

If then an other failure comes up give that, delete the S_CTS_ADMI and retest!

[Former Member]

> (although it does not hurt).

Mmmmmm... not so sure about that. The user could change the package (development class) which the transported object is assigned to. That can create a big mess, or possibly let them change it or do other things to it as well.

I looked into this a while back, and generally concluded that it can simply be ignored.

> This authorisation poping up in SU53 often happens at the moment a transport is comming into the system

I was not aware of that. What I had made of it was the fact that shared memory objects are only slightly shared memory as they are local to the specific application server. A solution therefore is to create temporary internal DB tables which can be shared beyond the program, user, appl server, process boundary. When the user runs such a program, this check is picked up by the trace somewhere deep down in the bowels of the system, but it can be ignored as in these cases it is not reacted to.

Has anyone else investigated the root cause of this? It turns up often enough that there must be more than two explanations for it...

Cheers,

Julius

[Bernhard_SAP]

Hi Auke,

I do not believe, that waiting for a moment, when no imports are performed will change the result of SU53.....

I just checked on my system, where definitely no transports are executed at the moment (as I am the only user who has access, I can be sure about this...).

Rather consider this:

This check is a side effect of the more personalized

application design (as far as I rmemeber it did not occur for instance in (R/3) release 3.1i or 4.6b).

So some applications try to find out, which

buttons should be shown - and which are useless because of missing

authorizations. Most of this 'hidden or silent' authorization checks

will be processed in generic tools like table maintenance or generic

application menus. But also while starting the easy access menu (!!!!).

If an application stopps due too missing authorizations and returns

to the easy access menu, the failed authorization check in the

application is not the latest, because of the failed silent check. This leads to the

weird SU53 content.

What now ...?

1st. As already mentioned earlier in this thread (and this should be standard for all authroization admins):

Use the authorization trace (transaction ST01 to get

more details, if the SU53 only shows the silent check).

SU53 shall always be just a 'simple' entry point for auth.-problem-analyzis. I understand that

SU53 will loose its importance more and more, as checks get more complex with each realease

or also by supportpackage delivery....

2nd. Tell your users the should call Su53 in a new mode before

they are turned back to the easy access menu (sometimes this helps, but not always) .

SU53 has to be started immediately, or other false checks could appear, for instance

for S_DOKU_AUT after clicking on the 'no authorization'-message or S_ADMI_FCD,....).

3rd. SAP developement is actually discussing, if more than only the

latest failed authority check can be recorded. If some of you could trigger a development

request this could help in the decision process...

b.rgds,

Bernhard

[Former Member]

Thanks for the insights Bernhard!

We had a similar discussion about two years ago in a thread called - must be the only documented case of an interview question, points-gaming and discussion about the weather having led to a development request...

As you can see, at the time the general consensus was that SU53 does exactly that which it is documented to do (=> it is human error to expect anything else of it, even if many folks can be expected to make this error) and what would be helpfull is to add more "reason codes" to the ST01 trace to show such complex checks.

For example:

- sy-subrc set to 0 by the kernel due to config (params) = 0a

- sy-subrc set to 0 due to SU24 "no check" indicator = 0b

- sy-subrc set to 0 due to SE97 "couples" flag = 0c

- sy-subrc not reacted to by raising an exception / message = 0d

- sy-subrc reacted to with a "w- or i-message" = 0e

- sy-subrc NE 0 reacted to by a subsequent AUTHORITY-CHECK which returned 0 = 0f

- subrc NE 0 imported into a different user context (function call with DESTINATION parameter) and returned sy-subrc = 0 = 0g

- etc...

> Most of this 'hidden or silent' authorization checks

> will be processed in generic tools like table maintenance or generic

> application menus.

That would also explain why it turns up when the end user accesses a dynamic table.

I have also come accross this in workflow scenarios, while restricting the authority of WF-BATCH.

You can call me "Don Quichotte" as well, but these "silent checks" do explain some "urban legends" that it cannot work without SAP_ALL...

> SU53 has to be started immediately, or other false checks could appear, for instance

> for S_DOKU_AUT after clicking on the 'no authorization'-message or S_ADMI_FCD,....).

Another famous one is S_BTCH_ADM...

> 3rd. SAP developement is actually discussing, if more than only the

> latest failed authority check can be recorded. If some of you could trigger a development

> request this could help in the decision process...

I still don't see how SU53 could do that, without itself becoming a "mini-ST01"...

Cheers and thanks again,

Julius

[Former Member]

Thanks Guys i was probably thinking the wrong direction.

Always good to discuss here as we all can learn from eachother!!