on 05-31-2016 12:45 PM
Hello experts
We had upgraded the SAP GRC Access control 10.0 system to 10.1 on SP13 (latest SP). Post upgrade we tried to test the MSMP workflows for the ARM request.
There are 3 requests (New, Change & Firefighter) for user provisioning used via ARM. These were working perfectly in 10.0 but the FF fails to assign user for Firefighter assignment request. The audit log shows that the FF id was requested and the next line says that the user was assigned to FF.
There is an approval step that is missing in the Audit log and the user is not assigned in the target system.
We have checked all settings and reactivated MSMP workflow to be sure that this was not related.
However, the assignment does not happen and there are no errors. We fear that the SPM owner agent may not be picked in the function module but this is an assumption. Is there anything at all that can be checked further or is prone to change during upgrade in your experience?
Thanks,
Kashif
Hi All,
I had raised an SAP incident and we implemented a NOTE 2282052 for the issue #1. Issue # 2 is still open.
The note implementation made it work.
NOTE for Issue # 1: Firefighter provision request did not trigger workflow. (The workflows were not getting triggered)
0002282052 Runtime error UC_OBJECTS_NOT_CONVERTIBLE for workflow runtime
Hope this helps while I keep this thread open for issue #2.
Thanks for your time.
Kashif
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Mohammed,
Can you check the following
1.Check if the role type being used in the access request is deactivated in SPRO.
2.Try creating a role in BRM and check if it is available for selection in access request.
3.Check if the required authorizations(GRAC_ROLE*,GRAC_REQ etc)are assigned to your ID. You can run a trace for the missing objects
For testing try assigning SAP_ALL to your ID.
4.Check the parameters 2033 and 2034
5.The system attribute should match with the name as in SM59
6.Run a full repository object sync
Let us know
Regards,
Manju
Hello Kashif,
For your Issue no:2, Check the following steps which are in bold. Might help you out.
Steps to be taken to check the Roles Availability for provisioning
1. Role has to exist in the Backend System
2. Role sync job has to be performed
3. Import roles in to BRM. Note: Role Authorization Source can be skipped if you do not want to maintain authorizations in BRM and just want to use roles for provisioning purposes only.
- Maintain the PRODUCTION status, and in order to do that
Go to IMG => Governance Risk and Compliance => Access control => Role Management => Maintain Role Status
- Make sure to check the PRODUCTION STATUS checkbox for the status (Recommended is PRD, but DEV and TST can be checked as production status based on the testing environment.)
4. Based on PRODUCTION STATUS settings configured in step 3, make sure each role status is set accordingly
- Go to Access Management => Role Management => Role Maintenance
- Search and Open the role , click on Additional Tab and then select Provisioning
- Make sure that the Role Status is set to Production or other status based on the settings performed in steps 3
5. Provisioning Allowed flag should be set to “Yes” for that system
6. Role Validity Period on the system should be current (valid) or should not be maintained
- To change the Validity period or Update it. Select the system, Click on "Set Default Period" button
- Change or update your Validity period
7. Make sure PROV scenario has been maintained for the system
Regards,
Rakesh Ram M
P.S: Since there are two issues, I suggest you to open two discussion threads so that anyone facing similar issue might directly open that specific discussion thread.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Dear Kashif,
did you check authorization (STAUTHTRACE) and logs (ST22, SLG1) whether anything comes up? I have just recently upgraded a client to SP13 who has same requirements and everything works perfectly.
Check your WF-BATCH user as well as others you might have specified. Posting screenshots would also help us to understand what you mean. Please also provide Provisioning Log.
Cheers,
Alessandro
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Alessandro,
Thanks for writing in. Comments on your analysis are below:
1. We have checked the Auth for WF-BATCH which is with SAP_ALL & SAP_NEW. 2. The ST22 logs had a few known dumps on web dynpro which SAP has fixed and are not related to the workflow issue 3. SLG1 logs show no errors when the ARM requests were submitted.
Meanwhile, this is not an SP upgrade to 13. This is a version upgrade from 10.0 SP20 to 10.1 SP13
Post upgrade, I have implemented Process Control without any issues post PC config. But the AC system failed to provision users via ARM which worked perfect on 10.0
I have an SAP Incident which SAP is looking into but prefer to have advice from this forum as well if can be resolved earlier.
Issue detail:
1) A request 1585 was created for assignment of FF ID in ECC system The Workflow for FF id request is pending and not complete. The user provisioning log does not show any access provisioned. The workflow has not progressed as per the Audit log. The workflow should follow the approval stage which is not available. This is Question #1 on why this request did not complete successfully?
2) The ARM request for New / Change Access does not populate any roles for assignment. This is Question #2? We see that the repository sync job has completed in SM37.
The MSMP workflow details attached for your reference: The MSMP workflow was reactivated post upgrade to 10.1 and the ARM request for New / Change does not show any roles and FF ID request does not complete.
Thanks,
Kashif
Hi Mohammed,
Issue 1 - Kindly check if the below Note helps
1736898 - Access Request workflow does not start and no E-Mail notification sent to Approver's Inbox
Issue 2 - Can you check if the roles are available in BRM repository with the below attribute values. The visibility of the roles in access request is controlled with these attributes.
Role exists = YES
Methodology = C(Complete)
Role status = PRD
Provisioning allowed = YES
If you are unable to unable to find the roles in BRM you need to import the roles into GRC using the role attribute file(for mass import) and run the repository object sync after successful import.
Hope this helps
Regards,
Manju
Hi Mohammed,
Issue 1 - Check the logs in transaction GRFNMW_DBGMONITOR_WD ( MSMP Instance Runtime Monitor) it might help.
Also you can enable debug logging for MSMP WF. Check the below Note
1624069 - GRC 10.0 Enabling Debug Logging for MSMP
Issue 2 - For role selection in access request you should have configured the limited functionality of BRM which is importing the roles from backend either directly or using a role attribute file.
When you search for the roles in access request the application will search for the role in BRM repository. Only running a repository object sync without importing the roles will not help as the roles will be available for Risk Analysis and not for selection in access request.
Can you check if the roles are available in BRM with the attribute values as in my previous reply.
If you are not able to find the roles in BRM you need to import the roles to GRC and do a repository object sync.
Let me know if you need any other details.
Regards,
Manju
Hi Manju.
Issue # 1:
I have enabled the debug log for MSMP but was unable to read the log file as the log file does not have a directory when I enabled the log, I thought the log must be in Temp directory (DIR_TEMP) but the file (GRFN_MSMP_RUNTIME_LOG) does not show in it (in tcode AL11). So I am stuck here to read the logs.
Issue # 2:
All attributes for roles are maintained as I see for most of the roles. And I am able to see the roles in Role Search but not in ARM req.
P.S. To remind that the functionality was working fine in 10.0 (SP20) but is not working in 10.1 (SP13) post upgrade in our testing where no changes to configuration were made.
Thanks,
Kashif
User | Count |
---|---|
13 | |
2 | |
2 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.