Using GRAC_DETOUR_SODVIOL_NO_ROLOWN Routing Rule

[Former Member]

Hi Guru's -

Can someone explain to how to use this Routing Rule or what the point of it is?

Based on the description, it sounds like this rule is supposed to check to see if the Access Request contains an SoD violation AND has roles associated with No Role Owner. Here is out the description reads in the MSMP Workflow:

SOD violation and no roleowner chained routing rule ( Process Type : SAP_GRAC_AR)

I have not seen any other threads on this so I assume that it is not utilized much, but I have a workflow design where I want to perform a check just like what is being implied in the routing rule. If the combination of roles has and SoD AND one or more of the roles does not have a Role Owner, I'd like to route the request to a different Path. However, when I try to implement this routing rule in the "Maint Route Mapping" stage, I get two options of either a Rule Result of "NO_ROLE_OWNER" OR "SODVIOL_DETOUR_PATH"

To me this seems redundant since there are two other Routing Rules "GRAC_MSMP_ROUTE_NO_ROLEOWNER" & "GRAC_MSMP_DETOUR_SODVIOL" which perform the exact same function and produce the same two Rule Results.

The description of this routing rule is misleading because to me in the description when it says "Chained Routing Rule", it implies that it will check for both conditions....

Can anyone provide feedback on how to use this Routing Rule and if it can be used the way that I'm suggesting?

It seems redundant to have the rule setup this way, but I believe I may not be using it right.... any feedback would be greatly appreciated.

[Former Member · Accepted solution]

All -

To accomplish the desired requirement, I created a BRF+ rule to create the inverse of what was initially intended. So instead of routing roles that did not have a role owner down a particular path, I created a custom role attribute to flag the roles which required role approval called 'check'. With this attribute, I created a BRF+ Initiator rule to check for roles that contained this 'check' attribute.

If roles were submitted with this attribute then they were routed do a custom Role Review path and if not then they were routed to the default path. I used the standard SoD Violation/No Role Owner routing rule in the default path to perform the SoD check routing and the standard SoD routing rule in the custom Role Review path.

This customized workflow worked great and even split up requests that had both 'Check' roles and non-role owner roles to send the same request down two separate paths. Although the request could not be completely provisioned until all parties approved the request based on our configuration. If the configuration was set to provision immediately for approved roles this would elevate the delay.

Unfortunately the standard {GRAC_DETOUR_SODVIOL_NO_ROLOWN} routing rule does not perform the implied logic on requests that meet  both conditions.

Based on the configuration that we've implemented in the BRF+ rule when the customer associates a role owner with roles which require approval for provisioning; they need to additionally flag the role as 'Checked' to ensure that the workflow is effective for the requirement. A validation process has been setup to check that all roles with a role owner have the check flag associated after every role import.

More details and screenshots of the configuration setup here may be more indepth and complex to capture in this thread, however if anyone has further questions in this regard please don't hesitate to reply to this thread.

Thanks,

Darnell

[Colleen]

HI Darnell

I suspected this routing rule exists if you have automatic SoD check (think set via configuration parameter 1071 Yes - Enable risk analysis on form submission) when user submits the request. This may capture scenario of both conditions as either no role owner is located straight up or a SoD violation is identified. Not sure what happens if both conditions are true.

Possible you could look at the ABAP and compare the differences to see how it returns the result?

Love to hear everyone's thoughts on this topic to clarify

Cheers

Colleen

[Former Member]

Hi Colleen,

Thanks for the feedback. I actually have this setup as you've suggested with the automatic SoD, but in the 'Maint Route Mapping' stage the rule result only let's you select one result... either 'No Role Owner' OR 'SoD Violation' but not both.

I've tested this in my workflow which has the following stages:

<Auto SoD Check>

(Path 1) [Stage 1] Manager - Using Routing Rule : GRAC_DETOUR_SODVIOL_NO_ROLOWN

(Path 1) [Stage 2] Role Owner - Using Routing Rule : GRAC_MSMP_DETOUR_SODVIOL

<Routed to Path 2>

(Path 2) [Stage 1] SoD Review

So what I'd expect is that at the Manager stage, if the Request does not have SoD Violations and No Role Owner but approved by a manager, it would be provisioned.

If it does have a Role Owner or SoD Violation it would continue through the path.

I'm not sure how it would handle request that have at least one role owner on the grouping of say 4 roles vs. no role owners on any of the roles.

As stated in my original post the 'Maint Route Mapping' stage in the MSMP workflow configuration when using the Routing Rule it only allows you to choose only one rule result (No Role Owner' or  'SoD Violation). Where I would expect it to allow you to select both or show a combined rule result.

Colleen, on a semi-related note; do you know of a good way to use the routing rules and paths to auto provision after the check is done? For example, I would like to run this Routing Rule check at the Manager stage and if their is no SoD or Role Owner, I would like for it to provision the role. But on the Route Mapping Stage a Path is required to be chosen in the configuration and I'm trying to find a good way to create an auto provision path.

[Colleen]

Hi Darnell

This is great testing and analysis that you are doing!! For all the effort, have you considered turning this into an article for the SCN community detailing the routing rules?

Ofcourse (slaps forehead) you would only get a single return result.

I suspect you just need to test the scenarios or see if any one else jumps in on this thread and adds their perspective.

do you know of a good way to use the routing rules and paths to auto provision after the check is done?

For this one, it's been covered in SCN already:..

Route to a Path that has no stages. This will request 0 approval for the stage and complete the workflow for that item or request (depending if you routed by line item or not and configuration settings).

Cheers

Colleen

[Former Member]

Thanks Collene,

I would be happy to pull something together for an article on routing in AC10.0. Also thanks for your feedback. I will need to do some more extensive testing but I will update the thread as well with my results.

Hopefully someone has had a similar need to use this routing rule and can chime in, but I guess I'll be left to testing until then.

Also thanks for the feedback on the no stages (slaps forehead as well)... makes a little too much sense to not have thought of that on my own

[Former Member]

Ok -

I have done some extensive testing and still do not have the result that I am expecting using the 'GRAC_DETOUR_SODVIOL_NO_ROLOWN' Rule ID. Unfortunately, this rule is pretty much useless for the function that I'm trying to perform because even though the description is written as an 'and' (i.e. SOD violation and no roleowner chained routing rule) it actually uses 'OR' logic.

For example, if I designate this rule at a single stage (Step 5 - Maintain Paths), let's say the Manager Stage I would expect that the rule will check to see if the request have an SoD 'AND' if there is no Role Owner, see Maintain Stage Config below:

However, at Step 6 (Maint Route Mapping), you must choose 'EITHER' NO_ROLE_OWNER 'OR' SODVIOL_DETOUR_PATH. As shown below:

The caveat is that you can route the rule result based on the rule values you select to different paths if you choose... For example, if there is No Role Owner then I can route to Path 1 with this rule or if there is an SoD Violation, I can route to Path 2 using the same Rule ID (GRAC_DETOUR_SODVIOL_NO_ROLOWN). Essentially allowing you to route a request from a single stage to 2 different paths with a single rule.

But this is not what I'm trying to accomplish...

My issue comes in when there is a request submitted that has an SoD Violation 'AND' a Role Owner. I am checking for SoD violations at the point of submission (via Parameter setting 1071  = Yes - Enable risk analysis on form submission), so I can verify if there is an SoD violation or not. But if there is a violation, I also need to know if there is a role owner associated with the request role as well so that a decision can be made based on both criteria. Which lead me to look at the Initiator Rules (Step 2 - Maintain Rules), specifically Initiator Rule - GRAC_AR_INITIATOR which starts the workflow.

The hope here is to possibly modify the initiator condition to use the 'risk analysis on submission' check and initiate the workflow to a chosen path based on whether or not there is an SoD. This way, I can make one of the decisions for the SoD Check without having to do it at a Stage.

The Rule Results for the GRAC_AR_INITIATOR looks like it allows you to add multiple results, which in my case I would like to use the initial SoD check and send the request to a different SoD Path at the initiator as shown below:

With this configuration, I would hope to be able to go to Step 6 (Maint Route Mapping) and add another Rule Result Value for the GRAC_AR_INITIATOR based on whether or not there was an SoD at the Initiation for the Access Request, see below:

Unfortunately, I have tested this scenario a couple of different ways; with and without SoD violations at the initiation of the access request and it continues to go down the Default Path.

Has anyone had any success adding multiple initiators the the MSMP workflow without the use of BRF+? I say this because I know there is a way for this to be accomplished by creating custom initiators, but the client has requested to attempt to keep the AC configuration as vanilla as possible and I want to avoid the additional training and knowledge transfer required to convey this type of custom configuration.

It seems to me that the above setup at Stage 2 (Maintain Rules), should be able to be accomplished by the path chosen at the initiator, but if this is not possible then I do not understand why this table is available to add additional Rule Results to it.

Any feedback based on your testing or understanding of this config would be greatly appreciated!

Darnell

QUICK UPDATE TO THIS POST:

Upon further testing of the GRAC_DETOUR_SODVIOL_NO_ROLOWN Routing Rule, I've determined that if both conditions are met at the same stage, the 'SoD Violation' condition wins over the 'No Role Owner' condition. See screenshots of example below were the Maintain Route Mapping - Stage 6 is setup with the routing rule and routing for both conditions at stage 1 of the default path:

An access request was submitted with a role meeting both conditions (i.e. SoD Violation and No Role Owner) and the rule routes to the SoD Path each time. See a audit log results below:

Message was edited by: Darnell Suggs

[Colleen]

Hi Darnell

Upon further testing of the GRAC_DETOUR_SODVIOL_NO_ROLOWN Routing Rule, I've determined that if both conditions are met at the same stage, the 'SoD Violation' condition wins over the 'No Role Owner' condition.

That's good to know. I still wonder that this rule was designed to capture SoD Violation and then situation arose when No Role Owner was found

Unless someone on this community can contribute to your analysis, it seems like you need to take this up with SAP and get a formal response

The key thing to remember with MSMP - it's default basic configuration. You use their solution or they have examples there for you to tweak and build your own. Ofcourse, knowing their routing rules is necessary to determine whether they are relevant to your business requirement and what you would need to "tweak"

Great Analysis

Cheers

Colleen