All users who want to display transaction data from authorization-relevant characteristics or navigation attributes in a query require analysis authorizations. Authorizations of this type are not based on the standard SAP authorization concept, which uses authorization objects. Analysis authorization is a new authorization concept introduced for SAP Business Warehouse (SAP BW) that instead includes a group of characteristics. You restrict the values for these characteristics. The authorizations can include any authorization-relevant characteristics, and they treat single values, intervals, and hierarchy authorizations in the same way. Navigation attributes also can be flagged as authorization-relevant in the attribute maintenance for characteristics and can be added to authorizations as separate characteristics. These authorizations are then added to roles under authorization object S_RS_AUTH and finally are assigned to users through the roles. However, when the number of analysis authorization objects increases, it becomes more complex to manage them through roles. For example, a restriction on a profit center or a cost center hierarchy node requires the creation of a large number of analysis authorizations that, in turn, are included in different roles (based on user requirements). That increases the number of roles that need to be created and maintained. You can avoid this by setting up dynamic analysis authorization.

Dynamic Analysis Authorization

The dynamic analysis authorization concept uses variables to provide values at run time instead of maintaining them in the analysis authorization itself. This requires activation of an exit in function module EXIT_SAPLRRS0_001 and the creation of custom tables to store values for user authorization assignments. While executing the query, the system checks for the necessary authorizations available to the user and, in the process, calls this exit. The code written in the exit searches for variables assigned to the analysis authorization objects being checked, and returns the available values for the user being checked. Dynamic analysis authorization can be provisioned using SAP Access Control in the following two ways: template roles or role-specific authorization information.

Using Template Roles

Template-role functionality can be used to provide users with a set of attributes, such as profit center, cost center, or reporting unit from which they can choose when creating access requests. Following are the steps for setting it up. Step 1. Activate template role functionality by enabling the Business Add-In (BAdI) GRAC_TEMPLATE_ROLE. You create a local implementation of the BAdI in your system by implementing the class. Four steps are required to implement the BAdI in your system. Execute transaction code SE18, which gives you an overview of the available BAdIs in the system. Enter the name of the BAdI (GRAC_TEMPLATE_ROLE) as shown in Figure 1. Click the Enhancement Implementation button after you have entered the BAdI name. Then click the Create option, as shown in Figure 2. In the screen that opens (Figure 3), enter the name of the custom enhancement and accept the name of the Implementing Class, or you can change it. Double-click the name of the Implementing Class and implement your coding in the required methods by clicking the Method name. The Implementing Class appears as shown by the arrow in Figure 3 (Z_GRC_TEMPLATE_BADI). The name is created by the developer. Clicking this opens the list of methods where code can be written. Step 2. Implement BAdI method IS_TEMPLATE ROLE. Double-click the method IS_TEMPLATE_ROLE of the custom class created above and implement it. SAP Access Control has different role types and one such role type is the template role. In order to use this role type, BAdI method IS_TEMPLATE_ROLE should be implemented. This method should return X if the role passed to it is a template role. If this method returns true (as indicated by the X), then the business role is considered as a template role. The parameter CV_IS_TEMPLATE_ROLE of the method should return X for a template role. A template role can be used to implement custom functionality for the roles. Take the following steps to add a template role to the SAP access request. Go to the GRC tool via the SAP NetWeaver Business Client (SAP NWBC) link or via a portal link. Click the Access Request link to create a new access request as shown in Figure 4. After the Access Request screen is displayed in a new window (not shown), you can add roles and system details in the access request and, in the end, submit them for approval by entering all the mandatory details (e.g., Line manager ID, Company Name, and User group). Click the Add button and then the Role button to include a template role in the access request as shown in Figure 5, which takes you to Figure 6. The user can enter the request reason in the Description box before or after adding the roles. Next, search for the template role by entering the role name in the Role/Profile Name input field on the right, and then clicking the Search button as shown in Figure 6. In my example the name is TEST_TEMPLATE. You could also use * for a wildcard search. Once the role is found, add the role in the access request by clicking the OK button. The template role is added to the access request as shown in Figure 7. Step 3. Use the GET_URL method of the BAdI to get the URL of the custom Web Dynpro application that I created earlier. The requestor needs to add a predefined template role while raising the request. On clicking the role Type and clicking the Template link (as shown in Figure 7), the screen shown in Figure 8 appears. It displays the different characteristics and attributes in the form of InfoObjects from which the user can make selections for the role. The screen in Figure 8 is a custom Web Dynpro screen that can be created per your business requirements. A user can select the InfoObject values and close the window. Data is saved into the custom tables at the time the access request is submitted. Step 4. Call the VALIDATE_ROLE method of the custom class implemented for the BAdI GRAC_TEMPLATE_ROLE during submission of an access request to check the consistency of the template role. To do this, you need to add the code in the method VALIDATE_ROLE of the class implemented in Figure 3, which displays the custom class implemented for the BAdI GRAC_TEMPLATE_ROLE. At the time of the request submission this method is called and performs the necessary validations. This method provides a chance to check if the additional information provided in the custom application (as shown in Figure 8) is consistent. This method implementation should return a list of error or success messages that needs to be shown in the access request form. Step 5. Save the values for these characteristics and attributes in a custom table along with the GRC request number by creating an enhancement using transaction code SE80, as shown in Figure 9. Click the spiral icon shown in Figure 9 to create a custom enhancement. This enhancement is done in the Post-Exit of the method CREATE in the component controller of the GRAC_UIBB_ACCESS_REQUEST Web Dynpro component. In the Post-Exit, you need to write the custom code to save the data in the custom tables in SAP Access Control. The arrow on the right in Figure 9 shows the Post-Exit enhancement created for the method CREATE where you need to write the code to save data in the custom table. The request follows a predefined multi-stage multi-path (MSMP) workflow path set up during GRC configuration in the system, and in the end triggers provisioning. You can configure the MSMP workflow according to your organization’s needs. Step 6. The GET_PROVISIONING_OBJECTS method of the custom class implemented for the BAdI is shown in Figure 3. You need to specify the table where the values of characteristics and attributes were originally stored at the time of the request submission, and also the way in which they should be passed on to the back-end SAP BW system. You need to implement coding inside this method. This method is used to fetch the data from custom tables in the Access Control system and to pass the data to the back-end SAP BW system via a Remote Function Call (RFC). For this you need to create a Post-Exit enhancement in the method ASSIGN_OBJECT of the class CL_GRAC_PROVISIONING_ENGINE. The problem with this approach is that the screen allows you to add the authorization-relevant characteristics and attributes without taking into account the roles requested in the GRC request. Attributes not authorized or relevant for particular roles can also be added via this approach. This may pose a threat as it can confuse users who may not be aware of the additional characteristics or attributes that are displayed. You can avoid this problem by choosing the second approach (i.e., using Role-Specific Authorization Information). In this method, the characteristics and attributes shown are dependent on the roles selected in the request. The first option is good for companies whose requestors know which InfoObjects to select in the request rather than on relying on the system to propose them.

Using Role-Specific Authorization Information

This approach to role-specific authorizations requires the following configuration and enhancement. Step 1. Identify the characteristics and attributes specific to each role and store them in a custom table in SAP Access Control. Table 1 is an example of such a table. The table shows that InfoObject 6 is linked to Role A. A value for this needs to be selected by the user if he or she wants Role A to be assigned to him or her in the SAP BW system. Without a valid value for this InfoObject, the user is not able to do the work. ROLE_NAME contains the actual SAP Access Control role name. The three lines maintained in the table for ROLE_A mean that three InfoObjects are displayed in the Web Dynpro application when this role is added in the Access Request screen. Similarly, for ROLE_B, only two InfoObjects are displayed. The INFO_OBJECT column contains the InfoObject name to be displayed. HIERARCHY is used to maintain hierarchies relevant for authorizations per role. This field is only maintained for those InfoObjects for which a hierarchy is shown to the user. The hierarchy displayed to the user is fetched based on the InfoObject maintained in the HIERARCHY column in the table. In an SAP BW system, some InfoObjects are created as hierarchy nodes. This makes it easy for users to visualize the InfoObjects in GRC. Step 2. Add a new button named BI/BW Attributes in the Access Request screen (as shown in Figure 10). You can access the screen via your GRC NWBC link. You can add the button shown in Figure 10 by creating an enhancement as explained below. The enhancement for adding the button is done in the Post-Exit of method INIT_ITEM_ALV of the component controller in the GRAC_UIBB_ACCESS_REQUEST Web Dynpro component. You access it via transaction code SE80, as shown in Figure 11. In the Post-Exit column of the method INIT_ITEM_ALV add the custom code to add the button. You click the Post-Exit item and a screen opens (not shown) where you can add the code. METHOD IF_SALV_WD_FUNCTION_SETTINGS~CREATE_FUNCTION of the class CL_SALV_WD_CONFIG_TABLE is used to create the button in the Post-Exit method mentioned above. Using this method, you can create a button dynamically in the Web Dynpro screen. You need to call this method in the Post-Exit of the method INIT_ITEM_ALV, which is used to create buttons dynamically in the toolbar. Step 3. Add another enhancement in the Post-Exit of method HDL_ALV_FUNCTION in the view V_REQUEST_ITEMS of the GRAC_UIBB_ACCESS_REQUEST Web Dynpro component. Use transaction code SE80 as shown in Figure 12. This passes the information regarding the roles selected in the access request to the interface node of the custom Web Dynpro component. Interface nodes are used to pass information from one Web Dynpro component to another Web Dynpro component. Read the Request Details Context Node N_REQ_DETAILS (not shown), which is present in the view V_REQUEST_ITEMS of the Web Dynpro component GRAC_UIBB_ACCESS_REQUEST in this enhancement. This node has the role as well as system-related information entered in the Access Request screen. Add the role-related information in the interface node of the custom Web Dynpro component in the Post-Exit method created above, as shown in Figure 9. This role information is needed in the custom Web Dynpro component to display the characteristics or attributes related to these roles only. Also add the code in the Post-Exit of method INIT_ITEM_ALV to open the Web Dynpro application on the click of the BI/BW Attributes button, which is created using an enhancement (as explained above and shown in Figure 10). Create a custom Web Dynpro component by selecting Web Dynpro Comp. / Intf from the drop-down options using transaction code SE80, as shown in Figure 13. Add the name of the Web Dynpro component in the input box and press Enter to create it. To add InfoObjects dynamically in the custom component, write the logic explained below in the WDDOMODIFYVIEW method of the MAIN view as shown in Figure 13 of the custom Web Dynpro component created. You need to double-click the MAIN view and go to the Methods tab to see the WDDOMODIFYVIEW method. Loop through the entries fetched from the custom table and create user interface (UI) elements (attributes) dynamically in the WDDOMODIFYVIEW method of the MAIN view. You use dynamic programming in Web Dynpro ABAP. Using dynamic programming you can add UI elements at run time. You can also add elements to a context at run time. Standard classes are used to create UI elements dynamically. They all start with CL_WD_ followed by the actual name of the View Element. You can apply the same procedure to all other View Elements as well. If you want to create a button dynamically, the class in question is the CL_WD_BUTTON. Use function module RSD_IOBJ_GET to get the metadata for the specific InfoObject for Access Control use. Label texts in the application can be fetched using the same function module. You can use the Short Description field TXTSH of the function module. An Object Value Selection (OVS) search help is created for the input fields that fetch the data from the SAP BW system via an RFC as shown in Figure 14. OVS search help is created by making use of the standard Web Dynpro component WDR_OVS. Click the F4 help provided for the input fields to open the search help as shown in Figure 14. This search help fetches the data from the back-end SAP BW system and displays the results in a new window. You can also create hierarchy-relevant authorizations per role. Web Dynpro ABAP gives the option to display the hierarchies via a TREE UI element. For this you need to add the TREE UI element in the Web Dynpro view created via transaction code SE80. Create a button UI element for every input field dynamically in the WDDOMOFIYVIW method of the MAIN view of the custom Web Dynpro component. METHOD NEW_BUTTON of the class CL_WD_BUTTON is used to create the button UI element. The user needs to add code in the WDDOMODIFYVIEW method. Based on the InfoObject maintained in the field HIERARCHY as shown in Figure 15, the application shows the detailed hierarchy structure for the specific InfoObject. RFC RSSH_HIER_OF_IOBJ_GET returns the list of existing hierarchies including name, version, and date for the Access Control hierarchy selection. Another RFC is called that returns the detailed hierarchy structure for a specific hierarchy ID. This RFC calls method NDI_GET of the class CL_RSSH_HIERARCHY_FUNC in the back-end system that is used to deliver a hierarchy or subtree (with node attributes) as shown in Figure 16. A function module needs to be created in the back-end SAP BW system that will call this method. The function module is then invoked in the GRC system via an RFC call. Figure 16 shows the method NDI_GET of the class CL_RSSH_HIERARCHY_FUNC, which is to be called in the SAP BW system to return the list of hierarchy nodes. Loop through the data returned and prepare the tree table in the GRC system by preparing an internal table with the tree data. Bind the internal table with the tree UI element in the view using method BIND_TABLE of the interface IF_WD_CONTEXT_NODE. A new custom Web Dynpro component is created using transaction code SE80 to display the hierarchies in a TREE structure as shown in Figure 17. Add a table UI element in the MAIN view of the Web Dynpro component and add the TreeByKeyTableColumn to display the hierarchy in the view. Using this component, the user is able to select the hierarchy as shown in Figure 18. Step 4. The enhancement to save data in the custom tables in GRC is done in the Post-Exit of the method CREATE in the GRAC_UIBB_ACCESS_REQUEST Web Dynpro component as shown in Figure 19. Figure 19 shows the Post-Exit created for method CREATE. In this Post-Exit, the user needs to write the logic to save the data in the custom tables in the GRC system. The arrow in Figure 19 displays the Post-Exit enhancement created for method CREATE. Step 5. The enhancement to send the data to the SAP BW system at the time of provisioning is done in the Post-Exit of method ASSIGN_OBJECT of the class CL_GRAC_PROVISIONING_ENGINE, as shown in Figure 20. For this you need to create a Post-Exit enhancement for the method ASSIGN_OBJECT of the class CL_GRAC_PROVISIONING_ENGINE. Figure 20 shows the implicit enhancement created in the GRC system. This enhancement calls an RFC-enabled function module to send the data from the Access Control system to the SAP BW system and also save it in the back-end tables in the SAP BW system.

Two Additional Features

There are some additional features that can be added to the solution explained above to make it more user friendly. These features also help the approvers in getting a view into the complete data requested before taking an action to approve or reject the request. These additional features are as follows. 1. The characteristics and attributes requested in the SAP Access Control request can be made visible to the line manager. A Display BW Values button is added to the request screen that is only visible to the approver to see the values that were originally selected by the person who raised the GRC request, as shown in Figure 21. The button is visible when the Access Request screen is in Display/Edit mode, so that it is only visible to the approver. The mode of the Access Request screen can be found using the domain GRFN_UI_MODE. The enhancement for adding the Display BW Values button is done in the Post-Exit of method INIT_ITEM_ALV in the component controller of the GRAC_UIBB_ACCESS_REQUEST Web Dynpro component, as shown in Figure 22. When you click the Display BW Values button shown in Figure 21, a new Web Dynpro component opens (not shown) that shows the values requested by the user in a new window. The data is fetched from the custom tables in GRC. The enhancement for the same is done in the Post-Exit of method HDL_ALV_FUNCTION in the view V_REQUEST_ITEMS of the GRAC_UIBB_ACCESS_REQUEST component controller, as shown in Figure 23. The line manager can view the details and take suitable action. 2. Characteristics and attributes of approved roles only are passed to the back-end SAP BW system. While passing data to the back-end SAP BW system, you can read the GRC request line items and check the data stored in the custom tables in GRC at the time of request submission against the approved roles, and pass only the characteristics and attributes of the approved roles to the SAP BW system. To read more about the analysis authorizations concept, go to Analysis Authorizations in the SAP Help Portal. To learn more about how to create a Web Dynpro component, go to Web Dynpro Component. To learn more about InfoObjects in SAP, go to InfoObject.