AC10.0/10.1: Create Rule Based on Risk Violation in Request, Using BRF+ Procedure Calls
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 document 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
Add another variable “BOOLEAN” 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
Many thanks for sharing.
Thanks a lot for this.
As per last screen shot you have maintained 2 variables but in post you have mentioned only one variable “RISK_ANALYSIS_RESULT” to add.
I was curious about this because while creating rule with process expression READ_RISK_VIOLATION , i am getting error as " No context available" instead of "Boolean".
yeah, i am also getting same..
It's possible use this for any kind of risk analysis ? Including roles ?
Very usefull material!
Any ideas how to solve error as " No context available" instead of "Boolean".?
I have changed step 11 to include the missing variable .
Thanks Amanjit. By adding the missing variable I was finally able to activate the rule succesfully. Is it possible to add a few snapshots for setting up the MSMP configuration with this rule as a routing rule enabled.
It is really good to see that you have explained the business scenario and what outcome you are trying to achieve before delving into the technical configuration steps
Thank you for a very detailed step by step Guideline. I am facing the following issue:
when I add this Rule as Initiator Rule in MSMP workflow, what should I add as Rule results? SODVIOL_DETOUR_PATH?
i have mentioned earlier two results values .
NO_SOD_VIOLATIONS this for path with no violation
SOD_VIOLATION this for path with violation
by trying to create this BRF+ rule I am facing this issue at Step No. 3.
Please give me an advice how to solve this Problem,
Please remove the highlighted row from signature .
Is it possible to add a few snapshots for setting up the correct MSMP configuration with this rule as a routing rule enabled. Thanks
Thanks for the hint. I will try it again.
I am unable to find GRFN_MW_S_ROUTING grc 10.1 . Do I need to activate any BC Sets or create new object on this name.
Thanks and regards
you wrote in your article that the Initiator rule "GRAC_INITIATOR_SOD_VIOLATIONS" is available in MSMP as a standard rule. But somehow I can not find these rule among 16 rules available in MSMP. Do I have to add this rule in Step 2 of MSMP workflow?
Thank you in advance,
I am using this guide in order to create another behaviour:
I have created a Routing rule that checks the content of of the Provisioning Action
If i simulated my function with this input information i get the correct Result
But when i perform on a real situation i face an error and the log indicates me the following. Seems like my decision table is returning /ROLEREMOVED2
Regards and thank you.
Can you able to resolve this? Please share.
Hello Amanjit Sir,
I tried configuring the same in our landscape.
The configuration is working fine when there are no risk violations.
the procedure call to call the function module "GRAC_IDM_RISK_WITH_NO_SERVICES" which returns the risk analysis result (Step 6) does not return any values when called in BRF+.
If i execute the function module stand alone in t-code SE37 by providing the same request number it provides 5 line items as risk violations (including high and low).
I have ensured that the custom table that i created in step 5 has the same table type as in the function module.
Please let me know if there is anything that i can change to resolve the issue.
Hi Amanjit Singh Bindra,
Excellent contribution. Your document is very rich in content and thanks for sharing your knowledge in how to use.
Again, in short..... Super 🙂
Great article and has proved to be very useful in enabling me to make a initiator that will take SoD violations into consideration before selecting the required approval paths.
The issue I have is that I would like to analyse each and every line item and split out the violating individual line items from the request and send them all to the additional approval path. I have implemented your version of the BRF+ rule as above, but it seems that the "READ_RISK_VIOLATION" table operation is looking at the whole request and if it contains at least one risk violating line item, it sends the whole request to the violation approval path.
Is there anything that can be modified so that each individual line item is scrutinised rather than the collective request? Or have I not implemented a rule correctly?
Many thanks for sharing your knowledge once again.
I am also stuck at the similar point you have discussed above.
Were you able to figure out the solution?
I have raised the following discussion:
I have not had the time to put in the extra effort to modify the rule so that it actually scrutinises the individual line items.
This rule works great if your implementation is wishing to forward the whole request to a single approver/team if it has at-least 1 risk.
Not heard anything back from the author or any other person from the community.
Thanks Aman Great work.
I am trying to implement similar solution . Initiate workflow based on the risk violations and i think this blog is the best fit.
I followed the steps however i ran into errors(assertion failed RABX STATE error) while adding rule to ruleset appreciate your suggestions.
How to correct the error
Probably the only way to eliminate the error is to correct the program.
If the error occurs in a non-modfied SAP program, you might be able to
find a solution in the SAP Notes system. If you have access to the SAP
Notes system, check there first using the following keywords:
"CL_FDT_WD_MODEL===============CP" bzw. CL_FDT_WD_MODEL===============CM00T
If you cannot solve the problem yourself, please send the following
information to SAP:
Thanks a lot for your valuable information !
I have followed your document and configured the same in my application .
I have one doubt, why we are not maintain the decision table for " critical level " which we have created while creating the BRF+ application .
Here I want use both the conditions for Routing 1 critical level and other one is SOD violations.
Can you please provide me your inputs on this ??
I believe the Critical level would be against the individual roles, i.e. line items. This rule works great, but as I have observed and commented earlier, it will detour the whole request if any one of the line items in the request causes a risk violation.
I had asked the author if there is a way to modify this rule to work in such a way so that only the actual roles/line items that cause a risk are re-routed.
the SAP delivered SoD-detour rule can do this, but would would like a way to replicate the same behaviour from the initiator stage.
Thanks a lot for your reply!
As you said critical level is against the individual role only.
my doubt is here we have one decision table only and in that we have maintained the condition as SOD violation, then from where it is checking for Critical role level.
can please let me know the steps.
correct me if I am wrong ??
Valid question. CRITLVL was'nt used elsewhere. Also, CRITLVL is associated with a role and not risk violations. For Risk Level (low, medium, high), there is a field RISKLEVEL under table GRACRISKLEVEL. Cant relate why the author used CRITLVL or if he is just showing for illustration purpose. Believe, if we select this line item RISKLEVEL, would fit what the author is trying to explain in this document.
Would be nice if the author replies back to share his thoughts on this. Lets hope 🙂
Anyone of you got performance issue while using this BRF+ rule or similar rules? As I created one and have to wait almost 1 minute to retrieve request number generated from the workflow.
The rule spent most of the time on doing risk analysis and it loaded the whole act_rule before analyzing user ID in the request.
Is there any good idea to improve? Thanks in advance!
How this works if we have New account, change, remove, lock/unlock request type?
I want the risk analysis happen first and then mitigated then it should go to role owner stage. How is that possible?
For role removal or delete it should go to different path?
Did you find the solution?Were you able to do configuration for getting risk analysis /Mitigation done before role owner stage?If so could you please provide the steps you performed.
Thank you for the valuable information! Can you please share how to only check for NEW risks. We would like to only route down the SOD path if a role being requested creates a new risk. I have implemented this solution and it appears once a request is submitted, it routes the request down the SOD path if the user has an existing SOD - Rather than only if the role in question creates a SOD. Also, parameter 1073 does not apply if this solution is implemented. It seems to only be applicable if GRAC_MSMP_DETOUR_SODVIOL is used.
Any feedback would be greatly appreciated!
Thank you for the document.
I have a query/reqiirement.
How can I send the request to SOD Risk Owners in the Process ID SAP_GRAC_ACCESS_REQUEST.
I understand I should create a agent rule with the same logic untill procedure call. And instead of table operator, I should use a logic to compare the results with standard table GRACSODRISKOWN, to get risk owners.
But not sure how to proceed.
Any help is very much useful.