Configuration & Implementation of CRM Access Control Engine (ACE)

Configuration & Implementation of CRM Access Control Engine (ACE)-Part 1

Business Scenario:  Any particular account and its Contacts can be displayed / edited / deleted  by the employee who has created that account and the other employees who are related to that Account with the relationship type “Is the Responsible Colleague Of”.  
To provide detailed steps, I would like to split this blog into two.  The first one would involve various configuration steps and second will explain the implementation with its code & finally maintenance related activities. 
First of all let’s see what needs to be maintained in the General parameters:
  

• DISPATCHER_DESTINATION parameter should have the name of RFC destination through which ACE update job is scheduled. The default entry is “ACE_ACCESS”.
• Then to deactivate/activate ACE you need to include the parameter “ACE_IS_INACTIVE” which when set to “X” makes ACE inactive and if blank then ACE is active.

To start with these parameters are enough to work and based on the requirement one can use the others. Detailed help is provided in Customization documentation.
 
 
Then the next step is to “Create Rules”. 
1. Add Super Object Type: You see default entries already maintained for our object ACCOUNTCRM. If the need arises one can add a new super object type too. We fill in the ACL table name, then GRP table name and UCT table name.
These are the runtime tables where in the authorization data is stored. You can have a look at the data of these tables from SE16. Because an individual set of runtime tables is created for each super object type, authorizations are spread across several tables. This enhances the performance.
 
2. Add Object Type: For each CRM object type used in ACE, a default BOR object type is assigned in table CRMC_PRT_OTYPE. Say for example object type “ACCOUNTCRM” the corresponding BOR object type is “BUS1006”. To define an object type, refer to the screen shot below.
Then you have the concept of Action and Action group. Actions are summarized in action groups, and used in connection with rights, they grant users specific authorizations such as READ, CHANGE, or DELETE. 
 
 
3. Create Actor Type: An actor type describes the relationship type between the user and an object, for example, contact person, responsible employee. Where as actor is an attribute of Actor Type. Refer to the screen shot below to create an Actor Type. Here we have created an Actor type “ZACC_EMP_RESP” for Employee Responsible as per our scenario explained in the start. 
 
 
4. Add AFO Class: AFO stands for 'Actors for objects'. Here we define AFO class ID for our Actor type created in the previous step. The class “ZCL_CRM_ACERULE_ACCOUNT” implements the interface “IF_CRM_ACE_ACTORS_FROM_OBJECT”.
 
 
5. Add OBF Class: OBF stands for ‘Objects by filter’. Here also we define the same ABAP class we defined in the previous step. We need to implement the interface “IF_CRM_ACE_OBJECTS_BY_FILTER“in that class.
  
 
6. Add AFU Class: AFU stands for ‘Actors for User’. We need to implement the interface IF_CRM_ACE_ACTORS_FROM_USER in the class “ZCL_CRM_ACERULE_ACCOUNT”. 
 
 
7. Create Rule: This is the final step in creation of ACE Rule. This rule would be used in the Right definition step. Refer to the screen shot below: 
 
 
Create Rights 
1. Work Package Definition: A work package is an organizational unit of the ACE, which combines user groups and enables them for one or several object types. We define a work package for all our Account Related ACE Rules. The super object type assignment ensures that users of the user group(s) are only active ACE users of the respective super object types and their sub objects.
 
2. Object Type Assignment for Work Packages: Assign the super object type to a work package. Refer to the screen shot below: 
 
 
3. User Group Definition - A user group contains users who should get authorizations for objects. User groups can contain single users, as well as roles. Furthermore, they can be nested. User groups are assigned to work packages.
Please have a look at the below note, which is mentioned in the documentation.
Note: Because a user group can be assigned to one work package only, nesting of user groups may result in non-unique assignments. For example, Group G1 is assigned to Package P1. Additionally, Group G1 is nested in Group G2, which in turn is assigned to Package P2. The user group in Package P1 is therefore not valid, because assignment to a package of Group G1 via nesting in Group G2 is not unique.
 
 
4. User Group Entries: The entries in the User group can be defined as a User, Role and a User group. Normally it makes sense if you create a role for which ACE authorization is applied and add that here. For demo purposes I have added a set of user IDs here.
 
 
5. Right Definition: Right definition makes the connection between a rule, which provides the objects as well as the actors, and the users, who are stored in the right via the user group. The right also defines the possible actions that the user can execute with the objects of the rule. Furthermore, you can specify a validity period for the rights and hence control them chronologically. Refer to the below screen shot which shows the Right we had created.
 
ACE Design Report 
Finally once the entire configuration is done, then our design can be verfied using the transaction “ACE_DESIGN” by giving the Right Name as input. Refer to the below screen shot where in you can check out the whole lot of things we had created in the previous steps.
 
 
So, far we have seen the entire configuration part involved in our scenario. In the next blog I will show you the entire implementation involved. 
You have very good documentation for each step in the Customization transaction. One can refer to that for better understanding.
This blog was just an attempt to put on all things at a single place which would be really helpful to starters.
Hope this blog serves its purpose!


Configuration & Implementation of CRM Access Control Engine (ACE)-Part 2

Business Scenario:  Any particular account and its Contacts can be displayed/edited/deleted by the employee who has created that account and the other employees who are related to that Account with the relationship type “Is the Responsible Colleague Of”. 
As per our requirement: 

• Objects: All the Business Partners who are Persons as well as Organizations.
• Actors: Responsible Employee of any Business Partner or an employee who has created the BP. 

We need to implement the following interfaces in the ABAP class ZCL_ACERULE_ACCOUNT... 
IF_CRM_ACE_OBJECTS_BY_FILTER~GET_OBJECTS_BY_FILTER 
This method fetches all the objects to which ACE right is applicable. Objects applicable to our ACE rule are all the Business Partners. So, get the entire Business Partners from BUT000 and append them to the exporting internal table of this method.
 
  
 
IF_CRM_ACE_ACTORS_FROM_USER~GET_ACTORS_FROM_USER 
This method calculates the Actors to every user assigned to our ACE right. Actors are employees as said before. So get the employee for each user and append them to the exporting internal table.
 
  
 
IF_CRM_ACE_ACTORS_FROM_OBJECT~GET_ACTORS_FROM_OBJECTS 
This method is very important in an ABAPer’s point of view as it has maximum amount of coding ;) 
This method queries actors according to a specified list of objects. (Mass data method) 
SAP recommends us to implement this (mass data) method instead of single object versions, such as method GET_ACTORS_FROM_OBJECT.  
It has the following parameters: 
1. 'IT_OBJECT_GUIDS': Importing, type CRMT_ACE_OBJECT_GUID
This has all the objects (GUID of BP) whose actors are to be determined.
2. 'ET_ACTOR_IDS': Exporting, type CRMT_ACE_OBJECT_ACTORS
All the determined actors are appended to this internal table. 
3. 'ET_FAILED_OBJECTS': Exporting, type CRMT_ACE_OBJECT_GUID
All the failed objects, say objects to which actors couldn’t be determined will be appended to this internal table. Please refer to the implementation code below, it is self explanatory. 
 
 
 
We will not be implementing the method GET_ACTORS_FROM_OBJECT hence forth. 
We also have another method  IF_CRM_ACE_OBJECTS_BY_FILTER~CHECK_OBJECTS_BY_FILTER in which additional filtering can be performed.
 
 
 
Have a look at the parameters of the custom method GET_RESP_EMP and also its implementation part.
 
 

Then have a look at the Public Local Type Definitions created:
 
 
Then we need to activate our Work Package and Rights. First activate you User Group from the User Groups tab and then activate your right from the Rights tab. Related screen shots are attached below:  
 
 
 
Once the right has been activated you can check out a job runs which can be checked in your SM37 TA and the runtime tables are filled in with the authorization data. After the job finishes, you can check out one of the runtime tables CRM_ACE2_BP_ACL filled in with authorization data.
 
 
 
 
Now, check out the TA ACE_RUNTIME which will show the runtime data. One can check out the accounts a particular user can access. One can also check out who ever is allowed to access a particular account.  
Filter Selection To call the report, select at least one superobject type.If you have selected a superobject type, you can refine your search by additional criteria and display the list. 
 
 
 
One can also use the TA "ACE_UPDATE" to update the user context as well as the Object Context. My next blog would deal with this aspect.