AC 10.1/10 : Create Routing Rule Based on SoD violation in Access Request Using BRF+

In Access Request, sometimes you would want to route your request based on the risk violations present in the request. There are some standard function module based detour/initiator rules which are available in MSMP like 'GRAC_INITIATOR_SOD_VIOLATIONS' and 'GRAC_MSMP_DETOUR_SODVIOL' where you can route your request based on risk violations. But these standard rules are inflexible, so if you want to add another condition for routing along with risk violation then you will have to change the abap logic within these function modules.

So using these standard rules you can route request based on risk violation only. If you want to create an initiator rule based on risk violation and 'Sensitivity' of role or if you want to create a routing rule based on the 'Risk Level' of violations then it is not possible using standard rules unless you change ABAP logic.

In this section we will see how we can utilize power of BRF+ by creating a very flexible initiator/routing rule where we can check combination of multiple conditions and not just Risk Violations. We will be taking example of following business scenario :  

Business Scenario :

If an access request contains risk violations with Risk Level as 'High', then the request should be routed to a special path, and if no violations with Risk Level  'High' are found, then continue with normal path

We will use BRF+ procedure call to get risk violations in the request. In BRF+ Procedure call, we will use one of the standard function module to get risk violation details of a request.

Follow steps below to create a BRF+ flat rule to achieve above scenario

1.) Generate BRF+ Shell for Access Request Initiator from transaction 'GRFNMW_DEV_RULES'

• Fill generation criteria (Process ID, Rule type, etc.)
• Specify Generation options and select any field from Header or Item to ensure decision table is generated automatically
• Generate rule shell (Execute button)

2.) Activate Empty BRF+ Rule using transaction BRF+

• To locate the generated function, use menu, 'Workbench -> Open Object' and specify object ID from previous step
• Activate the function
• Change the mode to “Event Mode”

3.) Change Result Data Object of BRF Function

• Since Function mode has been changed to “Event mode,” the result data object has changed automatically, so it has to be reset manually
• In “Signature” tab of BRF Function, change the result data object to GRFN_MW_S_ROUTING

4.) Function Module to Get Risk Violation Details

• We will be calling function module  “GRAC_IDM_RISK_WITH_NO_SERVICES” in BRF+ rule to get violations details 
• It returns a table with violations; so first, we will create a table in BRF rule which will hold the result of the function call

5.) Create Data Object

• From context menu of BRF+ application, create a Data Object of type “Table”
• This data object will hold the risk analysis result

• Select DDIC Binding and provide name of DIDC Table Type of “GRAC_T_WS_RA_OP_RISK_ANLYS_ID”
• Activate the Data Object

6.) Create Procedure Call to Get Risk Analysis Result

• Create a procedure call from context menu of BRF application

• Within procedure call, select Call Type of “Function Module” and provide Function module name as “GRAC_IDM_RISK_WITH_NO_SERVICES.” Press “Enter” key after providing function module name.
• Add parameters to the procedure call

• Select the Data Object created in step 5 as “Result Data Object” for this procedure call

Map Parameters to Context Fields

• Click on Mapped parameters to expand the details
• Assign value to these parameters using BRF+ context parameters
• Activate procedure call

7.) Create Expression — Table Operation : Check Risk Analysis Result Table for Risks

• Create an expression of type “Table Operation”
• This expression will read the result table of procedure call to check if any violations exist

• This expression will read the result table of procedure call “RISK_ANALYSIS_RESULT” to check if any violations exist
• Additionally, here we are checking for any risk with “High” risk level
• Activate “Table Operation” expression

8.) Add Condition Column to Decision Table

• Go to Decision Table that was generated automatically
• From decision table settings, add a column from expression and use expression “READ_RISK_VIOLATION,” which is a table operation

9.) Add Business Logic to Decision Table

• Add conditions to the decision table
• Based on the result of “Table Operation,” which checks whether any “High” risk violations exist in request or not, the path of request is decided

10.) Create Ruleset

• Go to BRF+ function and create a new ruleset

• Add variable “RISK_ANALYSIS_RESULT,” which was created in previous steps, to the ruleset

11.) Add Rule to Ruleset

• Create new rule within ruleset
• Within this new rule, call the procedure that was created in previous steps

12.) Add Second Rule to Ruleset

• Within same ruleset, create second rule that will call the “Table Operation” expression “READ_RISK_VIOLATION”
• This table operation will read the violations, which are returned by procedure call

13.) Add Third Rule to Ruleset

• Within same ruleset, create third rule that will call the “Decision Table” expression
• Decision table operation will internally call table operation to check if any violation was returned by procedure call and, based on the result, it can decide the path of request

14.) Check sequence of rules within ruleset

• Check the sequence of rules within ruleset
• First rule in the sequence should be procedure call, second should be table operation, and last should be decision table
• Activate all objects

Now you can configure this rule in msmp configuration and use it as routing or initiator rule

Role Import in BRM

The purpose of this section is to explain the role import features in GRC 10 and to discuss about all prerequisites for role import to avoid any issues. In this document import of composite roles was discussed rather than single roles.

Role Import Prerequisites

• Roles can be imported directly from the backend SAP system or using a role authorization data file.

• Define Role Selection criteria (like Business Process, Sub process, Project, Functional Area etc.)  and import data source.

• Roles have to exist in the backend system.

• Role sync job has to be performed. [Very Important step]

• Roles from backend system can be downloaded by executing Tcode /N/GRCPI/AC_ROLE_DNLD or by executing the program /GRCPI/GRIA_DNLDROLES in SE38.

• Maintain parameters 3021 path, 3003 value and download roles with .txt file (File location) and .xls (Role Info File)

• Maintain business process, sub process, Project, Role status, System [Alphanumeric (32)] etc. in theRole Info File downloaded from backend system. Role status is very important attribute. Only roles which are maintained with status as “PRD or "PRO” (depending on your GRC SP) in BRM will be available for selection for users during access request creation.

• To maintain production status, Go to IMG => Governance Risk and Compliance => Access control => Role Management => Maintain Role Status

• Make sure to check the PRODUCTION STATUS checkbox for the status (Recommended is PRD or PRO (Depending on your GRC SP), but DEV and TST can be checked as production status based on the testing environment).

• Based on PRODUCTION STATUS settings configured, make sure each role status is set accordingly.

• Make sure that Provisioning Allowed flag and Auto Provisioning flag is be set to “Y (YES)” in the role info file.

• Make sure PROV scenario has been maintained for the connector for which you are importing the roles. [Best practice is to link all the integration scenarios AUTH,PROV,ROLMG,SUPMG to every connector to avoid any discrepancies]

• Maintain Mapping for Actions and Connector Groups - Ensure connection group in place for 0004 Provisioning

• Once Role Info File is maintained with all required attributes, save this file in Text Tab Delimited format.

• Now we will have two files which can be used for role import, Role Authorization text file and Role Info text tab delimited file.

Role Import in NWBC

• Logon to GRC frontend application (either using Portal or NWBC)

• Go to "Access Management" WorkCentre.

• Click on option 'Role Import' under 'Role Mass Maintenance'. You will get below screen.

• In this document, we will discuss on role import feature by considering Import Source as “File on Desktop” for Role Attribute Source and “File on Desktop” for Role Authorization Source”.

• Role Attribute Source [Note: Role Authorization Source can be skipped if you do not want to maintain authorizations in BRM and just want to use roles for provisioning purposes only]

• Make sure that all the single roles associated to the composite roles are already imported into GRC box before your try to import the composite roles.

• Make sure that all the derived or imparting roles associated with the Master or Parent roles are already imported into GRC box before your try to import the Master/Parent roles.

• Also make sure that Authorization Sync job is already run and successfully finished for the connector against which you are trying to import the single/composite roles. Otherwise it gives an error message ‘’Composite Roles relation attribute and Authorization do not match.”

• While importing role template looks like as shown below.

Composite Role                                     Associated single roles

YP1_XXXXXXXXXX_XXX                             YJ_XXXXXXXX_XXXXXXXX

                                                              YJ1_XXXXXX_XXXXXX

                                                              YJ2_XXXXXXXXX_XXXXXXX

YP2_XXXXXXXXX_XXXXX                            YJ3_XXXXXXX_XXXXXXXX

                                                              YJ4_XXXXXXX_XXXXXXX

                                                              YJ5_XXXXXXXXXXX_XXXXX

• Provide application type, Landscape name, role name and other role details as per your requirement in the below screenshot and click on Next button.

Definition Criteria

• Application Type: It should be selected as SAP. If you are creating a Business Role, then it must be selected as Business Role.
• Landscape:  This should be selected as the connector group name and in case of a Business Role, select it as ‘Role Management Business Groups’
• Overwriting Existing Roles: This option overwrites the roles already existing in the system if this selected as ‘Yes’. If you do not want to overwrite the Roles, select it as No. 

Role Selection Criteria:

• Source System: Connector name from where the Role will be fetched.
• Role Updated After: Specify a date after which the Role was updated.
• All Roles except SAP Predefined Roles: Tick the check box if you want to import all the Roles into BRM except SAP Predefined Roles.
• Role From and Role To: Specify a range in between the Roles should be fetched.
• Methodology Status: This is important because this will decide whether the Role will be imported as ‘Complete’ or ‘Initial’. Role Methodology is the process followed for role creation and maintenance operation.

• In the below screen, select the Role Info file and Role authorization file which was earlier saved in desktop as shown below and click on Next button.

• Once you click on Next button, you will get the below screen and from here you can select “Preview all roles” button and can check if the roles are being shown before scheduling the Role Import job. If the roles are displayed and everything is fine, click on Next button.

• Once you click on Next button, you will get the below screen and from here you can execute role import job either in background or Foreground, depending on the volume of roles being imported

• Once roles are imported you will get a screen as shown below which shows how many roles imported and how many roles not.

GRC Role Management Scenarios in BRM and PFCG

• In NWBC, you have Role Maintenance>Role Import link. Via this link you can bring roles existing in GRC plugins (for instance ECC, BW, and CRM) and synchronize them in the GRC Repository tables.

In GRC10, we have these possible scenarios:

• R/3 roles are only synced by the role sync job, and never imported into BRM. We call them backend roles. In this case, the role exists only in table GRACRLCONN. And it can be deleted directly from PFCG, as the role sync will run and capture the deletion, and remove the role
  from GRACRLCONN table.

• R/3 roles are synced by the role sync job, and are IMPORTED into the BRM tool, via link "Role Import" in NWBC. In this case, the role exists in BRM. We call it BRM role. In this case, the role exists in both tables GRACROLE, and GRACRLCONN. And it should only be deleted from
  BRM. When it is deleted from BRM, it will be removed from BRM and also a background job will automatically start to remove the role from PFCG and from GRACROLE and GRACRLCONN tables, and all other related tables, like GRACROLEAPPRVR (for approvers).

• If you delete a BRM role from PFCG directly, you break the whole chain. And it introduces inconsistencies to the application.

To improve this document further with different issues caused during role import, please share if you have any details so that it would be easy for the people who are searching for help on this topic 

Common Issues during Role Import

• Role import doesn't show all roles during "Preview Roles". Please implement below note in that scenario.

1897975 - Role import does not show roles in the preview

Also check scn discussion on the same Role Import doesn't select all roles from source system

1576321 - Import derived role without master role 

1570971 - Composite roles cannot be imported without single roles