Skip to Content

How to get RFC call traces to build authorizations for S_RFC for free!


If you are looking for best-practices about creating an authorization concept for RFC you will find here an overview about some well-known pieces of information as well as a brand new approach how to get trace data on RFC authorizations for free.

Let’s start with the Online Documentation about authorization object S_RFC
Authorization Object S_RFC

As of basis release 7.02 respective 7.10 you can provide authorizations for individual function modules in addition to the well-known option to provide authorizations for function groups. See Note 931251 for details.

Well, this does not tell you how to create roles for this authorization object in an efficent way, therefore let’s read on in the Online Documentation:
Creating an Authorization Concept for RFC

Here you get the overall plan:
Step 1: Analyze and document the communication relationships within the system landscape.
Step 2: Trace the authorizations used by each user.
Step 3: Create an authorization concept for two user groups: service users and regular users.
Step 4: Fine-tune the concept for further user groups.
Step 5: Monitor the assigned authorizations at regular intervals.

On SDN you can find some documents which gives you the whole picture about RFC authorizations:

Secure the RFC Connections in Your SAP System Landscape (Overview)
Securing RFC Connections (Details)

In addition there exist a Wiki page showing Best Practice – How to analyze and secure RFC connections on SDN as well.

Since November 2014 you use a detailed white paper about Securing Remote Function Calls (RFC) (you find more security related white papers at ).

New: Standard transaction STRFCTRACE replaces the Z-report described in this blog (see note 2080378).

By the way: Do you know the authorization object S_ICF and that it can be used to secure the usage of RFC destinations? Using it you can restrict who is allowed to call RFC function modules using a RFC destination.
a) You run several productive clients in one system. There exist many RFC destinations pointing to other systems. You know that RFC destinations are client independent but you like to restrict the usage for some critical RFC destinations to a specific client. Using authorization object S_ICF you only assign authorizations for using these critical RFC destinations within this client.
b) The Central User Management (CUA) owns very powerful RFC destinations which should only be used by your user administrators. Using authorization object S_ICF you only assign authorizations for using these critical RFC destinations of the CUA master system to the user administrators.

You find the documentation about authorization object S_ICF in the RFC/ICF Security Guide (Well, it is located in the ICF part which is a little bit misleading):
Controlling Access to RFC Destinations 

Security Audit Log

You can use the Security Audit Log to trace incoming RFC calls. Then you can use the result to prepare lists of called RFC function modules and function groups. However, in this case you have to enable logging not only for critical events but also for sucessful events in the Security Audit Log. Because of the increased size of the resulting audit log files you may not want to do this.

Online Help about Transaction SM19 and SM20
The Security Audit Log

Blog Analysis and Recommended Settings of the Security Audit Log (SM19 / SM20)

System Trace

You can use the System Trace to log incoming RFC calls. This is a very fast and easy way to trace specific actions but you never switch it on for a long time. That means you can use it to analyze a specific application which you are currently testing but you cannot use it to build a complete authorization concept.

Nowadays you can use transaction STAUTHTRACE instead (actually I never call ST01 again). Here’s the Online Help about transaction STAUTHTRACE.

If transaction STAUTHTRACE is not available in your (quite old) system you can use report ZSHOWAUTHTRACE from SDN instead.

Workload analysis

Let’s go back to the plan described earlier:
Step 1: Analyze and document the communication relationships within the system landscape.
Step 2: Trace the authorizations used by each user.

The first step deals with the question which of the defined RFC destinations are really used and the second is about the list of RFC function modules or function groups which are called via RFC.

The analysis options of the Workload Statistic, transaction ST03N, show a lot information about these questions for free.

Here’s the Online Help about transaction ST03N:
Displaying RFC Profiles 
Controlling and Monitoring the Generation of Statistics Data

Here are the main hints how to use ST03N to view RFC statistics:

  • Select Workload for a server or for TOTAL and optionally a date.
  • To analyze incoming RFC calls choose profile “RFC Server Profile” and show the tab “Function Module”. Use this view to build authorizations for authorization object S_RFC.
  • To analyze incoming RFC destinations choose profile “RFC Server Profile Destination” and show the tab “Remote Destinations”. Select task type ‘RFC’.
  • To analyze outgoing calls choose profile “RFC Client Profile” and show the tab “Function Module”. Select task type ‘All’ or a specific task type.
  • To analyze outgoing RFC destinations choose profile “RFC Client Profile Destination” and show the tab “Remote Destinations”. Select task type ‘All’ or a specific task type. Use this view to build authorizations for authorization object S_ICF.
  • It’s useful to extend the data retention period for the monthly aggregates about RFC calls. Use can set a long time like 6 or 12 month.

Transaction ST03N -> Collector and Performance DB -> Performance Database -> Workload Collector Database reorganization -> Control


Transaction SM30 for table SWNCCOLLPARREO

Maintain settings “Month.Aggrs Ret.Per. “ and “TOTAL MnthAggrRetPer” for these areas:

WO          RFC Client Profil

WP          RFC Client Destination Profil

WQ          RFC Server Profil

WR          RFC Server Destination Profil

ST03N RFC Server Profile showing incoming RFC function calls

ST03N RFC Server Profile

ST03N RFC Client Destination Profile showing outgoing destinations

ST03N RFC Client Destination Profile


Transaction ST03N is not bad but it’s a little bit tricky to retrieve the relevant information from the workload analysis data. Therefore I’ve developed a small report which retrieves all information about RFC calls easily: Report ZRFC_STATRECS_SUMMARY on SDN shows you the daily, weekly and monthly aggregations about RFC calls including information about function groups, user types or user groups. You can directly use the result to build authorizations for authorization object S_RFC.

New feature (March 2013): Show authorizations of remote users concerning authorization object S_RFC and compare them with the data from the workload statistics.

Limitation: This report works as of SAP_BASIS release 7.00.

New: Standard transaction STRFCTRACE replaces this Z-report (see note 2080378).

You must be Logged on to comment or reply to a post.
  • Frank – I have used your program successfully in our ECC 6 environment.  In our ECC 5 environment there are a couple function modules and data dictionary elements that do not exist.  Do you have an alternative for ECC 5?  For ECC 6, the output provided the information needed to build a new security role.  This was much better than performing days of tracing to collect data.  This really adds value.  Will this or something like it be available in future releases possibly as an SUIM report?
  • Hi Greg,
    Thank you for your feedback.
    Well, unfortunately I’ve to restrict the validity of the report: It only works as of SAP_BASIS release 7.00.
    Kind regards
  • Hi Frank,

    The report is a wonderful idea, both in the functionality, and as an aid to learning my ABAP skills (I’m an itinerant BASIS Administrator, but I like to keep my hand in with the ABAP now and again !!).


  • Hi Frank,

    Thanks for such a wonderful report.

    when I check the user profile for some system users in ST03N it show some transactions as well. Does this mean that I need to add those transactions in the system id roles?



    • Are you talking about ZTCODE_STATRECS (but not ZRFC_STATRECS_SUMMARY)?

      Let’s have a look to a comment at the beginning of ZTCODE_STATRECS:

      *& Limitation:

      *& Report transactions like SE38 (=report RSABAPPROGRAM) are not fully supported.

      *& Currently only one of the report transaction is used, but maybe the wrong one

      *& Solution, which works only if the authorizations contain exact transaction names:

      *& Search for stat data which match to the program name of the report transaction.

      System users typically either call RFC functions or execute background jobs which in turn submit reports (but not call transactions). However, if there exist a report transaction for such a report, ZTCODE_STATRECS would display this transaction code in such a case even if the transactions is not called.

      System users typically do not need access to transactions via authorizations for S_TCODE. There might exist some exceptions: RFC functions or background jobs might hit some AUTHORITY-CHECK statements for S_TCODE or calls for function AUTHORITY_CHECK_TCODE. But this is out of the scope of what you can do with ZTCODE_STATRECS. To hunt for such cases you have to run a normal authorization trace using transaction STAUTHTRACE (= successor of good old ST01).

      Conclusion: It does not really make sense to use ZTCODE_STATRECS for system users.

      On the other hand I often have seen that some system users have authorizations for S_TCODE… I assume that’s usually simply an error – or the user administration team has simply reused dialog roles for remote or background usage.

      • I am talking user profile in ST03N log. When I check the transaction usage for a system id it gives me quite a number of transactions executed(specially CRM-ECC connection). does this mean that the same id is used somewhere else apart from RFC calls? I am creating roles for RFC users but not sure if I should add those transactions as well.

  • Hello Frank,

    thanks for the great documentations, they are very helpful.

    I have one question about the authority object S_RFC and the function module RFCPING, is this function module critical (from the point of view security)? The background of this question is, that I have defined in reginfo a gw security for an external system, then I have create an authority role for the RFC user very striktly (this means the user can only use a few function modules). The last function module we discuse is RFCPING.
    I think if an RFC user don’t have authority to this function module “he” is not able to “scan” the SAP systems, but on the other “handside” it’s good to have the function module because so I can determinate if a system is “still alive”.

    Do you have any experience about RFCPING and the security aspect?

    Best regards


    • First of all: Congratulation to run such a strict authorization concept for remote access covering S_RFC authorizations as well as access control lists secinfo and reginfo of the RFC Gateway!

      Do you like to share some experience about your your project to secure remore access?

      Function RFC_PING belongs to function group SRFC. -> no authority check for S_RFC (*).

      Function RFCPING belongs to function group SYST. -> with authority check for S_RFC

      If you take away RFCPING (which is ok, if not used by any user RFC scenario of the user), you still can call RFC_PING to check if the system is alive.

      Both function groups contain some more RFC enabled functions:

      Function group SRFC (no authority check for S_RFC)










      Function group SYST (with authority check for S_RFC)









      Having a look to these functions I would say that, e.g. RFC_SYSTEM_INFO, RFC_GET_LOCAL_DESTINATIONS, RFC_GET_LOCAL_SERVERS are more important as these functions show more detailed information compared with what you get using RFC_PING or RFCPING.

      (*) You can activate the authority check for the RFC enabled function modules of function group SRFC using profile parameter auth/rfc_authority_check (see note 1769064) but I do not recommend to do that – assuming hat you do not talk about a very-high-secure system for which *all* other security measures are already strictly enforced.

      By the way: ABAP4_LEAVE_TO_TRANSACTION requires a user which is allowed to use the SAPGUI (user type “dialog”) and having corresponding authorizations for S_TCODE -> safe

      Kind regards

      Frank Buchholz

      • Hi Frank – based on your writing above a customer is asking the below question. Do you have any experience with this?

        “We have these pesky errors when creating rfc destinations in our new BW on HANA environment.

        All of which complain that the program is not registered..

        Error Details       Error when opening an RFC connection (CPIC-CALL: ‘ThSAPOCMINIT’ : cmRc=2 thRc=67
        Error Details       ERROR: program (program_id) not registered
        Error Details       COMPONENT: SAP-Gateway

        This is very annoying. Anybody encountered these issues? And if so what exactly is going on?.”

        Kind regards


        • I suggest to re-post the question at SAP NetWeaver Technology Platform (or Security ).

          Are you using ABAP (SM59) of Java (Jco) to define the destination?

          What type (3 or T) of RFC destination do you try to create?

          In case of type T: What is the content of file secinfo and reginfo of the RFC gateway?

          (I’m confused as the error message “ERROR: program (program_id) not registered” does not name a specific “program_id”.)

          Kind regards


  • Hi, I like the Report ZBC_RFC_STATRECS_SUMMARY and I used it a lot in the last weeks.

    But I have a question. Is it possible that the value TO in the autorization objekt S_RFC is not or not correct checked? I tried to work with rages in the objekt S_RFC and than it seems the report doesn’t show the correct authorization for a user?!

    Example: The User has a role with autorization objek S_RFC for FUGR and Activity = 16. The value of S_RFC is A* – C*. Than the Report shows that the User has no authorization for Functiongroup BFHV. But the Group BFHV is in the range of A* TO C*.

    Kind Regards


    • Ups, while developing the report I didn’t had expected to see from-to-ranges for authorizations about function groups. Therefore I had oversimplified the programming logic ignoring the to-field. I need to extend the report and will upload a new version soon (whenever I’ll have time to do it…).

      Sorry for this error!

      Kind regards

      Frank Buchholz

    • Please get the updated version of the report ZRFC_STATRECS_SUMMARY from

      I’ve added support for authorization ranges for function groups and function names.

      Kind regards

      Frank Buchholz