The Access Control Engine (ACE) plays an important role in your SAP CRM system because traditional role-based authorization can’t always fulfill complicated business requirements. Compared to transaction PFCG (maintain SAP roles) roles, the ACE provides authorization on a much more granular control level. You can base your control on the master data, the relationship between master data, the transaction data, or even the logic/relationship defined by your own custom requirements.

The ACE is especially useful in the business context of a channel partner portal because a channel partner logs on to the supplier’s website to place the order. Each channel partner should only see its own customers or transactions. I elaborate on the steps you need when you want to use the ACE to control the object-level authorization for your project and you want to maximize your flexibility using customer coding. I use a simple example in which you want to manage the authorization of four customers belonging to two dealers. The two dealers should only have access to their own customers. The configuration and coding in the example are all based on SAP CRM 7.0 (though it is worth noting that some of the features I mention are available starting in SAP CRM 5.0).

The Basics Behind ACE

You can see the basic concept of the ACE in Figure 1. These are the elements involved:

• User: The SAP system user
• ACE ABAP class: SAP delivers several classes that model typical business scenarios. You should create your own Z class for your business requirements. The ACE ABAP class contains all the control logic of authorization. In almost all cases, the SAP standard class does not fulfill your requirements, but it is a good example to reference when you develop your own Z class.
• Object: The object to which the ACE controls the user’s access. For example, it could be a business partner, product, or business transactions.
• Actors: Actors may or may not have a real business meaning. For example, an actor can be the dealer number that has a real business meaning behind it, but an actor could also be simply character X (without any real business meaning). An actor is derived from the individual user and the individual object. When the actor matches, the user has the authorization to access the object.

Figure 1

The ACE concept (if “Yes,” authorization is allowed; if “No,” authorization failed)

To better illustrate this concept, I’ll use an example. Suppose there is a company that sells its goods through dealers. The dealer can log on to the SAP CRM system to browse and maintain its end customer, but the dealer should only able to see its own customer. To control the dealer access to business partner data, you can design the ACE as shown in Figure 2.

Figure 2

Dealer ACE control (if “Yes,” authorization is allowed; if “No,” authorization failed)

The elements involved are:

• User: The dealer user who uses the SAP CRM system
• ACE ABAP Class: For each user, it returns the dealer number to which the user belongs. For each business partner, it returns the dealer assigned to that business partner.
• Object: The object here is the end customer the dealers maintain through the SAP CRM system
• Actors: The actor in the current business context is the dealer number. If the dealer number from the user matches the dealer number from the business partner, the user is able to maintain and view the business partner.

Next, I’ll go through the entire ACE setup process using this business case — a sample dealer logging on to the supplier’s SAP CRM system to manage end customers.

A Simulated Business Case

The first step is to set up the master data I describe in this section in your system. Most of this master data should already exist in an IDES system. Even if you are not using an IDES system or if your IDES system is missing certain data, it should be very easy for you to set up something similar.

For this example, you have two dealers. The two screens shown in Figure 3 are for two business partners that are the dealers for your company. (Note that all the company names and information I use in my examples are fictitious.) If you are not using IDES, you can easily use transaction code BP to find existing business partners as long as they are companies. Click the Relationships button at the top of the BP screen to navigate to the business partner relationships screen.

Figure 3

Business partner screens for two dealers

Dealer 1190 already has three end customers in the system. If the relationship doesn’t exist in your system, you can create the relationship Had End Customer (technical name CRME02) with three existing business partners as shown in Figure 4. On the other hand, dealer 3558 has one end customer in the system (Figure 5).

Figure 4

Sample end customers for dealer 1190

Figure 5

End customer for dealer 3558

In this example, the employee responsible relationship is used to model the employee relationship between the dealer and the dealer’s employee (though the business meaning for the employee responsible relationship is a little different, as it is originally supposed to model the relationship between salespersons and their responsible account). In my example, Business Partner 4002111 (Hansen Chen) (Figure 6) is mapped to user HCHEN (Figure 7). If you want to test in your own system, you need to set up a business partner as an employee and map that business partner to a user in your system.

Figure 6

Employee of 1190

Figure 7

Business partner mapped to system user

Later in this article, you use this user (HCHEN in my example) for testing purposes. In summary, according to the master data I’ve shown so far, dealer employee Hansen Chen should only have access to dealer 1190’s end customers.

Step-by-Step Coding

The code in the ACE ABAP class is a very important step in the whole ACE setup process. It contains all the business logic that controls the access to different objects. The Z class you create should inherit three interfaces (Figure 8), and you should overwrite all five methods (Figure 9) provided in the three interfaces. 

Figure 8

Three interfaces you need to inherit

Figure 9

Five methods you need to overwrite

In the method GET_ACTORS_FROM_USER, you need to put in the logic for how to derive the actor from the user. For this example, you want to return the dealer number according to the employee responsible BUR011 relationship (Figure 10). Note that you can customize all example code in this article so it is applicable to your particular system.

method IF_CRM_ACE_ACTORS_FROM_USER~GET_ACTORS_FROM_USER.

  DATA: ls_actor         TYPE crms_ace_actor_id.
  DATA: lv_partner       TYPE bu_partner,
        ls_bupa_ok       TYPE bu_partner,
        lt_bupa_ok       TYPE TABLE OF bu_partner,
        ls_partner       TYPE crmt_partner_external_wrk,
        lv_user_bp       TYPE bu_partner,
        lv_user_bpguid   TYPE bu_partner_guid.
  DATA:
    lt_messages   TYPE STANDARD TABLE OF crmt_isales_return
                       WITH DEFAULT KEY.

  CALL FUNCTION 'CRM_ISA_IUSER_GET_BP_TO_ALIAS'
    EXPORTING
      username              = IM_USR_NAME
    IMPORTING
      business_partner      = lv_user_bp
      business_partner_guid = lv_user_bpguid
    TABLES
      messages              = lt_messages.
  CHECK lv_user_bp is not initial.
  SELECT partner1 INTO TABLE lt_bupa_ok
  FROM but050
    WHERE reltyp = 'BUR011'
      AND partner2 = lv_user_bp
      AND xrf = space
      AND date_to >= sy-datum
      AND date_from <= sy-datum.

  LOOP AT lt_bupa_ok INTO ls_bupa_ok.

    CLEAR ls_partner.
    SELECT SINGLE partner_guid INTO ls_partner-bp_partner_guid
    FROM but000
      WHERE partner = ls_bupa_ok.

    IF sy-subrc = 0.

      ls_actor-actor_id = ls_partner-bp_partner_guid.
      APPEND ls_actor TO ex_actor_id_table.

    ENDIF.

  ENDLOOP.

endmethod.

In the method GET_ACTORS_FROM_OBJECT, you need include the logic on how to derive the actor from the object (business partner). For this example, you want to return the dealer number according to the end customer CRME02 relationship (Figure 11).

method IF_CRM_ACE_ACTORS_FROM_OBJECT~GET_ACTORS_FROM_OBJECT.
  DATA: ls_actor         TYPE crms_ace_actor_id.
  DATA: lv_partner       TYPE bu_partner,
        lv_bupa_guid     TYPE bu_partner_guid,
        ls_bupa_ok       TYPE bu_partner,
        lt_bupa_ok       TYPE TABLE OF bu_partner,
        ls_partner       TYPE crmt_partner_external_wrk.
  lv_bupa_guid = im_object_guid.

  SELECT SINGLE partner FROM but000 INTO lv_partner
  WHERE partner_guid = lv_bupa_guid.

  IF sy-subrc <> 0.
    RETURN.
  ENDIF.

  SELECT partner1 INTO TABLE lt_bupa_ok
  FROM but050
    WHERE reltyp = 'CRME02'
      AND partner2 = lv_partner
      AND xrf = space
      AND date_to >= sy-datum
      AND date_from <= sy-datum.

  LOOP AT lt_bupa_ok INTO ls_bupa_ok.

    CLEAR ls_partner.
    SELECT SINGLE partner_guid INTO ls_partner-bp_partner_guid
    FROM but000
      WHERE partner = ls_bupa_ok.

    IF sy-subrc = 0.

* Return Dealer
      ls_actor-actor_id = ls_partner-bp_partner_guid.
      APPEND ls_actor TO ex_actor_id_table.
    ENDIF.
  ENDLOOP.
endmethod.

The GET_OBJECTS_BY_FILTER method returns all the objects that are controlled by the current business rule. For testing purposes, you only want to control the two example dealers, so select all the end customers belonging to the two dealers in this method (Figure 12). Typically, you would select a set of business partners/business transactions according to business partner group or business transaction type.

method IF_CRM_ACE_OBJECTS_BY_FILTER~GET_OBJECTS_BY_FILTER.
  DATA: lv_partner       TYPE bu_partner,
        lv_partner2       TYPE bu_partner,
        lv_object_guid   TYPE CRMS_ACE_OBJECT_GUID,
        ls_bupa_ok       TYPE bu_partner,
        lt_bupa_ok       TYPE TABLE OF bu_partner,
        ls_partner       TYPE crmt_partner_external_wrk.
  lv_partner = '0000001190'.
  lv_partner2 = '0000003558'.
  SELECT partner2 INTO TABLE lt_bupa_ok
  FROM but050
    WHERE reltyp = 'CRME02'
      AND ( partner1 = lv_partner or partner1 = lv_partner2 )
      AND xrf = space
      AND date_to >= sy-datum
      AND date_from <= sy-datum.
  LOOP AT lt_bupa_ok INTO ls_bupa_ok.
    CLEAR ls_partner.
    SELECT SINGLE partner_guid INTO ls_partner-bp_partner_guid
    FROM but000
      WHERE partner = ls_bupa_ok.
    IF sy-subrc = 0.
      lv_object_guid-OBJECT_GUID = ls_partner-bp_partner_guid.
      APPEND lv_object_guid TO EX_OBJECT_GUID_TABLE.
    ENDIF.
  ENDLOOP.
endmethod.

The CHECK_OBJECTS_BY_FILTER method checks whether the passed object should be controlled by the rule or not (Figure 13). This particular code is a simplified version of what you should have in your system, because this example only controls access to four end customers. This method is mandatory for ACE implementations, but the code in Figure 13 should not be used in real scenario because the GET_OBJECTS_BY_FILTER method usually returns a large set of data (i.e., not four). You should write a more performance-effective version of this sample code.

method IF_CRM_ACE_OBJECTS_BY_FILTER~CHECK_OBJECTS_BY_FILTER.
  data: lt_guid TYPE CRMT_ACE_OBJECT_GUID,
        ls_guid type CRMS_ACE_OBJECT_GUID.
  CALL METHOD ME->IF_CRM_ACE_OBJECTS_BY_FILTER~GET_OBJECTS_BY_FILTER
    IMPORTING
      EX_OBJECT_GUID_TABLE = lt_guid.
  loop at im_object_guid_table into ls_guid.
    read table lt_guid with key object_guid = ls_guid-OBJECT_GUID transporting no fields.
    check sy-subrc = 0.
    append ls_guid to ex_object_guid_table.
  endloop.
endmethod.

GET_ACTORS_FROM_OBJECTS is almost the same as GET_ACTORS_FROM_OBJECT. The only difference is that this method is passed in multiple objects. In Figure 14, the GET_ACTORS_FROM_OBJECT method is used to check the authorization for each object passed through parameter it_object_guids. In this example, they are the business process GUIDs.

method IF_CRM_ACE_ACTORS_FROM_OBJECT~GET_ACTORS_FROM_OBJECTS.
  DATA: ls_order_guid         TYPE crms_ace_object_guid,
        ls_actor_ids          TYPE crms_ace_object_actors,
        lt_actors             TYPE crmt_ace_actor_id,
        ls_actor              TYPE crms_ace_actor_id.
* Loop at Guids
  LOOP AT it_object_guids INTO ls_order_guid.
    CLEAR: ls_actor_ids, lt_actors[].
    MOVE ls_order_guid-object_guid TO ls_actor_ids-object_guid.
* Get actors from single object
    CALL METHOD me->if_crm_ace_actors_from_object~get_actors_from_object
      EXPORTING
        im_object_guid    = ls_actor_ids-object_guid
      IMPORTING
        ex_actor_id_table = lt_actors.
    IF NOT lt_actors IS INITIAL.
      MOVE lt_actors TO ls_actor_ids-actors.
      APPEND ls_actor_ids TO et_actor_ids.
    ELSE.
      APPEND ls_order_guid TO et_failed_objects.
    ENDIF.
  ENDLOOP.
endmethod.

Define the Rule

After you finish the coding, you need to configure and activate the ACE process in the IMG. First, configure the ZABAP ACE class by following IMG menu path Customer Relationship Management > Basic Functions > Access Control Engine > Rules > Create Rules.

After you enter the Create Rules configuration, double-click Add AFO Class on the left side of the screen. Then, click the New Entries button at the top of the screen. Enter the information as shown in Figure 15. The actor for object (AFO) class corresponds to the ABAP interface IF_CRM_ACE_ACTORS_FROM_OBJECT. For this example, you should use the existing object type and actor type. The object type is important because the system needs to know which object the class is going to manage. For this example, it is the business partner, so you should use the preconfigured object type ACCOUNTCRM. The actor type is important because the system needs to know what kind of actor the class returns. For this scenario, you want to return the business partner GUID as the actor, so you should reuse the existing standard BUSINESS_PARTNER actor type.

Figure 15

Configure AFO class

The Object by Filter (OBF) class corresponds to the ABAP interface IF_CRM_ACE_OBJECTS_BY_FILTER (Figure 16). You can reuse the SAP standard object type here.

Figure 16

Configure OBF class

The Actor from User (AFU) class corresponds to ABAP interface IF_CRM_ACE_ACTORS_FROM_USER. You can reuse the SAP standard actor type (Figure 17).

Figure 17

Configure AFU class

After you have configured the ABAP class in the system, you need to define a rule that integrates all three interfaces together. Enter the required information as shown in Figure 18. After you finish this step, save your work and exit the configuration screen. You have finished defining a rule in the system.

Figure 18

Configure the rule ID

Define the Right

A right connects the rule you defined in earlier steps and the user group that contains the user that is activated for the rule. To create a right, the first step is to define a work package by following menu path Customer Relationship Management > Basic Functions > Access Control Engine > Create Rights (Figure 19). The work package is the container of object type you want to activate. You must assign the object type to the work package as shown in Figure 20.

Figure 19

Define the work package

Figure 20

Assign object type to work package

Next, you need to define the user group (Figure 21). The user group is the container of the user, role, or subuser group you want to include in the right. In addition, it contains the work package ID associated with the user group. In the screen shown in Figure 21, you need to enter the user group ID (which is freely definable) and the work package ID you want to associate with the user group.

Figure 21

Add the user group

For this example, I only want to activate it for one user (HCHEN). Therefore, there is only one user contained in user group Z_DEMO, which you can enter in the User Group Entries folder under User Group Definition in the Dialog Structure (Figure 22).

Figure 22

Assign a user to a user group

Right definition integrates the rule, user group, and object type (Figure 23). It tells the ACE which object type (the object you are currently managing), rule ID (the code to manage the business logic), user group (the user managed by the right), and action group ID (typically ACT_GRP_FULL, which means you can display, change, and delete objects with the right) are used for this right.

Figure 23

Configure right ID

Activate and Test the ACE

After this configuration, you can activate the ACE based on your business rule. However, before you do this you need to set up the ACE_DISPATCHER job in transaction SM36 (Figure 24). This job is necessary because of mechanisms that were changed starting with SAP CRM 5.0. It also improves the performance of the entire ACE framework. In transaction SM36, first define a job with the name ACE_DISPATCHER and leave everything else as default. Then, define a step with program CRM_ACE_DISPATCHER (Figure 25). Back in the screen shown in Figure 24, set the start condition under After Event as SAP_CRM_ACE_DISPATCHER_REQUEST with a parameter equal to the client number for which ACE should be activated (100 in my example).

Figure 14

Define the job

Figure 25

Define steps inside the job

Now you can officially activate the ACE by following menu path Customer Relationship Management > Basic Functions > Access Control Engine > Activate/Deactivate Work Packages and Rights. First, activate the user group by clicking the Activate All User Groups button at the top of the tab (Figure 26). Notice that you only have one user under this user group. Next, select the Rights tab and activate the right by clicking the Activate Selected Right(s) button (Figure 27).

Figure 26

ACE activation for user group

Figure 27

Activate the right

You can monitor the progress of the activation in the Monitoring tab. Keep in mind that in the GET_OBJECTS_BY_FILTER method of the Z class, you only returned the end customers belonging to dealers 1190 and 3358. Therefore, the total number of objects (end customers belong to the two dealers) controlled by this right is four (Figure 28). This monitoring screen is useful when you activate a large ACE object.

Figure 28

Monitor the activation

To test, log in to the CRM WebClient UI as Hansen Chen (HCHEN) or your own sample user name and perform an open search on the account. You’ll find that the only accounts you have access to are the three end customers that belong to dealer 1190 (Figure 29). This is because this sample user only has the employee responsible relationship to dealer 1190.

Figure 29

Test in the CRM WebClient UI

Hansen Chen

Han (Hansen) Chen is a manager with PricewaterhouseCoopers’ SAP CRM practice. He has more than seven years of experience in the SAP CRM field and has finished more than 10 SAP CRM projects, on most of which he played a technical lead role. His project management experience includes managing more than 10 onsite/offshore developers and managing multiple project development teams in parallel. Han holds a PMP certification and has profound knowledge of CMMI methodology. He earned his bachelor’s degree in MIS from Tongji University, China.

You may contact the author at han.chen@us.pwc.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.