Say you are an SAP CRM user and want to search for a customer, but you know only part of the name. This is not a problem if you just have thousands of customers in your SAP CRM system. It is also not a problem if you are responsible for customers in just one sales area and your authorizations are set up to limit the results of your search query. However, what if you have millions of customers or you are responsible for customers across multiple sales areas and your search result lists contain irrelevant customers? It would be more efficient if the user’s authorizations could adapt to the user’s role.

To satisfy these requirements, SAP created Access Control Engine (ACE), which controls what you can view, modify, and delete by using rules. For example, a typical rule is that users can view all customers who belong to their sales areas, but only modify those they are linked to as the responsible employee. In addition to focusing searches, ACE allows you to control what external agents can view in your system. Also, if your organizational model changes, ACE allows your sales representatives to view updated customer lists automatically. To compare this to Basis authorizations, see the sidebar, “How ACE Differs from Basis Authorizations.”

I’ll explain the components of ACE — the actors, rules, user groups, and rights. Then, I’ll explain how to create custom rules so you can use ACE in CRM Sales and Service scenarios. In the standard delivered ACE content you have only user groups and rules that are designed for Partner Channel Management and contain relationship types that are specific to Partner Channel Management. This means that you cannot use the ACE rules out of the box in standard CRM Sales and Service scenarios. In this case, you must create your own rules by copying the standard SAP rules.

I’ll also describe how to activate the rules in ACE and show how they work during runtime. Finally, I’ll share some lessons learned from recent ACE projects. ACE works only with People-Centric User Interface (PCUI). You can use ACE in all SAP CRM versions in which PCUI is delivered, including SAP CRM 4.0 and 2005.

Actors, Rules, and User Groups

The central concept of ACE is the actor — this is the characteristic the user and the object to authorize have in common (Figure 1). Each actor follows rules, which describe what the actor is, how to get from the object to the actor, and how to get from the user to the actor (Figure 2). This is best explained by three example rules:

• Users are allowed to view, modify, and delete business partners in their countries. A user has an address containing a country. Business partners also have an address containing a country, so the actor in this rule is the country.
  
  
• Users are allowed to view, modify, and delete business partners in their sales areas. Typically users are employees who are assigned to a certain level in the organizational model. This level represents a sales area. Usually you also create business partners for a specific sales area, so the actor in this rule is the sales area. With this rule a user can view the sales area data of all business partners who belong to the same sales area as he does. According to this rule, you cannot view business partners who are not linked to a sales area.
  
  
• Users are allowed to view, modify, and delete business partner activities for which they are responsible. These activities have a linked business partner who has a “responsible employee” relationship with the user. The actor in this rule is the user.

Figure 1

Example of an actor, in this case the country, which is part of the user and part of the object

Figure 2

Example of a rule that allows users to see all business partners who are in the user’s country

Rights

The next concept of ACE is the rights you grant users to determine what the user can do with a certain rule: view, modify, or delete. A right consists of a rule plus what you can do with the objects matching the rule (view, modify, or delete). For example, in Figure 2, the user can only view business partners who are in the same country. This implies that users can have multiple rights for the same type of objects. For example, you can view all customers in your sales area, but only modify those to which you are assigned as the responsible employee.

A collection of rights forms a logical user group. For example, user group xyz - In-house user can view all business partners, activities, orders, and products in their sales area, but only modify the business partners, activities, and orders for customers for which they are responsible. You can link the logical user group to individual users, but a better practice is to link them to a regular authorization role, which can be a dummy role. You then link this authorization role to the actual users for which the ACE roles will be active (Figure 3).

Figure 3

How to link the ACE rules to the user

How to Create Custom Rules

I recently had to create some custom rules for a large company. One of these rules was to establish the link in SAP CRM between the customer and the sales representative (the CRM user) in the partner roles in SAP ERP Central Component (ECC). The system downloads the link automatically from ECC to SAP CRM. This rule allows ACE to determine which customers the users can view. Moreover, when the sales representative assignments change in ECC, ACE automatically updates which customers the user is allowed to see in SAP CRM.

As I go through the different steps I will use the example of creating a rule that allows users to see and modify all of the prospects that are in their country. This is the same example as shown in Figure 2.

Implementing a custom rule requires customizing and writing simple ABAP coding. This coding consists of five custom class methods that you create by copying an existing class. This also is the first step to configure a new ACE rule because you have to specify the name of this class in the customizing settings. In this step, you define the business rules and the environment by determining the following:

• Which types of users do you have (focused on authorizations)?
  
  
• On which objects do you need to set authorizations?
  
  
• Which user group is allowed to perform what action?
  
  
• What are the actors, rules, and rights?

The configuration of rules requires you to enter the ABAP class and method that the system should execute when it invokes the rule. For this reason, you must create the necessary code shells in which to input the code. Later in the process you code the specific logic required to realize your custom rule. To create these code shells, go to transaction SE24, look up a class that starts with CL_CRM_ACERULE*, and copy it to a custom class, in my example, ZCL_CRM_ACERULE_BPCOUNTRY (Figure 4). Leave all the input/output parameters as they are — for now you just need the name of the class to start customizing it.

Figure 4

Create a custom class

Next, access ACE by following IMG menu path Customer Relationship Management>Basic Functions>Access Control Engine. You can perform all of the customizing here, except for the actual coding of the methods. You start by creating the actor under Actors>Create actor types (Figure 5). For my example, I created the actor type ZCOUNTRY.

Figure 5

Create the actor ZCOUNTRY

Go to Actors>Link Object type with actor type to link the new actor to the object type (Figure 6). You can implement ACE for three types of business objects: accounts, one-order objects (e.g., orders, activities, opportunities, leads, or contracts), and products/services. This means that you cannot use ACE in marketing scenarios — you can use it only in sales and service scenarios in PCUI.

Figure 6

Link ZCOUNTRY to the object type ZBPCOUNTRY

In my example, the object type is account — also known as business partner — (ACCOUNTCRM). You also have to specify how to find the actors for the users — in my case, how to find the country of each user. Go to Actors>Actor determination for user. Define the class you created before so that the system uses the actors for user (AFU) method for your class (Figure 7). In the Actor Type ID field, enter ZCOUNTRY as the descriptive name for this method and enter GET THE COUNTRY OF THE USER in the AFU description field.

Figure 7

Enter the AFU method for your class

Next, tell the system which subset of business objects to take into account. In the Object by filter field, enter BP_WHO_ARE_CONSUMERS (Figure 8). This determines which objects the system takes into account when activating the ACE rule for the first time.

Figure 8

Specify the subset of business objects the system should consider

As I describe later, ACE uses runtime tables to store information about who is allowed to see which object. The system initially fills these tables when you activate the rule. For better performance, limit the set of objects for which the system determines actors. In my example, my rule only applies to prospects — I do not want the system to determine the country for all customers. This implies that the users attached to this rule can only maintain prospects and not customers.

Now I am ready to create the rule under Rules>Create Rules. Apart from a name and a description, a rule consists of four elements (Figure 9):

• The type of actor used
  
  
• A description of the method that determines the actor of the user
  
  
• A description of the method that determines the actor of the object
  
  
• A description of the method that determines which subset of objects to take into account

Figure 9

The main elements of the rule

The next step in the customizing is to create the right. As I explained earlier, the right describes which action (view, modify, or delete) you can perform with the objects of a certain rule. You can find the customizing for this by following menu path Rights>Create Rights (Figure 10). In this screen provide the right a name, specify the Object Type, User group, and the Action Group ID. The Action Group ID specifies the possible actions shown in Table 1. To define the user group mentioned in Figure 10, follow menu path User Groups>Create User Groups (Figure 11). You can have multiple rights for the same user group.

Figure 10

The elements of the right

Figure 11

The properties of a user group

The last customizing step is to link the user group to a Basis authorization role, which administrators can then link to the users. Follow menu path User Groups>Assign Users to User Groups (Figure 12). In the User group child field, enter the SAP Basis authorization role. A common practice is to create an empty dummy SAP Basis role from the SAP Basis authorization perspective. The dummy role contains no SAP Basis authorization objects and is used solely for ACE. As soon as a user has an SAP Basis role assigned, which you link in this customizing transaction to an ACE user group, ACE is active for this user.

Figure 12

Link the ACE user group to an SAP Basis authorization role

Now let’s look at the ABAP methods used in the classes. The last three elements of the ACE rules (actors from user, actors from object, object by filter) refer to the methods of the ABAP class I defined at the beginning. This requires some basic ABAP programming, so it helps if you know the function modules used in SAP CRM. To give a rough indication of the ability you’ll need, usually the number of lines of coding in an ACE method does not exceed 100 lines. Figure 13 shows the Class Builder screen (transaction SE24) for my custom class. There are always five methods, which you can group in three groups as shown in Table 2.

Figure 13

Class Builder screen for ZCL_CRM_ACERULE_BPCOUNTRY

It is important to understand the difference between methods 3a and 3b. The system calls method 3a when the system administrator activates the ACE rule and when the engine builds up the tables used during runtime. The system determines the actors for a large result set that it gets as input from the methods 1a and 1b. The system calls method 3b when a user creates a new business object in the system and it must update the ACE with this new object. In my example, when you create a new prospect, you need to determine the country and store the country as an actor linked to the new prospect in the runtime tables (Figure 14).

Figure 14

When activating a rule the ACE engine uses the GET_ACTORS_FROM_OBJECTS method

Activate a Custom Rule

After you finish all of the customizing and developments and link the users to the ACE groups either directly or via a regular authorization rule, you are not completely there. You have to activate the user groups and the rights with the CRM ACE Administration tools (transaction CRM_ACE_ADM), shown in Figure 15.

Figure 15

CRM ACE Administration tools

On the User Group Administration tab, select the user group and press F8 to activate it. Then, on the Rights Administration tab, activate the rights by selecting the custom right and pressing F8. When you activate the right, ACE builds up its runtime tables. These tables contain authorization data that the system uses during runtime, for example, when users search for prospects. If it didn’t do this, ACE would have to calculate all of the rules for every business object for every action. This would impact response times significantly. With the activation, it builds up to three tables per object type so that during runtime, the system can check the authorizations quickly.

Table 3 lists the tables for the three business objects involved in ACE. In this table, you can replace the XX with BP for business partners, OO for one-order objects — such as activities, orders, opportunities, and leads — or PR for products. From these tables you can see how ACE works internally — it knows your users and reads your ACE group IDs in the user context table (*UCT). Then, in the access control list table (*ACL), it reads all of the objects you are allowed to see.

How Does ACE Work During Runtime?

Function modules in the PCUI coding check which objects the user is allowed to see. For example, if you perform a search query on business partners, the system calls ACE. This call checks the runtime tables mentioned in Table 3. It also builds up a session cache for performance reasons because some processes call ACE often for the same object (Figure 16). These ACE calls are divided into two steps: first check if the object is in the cache, if not, then check the tables in the database.

Figure 16

The runtime access to the cache and database

Lessons Learned

Here are some lessons learned from a recent ACE implementation:

First write down exactly what needs to be done. Write down and illustrate the link between the users and the objects and how they relate via the actor. Then write down which rules and methods to create. This makes it easier to spot methods that you can reuse in different rules or rules that can cover multiple scenarios.

Know when to rebuild customer tables to avoid database performance issues. When you build up the runtime tables for the first time, the system determines the actors for all relevant objects. If you have many customers, the system determines all of the actors for every single customer. Therefore, it is important to program this process efficiently. In some cases, you may need to rebuild the tables, which can make ACE perform inconsistently. For large databases with millions of leads or orders it can take a couple of days if you do not focus on the performance aspects.

Know when to rebuild the access control list (ACL). There are two types of rebuilding: rebuilding the user contexts and rebuilding the object’s ACL. You must rebuild the user contexts every time you create a new user or change the roles or actors of an existing user. With ACL, the process is different because ACE also has logic that determines the actors when you create an object. The same logic re-determines the actors when you change an existing object, so it’s rare that you need to rebuild the ACL.

The only exception is what I call second-level relationships, which are relations a user has to an object via another object. For example, a user could be the employee responsible for a certain set of customers. These customers have contact persons, as illustrated in Figure 17. It makes sense that the user is also allowed to see the contact persons for these customers.

Figure 17

Example of a second-level relationship

You can configure a rule for your prospect’s contact persons so that the employees who can view the prospects can also view the related contact persons. After building up the runtime tables, the system determines the actors for all contact persons. However, when the country of a customer changes, this is a change transaction for a customer that re-determines the actors for this customer. It is not a change transaction for all linked contact persons, so it does not re-determine the actors for all linked contact persons.

Therefore I recommend that you rebuild the ACL on a regular basis and make sure to rebuild it when organizational changes occur. You can schedule the automatic jobs for rebuilding within the ACE Administration tools (transaction CRM_ACE_ADM).

Boris Dingenouts

Boris Dingenouts is a senior SAP CRM consultant for the Dutch consulting company Exxap. Boris has more than 11 years of consulting experience in SAP, with more than six years in SAP CRM. Exxap is an innovative SAP consultancy company with a focus on SAP xApps.

You may contact the author at boris.dingenouts@exxap.com.

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