on 07-07-2016 4:08 AM
Hello experts,
Is there a way we can put a validity period for a pending assignment. Say after 2 days pending, the assignment can be changed from pending to failed automatically.
We have a scenario that we need to follow a GRC approval process before the business role ->privileges can be assigned to a end user. Some times, the process is stuck, and the assignment remains pending forever. We cannot fix this issue by remove the business role and assign it back. However, if the assignment becomes failed, or rejected, we can use retry function in UI or in script to re-trigger the approval process.
So what I want to achieve is that, when a business role-privileges are assigned to a user, it can keep pending for one day or two, then becomes failed automatically. I then setup a job to collect failed assignments and do the retry.
Is this feasible?
Thanks,
Chenyang
If you need to manually fail a number of assignments, you could write a job with a script utilizing the uIS_Approval function. You could even write a job that runs on a schedule to look for approvals over your set amount of time, say 6 days, and that job could use uIS_Approval to fail any approvals that hit that mark.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I'm actually facing this exact same problem in my environment right now. I have a ton of PVOs that are waiting on approval but there no approval waiting out there for them; and yes you're right. uIS_Approval won't work without that ApprovalID. I actually posted on SCN a little bit ago asking how to push through PVOs awaiting approval where this was the case but never got any bites.
If you take the MSKEY of a PVO, you can see where it's hung up in the Provisioning Queue. My thought process was to try and manually manipulate the database values of the PVO in the Provisioning Queue to trick the system into thinking the approval was successful (or even declined) so that the provisioning would complete. I'm still working on that approach and if I come up with anything, I'll post here.
Finally, my company pays for SAP support so I'm going to submit an OSS ticket for this as well. I'd like to think I'm not the only one who's ever faced this issue, and now I know it's true since you're seeing it too. If SAP provides an answer, again, I'll update this discussion.
Brandon,
There is a way to remove the pending value object, then change the mcexecstate of the link to failed. You can retry the provisioning from there. But that approach needs database update, which is not ideal solution I am seeking.
From my environment it needs following steps,
1) find the existing PVOs for a user and their audit log IDs
2) delete the relevant audit log from database (this is the prerequisite before deleting PVOs)
3) delete PVOs from IdM console
4) update the mxi_link table and set the pending link to failed
5) retry failed assignments of the user either from UI or from a script
You can test this solution on your environment. Again, I wish having an easier solution than this.
I've considered that approach but, like you said, it's not the ideal solution. Again, since my company has SAP support, I'm going to wait to hear what they say. Hopefully they have something up their sleeves that's less disruptive to the data and a cleaner solution.
As before, I'll post what I get back from them when I get it.
Hi Chenyang,
have you tried setting a timeout in the options of the approval task of the AC-Validation Process (or Task Group in 7.2)?
Regards
Norman
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Chenyang,
that would mean it stops polling after 5 days and would get into failed state. But as you mentioned sometimes the logic is not working sufficiently for you, so you should try setting the same timeout on the actual approval task itself as well. It is the approval task (looking like a stamp) in the AC Validation task group.
Regards
Norman
User | Count |
---|---|
83 | |
23 | |
11 | |
9 | |
8 | |
5 | |
5 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.