Skip to Content

How to handle xRPM Backend Authorizations


There have been some posts on the Sap xApps forum about the best way to define xRPM Backend authorizations.

In this first weblog, we intend to provide a basic overview of xRPM 2.0 authorizations and we will focus on the Backend part (both EP and BW authorization concept will not be in the scope of this weblog)

You will also find useful information in the SAP xRPM Core Installation and Configuration Guide in the Sap xApps section of SDN.

The xRPM 2.0 Backend Authorization Concept

As an xApp, an xRPM solution can be composed of many components, only 3 of them will be discussed here: the SAP NetWeaver Portal (formerly known as SAP Enterprise Portal), the xRPM Backend, and its BW dedicated system.

In each component, you have to define what are the user’s authorizations and access rights. As far as the xRPM Backend is concerned, you have predefined roles that you can use. Generally, customers choose to implement their own roles, best suiting their business needs, and wonder which is the most restrictive set of authorizations that should be given in order for the solution to work…

As time goes by, the experience told us that, whenever possible, authorization objects should be put into single roles, and single roles encapsulated into composite roles that map business roles, making User administration much simpler!

The Minimal Set

Communication issues… ?

Firstly, the communication between the Portal and the xRPM backend heavily relies on calling RFC function modules (FM) using JCo connections. If you activate the JCo log in the Portal (set the Show Debug property to ‘Yes’ in the relevant iView), you can see what FM is called and what are the parameters in and out.

Secondly, users are associated with a specific Business Partner for Workflow reasons. You will also need authorizations for this.

Fortunately, the standard role SAP_BC_ENDUSER will fulfil both needs.

Categories & Subcategories

Apart from this, the xRPM Backend 2.0 authorization is straightforward: you just have to define which project categories and subcategories you want to allow a user to access (see +Define Project Categories+ in the IMG)

Everything goes through the only xRPM authorization object – named RPM_PROJ – to check that the action is valid.

Going further!

Of course, it is still possible to extend the authorization concept by developing new authorization objects (whether they will focus on the Execution status, Location or any other project attributes).

To make things work, you will simply have to implement the CUST_PROJ_AUTHORIZATION method of the Badi RPM_PROJ_CUST_FIELDS.

Just have a look at the use and content of the Function Module ‘RPM_CHECK_AUTHORITY’ in SE37 to get convinced of its central role.

Now that the general overview is settled, let’s try to offer a BSP application that would facilitate maintenance and reporting of user authorization.


Basically, the layout consists in 3 components:

– a quite simple User Details box, in order to check/remind that we are viewing the relevant user

– a tree view containing Composite roles on the first level, and the Single Roles on the second level (with a special case for “stranded” Single roles… 😉

– a table listing every Category and Subcategory present in the system and the corresponding User authorization for each and everyone of them.

In the following part, we are going to briefly explain the key steps of each component.

Name & Email

Nothing spectacular here. A simple inputField for the SAP UserId reminds the User of the selection-screen option chosen. For the name & email box, we make use of the ‘BAPI_USER_GET_DETAIL’ FM to retrieve the information.


User Roles

As stated above, we have 2 levels of roles : Composites roles (mapped to the Business roles) including Single Roles (mapped to technical roles). What a great opportunity to implement a Tree !  😉

      LIKE LINE OF wt_agr_texts.

*_ Retrieve all roles of the user



      user_name                    = username

      time_dependent               = ‘X’


      activity_groups_users        = wt_agrs


      no_activity_groups_available = 1

      OTHERS                       = 2.

  IF sy-subrc = 0.

*__ No need to keep roles inherited from composite Roles, we will

  •   directly process the Composite roles with their definition

    DELETE wt_agrs WHERE col_flag = ‘X’.

*__ Due to validity period, it is possible to have the same Role twice

  •   and even overlapping

    SORT wt_agrs BY agr_name col_flag.


*__ Get all composite roles definition that are relevant for THIS user

  •   no need to test if the internal table because the FM

  •   would have returned an exception 1

    SELECT * FROM agr_agrs


       FOR ALL ENTRIES IN wt_agrs

      WHERE agr_name = wt_agrs-agr_name.

*__ Get texts for roles (composite/single)

  •   no need to test if the internal table because the FM

  •   would have returned an exception 1

    SELECT * FROM agr_texts


       FOR ALL ENTRIES IN wt_agrs

      WHERE agr_name = wt_agrs-agr_name

        AND spras    = sy-langu.

*__ Remove from the list of Single roles, the roles that are,

  •   in fact, Composites ones

    LOOP AT wt_composite ASSIGNING -agr_name ‘)+’ INTO wa_tab-text.

        CONCATENATE ‘<span style=>’ -child_agr ‘)+’ INTO wa_tab-text.

        CONCATENATE ‘<span style=>’

CLASS cl_htmlb_manager DEFINITION LOAD.

DATA : event    TYPE REF TO cl_htmlb_event.

DATA : wa_tab   LIKE LINE OF tab_roles.

  • Test that this is an event from HTMLB library.

IF event_id = cl_htmlb_manager=>event_id.

  • Retrieve the name of the event

  event = cl_htmlb_manager=>get_event( runtime->server->request ).


  CASE event->server_event.

    WHEN ‘tree_expand_all’.

*____ Expand the entire tree

      CLEAR : wa_tab.

      wa_tab-status = ‘open’.

      MODIFY tab_roles FROM wa_tab TRANSPORTING status WHERE status = ‘closed’.

    WHEN ‘tree_collapse_all’.

*____ Collapse the entire tree

      CLEAR : wa_tab.

      wa_tab-status = ‘closed’.

      MODIFY tab_roles FROM wa_tab TRANSPORTING status WHERE status = ‘open’.





Categories & Subcategories

Last but not least, the page core purpose is to display categories and subcategories available to the user, that is to say getting RPM_PROJ authorization object for the user.

But, we want to display it in a comprehensive manner. We achieve this using green and red lights and the following structure:


First step: Get all Categories & Subcategories in the system

*_ Retrieves information from Text tables of Categ./Subcateg.

  SELECT scategory ssubcategory ctext stext

    INTO (wa_cat_subcat-category,




    FROM rpm_proj_subct_t AS s INNER JOIN rpm_proj_cat_t AS c

         ON  ( slangu = clangu

           AND scategory = ccategory )

   WHERE s~langu = sy-langu.

    APPEND wa_cat_subcat TO pt_cat_subcat.


  IF sy-subrc = 0.

*__ Manually add the fictitious ‘0000’ Category for Global Roles

    CLEAR : wa_cat_subcat.

    wa_cat_subcat-category    = ‘0000’.

    wa_cat_subcat-subcategory = ‘0000’.

    wa_cat_subcat-cat_text    = text-cat.

    wa_cat_subcat-subcat_text = text-sub.

    APPEND wa_cat_subcat TO pt_cat_subcat.

    SORT pt_cat_subcat BY category subcategory.


Second step: Get authorization for selected user

Thrid step: Mix both table to make a flat list for table display

  DATA : w_subrc_all LIKE sy-subrc,

         w_subrc_cat LIKE sy-subrc.

  DATA : wa_cat_subcat LIKE LINE OF pt_cat_subcat.

  DATA : wa_actvt_user LIKE LINE OF pt_actvt_user.

  CLEAR   : pt_actvt_user.

  REFRESH : pt_actvt_user.

*_ Process by pair of category/subcategory one after the other

  LOOP AT pt_cat_subcat INTO wa_cat_subcat.

    CLEAR : wa_actvt_user.

    MOVE-CORRESPONDING wa_cat_subcat TO wa_actvt_user.

*__ First, we look for the subcategory

    LOOP AT pt_autoris INTO wa_profile

                       WHERE field = ‘RPM_SUBCAT’

                         AND ( von   = wa_actvt_user-subcategory

                            OR von   = ‘*’ ).

*____ Either the category is generic

      READ TABLE pt_autoris WITH KEY auth  = wa_profile-auth

                                     field = ‘RPM_CAT’

                                     von   = ‘*’

                            TRANSPORTING NO FIELDS.

      w_subrc_all = sy-subrc.

*____ Or, it is the correct category

      READ TABLE pt_autoris WITH KEY auth  = wa_profile-auth

                                     field = ‘RPM_CAT’

                                     von   = wa_actvt_user-category

                            TRANSPORTING NO FIELDS.

      w_subrc_cat = sy-subrc.

      CHECK ( w_subrc_all = 0 OR w_subrc_cat = 0 ).

*____ Finally, we get the rights for the current pair of

  •     category/subcategory

      LOOP AT pt_autoris INTO wa_autoris

                         WHERE auth  = wa_profile-auth

                           AND field = ‘ACTVT’.

        CASE wa_autoris-von.

          WHEN ’01’. ”      Create or generate

            wa_actvt_user-create  = ‘X’.

          WHEN ’02’. ” Change

            wa_actvt_user-change  = ‘X’.

          WHEN ’03’. ” Display

            wa_actvt_user-display = ‘X’.

          WHEN ’06’. ” Delete.

            wa_actvt_user-delete  = ‘X’.

          WHEN ‘*’.

            wa_actvt_user-create  = ‘X’.

            wa_actvt_user-change  = ‘X’.

            wa_actvt_user-display = ‘X’.

            wa_actvt_user-delete  = ‘X’.




    APPEND wa_actvt_user TO pt_actvt_user.


And the result using an iterator for display enhancements:



I hope you get now a fair idea of how xRPM authorization is working, and a nice BSP application to visualize those of your users!


The author would like to thank Thomson for the courtesy of the code given in this article and for the support they have provided me with during the last 7 months.

You must be Logged on to comment or reply to a post.
  • Way to go Guillaume Garcia!
    I just visited the xAPPs forum and see how busy and helpful you have been these last few weeks, there.
    /message/1197276#1197276 [original link is broken]

    It’s wonderful to have community insights and support concerning xRPM.

    Keep blogging and sharing.  Hope others will weigh in on the value of these contents!