Disable mitigation control workflow

Hi community,
one pretty simple question: I would like to be disable the mitigation control workflow, meaning, I would like to be able to directly save mitigation controls, without sending this through an approval process. I cannot find the associated activity in the spro. Can you please assist me on this?
The way I saw this some time ago was that, if one disabled the mitigation control workflow, the Save button was visible in the mitigation control maintenance screen. When the workflow was enabled, the Submit button was visible (which, of course, makes sense). Now, I would like to be able to do this change.
I did also look into transaction GRFNMW_CONFIGURE_WD - nothing suspicious here.
Any help is highly appreciated. Thanks in advance!
EM

Hi EM,
Please set 1061 and 1062 to NO as per your requirement for mitigation assignment and mitigation maintenance.
BR,
Mangesh

Similar Messages

Mitigation control workflow for AC10

We are configuring the Mitigation control workflow during the implementation of AC 10.
I would like to know whether its mandatory to have the workflow for Mitigation approver and monitor. As per the implementation team there is no requirement for them as this is not covered during the rampup. But I think this should be mandatory to have the mitigation approval worflow so all the mitigation risk should be approved before mitigating. Otherwise, security admin can mitigate any risk and complete the request.
Please advice.

Hi,
Yes. It will be a manual process. In some of the organizations, risks identification and mitigation will be performed manually by the Business process owners, which means in reality there will not be any risks that pop-up in CUP or RAR since they are already mitigated for the user.
If you don't want to enable the mitigation process in the workflow, you have to do it and record the evidences manually.
Hope this answers.
Regards,
Raghu

Request creation error for mitigation control workflow

Dear Expert,
         I had activiate the workflow from RAR to CUP on Mitigated User assignment, I had completed following customizing:
1)RAR->configaration->Workflow
2)CUP->configaration->initiator, stage, path.
but when I created mitigated user assignments in RAR, after click "Submit", error popup: "Request creation error"
can some one help?
thanks!

Dear,
     the log is below:
ERROR       service 'SAPGW00' unknown
TIME        Thu May 20 13:33:16 2010
RELEASE     701
COMPONENT   NI (network interface)
VERSION     38
RC          -3
MODULE      niuxi.c
LINE        1732
DETAIL      NiPGetServByName2: service 'SAPGW00' not found
SYSTEM CALL getservbyname_r
COUNTER     375
May 20, 2010 1:33:16 PM com.virsa.cc.common.SAPAdapter serverExceptionOccurred
INFO: Exception in Server YYY:
com.sap.mw.jco.JCO$Exception: (129) JCO_ERROR_SERVER_STARTUP: Server startup failed at Thu May 20 13:33:16 CST 2010.
This is caused by either a) erroneous server settings, b) the backend system has been shutdown, c) network problems. Will try next startup in 3600 seconds.
Could not start server: Connect to SAP gateway failed
Connect parameters: TPNAME=YYY GWHOST=visoil01 GWSERV=SAPGW00
ERROR       service 'SAPGW00' unknown
TIME        Thu May 20 13:33:16 2010
RELEASE     701
COMPONENT   NI (network interface)
VERSION     38
RC          -3
MODULE      niuxi.c
LINE        1732
DETAIL      NiPGetServByName2: service 'SAPGW00' not found
SYSTEM CALL getservbyname_r
COUNTER     375
May 20, 2010 1:33:16 PM com.virsa.cc.common.SAPAdapter serverExceptionOccurred
INFO: Exception in Server YYY:
com.sap.mw.jco.JCO$Exception: (129) JCO_ERROR_SERVER_STARTUP: Server startup failed at Thu May 20 13:33:16 CST 2010.
This is caused by either a) erroneous server settings, b) the backend system has been shutdown, c) network problems. Will try next startup in 3600 seconds.
Could not start server: Connect to SAP gateway failed
Connect parameters: TPNAME=YYY GWHOST=visoil01 GWSERV=SAPGW00
ERROR       service 'SAPGW00' unknown
TIME        Thu May 20 13:33:16 2010
RELEASE     701
COMPONENT   NI (network interface)
VERSION     38
RC          -3
MODULE      niuxi.c
LINE        1732
DETAIL      NiPGetServByName2: service 'SAPGW00' not found
SYSTEM CALL getservbyname_r
COUNTER     375
May 20, 2010 1:33:16 PM com.virsa.cc.common.SAPAdapter serverExceptionOccurred
INFO: Exception in Server YYY:
com.sap.mw.jco.JCO$Exception: (129) JCO_ERROR_SERVER_STARTUP: Server startup failed at Thu May 20 13:33:16 CST 2010.
This is caused by either a) erroneous server settings, b) the backend system has been shutdown, c) network problems. Will try next startup in 3600 seconds.
Could not start server: Connect to SAP gateway failed
Connect parameters: TPNAME=YYY GWHOST=visoil01 GWSERV=SAPGW00
ERROR       service 'SAPGW00' unknown
TIME        Thu May 20 13:33:16 2010
RELEASE     701
COMPONENT   NI (network interface)
VERSION     38
RC          -3
MODULE      niuxi.c
LINE        1732
DETAIL      NiPGetServByName2: service 'SAPGW00' not found
SYSTEM CALL getservbyname_r
COUNTER     375
May 20, 2010 1:33:16 PM com.virsa.cc.common.SAPAdapter serverExceptionOccurred
INFO: Exception in Server YYY:
com.sap.mw.jco.JCO$Exception: (129) JCO_ERROR_SERVER_STARTUP: Server startup failed at Thu May 20 13:33:16 CST 2010.
This is caused by either a) erroneous server settings, b) the backend system has been shutdown, c) network problems. Will try next startup in 3600 seconds.
Could not start server: Connect to SAP gateway failed
Connect parameters: TPNAME=YYY GWHOST=visoil01 GWSERV=SAPGW00
ERROR       service 'SAPGW00' unknown
TIME        Thu May 20 13:33:16 2010
RELEASE     701
COMPONENT   NI (network interface)
VERSION     38
RC          -3
MODULE      niuxi.c
LINE        1732
DETAIL      NiPGetServByName2: service 'SAPGW00' not found
SYSTEM CALL getservbyname_r
COUNTER     375
May 20, 2010 1:33:16 PM com.virsa.cc.common.SAPAdapter serverExceptionOccurred
INFO: Exception in Server YYY:
com.sap.mw.jco.JCO$Exception: (129) JCO_ERROR_SERVER_STARTUP: Server startup failed at Thu May 20 13:33:16 CST 2010.
This is caused by either a) erroneous server settings, b) the backend system has been shutdown, c) network problems. Will try next startup in 3600 seconds.
Could not start server: Connect to SAP gateway failed
Connect parameters: TPNAME=YYY GWHOST=visoil01 GWSERV=SAPGW00
ERROR       service 'SAPGW00' unknown
TIME        Thu May 20 13:33:16 2010
RELEASE     701
COMPONENT   NI (network interface)
VERSION     38
RC          -3
MODULE      niuxi.c
LINE        1732
DETAIL      NiPGetServByName2: service 'SAPGW00' not found
SYSTEM CALL getservbyname_r
COUNTER     375
May 20, 2010 1:33:16 PM com.virsa.cc.common.SAPAdapter serverExceptionOccurred
INFO: Exception in Server YYY:
com.sap.mw.jco.JCO$Exception: (129) JCO_ERROR_SERVER_STARTUP: Server startup failed at Thu May 20 13:33:16 CST 2010.
This is caused by either a) erroneous server settings, b) the backend system has been shutdown, c) network problems. Will try next startup in 3600 seconds.
Could not start server: Connect to SAP gateway failed
Connect parameters: TPNAME=YYY GWHOST=visoil01 GWSERV=SAPGW00
ERROR       service 'SAPGW00' unknown
TIME        Thu May 20 13:33:16 2010
RELEASE     701
COMPONENT   NI (network interface)
VERSION     38
RC          -3
MODULE      niuxi.c
LINE        1732
DETAIL      NiPGetServByName2: service 'SAPGW00' not found
SYSTEM CALL getservbyname_r
COUNTER     375
May 20, 2010 1:33:16 PM com.virsa.cc.common.SAPAdapter serverExceptionOccurred
INFO: Exception in Server YYY:
com.sap.mw.jco.JCO$Exception: (129) JCO_ERROR_SERVER_STARTUP: Server startup failed at Thu May 20 13:33:16 CST 2010.
This is caused by either a) erroneous server settings, b) the backend system has been shutdown, c) network problems. Will try next startup in 3600 seconds.
Could not start server: Connect to SAP gateway failed
Connect parameters: TPNAME=YYY GWHOST=visoil01 GWSERV=SAPGW00
ERROR       service 'SAPGW00' unknown
TIME        Thu May 20 13:33:16 2010
RELEASE     701
COMPONENT   NI (network interface)
VERSION     38
RC          -3
MODULE      niuxi.c
LINE        1732
DETAIL      NiPGetServByName2: service 'SAPGW00' not found
SYSTEM CALL getservbyname_r
COUNTER     375
May 20, 2010 1:33:16 PM com.virsa.cc.common.SAPAdapter serverExceptionOccurred
INFO: Exception in Server YYY:
com.sap.mw.jco.JCO$Exception: (129) JCO_ERROR_SERVER_STARTUP: Server startup failed at Thu May 20 13:33:16 CST 2010.
This is caused by either a) erroneous server settings, b) the backend system has been shutdown, c) network problems. Will try next startup in 3600 seconds.
Could not start server: Connect to SAP gateway failed
Connect parameters: TPNAME=YYY GWHOST=visoil01 GWSERV=SAPGW00
ERROR       service 'SAPGW00' unknown
TIME        Thu May 20 13:33:16 2010
RELEASE     701
COMPONENT   NI (network interface)
VERSION     38
RC          -3
MODULE      niuxi.c
LINE        1732
DETAIL      NiPGetServByName2: service 'SAPGW00' not found
SYSTEM CALL getservbyname_r
COUNTER     375
May 20, 2010 1:33:16 PM com.virsa.cc.common.SAPAdapter serverExceptionOccurred
INFO: Exception in Server YYY:
com.sap.mw.jco.JCO$Exception: (129) JCO_ERROR_SERVER_STARTUP: Server startup failed at Thu May 20 13:33:16 CST 2010.
This is caused by either a) erroneous server settings, b) the backend system has been shutdown, c) network problems. Will try next startup in 3600 seconds.
Could not start server: Connect to SAP gateway failed
Connect parameters: TPNAME=YYY GWHOST=visoil01 GWSERV=SAPGW00
ERROR       service 'SAPGW00' unknown
TIME        Thu May 20 13:33:16 2010
RELEASE     701
COMPONENT   NI (network interface)
VERSION     38
RC          -3
MODULE      niuxi.c
LINE        1732
DETAIL      NiPGetServByName2: service 'SAPGW00' not found
SYSTEM CALL getservbyname_r
COUNTER     375
May 20, 2010 2:10:50 PM com.virsa.cc.workflow.bo.WorkflowBO submit
INFO: END POOINT URL: http://9.186.143.129:50100/AEWFRequestSubmissionService_5_2/Config1?style=document
May 20, 2010 2:10:50 PM com.virsa.cc.workflow.bo.WorkflowBO submit
INFO: before submit:
May 20, 2010 2:10:50 PM com.virsa.cc.workflow.bo.WorkflowBO submit
INFO: wftype: MITIOBJ reqid: GRC01
May 20, 2010 2:10:50 PM com.virsa.cc.rulearchitect.dao.dto.MitObjDTO getObjContext
FINEST: validfrom: 2010-05-20 validto: 2011-05-20
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Data Type: String
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Descripton: MITREFNO
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Name: MOMITREFNO
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Value: CT01
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Data Type: String
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Descripton: RISKID
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Name: MORISKID
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Value: ZC02
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Data Type: String
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Descripton: LANG
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Name: LANG
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Value: EN
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Data Type: String
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Descripton: MONITORID
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Name: MONITORID
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Value: GRC01
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Data Type: Integer
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Descripton: STATUS
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Name: MOSTATUS
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Value: 0
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Data Type: DATE
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Descripton: VALIDFROM
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Name: VALIDFROM
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Value: 05/20/2010
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Data Type: DATE
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Descripton: VALIDTO
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Name: VALIDTO
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Value: 05/20/2011
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Data Type: String
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Descripton: BU ID
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Name: BUID
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Value: null
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Data Type: String
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Descripton: Approver ID
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Name: MOAPPROVERID
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Value: null
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Data Type: String
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Descripton: OBJTYPE
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Name: OBJTYPE
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Value: U
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Data Type: String
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Descripton: OBJID
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Name: OBJID
May 20, 2010 2:10:50 PM com.virsa.cc.xsys.aewf.SubmitAEWorkflow setProcessContext
INFO: Value: 207471
May 20, 2010 2:10:50 PM com.virsa.cc.workflow.bo.WorkflowBO submit
INFO: Return code: 2010 Message: com.virsa.ae.core.ObjectNotFoundException: Invalid Priority Value : MO_HIGH workflow id: null Status: null
May 20, 2010 2:10:50 PM com.virsa.cc.workflow.bo.WorkflowBO submit
WARNING: 2010: null

CUP - Mitigation Controls in a Detour Workflow

Hello everybody,
I have a problem with a detour workflow in CUP.
I choose the detour condition: "SoD violation".
So in theory, if there is no conflicts the workflow don't take the detour path.
We supposed that the user request has an SoD conflict.
In the stage(s) before the detour, if we assign a mitigation control that mitigate the risk, the detour is still taken.
I think the workflow swich systematically to the detour if the request had a conflict, even if the risks were deleted by an Mitigation Controls assignment.
Does anyone have a solution to avoid the detour path if we mitigate the risks?
Thank you in advance!!

Ben,
This is how CUP works. There is no configuration which allows you to ignore SOD violaton even if there is mitigation. You will have to live with this for now.
Regards,
Alpesh

GRC AC V10 - Mitigation Control Approval Workflow

Hi guys,
can me explain somebody the difference between the processID SAP_GRAC_CONTROL_ASGN und SAP_GRAC_CONTROL_MAINT?
And as well can somebody provide me the initiator rule ID for both so that we can have a detailed look into the brfplus rule.
We only want to mitigate controls via an controlowner approval and not a process for the creation of new controls.
That means an asisgnment approval workflow for mitigation controls.
Thanks a lot.

Hello Alexa,
Did you ever employ SAP_GRAC_CONTROL_ASGN ? Were you able to identify the included agents ?
I am interested in identifying approvers for mitigating controls who can be included in the workflow but are not risk owners. Would you have any suggestions for this type of agent ?
Any information would be appreciated.
Thanks,
Jamie

Detect obsolete mitigating control assignments?

Hello,
What report/s would you use to detect obsolete mitigating control assignments?
The scenario is: A user has been assigned a mitigating control, let's say during the CUP workflow, to mitigate a certain risk that came with a certain role. Later, that role is removed from the user. Now the user is in the scope of a mitigating control. However, the user is not even subject to the risk in question anymore.
Which way (periodically?) could you detect these cases and clean up the mitigating control assignments?
Thanks and regards
Patrick

Hey,
My experience of cleaning up controls has not been very straight forward.
I have had to perform various risk analysis reports and look up a list of user accounts that have been marked as "Expired" etc.
It can be slightly more difficult if, like many organisations, you decide to assign a control with a infinite validity period (i.e. 12.12.9999).
The Business and Internal Control team need to be very proactive about regularly monitoring the controls and reviewing the assignments. This is one reason why I strongly recommend that controls are only assigned for a set period (i.e. 365 days/1 year), so a compulsory review takes place by the control owners/business on a regular basis. This makes the controls much more affective, robust and fit for purpose.
Happy to hear other's opinions and ideas.

Error when trying to approve a mitigation control in CUP

Hi,
I have created a Mitigation Control in RAR and set-up the necessary workflow. The request ends up in CUP and the approver is able to see the request when he/she logs in, however the approver cannot approve or reject the request.
The following error messages appear:
- Approve: Error processing your request, Request no: 2 in stage : MITIGATION
- Reject: Error rejecting request no: 2
I have check the workflow many times now and I have also checked the mitigation URL's.
Any idea what the problem can be?
Thanks.

Thank you for your response. No the approver is not part of the DL. I just added the approver to the workflow (CAD).
Please find log details below:
2010-03-18 16:09:32,729 [SAPEngine_Application_Thread[impl:3]_8] ERROR Service call exception; nested exception is:
     com.sap.engine.services.webservices.jaxrpc.exceptions.InvalidResponseCodeException: Invalid Response Code: (401) Unauthorized. The requested URL was:"http://vgrdci.sap.client.co.za:51900/VirsaCCWFExitService5_2Service/Config1?style=document"
java.rmi.RemoteException: Service call exception; nested exception is:
     com.sap.engine.services.webservices.jaxrpc.exceptions.InvalidResponseCodeException: Invalid Response Code: (401) Unauthorized. The requested URL was:"http://vgrdci.sap.client.co.za:51900/VirsaCCWFExitService5_2Service/Config1?style=document"
     at com.virsa.ae.request.ws.cc.Config1BindingStub.execWFExitService(Config1BindingStub.java:87)
     at com.virsa.ae.request.ws.cc.Config1BindingStub.execWFExitService(Config1BindingStub.java:96)
     at com.virsa.ae.accessrequests.bo.RequestExitServiceHelper.callCCExitService(RequestExitServiceHelper.java:263)
     at com.virsa.ae.accessrequests.bo.RequestExitServiceHelper.callExitServiceForApprovedRequest(RequestExitServiceHelper.java:51)
     at com.virsa.ae.accessrequests.bo.RequestBO.callExitService(RequestBO.java:5335)
     at com.virsa.ae.accessrequests.bo.RequestBO.approveRequest(RequestBO.java:5174)
     at com.virsa.ae.accessrequests.bo.RequestBO.approveRequest(RequestBO.java:4967)
     at com.virsa.ae.accessrequests.actions.RequestViewAction.confirmRequestApproval(RequestViewAction.java:928)
     at com.virsa.ae.accessrequests.actions.RequestViewAction.execute(RequestViewAction.java:103)
     at com.virsa.ae.commons.utils.framework.NavigationEngine.execute(NavigationEngine.java:271)
     at com.virsa.ae.commons.utils.framework.servlet.AEFrameworkServlet.service(AEFrameworkServlet.java:425)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
     at com.sap.engine.services.servlets_jsp.server.runtime.RequestDispatcherImpl.doWork(RequestDispatcherImpl.java:321)
     at com.sap.engine.services.servlets_jsp.server.runtime.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:377)
     at com.virsa.ae.commons.utils.framework.servlet.AEFrameworkServlet.service(AEFrameworkServlet.java:455)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
     at com.sap.engine.services.servlets_jsp.server.runtime.RequestDispatcherImpl.doWork(RequestDispatcherImpl.java:321)
     at com.sap.engine.services.servlets_jsp.server.runtime.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:377)
     at com.virsa.ae.commons.utils.framework.servlet.AEFrameworkServlet.service(AEFrameworkServlet.java:455)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
     at com.sap.engine.services.servlets_jsp.server.HttpHandlerImpl.runServlet(HttpHandlerImpl.java:401)
     at com.sap.engine.services.servlets_jsp.server.HttpHandlerImpl.handleRequest(HttpHandlerImpl.java:266)
     at com.sap.engine.services.httpserver.server.RequestAnalizer.startServlet(RequestAnalizer.java:386)
     at com.sap.engine.services.httpserver.server.RequestAnalizer.startServlet(RequestAnalizer.java:364)
     at com.sap.engine.services.httpserver.server.RequestAnalizer.invokeWebContainer(RequestAnalizer.java:1039)
     at com.sap.engine.services.httpserver.server.RequestAnalizer.handle(RequestAnalizer.java:265)
     at com.sap.engine.services.httpserver.server.Client.handle(Client.java:95)
     at com.sap.engine.services.httpserver.server.Processor.request(Processor.java:175)
     at com.sap.engine.core.service630.context.cluster.session.ApplicationSessionMessageListener.process(ApplicationSessionMessageListener.java:33)
     at com.sap.engine.core.cluster.impl6.session.MessageRunner.run(MessageRunner.java:41)
     at com.sap.engine.core.thread.impl3.ActionObject.run(ActionObject.java:37)
     at java.security.AccessController.doPrivileged(AccessController.java:219)
     at com.sap.engine.core.thread.impl3.SingleThread.execute(SingleThread.java:104)
     at com.sap.engine.core.thread.impl3.SingleThread.run(SingleThread.java:176)
Caused by:
com.sap.engine.services.webservices.jaxrpc.exceptions.InvalidResponseCodeException: Invalid Response Code: (401) Unauthorized. The requested URL was:"http://vgrdci.sap.client.co.za:51900/VirsaCCWFExitService5_2Service/Config1?style=document"
     at com.sap.engine.services.webservices.jaxrpc.wsdl2java.soapbinding.MimeHttpBinding.handleResponseMessage(MimeHttpBinding.java:998)
     at com.sap.engine.services.webservices.jaxrpc.wsdl2java.soapbinding.MimeHttpBinding.call(MimeHttpBinding.java:1449)
     at com.virsa.ae.request.ws.cc.Config1BindingStub.execWFExitService(Config1BindingStub.java:80)
     ... 33 more

Mitigated risks workflow for SoD detour approval

Hi All,
Please assist. I have configured a workflow for requests as follows:
Super user submits request - Workflow to Business Analyst (if there are violations they can assign an existing mitigation control) - Auto Provision
If no existing control is available - Detour to SoD officer (to compile a new control with Business Analyst) - workflow to GRC administrator to capture new control on the system - Auto provision
The problem that I have now is with the first part of the workflow wherein there are violations and there is a control in place that can be applied to mitigate the risk. If mitigate the risks associated with the request, the worflow still goes to SoD officer in spite of all risks mitigated.
Is there a way I can set this to enforce the assigned controls? Checking from RAR, the user is only linked to the control upon closing the request.
I have set Risk Analysis defaults on CUP to "Consider Mitigation Controls"
GRC 5.3 SP13
Any help will be appreciated.
Thanks,

Hi Sabrina,
For Access Request workflow, we generally use GRAC_MSMP_DETOUR_SODVIOL to implement routing rule(based on detour condition - risk found). Purpose of same (if I am not mistaken) is to through the request to another level of approver wherein mitigation monitor agent reviews the mitigation performed by role owner stage and approve/reject the request.
But, when we create a role same is not the condition as we do not mitigate role level risk thus no need to go for mitigation monitor stage. May be you have some business scenario, if you can let us know will be gr8.
For the rule ID, did you try adding the rule ID ?(you may already know, still would like to cross check with you).
GRAC_MSMP_DETOUR_SODVIOL under list of rules for "
Role Approval Workflow" In the screenshot you have shown, just click on ADD feed -
Rule ID -GRAC_MSMP_DETOUR_SODVIOL.
Rule description - same as Access request.
Rule type - Function module based
rule kind - routing rule.
Add this and check if it works and let us know the result too.
Regards,
Nishant

GRC CUP 5.3 SP16.3 Mitigation Controls automation removal

Does anyone know that if you create any user requests to remove roles from a user, that if any mitigation controls were assigned to the users for those roles, the mitigating control ids can also be automatically removed from RAR during auto provisioning of the request?
Right now, GRC CUP, if configured properly, during auto provisioning, will assign the mitigation controls automatically to the userid in RAR to mitigate the risks when the request is processed if the new access will give any SOD violations. But if you remove the roles from a user and he/she had any mitigation ids assigned in RAR, can the request also automatically remove the mitigated control id associated with it if the user will no longer have that risk? I have not seen the request automatically remove the mitigated id from RAR when the role was removed from the user id during auto provisioning. But I'm not sure if this requires additional workflow configuration or not.
Will greatly appreciate if any1 is aware of this issue and how to resolve it. Or is the only solution to manually remove it from RAR..but this can be tiresome..bc then you have to run the report every week or month in RAR to remove the excessive controls assigned if the users do not have the risks anymore..comparing reports from current to previous month, etc.
Thanks,
A.

Hi Alley,
It is not possible to automate the removal of mitigation controls through a workflow in CUP. The only solution is to review on a regular basis and remove them manually from RAR
We also has the same issue and performing manual review at regular intervals of the user & role assigned mitigation controls
Best Regards,
Srihari.K

Delete mitigation control

Hello
I am testing our access request workflows and applied a try to delete mitigation control.
The workflow is work fine, but the mitigation control still exist.
The same problem when i try to delete a mitigation user, the workflow work fine and the mitigation user still exist.
Mi GRC is SP 13.
Regards-

Hi,
Perform the tasks listed in:
1.Run transaction SM30
2. Display the view GRFNPARENT in change mode
3. Add new line
4. Entity = SUBPROCESS
5. Parent = ORGUNIT
Still the problem persists.
Regards.

MSMP Access request and mitigation assignment workflows

Hi Guys,
Need help in understanding access request workflow. Here is the flow:
Requester submitted access request.
1. Manager stage (010)
2. Role owner (020) - at this stage routing enabled for DETOUR_SODVIOL with standard rule ID by creating detour path with new stage (021).
3. Security Lead (030).
Instead of going to SoD stage (021) request is diverted to MIT_ASSIGNMENT workflow for applying mitigation control with a new number generated.
I am confused with system behavior, Please suggest.
Thanks all for your time.
Thanks & regards
Harry

Hello,
Based on your requirement you need 2 PATH .
PATH A : where you have 3 stages
Manager
Roleowner
Security Lead
and PATHB 2 stages if security Lead is required after SOD Stage.
1)SOD stage
2)Security Lad
Requester submitted access request. nThis is Go in PATHA
1. Manager stage (010): Manager Appoves then goes to Next stage
2. Role owner (020) - at this stage routing enabled for DETOUR_SODVIOL with standard rule ID by creating detour path with new stage (021).: After Role owner approves with check for condition and route mapping based on rule result value
3. Security Lead (030).
Instead of going to SoD stage (021) request is diverted to MIT_ASSIGNMENT workflow for applying mitigation control with a new number generated.
Ensure MITIGATION workflow in not active in Configuration parameter.
Good Luck
Prasant

Mitigating Control Management Approver

Hello,
What is the significance of the Management Approver when creating a Mitigating Control? I do not see any approval process in GRC . Does this relate to setting up workflow?
thanks
Tammi

Hi Tammi,
Do you have any process documentation on mitigating controls? I don't need to know how to create them in GRC - I've got that covered. However from a non technical audit perspective, there's a process around creating a control, prior to having to set it up in the system. Do you have anything in that area?
If you do and you don't mind sharing, I would most appreciate it.
Thanks,
Santosh

Issue in Process Controlled workflow for Shopping cart in Quality system.

Hello All,
I ahve configured a Process controlled workflow in SRM 7.0 with custom resolver, and I am facing an issue taht the Workflow works well in Development but in Quality the approvers are dropped after SC is ordered in Quality system.
The SC Workflow drops the approvers picked up from the Interface method /SAPSRM/IF_EX_WF_RESP_RESOLVERGET_AREA_TO_ITEM_MAP and IF_EX_WF_RESP_RESOLVERGET_APPROVERS_BY_AREA_GUID of BADI /SAPSRM/BD_WF_RESP_RESOLVER. The approvers can be seen in the shopping cart Approval preview Tab until the SC is ordered.
I have compared the OSS notes relevant for Workflow, all of them have been transported, Also I compared and checked general Workflow settings, BRF Config and Process level settings in Dev and Quality, everything is same.
Also while debugging; the approvers can be seen in the decision set table in the create_process_forecast method of class /SAPSRM/CL_WF_PROCESS_MANAGER.
Kindly let me know what else i can check to find the root cause.
Thank you in advance for help!
Regards
Prasuna.

Hello Vinita;
Thanks for the input and sorry for the not so "ASAP" reply;
From what I'm seeing in from your 2 screenshot, i strongly believe that the problem is even before the Z implementation /SAPSRM/IF_EX_WF_RESP_RESOLVER~GET_APPROVERS_BY_AREA_GUID (in which the FM i ZSRM_GET_USER_FROM_PGRP is called. I think the problem could be in the process level determination ZSRM_WF_BRF_0EXP000_SC_APP100. Let me explain:
In your cases where not buyer is determined, in the approval tab there is not even a process level for buyer approval. If the problem were indeed in the implementation /SAPSRM/IF_EX_WF_RESP_RESOLVER~GET_APPROVERS_BY_AREA_GUID then the process level would be there, but the system will display, instead of the name of the buyer(if the buyer determination fails) a red label with the message: "With the strategy "Buyer determination" an approver could not be determined (or something like that..please check the image at the end of the text)".
I can propose a way to discard this: Implement the method /SAPSRM/IF_EX_WF_RESP_RESOLVER~GET_FALLBACK_AGENTS of class ZCL_BADI_SC_WC (in case you didn't know, in this method you can specify an "default" approver in case that the determination of approver in GET_APPROVERS_BY_AREA_GUID fails). The idea is to specify an default approval and see how it behaves:
If the user you indicated in the method GET_FALLBACK_AGENTS appears as approver, then yes, the problem is arises from implementation GET_APPROVERS_BY_AREA_GUID, in which case it could be a data problem (peharps in pposa_bbp?). You could also check in TX SU53 with the users with this problem to see if there's a missing authorization objetc.
If, in the other hand, the "default" approver is not shown, it means that the process level buyer determination is not even called, so you should check in more detail ZSRM_WF_BRF_0EXP000_SC_APP100 and /SAPSRM/CL_WF_PROCESS_MANAGER > Determine process restart –method ----- (i have never used this method, so i could not tell if it could be the source of the problem).
Also, you could implement the method GET_FALLBACK_AGENTS in this way so the default approver would be the WF administrator indicated in the customizing (or you could just append directly any user you want):
METHOD /SAPSRM/IF_EX_WF_RESP_RESOLVER~GET_FALLBACK_AGENTS.
   DATA: lv_admin_expr TYPE swd_shead-admin_expr,
         lv_admin      TYPE swd_shead-wfi_admin,
         lv_admin_type TYPE sy-input,
         ls_agent      TYPE /sapsrm/s_wf_approver.
   CALL FUNCTION 'SWD_WF_DEFINITION_ADMIN_GET'
     IMPORTING
       default_admin_expr = lv_admin_expr
       default_admin      = lv_admin
       default_admin_type = lv_admin_type.
   ls_agent-approver_id = lv_admin.
   APPEND ls_agent TO rt_agent.
ENDMETHOD.
Error of agent determination:
Please let me know the result of the test with the implementation of method GET_FALLBACK_AGENT. By doing this we could ensure if really the problem is in method GET_APPROVERS_BY_AREA_GUID or before. I just made the test in our system and I'm almost sure that you wont get the default approver, but i could be wrong.
Any question please let me know.
Best regards
Cristian R.

How do you disable voice control on iphone 4

Voice Control doesnt seem to work to create a text message on iphone 4 like it does on the 4S. How do I disable Voice Control all together on a 4?

capsjenwalker wrote:
How do I disable Voice Control all together on a 4?
Sorry, you can't. There is no setting to completely disable such.

Disable remote control IR receiver is not showing up in system pref.

My remote for my iMac is not working. I originally thought it neeeded a new battery but that was not it. I had a power outage the other night and since then have been noticing the problem.
The apple support says;
'To turn on IR reception:
Open System Preferences and click Security.
Deselect "Disable remote control infrared receiver.'
When I go to system preferences and then security, the option to 'disable remote control infrared receiver' does not show up.
Yesterday I restarted and the option came back, this morning after turning my computer on it wasn't there again. Any idea how to resolve this problem for good?
Thank you
Dan

The next time you notice the line gone from the System Preferences, open up your System Profiler (from the /Applications/Utillities/ folder) and check to see if the "IR Receiver" is listed under the USB section in Hardware.
If it doesn't appear there, then perhaps you're having some kind of failure of your receiver? If it does appear there, then it would seem more likely that you're having some kind of preference file or setting problem.
-Doug

Disable mitigation control workflow

Similar Messages

Maybe you are looking for