In my Configuration & Implementation of CRM Access Control Engine (ACE)-Part 1 blog, I had listed down the configuration steps required for the business scenario discussed. In this blog we will go through the implementation of the ABAP class for Access Control.
Let me revist our Business scenario:
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…
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.
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.
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.
Also, I would like to thank my Project Lead @Cognizant, Gautam Mandal who was the driving force behind this implementation.
I hope that this blog series would be very helpful to ABAP technical consultants while imlementation of Access Control Engine.
Hope this blog serves its purpose!