SAP Access Control 10.0 provides users the flexibility to create and maintain multiple rulesets. A typical organization needs to manage multiple rulesets for various reasons ranging from business process control structure to organizational structure make-up. SAP Access Control allows you to choose from more than one ruleset to perform risk analysis automatically. This capability is also seamlessly supported in access request management functionality. More important, you can build Business Rule Framework plus (BRFplus) logic to default a specific ruleset to an access request once defined criteria are satisfied. This is essentially the business case on which I focus. This is a way to eliminate the need for a manual field (ruleset) update and also to enforce control so that the risk analysis is executed using the correct and appropriate ruleset, thereby making the entire process of risk analysis less error prone. Figure 1 shows a representation of the behavior of the business logic on which Request multiple ruleset is based. It shows that if an access request is created for a user against the business process BS_EAST and parameter 1071 (Enable risk analysis on form submission) is set to NO, then on form submission to the approver the ruleset field is autopopulated as RS_EAST and risk analysis is not automatically performed. On the contrary, if another access request is created for a user against the business process BS_WEST and parameter 1071 (Enable risk analysis on form submission) is set to YES, then on form submission to the approver the ruleset field is autopopulated as RS_WEST and risk analysis is automatically performed. This illustrates a simple use case of this business logic that I replicate in this article. The ruleset forms the basis for empirical risk analysis in the access control application. Therefore, the use of the appropriate ruleset is important at any time to gain assurance that there are no risk violations that can expose an enterprise business application to the possibility of fraudulent activities. The need for the use of appropriate ruleset (especially in an environment with multiple rulesets) makes the request multiple ruleset business rule valuable. Therefore, it is important to emphasize that besides the fact that the content of the ruleset needs to be a correct representation of the access risk perception and the segregation of duties (SoD) requirement of an enterprise, the appropriate ruleset must be used for risk analysis at all times. In this article, I assume that you have configured the access risk analysis and access request management scenarios in your environment. You can run risk analysis and also create and approve access requests using a configured workflow process. Also, note that the understanding of BRFplus is a prerequisite because I do not explain in detail the basics of maintaining the standard BRFplus objects. I address this subject matter under the following topics:

• Set parameters for Request multiple ruleset
• Map BRFplus function ID with access control application
• Configure a BRFplus rule for Request multiple ruleset
• Simulate a business scenario

Set Parameters for Request Multiple Ruleset

Many configuration parameters influence access risk analysis business scenarios, especially the parameters related to the parameter groups Risk Analysis and Risk Analysis Access Request. However, one important configuration parameter that influences the behavior of the multiple ruleset capability of access risk analysis and access request management business scenarios is parameter 1071 (Enable risk analysis on form submission). There is no mandatory value to set for this parameter to use the multiple ruleset application functionality. However, the value defined affects the behavior of the process when an access request is submitted for approval processing. More important, the parameter allows risk analysis to be executed automatically when an access request form is submitted with the defined (or evaluated using BRFplus rule) ruleset when the configuration parameter is set to YES. On the other hand, risk analysis is not executed automatically when an access request is submitted if it is set to NO. In the latter case, the approver needs to explicitly initiate the execution of risk analysis as required using the defined ruleset. The parameter can be maintained by accessing menu path SPRO > SAP Reference IMG > SAP Customizing Implementation Guide > Governance, Risk and Compliance > Access Control > Maintain Configuration Settings. Figure 2 shows a typical setting for parameter 1071. If you need to maintain it, you switch between NO and YES when you are in change mode.

Map BRFplus Function ID with Access Control Application

Request multiple ruleset functionality is standard in SAP Access Control 10.0. This functionality is defined and maintained within the business rules framework workbench. You need to check for the correct function ID in the BRFplus workbench. You can identify the correct function ID via accessing transaction code BRFplus and navigating to the appropriate function of the application as shown in Figure 3. The actual mapping is done in customizing. Ensure that the correct function ID is mapped against the right access control application in customizing by following menu path SPRO > SAP Reference IMG > SAP Customizing Implementation Guide > Governance, Risk and Compliance > Access Control > Maintain AC Applications and BRFplus Function Mapping. If the entries for the application ID and BRF function ID do not already appear in the Change View for “Application mapping”: Overview (Figure 4)  by default, then you need to click the New Entries button and add these entries (Appl Id and BRF Function Id).

Configure a BRFplus Rule for Request Multiple Ruleset

To configure the BRFplus logic using the standard application  GRAC_BRFP_MULTIPLE_RULESET, you need to create a decision table object in the BRFplus workbench in which you define the criteria that are evaluated in the logic and the outcome to expect. The application and all the referenced objects can be accessed via transaction code BRFplus or by following the menu path SPRO > SAP Reference IMG > SAP Customizing Implementation Guide > Governance, Risk and Compliance > Access Control > Workflow for Access Control > Define Business Rule Framework. The next screen (Figure 5) appears after you search for the multiple ruleset application using the find function. Open the function folder (under the GRAC_BRFP_MULTIPLE_RULESET application folder) to navigate to the function. Choose the function node as shown in Figure 6. In the Mode field, choose the Functional Mode option from the drop-down menu in the Properties tab of the Details page of a function (Figure 7). The function is set to Functional Mode because the example I use in my business scenario is simple and straightforward. The setting of the mode to Functional Mode for the multiple ruleset function allows you to directly create a decision table for this business example as a top expression. To complete this step, click the icon beside Top Expression and choose Create… from the drop-down list of options (Figure 8). In the next screen (Figure 9) you need to enter a name and other details of the decision table. Click the Create and Navigate To Object button. In the next screen (Figure 10) click the Yes button in the dialog box that displays. In the next screen (Figure 11), populate the tables in the Condition Columns and Result Columns sections by clicking the Insert Column and Insert Column from Data Object buttons, respectively. In the next screen  (Figure 12), the decision table setting for the multiple ruleset needs to be maintained. The Condition Column in my business example is the business process (BPROC), and the Result Column is the table data object RULESET_ID, which contains the elements RULESETID, UPDTIME, UPUSER, DESC, and CHGMODE. The RULESET_ID is the key element to consider. Therefore, you need to set it to mandatory. The Result Data Object needs to be configured to return all matches found (select the Return all matches found checkbox in Figure 12). This option is typically used when the result data object is a table data object. The use of decision tables offers the flexibility to choose if you intend to use the first matching record as the result or use all matching records. Click the OK button. For the purpose of my business scenario, in the next screen (Figure 13) you need to update the decision table as follows:

• If the business process associated with a request is BASIS_EAST, the ruleset RS_EAST needs to be used to perform access risk analysis.
• If the business process associated with a request is BASIS_WEST, the ruleset RS_WEST needs to be used to perform access risk analysis.

After defining values for the different columns (BPROC and RULESETID), you need to save the object. After you click the Save button, you receive a status message (Figure 14). Click the Activate button to active the decision table to make the definition productive. In the next screen (Figure 15) you receive a dialog box with a message confirming if you want to proceed with the activation. Click the Activate button. The status message shown in Figure 16 displays. In the next screen (Figure 17), the decision table Z_MULTIPLE_RULESET_DT is assigned as the top expression. Click the Activate button to make the function definition productive. Now you receive a message confirming if you want to activate the function as shown in Figure 18. Click the Activate button. In the next screen (Figure 19) you receive a status message.

Simulate Business Scenarios

To simulate the result of the BRFplus logic I just defined, you need to assign the same role to two different access requests that are analyzed using different rulesets based on the business process assignment. Also, I show the impact of setting parameter 1071 to YES or NO for different access requests. For the purpose of this scenario, I have created two rulesets; namely, RS_EAST and RS_WEST as shown in Figure 20. These rulesets can be created and maintained via customizing (SPRO > SAP Reference IMG > SAP Customizing Implementation Guide > Governance, Risk and Compliance > Access Control > Access Risk Analysis > SoD Rules) or via the front-end (NWBC – Rule Setup Workcenter > Access Rule Maintenance).

Scenario 1

In this scenario, an access request is created for user EAST_USER with the parameter 1071 set to NO. The submitted access request (Access Request 34) is shown in Figure 21 for a user who is assigned to the business process Basis Administration East (BS_EAST). Now the approver accesses his inbox and chooses the access request to approve. When he makes a selection a screen appears (Figure 22). In the User Access tab of this screen the approver sees that risk analysis has not been done for this access request. If the approver selects the Risk Violations tab, he sees that the ruleset is RS_EAST based on the business rule logic as shown in Figure 23. Note the following data shown in this scenario:

• The risk analysis has not been performed (parameter 1071 is set to NO) as shown in Figure 22.
• When you click the Risk Violations tab in the access request, you notice that the Rule Set field is autopopulated as shown in Figure 23. The ruleset is, of course, set to RS_EAST because the business process assignment of the access request is Basis Administration East (BS_EAST).

Scenario 2

In this scenario, an access request (access request 35) is created for user WEST_USER with the parameter 1071 set to YES. The access request is shown in Figure 24 for a user who is assigned to the business process Basis Administration West (BS_WEST). Now the approver accesses his inbox and chooses the access request to approve. When he clicks the User Access tab (Figure 25) he sees that risk analysis has been done. When the approver clicks the Risk Violations tab (Figure 26), he can see that the ruleset is RS_WEST based on a business rule. Note the following data shown in this scenario:

• The risk analysis has been performed (since parameter 1071 is set to YES) as shown in Figure 25 (compare this screen with the one shown in Figure 22).
• When you choose the Risk Violations tab in the access request, you notice that the Rule Set field is autopopulated. The ruleset is, of course, set to RS_WEST because the business process assignment of the access request is Basis Administration West (BS_WEST).