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.

Untitled.png

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)

Untitled.png

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”

Untitled.png

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

Untitled.png

Untitled.png

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

Untitled.png

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

Untitled.png

Untitled.png

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

Untitled.png

6.) Create Procedure Call to Get Risk Analysis Result

  • Create a procedure call from context menu of BRF application

Untitled.png

Untitled.png

  • 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

Untitled.png

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

Untitled.png

Untitled.png

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

Untitled.png

Untitled.png

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

Untitled.png

Untitled.png

  • 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

Untitled.png

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

Untitled.png

Untitled.png

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

Untitled.png

10.) Create Ruleset

  • Go to BRF+ function and create a new ruleset

Untitled.png

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

Untitled.png

Untitled.png

Untitled.png

Add another variable “BOOLEAN” to the ruleset

/wp-content/uploads/2013/08/1_395385.jpg

/wp-content/uploads/2013/08/3_395411.jpg

/wp-content/uploads/2013/08/4_395412.jpg

11.) Add Rule to Ruleset

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

Untitled.png

Untitled.png

Untitled.png

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

Untitled.png

Untitled.png

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

Untitled.png

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

Untitled.png

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

To report this post you need to login first.

35 Comments

You must be Logged on to comment or reply to a post.

  1. Deepak Jaiswal

    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”.

    (0) 
      1. T. de Jong

        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.

        (0) 
  2. Colleen Hebbert

    Hi Amanjit

    Great article!

    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

    Cheers

    Colleen

    (0) 
  3. Sabrina G.

    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?

    sod6.PNG

    Thanks,

    best Regards

    Sabrina

    (0) 
  4. Sabrina G.

    Hello all,

    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,

    thanks,

    Sabrina

    brf+.PNG

    (0) 
      1. T. de Jong

        Hi Amanjit,


        Is it possible to add a few snapshots for setting up the correct MSMP configuration with this rule as a routing rule enabled. Thanks

        (0) 
  5. Sabrina G.

    Hello Amanjit,

    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,

    best regards

    Sabrina

    (0) 
  6. Sara G

    Hi all.

    I am using this guide in order to create another behaviour:

    Business scenario:

    1. A requestor creates a request with one , two or more roles and sends to approve to various role owners.
    2. The role owners indicates (in the Provisioning Action field) if they accept or not an scpecific role. Like showed in the screenshot below and then they push on Submit button

    roles.JPG

    I have created a Routing rule that checks the content of of the Provisioning Action

    • If any of them is set as Remove route the Request to specific path 1
    • If all of them are set as Assign route the Request to specific path 2

    If i simulated my function with this input information i get the correct Result

    • One of the provision action to Remove (action = 009)

    roleremoved.JPG

    resultremoved.JPG

    • All the provision action to Assign (action = 006)

    roleapproved.JPG

    roleassigned.JPG

    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

    log.JPG

    Regards and thank you.

    (0) 
  7. Khush Bafna

    Hello Amanjit Sir,

    I tried configuring the same in our landscape.

    The configuration is working fine when there are no risk violations.

    Problem:

    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.


    Regards,

    Khush Bafna.

    (0) 
  8. Harinam SanKirtan

    Hi Amanjit,

    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.

    (0) 
      1. Harinam SanKirtan

        Hi Harris,

        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.

        (0) 
  9. Sam S

    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.

    Ex:

    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:

       “ASSERTION_FAILED”

       “CL_FDT_WD_MODEL===============CP” bzw. CL_FDT_WD_MODEL===============CM00T

       “IS_MODEL_NODE_TRACKED”

       If you cannot solve the problem yourself, please send the following

       information to SAP:

    (0) 
  10. beere naresh

    Hi Amanjit,

    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 ??

    Regards,

    Naresh

    (0) 
    1. Harinam SanKirtan

      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.

      (0) 
      1. beere naresh

        Hi Harinam,

        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 ??

        Regards,

        Naresh

        (0) 
    2. Venu Gudimalla

      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 🙂

      Venu

      (0) 
  11. Yui Du

    Hi,

    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!

    (0) 
    1. Krishna VG

      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?

      Please help

      (0) 
      1. Anika Gupta

        Hi Krishna

        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.

        Thanks

        Anika

        (0) 
  12. Jamie Traffas

    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!

    Jamie

    (0) 
  13. Yuvaraj Yalamarthi

    Hi Amanjit,

    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.

    Regards,
    Yuvaraj

    (0) 

Leave a Reply