Expand +



Access Control Engine (ACE) design considerations for SAP CRM 7.0

by The Tip Doctor

September 9, 2010

This tip was taken from “A Behind-the-Scenes Look at Access Control Engine 7.0 Concepts and Troubleshooting” by Han Chen, which was posted to the CRM Expert knowledgebase in June 2010 (Update 5).  

Tip Doctor, Insider Learning Network

When your company decides to adopt the Access Control Engine (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 these 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 re lationship 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

CALL METHOD cl_crm_ace_manager= >handle_changed_objects_guid
      im_object_type  = lc_object_type
      im_is_bor_otype = 'X'
      im_object_guids = lt_changed_object_guids.

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.

An email has been sent to:

More from SAPinsider


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!