RFC authorizations.

[Private_Member_119218]

Situation:

After replacing old roles on my system that had auth obj. S_RFC with following values

[ACTVT = 16; RFC_NAME = *; RFC_TYPE = FUGR;]

in most of them, my system is plagued by RFC_NO_AUTHORITY short-dumps. I'm yet to see any transaction that has profile generator defaults (SU24) maintained for S_RFC object although many have this object as "Checked", and, as far as I know, there is no way to determine what RFC calls the transaction could make ahead of time. As far as I can understand, all these calls are local, e.g. target is "NONE" in the shortdump.

Question for the experts here:

What is the most correct way to handle this situation? What am I missing here?

Feeling a bit lost, here.

Edited by: Martinsh Shaiters on Jun 1, 2009 6:20 PM

[former_member182098]

This message was moderated.

[sdipanjan]

> Situation:

> After replacing old roles on my system that had auth obj. S_RFC with following values

[ACTVT = 16; RFC_NAME = *; RFC_TYPE = FUGR;]

in most of them, my system is plagued by RFC_NO_AUTHORITY short-dumps. I'm yet to see any transaction that has profile generator defaults (SU24) maintained for S_RFC object although many have this object as "Checked", and, as far as I know, there is no way to determine what RFC calls the transaction could make ahead of time.

You can measure the RFC call failure by measuring through ST01 and also check the RFC connection attempt by SM20.

As far as I can understand, all these calls are local, e.g. target is "NONE" in the shortdump.

>

> Question for the experts here:

> What is the most correct way to handle this situation? What am I missing here?

>

Check whether the RFC objects. Are those for failing for the customer developed interfaces? If yes, then check the ST01 trace or preferably the Program whether the RFC Object to be protected has been mentioned already with some specific name.

Before all these, please check whether PFUD has been executed for the role changes performed and is there any validity date assigned mistakenly.

Regards,

Dipanjan

[Former Member]

Hi Martinsh,

Thats good that you are removing '*' from S_RFC. What roles have you modified? End user roles / roles for background ids? What is the user type ( dialog / communication / ... ) in the dump?

Are the end users using portal?

S_RFC is checked in the target system when a user calls a function module remotely, so in essence, the authority check happens in the target system, but the call is made externally, examples could be portal applications, BI , Bex...etc. Based on which user is failing on the RFC you could add those Function groups to the roles you modified. Like Dipanjan mentioned, SM20N is a good tool to check these.

Regards

Abhishek

[Former Member]

Hi Abhishek,

Depending on your setup it is very possible that the majority of your RFC calls are performed internally. There are plenty of transactions which use RFC calls for FM's which originate & operate in the same system. On my current client I would say they make up 80% of all RFC calls (maintaining SU24 for them has been fun!). ST22 is a good way of picking these up, in addition to the techniques mentioned by you and Dipanjan.

Cheers

Alex

[Former Member]

Hi Alex, that's true

For us too, we faced so many dumps for these that we lost hope in maintaining the SU24. We tried our best though. For some of the custom functional modules, they would just endlessly make recursive calls...

For we had some customs for ESS/MSS and FSCM, it became a nightmare of authorization failures :-). The best part for this is.. we noticed, once we got the roles streamlined for them ( esp. S_RFC), we would notice an exponential decrease in dumps... so thats one good part. . Just for 1 FUGR, redwood alone accounted for hundreds of dumps.

ST22 is indeed the first choice. If many app servers are present, then ST01 becomes difficult to handle for portal calls, has to be used with SM20N then. Load balancing kinda clicks here.

Like you said, its fun

Abhishek

[Former Member]

Please take a look at the note mentioned by Zaheer in

The checks are config dependent (RZ11 --> auth/rfc_authority_check) but the SM20 logs will record them (and sometimes more) independently of this. This is usefull but can be misleading if you are not aware of your config.

Internal RFC authority is not checked by default (e.g. destination "NONE") even although the logs might say so. I know that SAP is looking into the SM20 aspect of this "always write a log" but the short-dumps can be more misleading. IMO it is not acceptable to "tollerate" short dumps though...

See for an explanation for the different RFC_TYPE's. You are currently only using FUGR...

So, which FUGR is it? Is there anything corresponding to them in SM13? (that would be more critical)

Also, which release / SP / Kernel level / OS are you on?

If you are interested in more technical details of SM20, with possible consequences for ST22, then see

Cheers and please give us more details,

Julius

[Former Member]

> I'm yet to see any transaction that has profile generator defaults (SU24) maintained for S_RFC object although many have this object as "Checked".

This means only that the transaction has the possibility to check the authority, dependent on config and the authority of the user (and in special cases the transport type).

If you are really using a remote enabled RFC, then IMO it is better to maintain the authorization via the menu by adding the Function Module to it and maintaining SU24 for the function module, and not the transaction...

Cheers,

Julius