Special Access Control Topics - How to Provide Access Control on Custom Business Object
7 min read
Overview
Understand the access control concepts in partner-developed custom Business Objects (BO).
Table of Contents
Background on Access Control and Context
Business Objects developed by SAP can have controlled-access based on the Access Control List (ACL) associated node data. ACL is a dependent object (DO) that can be associated with a Business Object to provide controlled-access.
You can restrict the access to instances of Business Objects, be it read or write, based on certain predefined contexts like Employee, Company, and Site.
A user is assigned access to these access contexts. These control the operations that the user can perform on the Business Object instances.
For example, the Business Object ‘PurchaseOrder’ has an access context of Company. By default, the access rights are ‘Unrestricted’ and the user has "read" and "write" rights for the purchase orders for all companies.
To control the access, the user can be assigned access (under Application and User Management → Business Users → Edit Access Rights → Access Restrictions) to read and/or write on purchase orders belonging to a certain set of companies.
This brings in restricted access to the Business Object.
The access context, in the above screenshot, is 1007-Company and the access context UUID is the company UUID. This means that this instance of the purchase order belongs to company 00145EF588E602DBB8B3AC44715E0CC1 and a user, who has been given "read" access rights for this company, can only read the purchase order. If "write" access is given for this company, then the user can also write on this purchase order.
Access Control for Partner-Developed Business Objects
The same function of providing controlled-access can be achieved for partner-created Business Objects. There are two ways of doing this in SAP Cloud Applications Studio:
- Link the custom BO to a standard BO which has the supported access context required for custom BO. This can be done using the following association in custom BO definition: [RelevantForAccessControl] association For_Access_Control to PurchaseOrder. This association helps to use the access context of the Purchase Order for the custom BO without having to integrate the custom BO with the ACL.
- A second approach is to integrate the ACL dependent object with the custom BO and to use a similar concept
as the standard Business Objects. As of today, however, this approach only supports the access context
‘1010-Employee’.
How to Integrate ACL with a Custom Business Object
In this secton, you will learn more about the second approach, mentioned above, to achieve controlled-access to a custom Business Object.
Let's look at the following example: A partner has created a Business Object ‘PurchaseOrder’ and wants to control the access to it, based on the employee who created the instance. User PGREENE is allowed to only read the records created by TWEBBER but can read and write records created by himself.
1. Create a solution in Standard Development Kit (SDK).
2. Add a Business Object ‘PurchaseOrder’ to your solution and activate it. Define the BO as follows: The first three elements represent the employee ID, Name and Address of the employee who created the PurchaseOrder instance. The element marked with annotation [AccessControlContext(Employee)] creates an association from the ROOT node to the ACL dependent object. This ACL will have access context 1010-Employee and the access context UUID will be copied from the ‘OwnEmployeeUUID’ attribute.
3. Add a script file (Event-AfterModify) to fill the attribute ‘OwnEmployeeUUID’ with the current employee’s UUID. It will then get passed to the ACL node for controlled-access.
4. Create screens on the Business Object.
5. Open the .uiwocview file in UI Designer by double-clicking on it. Under the properties tab, under the section RBAMData, set the access context on the Work Center (WoC) View to 1010-Employee. Select the Quick Activity Floorplan (QAF) and the Object Instance Floorplan (OIF) screens against the AssignedObjects. Save and Activate.
6. Open the Object Work List (OWL) file in UI Designer. Under the properties tab, under the section RBAMData, select AccessControlledBusinessObject and remove the default flag ‘UnrestrictedAccess’. This allows OWL to load only relevant data based on access rights.
7. On the OWL screen, the SELECT_ALL query is set by default for loading the data, but this query does not have any ACL attributes. Use the Fast Search Index (FSI) query ‘QueryByElements’ as the default query. This query is created implicitly with the ROOT node to load the data and already includes the ACL node attributes to fetch relevant data.
8. Set the RBAMData for the QAF screen, similar to the OWL.
9. Assign the new WoC view to the users and set the access rights as follows for user PGREENE:
a. Both "read" and "write" access for PGREENE records
b. Only "read" access
for TWEBBER records
10. Create some instances of custom BO with user PGREENE and TWEBBER. Test on the system by loading the OWL and the QAF.
In OWL, PGREENE should be able to see the records created by PGREENE and TWEBBER. If PGREENE tries to edit the records created by TWEBBER, then a "Not Authorized" error will be returned.
Conclusion
This article introduced you to an approach to achieve controlled-access to a custom Business Object. Now, it is your turn to try it out in your projects!
