Dear colleagues,
I hope that some of you who reads this blog can influence on the process to improve GRC ARQ functionality by voting for the idea.
Let me describe my vain attempts to outflank poor functionality of multiple user request. Maybe some of you can suggest obvious way to resolve the described problem.
I started my discovering after getting a task to customize block/unlock processes. The processes should forward requests for a certain approver basing on user's region. So that, if a request contains user from Dagobah, the request will be forwarded to Yoda; if a request contains user from Kashyyyk - it goes to Chewbacca. Simple logic that surely must be made in GRC and can be made... but only for a single-user request. If we create a multiple request with both users from Dagobah and Kashyyyk, then the whole request will be approved or rejected by the first approver (I assume it would be Yoda, because he is Jedi :lol: ).
Firstly, I tried to customize BRF rule for a stage with approvers. I created the rule that works perfect in simulation mode, but it didn't work in a real workflow. SAP support found a bug in BRF (Note 2317257), but the summary for my incident was "it's not available to take a decision for a single user in multiple request". The possible solution, in my opinion, might be adding for MSMP stage properties approve level "users" as well as we have it for "system" and "role".
Secondly, I decided to divide users in different paths by their company. Again, a few days to create a rule was waste to get a similar result. In simulation mode rule works fine, but in real work mode I get the error message:
Rule SAP_GRAC_ACCESS_REQUEST/B/578E2CB300E8E3AFE1000000C0A80947: Returned result for not requested Line-Item ''
I assume that again it happens because multiple or even single user request contains line items (system and/or role) that cannot be forwarded to another stage, while my rule based on users' attributes that are not a line items. So, the system can segregate line items only, but not other valuable entities of requests.
I hope that someone can advice me the possible solution in the comments or at least to vote the mentioned idea.
In the end, I decided to share my function for searching approvers, I hope that someone can use the logic or a part of it to implement in own system. Please find it below.
Special thanks to christian.lechner who helped me with my issue during investigations.
Regards,
Artem
GRC 10 SP23
Be aware, it's just an example that needs to be customized according to your needs (for example, add request type in the logic).
If we test the function with the following REQ_ID we get the correct results: request with one user (#39 and BRK company) goes to single path, request with multi user (#100) goes to different paths according with the company addresses.
Single-user request
Multiple-user request
Simulation for single:
Simulation for multiple:
