Wednesday, May 25, 2011

ACE Technical details

If you apply ACE to business partners, a few tables are generally relevant:

This is the actual Access Control List. Here, all relevant business partners are linked to an ACE-group.
One business partner can be assigned to several ace-groups.
This table will generally contain many entries (at least one for every BP).

Here, rights are mapped to actor_id’s and ACE-groups.
This table will generally not contain many entries.

The CRM_ACE2_BP_UCT contains the mapping between actual USERID’s and the ACEGROUP.

Rights Activation
Once implemented, Rights should be activated. Activating a Right will trigger the system to determine the ACL based on the customizing (so select all relevant objects based on the OBF class, select all the Actors based on the AFO and assign the users to the Right based on the AFU.
Once activated, all relevant objects will be added to the WorkList. The worklist consists of 2 tables:

CRM_ACE2_RIG_WL is used to gather all objects after the initial activation of a rule.

CRM_ACE2_OBJ_WL is used to gather all objects that have been changed, and this serves the delta mechanism.

The worklist is processed by a background job named CRM_ACE_DISPATCHER. This job is triggered by background event SAP_CRM_ACE_DISPATCHER_REQUEST.

During Right customizing, we created a user group. You can choose to create user groups specifically for a user, but more logical would be to apply a right to a Role. This role is a PFCG role. The rule will then be applied to all users that have this PFCG-role assigned. The PFCG-role itself does not necessarily need to contain objects, but is just used for assignment means.

Performance considerations
When applying ACE, you should consider performance, as ACE will generally create big ACL tables and call these tables often. You can influence the size of these tables from a functional perspective by focusing on the objectgroups rather than usergroups when implementing ACE. I will show this based on an example:

Let’s say you have 10.000.000 businesspartners in your system to which you want to apply ACE.
You are implementing ACE for 5 usergroups.
All of these usergroups have display rights for all businesspartners.
Each of these usergroups has a specific group of 2 mln BP’s they will get change-authorisation for.

You now have two ways to implement this:

Option 1
Create 5 workpackages, one for each usergroup and contain the definition for the usergroup in the workpackage. The workpackage could consist of the following rules:
• Display rights for all businesspartners.
• Display rights for all contacts of the assigned businesspartners.
• Change rights for the 2 mln businesspartners based on an attribute.
• Change rights for the contacts of the 2 mln businesspartners.

Option 2
Create 6 workpackages, one for each usergroup and one for the display all. The display workpackage would contain the display rights for all businesspartners, the change workpackage would contain the change rights for the specified group.

In the above example, even though from a customizing point of view, it doesn’t seem to matter, in practice, the second option would be the best, because in the first option, the access control lists of all 5 workpackages would contain 12 mln entries (10.000.000 + 2.000.000). This sums up to 12 * 5 = 60 mln records to check when trying to display a businesspartner. Not to mention the fact that contact persons should also be counted in.

In the second example, there are 10 mln entries in the display workpackage, and 5*2 mln = 10 mln in the other workpackages, summing up to 20 mln records to check when trying to display a businesspartner.

The conclusion is that when implementing ACE, think from an object perspective, and not from a user perspective. Rather assign more than one ace PFCG role to a user than assign more than one ‘right’ to a workpackage, unless they obviously belong together (such as accounts and their contacts).