cancel
Showing results for 
Search instead for 
Did you mean: 

How to pass MX_REASON to GRC ?

Frank_Buchholz
Advisor
Advisor
0 Kudos

When creating a role request in IdM we want to utilize mandatory attribute MX_REASON as part of the MXREF_MX_ROLE request. The UI task produces a MX_PENDING_VALUE object. The attributes of the pending object are used to construct the request which is send to GRC.

However, currently the reason MX_REASON of the request is not passed to MX_PENDING_VALUE  and therefore cannot be forwarded to GRC.

I guess the we have missed a very simple configuration step - assuming that it's a standard case to create role requests in IdM and run the approval process in GRC. Do you have a description of the main configuration steps to enable passing MX_REASON to GRC?

Mit freundlichen Grüßen / Kind regards

Frank Buchholz

Accepted Solutions (0)

Answers (1)

Answers (1)

deepakkg86
Participant
0 Kudos

Hello Frank,

I am using IDM 7.2 SP8 Version and I can see that MX_REASON attribute is assigned to entry type: MX_PENDING_VALUE which inturn sends the reason to GRC while submitting request.

There is a piece of Java script involve to calculate the reason.

Please see below and check the script code for script:

sap_grc10_setRequestReason

Thanks

Deepak Gupta

Frank_Buchholz
Advisor
Advisor
0 Kudos

Hi Gupta,

I guess, that I've seen the same code in the script which creates the GRC request like in your screenshot (here converted to text):


REQUEST_EMPLOYEETYPE    $FUNCTION.sap_grc10_getGlobalVariable(GRC_ROLE_EMPLOYEE_PERMANENT)$$

REQUESTREASON    $FUNCTION.sap_grc10_setRequestReason(%$rep.GRC_REASON%)$$


In our case here, we see that the attribute is available for the PVO but not set and we cannot find a corresponding record in the database. Therefore sap_grc10_setRequestReason  simply pulls the repository constant instead of the reason of the request.


Can you confirm, that the attribute MX_REASON of MX_PENDING_VALUE actually gets the text of the reason from the request (and that this individually text is then send to GRC)?

If you have the seen it live, than we would know that something is wrong with our configuration. 


We can see the reason of the request in table idmv_link_ext2 (Thank you Savas for this tip!):

"SELECT mcOtherMSKEY, mcValidFrom, mcValidTo, mcReason FROM idmv_link_ext2 NOLOCK WHERE mcThisMSKEY = " + thisMskey + " AND mcLinkState != 2 AND mcLastAudit = " + auditID

Table idmv_link_ext2

https://help.sap.com/saphelp_nwidmic72/en/mc/dse_views_for_reference_attributes.htm


However, we do not want to modify the GRC integration script (or sap_grc10_setRequestReason) to read this table.


Kind regards

Frank



deepakkg86
Participant
0 Kudos

Hello Frank,

I can confirm that in my system it works fine, If I give any reason while raising request this gets written to GRC request and if not then scripts picks the default reason defined in GRC10 repository constant.

Regards

Deepak Gupta

deepakkg86
Participant
0 Kudos

Hello Frank,

May be you can put UINFO / UWARNING function in script to see what data it picks for MX_REASON .

I guess your script doesnt pick the correct identity store and hence failing to pick MX_REASON.

Regards

Deepak Gupta

Frank_Buchholz
Advisor
Advisor
0 Kudos

Thanks for confirmation!

Well, then I need to search deeper for the root cause...

Could it be an issue with roles vs. privileges? In our case users request roles in IdM, but the request for GRC contains the privileges (as far as I have understood it). GRC knows only yout the IdM privileges = ABAP roles, but not about the roles in IdM.

Kind regards

Frank

deepakkg86
Participant
0 Kudos

Hello Frank,

Exactly, That is the case.

Since MX_REASON is only written to Roles and not inherited to the privileges.

Let me just work out for this, How we can send the same reason from Role to GRC with privileges.

If you get any solution then please post.

Regards

Deepak Gupta