Blogs

http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/4407

The concept and implementation of CRM-ACE Subscribe

Boris Dingenouts  Print
Business Card
Permalink
Company: Exxap
Posted on Sep. 18, 2006 08:43 AM in ABAP, Enterprise Portal (EP), SAP NetWeaver Platform, Share
Emerging Technologies
Hello all, in this blog I want to explain you what CRM ACE is, what it can do, what the concept is and how you can implement it.

Introduction
Large and complex (international) CRM installations all face the same problem: how do we show the users only the data that they need to see?
We don’t mean authorizations related to functionality, but related to business content. Imagine you run a big business and have a million
customers worldwide. Then a sales rep responsible for a group of customers in Belgium should not see any customers from Asia in his search
results. Or a sales rep with responsibility for a certain branche should not be bothered with customers of other branches. Furthermore, if the
structure of the sales organisation changes, you don’t want to end up changing all kind of authorization profiles.

To solve these issues, SAP came up in CRM for the PCUI with a pretty nice solution: CRM-ACE. This stands for Access Control Engine and is a
framework to calculate user dependent access rights on object level. It originates from Channel Management but works in all PCUI
functionalities. Unfortunately it doesn’t work in other environments like IC Webclient or via the SAP GUI (but I created a development request
for this….).

When I started looking into ACE a while ago there was very little documentation and information on this topic. There is some information in the
IMG and a very basic SAP tutor file but posts in SDN Forums asking for info got almost no reply. As usual I found out how it works myself by
debugging and tracing….and therefore I thought it would be a good idea to share it with you.

Difference with ‘normal’ authorizations

What is the real difference with the ‘normal’authorization concept we are all familiar with? In this traditional concept you have to specify all
values is the role; e.g. the sales organisation which the user is allowed to see data from. If you have 30 sales organisations you need 30 roles.
These are static autorisations. In ACE you can specify in one role that all users who have this role can see customers for the sales area to
which they are linked to. So with 30 sales organisations you only need one role. If a sales rep moves from one organisation to another you
don’t even need to change his authorizations. These are dynamic authorizations.

The concept of ACE

The basic element in the concept of ACE is the actor. To explain this in the most easy way you can say this is the linking and filtering element
between the user and the object. The actor determines if the user should see the object or not. As an example look at the following picture
which explains the scenario that a user is only allowed to see business partners where he is in the sales team. The user is linked to an
employee and these employees are stored in the sales teams of the business partners.

From the user’s perspective you can determine the employee id which is in the sales team. Also from the business partners perspective you can
see who are in his sales team. If both of them match, the user can see the object. If you understand the concept of the actor you understand
the ACE for 75% already.

How the actor from both perspectives is determined is stored in a rule. Here are three methods defined: how to determine the actors from the
user, how to determine the actors for an object, and a method to specify which objects to take into account in the first place. This is shown in
the following pic:

An ACE rule is a combination of a role and an action (read, write, delete). These rules you can assign to ACE user groups which you can link to
individual users or in most cases to dummy ‘normal’ authorization roles which you can assign in the user master.

The nice thing about the concept of ACE is that when you activate it it fills the ACE tables with data so it can later during runtime determine
very fast who is allowed to see what data objects. Basically it determines beforehands for all users and for all objects what it’s actors are and
stores this in tables. During runtime it knows your user so can quickly read your actors and then read all objects which have the same actor. If
a new object is created after the activation it automatically in the background determines the actors and updates the corresponding tables.
Really nice!

Technical view
And now the interesting technical stuff: the place where you can customize all of the above is in the IMG under CRM\Basic Functions\ACE. Most
things there speak for itself and the documentation is reasonably well.

If you create a new ACE right you have to implement a new class (copy from an existing class in the range CL_CRM_ACERULE*). The class
contains 5 methods:
1. GET_ACTORS_FROM_USER: this method receives the userid in the field im_usr_name and determines the actors for this user which should
be put in table ex_actor_id_table. Code samples will be below in this blog.
2. GET_OBJECTS_BY_FILTER: this method determines which objects to take into account and puts their GUIDs in table ex_object_guid_table
3. CHECK_OBJECTS_BY_FILTER: this method receives the table from the GET_OBJECTS_BY_FILTER method and here you can add additional
filtering
4. GET_ACTORS_FROM_OBJECTS: this method receives the internal table of method CHECK_OBJECTS_BY_FILTER and for all these object
GUIDS it determines the actors at once. It puts these in the itab et_actor_ids.
5. GET_ACTORS_FROM_OBJECT: this method is called when there is a new object created after the activation; e.g. when you create a new
prospect this method calculates its actors. It gets as input the object GUID in field im_object_guid and gives its actors in table
ex_actor_id_table

So methods 1-4 are used during the activation of ACE and the last one is used when new objects are created. At the end of this blog you will
find some code samples.

The relevant tables involved are the following (where XX can be BP for business partners, OO for ‘one order’ objects which can be activities,
orders, opportunities and leads, and PR for products; these are the three objects for which SAP delivers tables)
1. CRM_ACE_XX_GRP: in this table all possible actors are stored (e.g. all employee numbers or all sales areas) with their ACE_GROUP_ID,
which is the GUID linked to this actor.
2. CRM_ACE_XX_UCT: in this table all users with all their ACE_GROUP_Ids (=all their actors) are stored
3. CRM_ACE_XX_ACL: here all object Ids with their actors (in the form of the ACE_GROUP_Ids) are stored.

From these tables you can easily see how ACE internally works: it knows your users, then reads in the user context table (*UCT) your acegroup
Ids, and then in the access control list table (*ACL) it reads directly all objects you are allowed to see. It works as easy as that.

Performance
Does ACE boost the performance of your system? Seen the logic of the tables above, it should. However unfortunately the answer is no, or
maybe just a very little. When you search for business partners, in the background it still retrieves all business partners, and then at a later
stage it limits the result list according to the ACE rules. So from that point in time the result list is smaller, but the first search already spoiled
the response time. But maybe in future releases SAP will improve the logic of searching in the PCUI so it first reads the ACE tables, and then
the other tables. In most SAP systems this will be quicker, depending on how the employees are mapped to the business partners.

Code samples of the methods

And last but not least…..the code samples. In this example I implemented class ZCL_CRM_ACERULE_RELATION which does the following: it
allows users only to see business partners for which they have a relation with. For example, they are defined as employee responsible, or as
account manager.

As I’m not a real programmer (actually I’m a functional consultant however somehow I often end up programming too) there might be some
room for improvement. I’m open for your suggestions!

GET_OBJECTS_BY_FILTER
This method retrieves all business partners which are organisations and all contact persons which are linked to a BP (because if you see a BP,
you also want to see it’s CPs!)