You have fully set up the Access Control Engine (ACE) 7.0 in your SAP CRM system. Now that it’s done, should you simply dive in? Not quite yet — it’s best to start using ACE only after you understand a few key points about its architecture, design, and potential user interaction issues. I’ll describe some common problem areas and show you how to troubleshoot them effectively. I’ll also provide tips on large data sets and what can change in the ACE if you upgrade SAP CRM.

ACE Tables

Tables are often what you should examine first to understand a framework technically. There are many tables in the Access Control Engine (ACE) framework. I’ll describe some of the key tables you should know.

ACE authorization tables are a set of three tables that you can set up at the superobject type level. You can reuse the existing authorization table, but you also have the option of creating your own set of authorization tables (this process is beyond the scope of this article, however). Figure 1 shows a set of existing SAP standard authorization tables you can review by following IMG menu path Customer Relationship Management > Basic Functions > Access Control Engine > Rules > Create Rules. You can also define your own superobject type and the corresponding ACE authorization tables here. Next I’ll take a detailed look at the three authorization tables in Figure 1 so you understand the information stored in them.

Figure 13

ACE authorization fail in the CRM WebClient UI

The User Context table (UCT): Use transaction code SE11 to open the first of these tables, table CRM_ACE2_BP_UCT (Figure 2). The UCT stores the user and the calculated ACE group ID, which is a combination of the actor ID and the right ID.

Figure 2

UCT

The Access Control List (ACL) table: The ACL table stores the object (for your scenario business partner) and the calculated ACE group ID (Figure 3). When the ACE group ID stored in this table matches the UCT, the user is authorized to access the object.

Figure 3

ACL table

Group (GRP) table: This table stores the ACE group ID and its corresponding combination of the right ID and actor ID (Figure 4). Although the ACE group ID is stored in both the UCT and ACL table as well, the system needs the GRP table to tell it which right and actor (for this scenario, the actor is the dealer number) the ACE group ID belongs to. This is because there can be different right IDs activated in your system at the same time for different purposes. ACE group ID is a pure system field (field name ACEGROUP_ID in Figures 2, 3, and 4) that doesn’t have any business meaning behind it. The GRP table translates the group ID to fields with business meanings.

Figure 4

GRP table

You should also know about the ACE work list table, a new concept as of SAP CRM 5.0. When you changed a business partner in older versions of SAP CRM, the ACE table was recalculated in an update task. Therefore, if you had a mass update program that changed 10,000 business partners simultaneously, the system would often hang due to the triggering of the update task. SAP improved this scenario with a work list table. Whenever there is a recalculation need — for example, in a business partner change (Figure 5, showing table CRM_ACE2_OBJ_WL) or right ID activation (Figure 6, showing table CRM_ACE2_RIG_WL) — the SAP system puts an entry in the work list table. These table entries are picked up later by the job ACE_DISPATCHER. For instructions on how to set up this job, refer to my article “Best Practices for Setting up Access Control Engine 7.0.” With this new work list functionality in place, your system performance is greatly improved.

Figure 5

Object recalculation work list table

Figure 6

Right activation work list table

Another table of note is the ACE user table. This table stores the user currently activated for the ACE (Figure 7). If a user is not listed in this table with the IS_ACTIVE column set to X, the user bypasses all the ACE logic. That is to say, the user will run SAP CRM without any authorization check conducted by ACE.

Figure 7

ACE user table

Troubleshooting Tips

I’ve often been asked “Why can the user see this business partner?” or “Why can’t the user see this partner?” It will be easy for you to answer these questions if you check common trouble areas. You can follow these steps for troubleshooting:

Step 1. Make sure parameter ACE_IS_INACTIVE is not set to X (this parameter turns off the ACE system wide). You can do this via IMG menu path Customer Relationship Management > Basic Functions > Access Control Engine > Maintain General Parameters.

Step 2. Check whether the user is active in CRM_ACE_USERS. If not, the user is not controlled by the ACE.

Step 3. Test with your Z ABAP class to ensure the actors derived from the user and object are the same. If not, your business rule coded in the Z class doesn’t allow the access.

Step 4. Check the ACE work list table to see whether there is any pending calculation needed. If yes, check whether the job ACE_DISPATCHER is scheduled.

Step 5. Check the ACE authorization tables (i.e., CRM_ACE2_BP_ACL, CRM_ACE2_BP_UCT, and CRM_ACE2_BP_GRP). Check whether they failed because the user actor or object actor is stored incorrectly.

• If they fail because the user actor was stored incorrectly, check the LAST_UCT_CALC column in the CRM_ACE_USERS table to find out the last calculation time of the user context. You might need to refresh the user context manually.
• If they fail because the object actor was stored incorrectly, check the business partner create/change scenario to find out why the ACE is not refreshed during it. You can refer to the “ACE User Interaction Analysis” and “ACE Design Considerations” sections later in this article for more information.

Step 6. Review the SAP runtime report (transaction ACE_RUNTIME). SAP also provides this very useful analysis report as a way to simplify the above troubleshooting steps and provide a one-stop troubleshooting tool. You should know both the benefits and limitations of this tool to avoid misinterpretation of the information it provides:

• Benefits: The tool has a much more user-friendly interface than the above troubleshooting steps, including:
  • Easy selection of the information you want to verify in the selection screen (Figure 8). All the fields are search help enabled. There is no need to look up all the Global Unique IDs (GUIDs) in the database.
  • Meaningful output (Figure 9). The tool tells you not only the GUID/business partner number but also the business process that facilitates the troubleshooting. It also provides useful information such as the last update date and the last type of processing, which helps you understand why the recalculation went wrong.
  • You can trigger the recalculation directly from the report with the Send to Update Tool button (Figure 9)

Figure 8

ACE Runtime Report selection screen

Figure 9

ACE Runtime Report results screen

• Limitations: Even though the tool can be very useful, it may cause confusion for the following reasons:
  • It does not tell you why the authorization is missing (e.g., whether it is because of user authorization calculation or object context calculation)
  • It does not have the last user recalculation time, which is often a key factor for authorization error
  • If you find the authorization is missing but you are not sure why, you may need to go through manual troubleshooting steps

These troubleshooting steps are useful in both project implementations and day-to-day operations. You’ll find that particularly in complicated business environments, different ACE rules may control users and objects.

ACE User Interaction Analysis

You can analyze several user interaction scenarios related to the ACE to understand it better. Here are some example scenarios:

• A user logs on to the CRM WebClient UI and tries to open a business process: In this scenario, the user context’s last calculation time will first be read by the ACE framework. If the last calculation time exceeds the maximum (16 hours default), the user context is recalculated (method GET_ACTORS_FROM_USER will be triggered automatically by the system) and stored in the UCT. Then, the UCT, ACL, and GRP tables are read to determine the user’s authorization.
• A user creates or changes a business partner or a business partner relationship: The object context of the business partner is recalculated (method GET_ACTORS_FROM_OBJECT is triggered automatically by the system) and stored in the ACL table. This behavior causes some limitations on the ACE. I describe this in detail in the next section, “ACE Design Considerations.”
• A user performs an open search on business processes: All the business partners are retrieved from the database. Then, they go through the ACE logic 500 records at a time to filter out the business partner that the user can’t visit. This also causes some limitations on the ACE, which are also discussed under “ACE Design Considerations.”

ACE Design Considerations

When your company decides to adopt the ACE to meet the business requirements for access control, you should not only consider the benefits the ACE provides, but also the limitations the ACE can cause to your SAP CRM implementation (specifically in aspects such as performance and authorization accuracy). You can follow the guidelines in this section to avoid these limitations when you design your ACE.

First, always try to design the simplest ACE model that you can. For example, if you are using the ACE to control business partner access, limit the ACE logic to one level of the business partner relationship. Avoid calculating the actor based on several layers of the relationship because when a business partner relationship is changed, only the authorizations of the business partner directly associated by the relationship is recalculated by the ACE.

For example, say a salesperson is assigned to a customer and this customer has one employee assigned to them. According to your business requirements, only assigned salespeople can visit their customers and their assigned employees. If you want to obtain the actor of the customer’s employee, you may want to use the salesperson as the actor. In this case, you are using two levels of the relationship (i.e., you need to get the customer the employee belongs to first, and then get the sale person assigned to that customer). Based on the ACE logic I’ve described, the risk is that the employee’s ACE data belonging to the customer may not be recalculated when you reassign the customer to another salesperson. Instead, only the authorizations of business partners (i.e., the salesperson and customer) directly associated with the relationship (i.e., the assigned salesperson) are recalculated. You can include some additional code to recalculate the ACE authorization, but the maintenance effort sometimes overrides the benefit it provides.

If your particular business requirements make it necessary for you to design a complicated ACE model, the code in Figure 10 should be added wherever you need to recalculate object authorizations. (Note that you can customize this code for your particular system.)

Figure 10

Code for triggering ACE recalculation

Always consider the data size you want to manage with the ACE and the performance you are targeting. If you have one million sales people and each of them has 10 customers, you may want to think twice about how to adopt the ACE. Say in this scenario a salesperson does an open search on a business partner. He expects only his 10 end customers to pop up, and within one second. However, what actually happened in the background is that all 10 million records (10 customers each for one million sales people) are retrieved from the database; they are then run against the ACE table 500 records at a time. The whole process may take quite a few seconds. In this scenario, you should enhance the search framework to put in some additional criteria when the business partner is retrieved from database.

Deactivate or Activate Large Sets of ACE Data

If your company has a large set of ACE data, you may face some issues when you try to activate or deactivate the right ID:

• When you deactivate the right ID by triggering the deactivation (clicking the Deactivate Selected Right[s] button) as shown in Figure 11, you may see a program dump (i.e., an uncaught error in code). You also may see the number of records in the ACL or GRP tables decrease and then increase back to the original number. This is because the system is trying to delete the entire record set within one single commit in the program. The first solution you should try is using report CRM_ACE_CLEANUP_RUNTIME_TABLES directly. In this report, each record is deleted and committed individually. The only drawback is that with a large set of data, the report runs slowly. It may take hours for 20 million records, for example.

Figure 11

Deactivate ACE with the ACE activation tool

• When you deactivate the right ID and you are sure you don’t need anything in the GRP or ACL tables (i.e., the other right IDs can also be deleted), you can also use transaction SE14 to delete the data directly. This is very useful for finishing a clean refresh if you have a tight deadline.                                                                                 
• If you need to activate multiple right IDs sequentially (sometimes an entire activation can take over 10 hours) once you’ve activated the right ID,  you should select multiple lines at the same time and then click the Activate Selected Right(s) button (Figure 12). You should not select one line, click activate, and then select another line and click activate again one by one. By activating IDs one at a time, you sometimes see table interlock and program dump.

Figure 12

Activate multiple right IDs

Changes When You Upgrade

The ACE has been changed significantly between versions of SAP CRM. For example, SAP introduced the work list background job to improve the performance of the recalculation of ACE authorization in SAP CRM 5.0. In SAP CRM 7.0, SAP introduced the event triggering concept of the background job that allows a job to only be scheduled as needed. It is beyond the scope of this article to discuss all the differences between each version, so this section is based on an upgrade from SAP CRM 4.0 to SAP CRM 7.0. Upgrades between other versions may see only some of the effects I discuss next.

Although the changes in the ACE between versions are not as dramatic as changes to the CRM WebClient UI, SAP has improved the ACE’s usability, stability, and performance. The concept and most configuration tables remain the same, while the configuration screen has been changed to improve usability. Ideally, after an upgrade, you should go through the IMG to become familiar with the new configuration screen and ensure your configuration is still valid. Then, you can schedule a dispatcher job. After that, you should be able to activate your ACE right in the new version (this step is manual because the authorization tables changed between versions; SAP Note 825264 - ACE reorganizing after CRM 4.0 upgrade documents the steps). Also, you can use the upgrade as a chance to improve the ACE design, add new functionality, or clean up performance issues.

Here are several specific improvements you may notice when you upgrade SAP CRM to 7.0 from 4.0:

• Tables have been changed: SAP has changed the authorization tables that store ACE authorization data. The new set of tables has an additional “2” behind the ACE (Table 1). The fields in the new tables are almost the same. The main difference is that the GRP table field sequence was reorganized (the key and non-key fields were switched).

Table 1

Comparison of old and new ACE tables

• Performance improvements: As I mentioned earlier, the ACE framework has adopted the work list concept to enhance the performance of authorization recalculation
• Administration user interface (UI) has been improved: The new administration tool has a much better UI than previous versions. The most useful part is the monitoring tab, where you can calculate the approximate time it takes to finish the activation.
• Business logic improvements: SAP has put the ACE check in more places than it was previously, which makes the ACE a more robust framework. For example, when a user is manipulating a business transaction, he or she may see more warning messages displayed due to ACE authorization fails than in older versions (Figure 13). This is partially due to the switch from the People-Centric User Interface (People-Centric UI) to the CRM WebClient UI in SAP CRM.

Figure 13

ACE authorization fail in the CRM WebClient UI

• The main functionality stays the same: Despite the various improvements, the core functionality and concept of the ACE is untouched. You can reuse any Z code you developed in previous versions of SAP CRM and the ACE without any changes.

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.