Risk Analysis Mandatory while rejecting a request

Hi experts,
We are using GRC 5.30 CUP SP 8
I have made risk analysis mandatory in the final stage. This is to prompt the risk analysis message when the user is trying to approve the request without running risk analysis to check for SOD conflicts.
However, the system promptsfor risk analysis even when I am rejecting the request. How can this be avoided?
It is causing the request to be on an endless loop and I am unable to reject the request unless the risk analysis settting is turned off in this stage..
Is this a bug in 5.3 or has anyone got this issue so far?
Appreciate your response..
Thanks
Siri

Hi Siri,
As Alpesh has said this is fixed in SP10. Prior to that, the risk analysis is either on or off regardless of the decision being made at the approval stage.
Simon

Similar Messages

Batch risk analysis job while database is down

Hello,
Can I run RAR batch risk analysis job while MaxDB database is down in GRC AC 5.3. Our AS Java database is MaxDB.
Please note that when the MaxDB database crashed, while the batch risk analysis job was running and then it completed successfully, while the database was still down.
My query is that does batch risk analysis job, not require AS JAVA database to be up & running?
Thanks

Hi Alpesh/ Frank,
I did check the Background Job Spool file location and Alert Log file location configured in RAR - Misc, I found those directories to be empty.
Actuallay the configuration has been set to Java Logger.
Then I checked the background job log from RAR and found out the following information, seen below. (The log file is very long, I have given few lines of it below).
INFO: Case4: UPDATE VIRSA_CC_SCHEDULER query got executed
Apr 21, 2010 2:59:40 PM com.virsa.cc.common.util.ConfigUtil setDefaultJ2EEParam
WARNING: absWebResourceURL:http://ip_address:50000/
Apr 21, 2010 2:59:40 PM com.virsa.cc.xsys.bg.AnalysisDaemonThread run
FINEST: Analysis Daemon Thread: Invoking (HTTP): http://ip_address:50000/webdynpro/dispatcher/sap.com/grc~ccappcomp/BgJobStart?daemonId=
[9024350]E:\usr\sap\CME\JC00\j2ee\cluster\server0\.&threadId=0&daemonType=BG
INFO: -
Scheduling Job =>20----
Apr 21, 2010 2:59:51 PM com.virsa.cc.common.util.ExceptionUtil logError
SEVERE: null
java.lang.NullPointerException
     at com.virsa.cc.comp.wdp.IPublicBackendAccessInterface$IUserListInputElement.wdGetObject(IPublicBackendAccessInterface.java)
     at com.sap.tc.webdynpro.progmodel.context.NodeElement.getAttributeAsText(NodeElement.java:888)
Apr 21, 2010 5:17:08 PM com.virsa.cc.common.util.ExceptionUtil logError
SEVERE: null
java.lang.NullPointerException
     at com.virsa.cc.comp.wdp.IPublicBackendAccessInterface$IAuthForUserInputElement.wdGetObject(IPublicBackendAccessInterface.java)
Apr 21, 2010 5:17:08 PM com.virsa.cc.xsys.meng.ObjAuthMatcher <init>
FINEST: ObjAuthMatcher constructed: 0ms, #singles=14, #ranges=0, #super=0
END----
The last line ends with FINEST: ObjAuthMatcher constructed: 0ms, #singles=14, #ranges=0, #super=0.
When I checked the status of the Background job, the Batch risk analysis job broken into multiple jobs using User ID Ranges was completed.
1- My query is from the above log file, is there anything wrong?
2- If there is something wrong, then why is the status of Background job shown as completed (at a time when MaxDB database was down due to memory issues)?
Thanks,
Haleem

ARQ: A requester is able to perform risk analysis even after submitting a request???

Hi,
A requester is able to perform risk analysis even after submitting a request. May I know how I can restrict this?
Regards,
Faisal

Hi Faisal,
you can restrict by removing authorization. Basically authorization object GRAC_RA with ACTVT 16 (Execute) is used to execute the risk analysis.
Hope this helps.
Regards,
Alessandro

Risk Analysis mandatory before approvation?

Referring to this discussion: How to switch on mandatory risk analysis in Business Role Management?
I'd like to propose another scenario.
Now Risk Analysis is before profile generation and it is correct in this way.
But also Risk Analysis must be mandatory in that step (before approvation) and NOT ONLY during profile generation.
Is it possible to setup a "specific" configuration in this way?
Thanks.
Ettore

Hi Ettore,
you need to Create deterrent Methodology.in Access Control > Role Management> Define Methodology Process and Steps >
Example Methodology 1 for only steps sequence 1,3,4,5 (With Risk Analysis) and
other Methodology 2 for only steps 1,2,3,5 (Without Risk Analysis)
Now Assign those Methodology in Access Control > Role Management> Associate Methodology Process to condition Group.
Now call those condition group name from BRF+ decision table.
Thanks, Arif

ARQ: What level of risk analysis is performed in Access Request???

Hi,
I have a question/doubt which might look silly!
When we perform risk analysis in access request in "Risk Violation" Tab. May I know if I am correct in saying that this is "USER LEVEL" risk analysis?
Secondly, note#1638140 says:
Resolution
The Impact Analysis type in Access Request risk analysis simulation is suppose to evaluate the HR org or position changes, which might have an impact on other users that are in the same org or assigned to the same positions. The Risk Analysis type is showing existing risks plus the risks if the new access in the request is added to the users or roles.
I am a bit confused with this statement. It says "if the new access in the request is added to the users or roles".
Can anybody please help me understand this?
Thirdly, if a request shows existing risks plus new risks if the new access (only 1 single role) in the request is added to a user, does such request qualify for "Violation Detour" and changes its path for the new role added?
Please advise.
Regards,
Faisal

Faisal,
not really sure if I understand your doubts correctly.
The risk analysis in simulation analyzes all the current and to-be-added authorization. Better to explain in an example.
User has ROLE_A and ROLE_B and in simulation you add ROLE_C. ROLE_A contains FB60, ROLE_B MM03 and ROLE_C FK02. Per definition from rule set a violations is between FK02 and FB60. MM03, as it is only display, isn't a risk.
So the user has with the current authorization (MM03, FB60) no risk. In simulation you add FK02 which conflicts with FB60 and the simulation will show a violation. In the simulation you can differenciate risks based on their color if it comes from existing or newly added authorization.
In simulation it is possible to simulate different scenarios like adding tcodes, roles or profiles. Be aware that if you run the simulation if always analyzes the full authorization (current and simulated).
Does this answer your question?
Regards,
Alessandro

Risk Analysis not performed when using IDM WS

Hi ,
We are using the SAP delivered IDM WebService for submitting Access requests to CUP 5.3 SP8 Patch1.
We have defined the properties:
1. Perform Risk Analysis on Request Submission - YES
2. Risk Analysis Mandatory (approval stage) - YES, When Access Changed
3. Approve Request Despite Risks - NO
(This setting will enable the approver to approve the access request without performing a Risk Analysis, if the initial risk analysis doesn't identify any risk with the access request. But if there are risks, the approver need to mitigate the same before he can approve it.)
But we have found out that when submitting a request through the SAP Delivered IDM WS -'SAPGRC_AC_IDM_SUBMITREQUEST', the system DOESN'T perform RA during request submission. But when the request is submitted directly in CUP, it does.
We've referred the Note:1168508 where it's mentioned that this issue is being fixed with SP7 Patch 1. But we are already on SP8.
The Note says:
"The following issues are resolved as part of Support Package 7 Patch 1:"
and the last bullet point states that:
"While submitting a CUP Request from web service, if the flag for Risk Analysis on submission is set not performing the Risk Analysis on submission."
This feature was not working before and hence thought SAP has fixed it as mentioned in the Note. Has anybody suceeeded in getting this feature working???
Thanks & Regards,
Anil

Yes Dries, we have tried both and we happen to see some exceptions on request submission thru WS.
But the request is still getting created. I've an open tkt with SAP to follow it up..I'll update once i get this fixed.
Exception Details:
Exception during EJB call, Ignoring and trying Webservice Call  [EXCEPTION] com.virsa.ae.service.ServiceException: Exception in getting the results from the EJB service : com/virsa/cc/xsys/ejb/RiskAnalysis.execRiskAnalysis(Lcom/virsa/cc/xsys/webservices/dto/WSRAInputParamDTO;)Lcom/virsa/cc/xsys/w...
Full Message Text
Exception during EJB call, Ignoring and trying Webservice Call
com.virsa.ae.service.ServiceException: Exception in getting the results from the EJB service : com/virsa/cc/xsys/ejb/RiskAnalysis.execRiskAnalysis(Lcom/virsa/cc/xsys/webservices/dto/WSRAInputParamDTO;)Lcom/virsa/cc/xsys/webservices/dto/RAResultDTO;
at com.virsa.ae.service.sap.RiskAnalysisEJB53DAO.getViolations(RiskAnalysisEJB53DAO.java:294)
at com.virsa.ae.service.sap.RiskAnalysisEJB53DAO.getViolations(RiskAnalysisEJB53DAO.java:418)....
at com.sap.engine.core.thread.impl3.SingleThread.run(SingleThread.java:176)
Caused by: java.lang.VerifyError: com/virsa/cc/xsys/ejb/RiskAnalysis.execRiskAnalysis(Lcom/virsa/cc/xsys/webservices/dto/WSRAInputParamDTO;)Lcom/virsa/cc/xsys/webservices/dto/RAResultDTO;
at com.virsa.ae.service.sap.RiskAnalysisEJB53DAO.execRiskAnalysis(RiskAnalysisEJB53DAO.java:304)
at com.virsa.ae.service.sap.RiskAnalysisEJB53DAO.getViolations(RiskAnalysisEJB53DAO.java:276)
... 44 more
Thx,
Anil

AC10 - Auto risk analysis and auto mitigation

Hi,
I was wondering if it is possible to
- run an automatic risk analysis at the end of an approval stage of the workflow, the same way it is possible to configure at the time of request sending?
- automatically put a mitigating control in the request for the risks found?
In our case, there is only one mitigating control for each risk and the assignment of the control is an unnecessary manual task to perform. The mitigation assignment will be approved in a seperate WF by the mitigation owner.
It seems there is no out of the box solution to this, so any alternative suggestions are welcome.
Thanks,
Daniela

Hi Daniela,
If I may give my opinion, I would probably break your question down into 2 parts.
1) Auto Risk analysis at the end of a stage - Making "Risk Analysis Mandatory" at that stage is probably the method. Unfortunately this does mean clicking one or two buttons (so not fully automated). Think AC uses this method to ensure the reviewer is aware of the conflicts caused etc.
2) Auto Mitigation - For a business access workflow in a 'Live' situation, this is probably not a good idea, as analysing and making the decision on whether to proceed with the request should really be performed by an actual person responsible for that stage in the work flow e.g. Role Owner or Security Lead etc. You would not want to mitigate all risks automatically (if I have understood correctly that you have a mitigation per risk ID). In theory, an automated mitigation process would mitigate all risks without discrimination.
On a side note, there is a configuration setting under SPRO for Access controls as follows
"Risk Analysis- Access Request : Param ID 1072 - Mitigation of critical risk required before approving the request". By enabling this configuration, you could force a mitigating control to be applied to any user requesting Critical Access.
Hope this helps.

Skipping the risk analysis

Hi All,
I have CUP .net version in GRC.We have a risk analysis mandatory for every request.I want to know if I can skip the risk analysis for some orders in CUP.How I can do it.
Thanks in advance

Yes, you can skip.
Goto -> CUP Configuration -> Workflow -> Stage -> Addition configuration -> Risk Analysis Mandatory ->NO
Suggest you to perform risk analysis if its part of your process..
Rakesh

AC 5.3 RAR - combined risk analysis reports for regular auth. and SPM auth.

Dear All,
we have users that have regular day-today authorization and also FF authorization.
Does the Batch Risk Analysis takes into account both authorizations when doing the risk analysis for those users ? will we see it in the reports ?
Thanks
Yudit

ok, so basically the answer is no, in the RAR components we do not have risk analysis for the combinations of the roles assigned to the user and to his FF ID.
in that case, at what stage does the system checks for those combined risks ?
is it checked when we manage the risk analysis phase in the CUP request that is asking to assign the FF ID to the user ?
thanks
Yudit

Risk analysis Report Error in GRC AC 10.0

Dear GRC,
I had problem with Risk analysis Report in GRC Access Request form
When i run the Risk analysis report on Action Level , Permission Level , Critical Action Level and Critical Permission Level then report showing as "No Violations" but if i run the Risk analysis report only on Critical Action Level and Critical Permission Level then report showing too many Violations.
I maintained Action Level , Permission Level , Critical Action Level and Critical Permission Level as default risk analysis type in SPRO Configuration Parameters settings.
i am not understanding why system behaves like this. Could you please help me on this.
System Details : GRC AC 10.0 , SP-12
Thanks a lot for swift response.
Best Regards,
RK

Hi GRC Team,
Please help me on this. I am waiting for your replay.
Regards,
KR

GRC AC 10.0 Mass risk analysis vs. Role level analysis

Hello GRC experts,
I urgently need your advice on the issue with deactivated permission objects which are identified as risks in the mass role analysis.
For example, in one role we have deactivated the permission object: S_ARCHIVE, and there are No activities maintained.
But in the mass role risk analysis and in the CUP request this object S_ARCHIVE with the ACTVT 01 is displayed as risk. As you can see in the screenshot, there are no activites maintained at all. We have created the MSMP workflow where all CUP requests with risks should go the the Security Stage. Now we have the situation that even though our roles are clean, they are forwared to the Security stage. It is a huge problem, because our security stage has no even more to to, than before using GRC! Because the dectivated objects are identified as risks.
Please advise me, how to solve the problem. Did I missed some config parameters or is it a well known problem?
We are on SP14, AC 10.0.
At the single role level there are no risks displayed.
Thanks in advance,
regards
Sabrina

Hi Sabrina,
check note
http://service.sap.com/sap/support/notes/2036645
Please let me know if it works.
Regards,
Alessandro

Getting "Risk Analysis Failed " error while raising request from IDM

Hi friends,
Some of the User to Role mapping requests from IDM did not reach CUP (request ID = null) . When noticed the VDS log , we found the error from GRC webservice to be Risk Analysis Failed . We thought it might be an RAR issue , however , the request just got through CUP when submitted from GRC webservice directly . From RAR perspective also, everything looks ok .
Please provide your thoughts as to whether this error is pertaining to some other issue or suggest me what I can check in Identity center to correct this .
Thanks in advance for your help .

The connector set up are all looking correct . However the requests are not getting raised in many cases .
At one point we identified that , since our SAP systems have been migrated to DB2, some of the systems were down .
So when the system is down we decided , Risk analysis is failing . however , now the systems are up and running and still the risk analysis is failing .

Error while executing the Job for Objects :null Batch Risk Analysis

Hi All,
We've recently upgraded Virsa to version 5.3_14 . I'm encountering a problem when executing the Batch Risk Analysis job for users, roles and profiles. The job does not complete for some objects and it seems to be sporadic and shows this error: -
Background Job History: job id=395, status=2, message=Error while executing the Job for Object(s) :ABROWN:null
I've attached the log for your review.
Thanks in advance for your help.
Linda Lewis
Feb 9, 2011 1:47:53 PM com.virsa.cc.xsys.meng.ObjAuthMatcher <init>
FINEST: ObjAuthMatcher constructed: 4ms, #singles=2141, #ranges=0, #super=0
Feb 9, 2011 1:47:54 PM com.virsa.cc.xsys.riskanalysis.AnalysisEngine riskAnalysis
WARNING: Job ID:395 : Failed to run Risk Analysis
java.lang.StringIndexOutOfBoundsException at java.lang.String.substring(String.java:1019)
at com.virsa.cc.xsys.util.RuleLoader.getPermRule(RuleLoader.java:573)
at com.virsa.cc.xsys.riskanalysis.AnalysisEngine.performActPermAnalysis(AnalysisEngine.java:1609)
at com.virsa.cc.xsys.riskanalysis.AnalysisEngine.riskAnalysis(AnalysisEngine.java:321)
at com.virsa.cc.xsys.bg.BatchRiskAnalysis.performBatchRiskAnalysis(BatchRiskAnalysis.java:1166)
at com.virsa.cc.xsys.bg.BatchRiskAnalysis.performBatchSyncAndAnalysis(BatchRiskAnalysis.java:1464)
at com.virsa.cc.xsys.bg.BgJob.runJob(BgJob.java:560)
at com.virsa.cc.xsys.bg.BgJob.run(BgJob.java:363)
at com.virsa.cc.xsys.riskanalysis.AnalysisDaemonBgJob.scheduleJob(AnalysisDaemonBgJob.java:375)
at com.virsa.cc.xsys.riskanalysis.AnalysisDaemonBgJob.start(AnalysisDaemonBgJob.java:92)
at com.virsa.cc.comp.BgJobInvokerView.wdDoModifyView(BgJobInvokerView.java:444)
at com.virsa.cc.comp.wdp.InternalBgJobInvokerView.wdDoModifyView(InternalBgJobInvokerView.java:1236)
at com.sap.tc.webdynpro.progmodel.generation.DelegatingView.doModifyView(DelegatingView.java:78)
at com.sap.tc.webdynpro.progmodel.view.View.modifyView(View.java:337)
at com.sap.tc.webdynpro.clientserver.cal.ClientComponent.doModifyView(ClientComponent.java:481)
at com.sap.tc.webdynpro.clientserver.window.WindowPhaseModel.doModifyView(WindowPhaseModel.java:551)
at com.sap.tc.webdynpro.clientserver.window.WindowPhaseModel.processRequest(WindowPhaseModel.java:148)
at com.sap.tc.webdynpro.clientserver.window.WebDynproWindow.processRequest(WebDynproWindow.java:335)
at com.sap.tc.webdynpro.clientserver.cal.AbstractClient.executeTasks(AbstractClient.java:143)
at com.sap.tc.webdynpro.clientserver.session.ApplicationSession.doProcessing(ApplicationSession.java:332)
at com.sap.tc.webdynpro.clientserver.session.ClientSession.doApplicationProcessingStandalone(ClientSession.java:741)
at com.sap.tc.webdynpro.clientserver.session.ClientSession.doApplicationProcessing(ClientSession.java:694)
at com.sap.tc.webdynpro.clientserver.session.ClientSession.doProcessing(ClientSession.java:253)
at com.sap.tc.webdynpro.clientserver.session.RequestManager.doProcessing(RequestManager.java:149)
at com.sap.tc.webdynpro.serverimpl.defaultimpl.DispatcherServlet.doContent(DispatcherServlet.java:62)
at com.sap.tc.webdynpro.serverimpl.defaultimpl.DispatcherServlet.doGet(DispatcherServlet.java:46)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
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:207)
at com.sap.engine.core.thread.impl3.SingleThread.execute(SingleThread.java:104)
at com.sap.engine.core.thread.impl3.SingleThread.run(SingleThread.java:176)
Feb 9, 2011 1:47:54 PM com.virsa.cc.xsys.util.Lock lock
FINEST: Lock:1004
Feb 9, 2011 1:47:54 PM com.virsa.cc.xsys.util.Lock unlock
FINEST: Unlock:1004
Feb 9, 2011 1:47:54 PM com.virsa.cc.xsys.bg.BatchRiskAnalysis performBatchRiskAnalysis
WARNING: Error: while executing BatchRiskAnalysis for JobId=395 and object(s):ABROWN: Skipping error to continue with next object: null Feb 9, 2011 1:47:54 PM com.virsa.cc.xsys.bg.BgJob updateJobHistory
FINEST: --- @@@@@@@@@@@ Updating the Job History -
2@@Msg is Error while executing the Job for Object(s) :ABROWN:null
Feb 9, 2011 1:47:54 PM com.virsa.cc.xsys.bg.dao.BgJobHistoryDAO insert
INFO: -
Background Job History: job id=395, status=2, message=Error while executing the Job for Object(s) :ABROWN:null
Feb 9, 2011 1:47:54 PM com.virsa.cc.xsys.util.Lock lock
FINEST: Lock:1004
Feb 9, 2011 1:47:54 PM com.virsa.cc.xsys.util.Lock unlock
FINEST: Unlock:1004
Feb 9, 2011 1:47:54 PM com.virsa.cc.xsys.bg.BatchRiskAnalysis performBatchRiskAnalysis
INFO: --- BKG User Permission Analysis (System: P20:020) completed --- elapsed time: 4522 ms
Feb 9, 2011 1:47:54 PM com.virsa.cc.xsys.util.Lock lock
Edited by: Linda Lewis on Feb 9, 2011 9:08 PM

Hi,
Was a solution found for this error?
Thanks,
Glen

RAR: Error message while running role risk analysis.

Hi All,
We are implementing RAR 5.3. When running permission level risk analysis we get the following error message:
"Error while executing the Job:Cannot assign a blank-padded string to host variable 1.u201D
This happens only at permission level for just one single role and for all the composite roles that contain this one.
The rules were generated without any issue and we cannot find anything unusual on that particular single role.
Any ideas of what could be the cause of this error?

Hi Iliya:
Please find below the job log with the detailed error description:
Mon Dec 15 10:06:37 GMT-02:00 2008 : -----------------------Scheduling Job =>233---------------------------------------------------------------
Mon Dec 15 10:06:37 GMT-02:00 2008 : --- Starting Job ID:233 (RISK_ANALYSIS_ADHOC) - mm:user10
Mon Dec 15 10:06:37 GMT-02:00 2008 : ----------- Background Job History: job id=233, status=1, message=mm:user10 started
Mon Dec 15 10:06:37 GMT-02:00 2008 : Job ID:233 : Exec Risk Analysis
Mon Dec 15 10:06:37 GMT-02:00 2008 : Start Analysis Engine->Risk Analysis ..... memory usage: free=1571M, total=1962M
Mon Dec 15 10:06:38 GMT-02:00 2008 : Rule Loader Syskey => *
Mon Dec 15 10:06:38 GMT-02:00 2008 : No of Systems=1
Mon Dec 15 10:06:51 GMT-02:00 2008 : Action rules cache loaded: memory used in cache=56M, free=1512M, total=1962M
Mon Dec 15 10:06:51 GMT-02:00 2008 : Job ID:233 : Rules loaded, elapsed time: 13694 ms
Mon Dec 15 10:06:57 GMT-02:00 2008 : Job ID:233 :
Mon Dec 15 10:06:57 GMT-02:00 2008 : Job ID:233 : Analysis starts: MM:USER10
Mon Dec 15 10:07:16 GMT-02:00 2008 : Auth Map cache reloaded successfully
Mon Dec 15 10:07:32 GMT-02:00 2008 : Cannot assign a blank-padded string to host variable 1.com.sap.sql.log.Syslog.createAndLogOpenSQLException(Syslog.java:85)
com.sap.sql.log.Syslog.createAndLogOpenSQLException(Syslog.java:124)
com.sap.sql.types.VarcharResultColumn.setString(VarcharResultColumn.java:66)
com.sap.sql.jdbc.common.CommonPreparedStatement.setString(CommonPreparedStatement.java:511)
com.sap.engine.services.dbpool.wrappers.PreparedStatementWrapper.setString(PreparedStatementWrapper.java:355)
com.virsa.cc.xsys.util.ObjTextReader.lookupByKey(ObjTextReader.java:353)
com.virsa.cc.xsys.util.ObjTextReader.getFieldValueDesc(ObjTextReader.java:261)
com.virsa.cc.xsys.riskanalysis.AnalysisEngine.insertPermReportLines(AnalysisEngine.java:2286)
com.virsa.cc.xsys.riskanalysis.AnalysisEngine.outputPermissionViolation(AnalysisEngine.java:1858)
com.virsa.cc.xsys.riskanalysis.AnalysisEngine.performActPermAnalysis(AnalysisEngine.java:1182)
com.virsa.cc.xsys.riskanalysis.AnalysisEngine.riskAnalysis(AnalysisEngine.java:243)
com.virsa.cc.xsys.riskanalysis.AnalysisEngine.riskAnalysis(AnalysisEngine.java:207)
com.virsa.cc.xsys.bg.BgJob.runJob(BgJob.java:305)
com.virsa.cc.xsys.bg.BgJob.run(BgJob.java:183)
com.virsa.cc.xsys.riskanalysis.AnalysisDaemonBgJob.scheduleJob(AnalysisDaemonBgJob.java:154)
com.virsa.cc.xsys.riskanalysis.AnalysisDaemonBgJob.start(AnalysisDaemonBgJob.java:81)
com.virsa.cc.comp.BgJobInvokerView.wdDoModifyView(BgJobInvokerView.java:434)
com.virsa.cc.comp.wdp.InternalBgJobInvokerView.wdDoModifyView(InternalBgJobInvokerView.java:1223)
com.sap.tc.webdynpro.progmodel.generation.DelegatingView.doModifyView(DelegatingView.java:78)
com.sap.tc.webdynpro.progmodel.view.View.modifyView(View.java:337)
com.sap.tc.webdynpro.clientserver.cal.ClientComponent.doModifyView(ClientComponent.java:480)
com.sap.tc.webdynpro.clientserver.window.WindowPhaseModel.doModifyView(WindowPhaseModel.java:551)
com.sap.tc.webdynpro.clientserver.window.WindowPhaseModel.processRequest(WindowPhaseModel.java:148)
com.sap.tc.webdynpro.clientserver.window.WebDynproWindow.processRequest(WebDynproWindow.java:335)
com.sap.tc.webdynpro.clientserver.cal.AbstractClient.executeTasks(AbstractClient.java:143)
com.sap.tc.webdynpro.clientserver.session.ApplicationSession.doProcessing(ApplicationSession.java:299)
com.sap.tc.webdynpro.clientserver.session.ClientSession.doApplicationProcessingStandalone(ClientSession.java:711)
com.sap.tc.webdynpro.clientserver.session.ClientSession.doApplicationProcessing(ClientSession.java:665)
com.sap.tc.webdynpro.clientserver.session.ClientSession.doProcessing(ClientSession.java:232)
com.sap.tc.webdynpro.clientserver.session.RequestManager.doProcessing(RequestManager.java:152)
com.sap.tc.webdynpro.serverimpl.defaultimpl.DispatcherServlet.doContent(DispatcherServlet.java:62)
com.sap.tc.webdynpro.serverimpl.defaultimpl.DispatcherServlet.doGet(DispatcherServlet.java:46)
javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
com.sap.engine.services.servlets_jsp.server.HttpHandlerImpl.runServlet(HttpHandlerImpl.java:401)
com.sap.engine.services.servlets_jsp.server.HttpHandlerImpl.handleRequest(HttpHandlerImpl.java:266)
com.sap.engine.services.httpserver.server.RequestAnalizer.startServlet(RequestAnalizer.java:386)
com.sap.engine.services.httpserver.server.RequestAnalizer.startServlet(RequestAnalizer.java:364)
com.sap.engine.services.httpserver.server.RequestAnalizer.invokeWebContainer(RequestAnalizer.java:1039)
com.sap.engine.services.httpserver.server.RequestAnalizer.handle(RequestAnalizer.java:265)
com.sap.engine.services.httpserver.server.Client.handle(Client.java:95)
com.sap.engine.services.httpserver.server.Processor.request(Processor.java:175)
com.sap.engine.core.service630.context.cluster.session.ApplicationSessionMessageListener.process(ApplicationSessionMessageListener.java:33)
com.sap.engine.core.cluster.impl6.session.MessageRunner.run(MessageRunner.java:41)
com.sap.engine.core.thread.impl3.ActionObject.run(ActionObject.java:37)
java.security.AccessController.doPrivileged(Native Method)
com.sap.engine.core.thread.impl3.SingleThread.execute(SingleThread.java:102)
com.sap.engine.core.thread.impl3.SingleThread.run(SingleThread.java:172)
Mon Dec 15 10:07:32 GMT-02:00 2008 : Cannot assign a blank-padded string to host variable 1.com.virsa.cc.xsys.bg.BgJob.runJob(BgJob.java:309)
com.virsa.cc.xsys.bg.BgJob.run(BgJob.java:183)
com.virsa.cc.xsys.riskanalysis.AnalysisDaemonBgJob.scheduleJob(AnalysisDaemonBgJob.java:154)
com.virsa.cc.xsys.riskanalysis.AnalysisDaemonBgJob.start(AnalysisDaemonBgJob.java:81)
com.virsa.cc.comp.BgJobInvokerView.wdDoModifyView(BgJobInvokerView.java:434)
com.virsa.cc.comp.wdp.InternalBgJobInvokerView.wdDoModifyView(InternalBgJobInvokerView.java:1223)
com.sap.tc.webdynpro.progmodel.generation.DelegatingView.doModifyView(DelegatingView.java:78)
com.sap.tc.webdynpro.progmodel.view.View.modifyView(View.java:337)
com.sap.tc.webdynpro.clientserver.cal.ClientComponent.doModifyView(ClientComponent.java:480)
com.sap.tc.webdynpro.clientserver.window.WindowPhaseModel.doModifyView(WindowPhaseModel.java:551)
com.sap.tc.webdynpro.clientserver.window.WindowPhaseModel.processRequest(WindowPhaseModel.java:148)
com.sap.tc.webdynpro.clientserver.window.WebDynproWindow.processRequest(WebDynproWindow.java:335)
com.sap.tc.webdynpro.clientserver.cal.AbstractClient.executeTasks(AbstractClient.java:143)
com.sap.tc.webdynpro.clientserver.session.ApplicationSession.doProcessing(ApplicationSession.java:299)
com.sap.tc.webdynpro.clientserver.session.ClientSession.doApplicationProcessingStandalone(ClientSession.java:711)
com.sap.tc.webdynpro.clientserver.session.ClientSession.doApplicationProcessing(ClientSession.java:665)
com.sap.tc.webdynpro.clientserver.session.ClientSession.doProcessing(ClientSession.java:232)
com.sap.tc.webdynpro.clientserver.session.RequestManager.doProcessing(RequestManager.java:152)
com.sap.tc.webdynpro.serverimpl.defaultimpl.DispatcherServlet.doContent(DispatcherServlet.java:62)
com.sap.tc.webdynpro.serverimpl.defaultimpl.DispatcherServlet.doGet(DispatcherServlet.java:46)
javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
com.sap.engine.services.servlets_jsp.server.HttpHandlerImpl.runServlet(HttpHandlerImpl.java:401)
com.sap.engine.services.servlets_jsp.server.HttpHandlerImpl.handleRequest(HttpHandlerImpl.java:266)
com.sap.engine.services.httpserver.server.RequestAnalizer.startServlet(RequestAnalizer.java:386)
com.sap.engine.services.httpserver.server.RequestAnalizer.startServlet(RequestAnalizer.java:364)
com.sap.engine.services.httpserver.server.RequestAnalizer.invokeWebContainer(RequestAnalizer.java:1039)
com.sap.engine.services.httpserver.server.RequestAnalizer.handle(RequestAnalizer.java:265)
com.sap.engine.services.httpserver.server.Client.handle(Client.java:95)
com.sap.engine.services.httpserver.server.Processor.request(Processor.java:175)
com.sap.engine.core.service630.context.cluster.session.ApplicationSessionMessageListener.process(ApplicationSessionMessageListener.java:33)
com.sap.engine.core.cluster.impl6.session.MessageRunner.run(MessageRunner.java:41)
com.sap.engine.core.thread.impl3.ActionObject.run(ActionObject.java:37)
java.security.AccessController.doPrivileged(Native Method)
com.sap.engine.core.thread.impl3.SingleThread.execute(SingleThread.java:102)
com.sap.engine.core.thread.impl3.SingleThread.run(SingleThread.java:172)
Mon Dec 15 10:07:32 GMT-02:00 2008 : Job ID: 233 Status: Error
Mon Dec 15 10:07:32 GMT-02:00 2008 : ----------- Background Job History: job id=233, status=2, message=Error while executing the Job:Cannot assign a blank-padded string to host variable 1.
Mon Dec 15 10:07:32 GMT-02:00 2008 : -----------------------Complted Job =>233---------------------------------------------------------------
Regards.
Leandro.

ARQ: Risk Mitigation Mandatory and Request Forward causing problem???

Hi,
I have a scenario where in, at a certain stage, "Risk Mitigation" is made mandatory and also "Forward Request" option is available at this stage for the same approver.
What is happening is that, when this approver tries to approve the request without mitigating the risks, it gives error message and request can not be approved. This is fine and going as per the configuration.
Now the same approver is trying to forward the request to some other person for some business reasons (with "WITH RETURN" check box checked and disabled). This request is reaching to the desired recipient as expected. But the problem is that, when after providing his comments (a business requirement before mitigating risks, if need be) if he tries to approve (submit) the request, application gives the same error message that: "Request can not be submitted. Mitigate Risk XYZ"!
Due to this, request can not be submitted and sent back to main approver! I noticed that, the request still lies on the same stage and the same stage configuration is being considered for this forwardee too!
This is keeping the request hanging as this forwadee is not authorized to mitigate the risks.
Can any one please help me resolve this?
Regards,
Faisal

Alessandro,
Thanks for your reply.
Now I see (as confirmed) that we have technical limitation or application design that when we forward a request, it DOES NOT change the stage (even I noticed this). So I was thinking that only we have "SUBMIT" button to send it back to the main approver.
But as you said, this forwardee can use the same "Forward Request" option instead of "Submit" button. This looks the option here which suits the situation.
But can you please tell me if we can do something to inform the forwardee that he must select "Forward Request" option and not Submit button?
Because, this submit button is visible and he can click it without knowing! And then this error message of Mandatory risk analysis then appears!
Is there any work around?
Please advise.
Regards,
Faisal

Risk Analysis Mandatory while rejecting a request

Similar Messages

Maybe you are looking for