Saviynt unveils its cutting-edge Intelligence Suite products to revolutionize Identity Security!
Click HERE to see how Saviynt Intelligence is transforming the industry.
Saviynt Copilot Icon

Saviynt request id is not getting created for a user in ARS after external SOD evaluation.

Dev
New Contributor III
New Contributor III

 

We are facing the issues when the request is submitted which contains external sod evaluation from SAP grc. So once the request is raised for a user, request id's are not generated instead it is redirected to final page with SOD confirmation number. Multiple users have been affected.

Since the request id's are not generated those are not visible under the request history,  based upon confirmation we are able to find entries under ars_requests table.

 

Dev_1-1692074962212.png

Dev_2-1692075176468.pngDev_3-1692075195481.png

 

10 REPLIES 10

sai_sp
Saviynt Employee
Saviynt Employee

Please try with the query 

select * from ars_requests where jbpmprocessinstanceid like ‘%39244’

Dev
New Contributor III
New Contributor III

Hello Sai,

Please find below screentshot, request is not created

Dev_1-1692197026216.png

 

rushikeshvartak
All-Star
All-Star

Below are possible root cause of issue.

  • No. of access requested are more in request
  • Database deadlock
  • Network Connectivity Issue with Saviynt to GRC System.
  • Since Sod Evaluated is 0 it means external sod is not detected here. Kindly check logs and SAP System to confirm Saviynt is hitting GRC System

Regards,
Rushikesh Vartak
If this helped you move forward, click 'Kudos'. If it solved your query, select 'Accept As Solution'.

Manu269
All-Star
All-Star

Once the request is submitted you might have recived the request number.

In the external sod evaluation this request number is used by GRC system to evaluate the SOD.

Based on number of SOD configured in GRC, EIC performs the evaluation.

After few seconds, you should be able to view the Request ID in request history page.

Regards
Manish Kumar
If the response answered your query, please Accept As Solution and Kudos
.

Dev
New Contributor III
New Contributor III

We are aware about the process, our concern is request id is not getting generated for some requests

Does connector name in logs and security system name & endpoint name matches ?

when you submit request capture log and check connector name.

please share logs snip when request is submitted 


Regards,
Rushikesh Vartak
If this helped you move forward, click 'Kudos'. If it solved your query, select 'Accept As Solution'.

Dev
New Contributor III
New Contributor III

Please check the below snip from log 

2023-08-20/07:47:37.784 [{}] [Thread-2491]  DEBUG integration.SapDataImportService - gracidmriskwoutnoservicesmap = [ROLE_TYPE:, USER_GROUP:, OBJECT_TYPE:USR, ORG_LEVEL:, BUSINESS_PROC:, REPORT_TYPE:2, RULE_ID:, RISK_LEVEL:, RULE_SET_ID:GLOBAL, REPORT_FORMAT:2, USER_TYPE:A, SIMULATION_RISK_ONLY:, APPLICATION_TYPE:SAP, HIT_COUNT:50000, LANGUAGE:EN]
2023-08-20/07:47:37.784 [{}] [Thread-2491]  DEBUG integration.SapDataImportService - connectorid = |---------|
| TABLE 'GRAC_T_WS_API_CONNECTOR_LST'
|---------|
|CONNECTOR|
|---------|
|         |
|---------|
|VB2CLNT00|
|---------|

________________________________

endpoint name: VB2CLNT001

Security System name: VB2CLNT001

  1. Update Endpoint name & Security System name from VB2CLNT001 to VB2CLNT00
  2. update externalconfig.properties , sod.endoints =VB2CLNT00 
  3. Restart Server

and Retry submitting request


Regards,
Rushikesh Vartak
If this helped you move forward, click 'Kudos'. If it solved your query, select 'Accept As Solution'.

Hi @rushikeshvartak , This is working fine if the conflict is less than 50000 (total approx 50 entitlements). It is only not working when the conflict is greater that 50000. We have already increased the hit count to 1 Lakh in the connection. We have another app which is also using GRC for calculation SOD, that working fine for any number of conflicts. 

I am attaching the error log here:

2023-08-22/13:54:24.549 [{}] [Thread-2917] ERROR util.JDBCExceptionReporter - Uncaught underlying exception.
2023-08-22/13:54:24.550 [{}] [Thread-2917] ERROR transaction.JDBCTransaction - Could not toggle autocommit
java.sql.SQLException: Connection has already been closed.
at org.grails.datastore.gorm.GormStaticApi.withTransaction(GormStaticApi.groovy:814)
at org.grails.datastore.gorm.GormStaticApi.withTransaction(GormStaticApi.groovy:766)
at org.grails.datastore.gorm.GormStaticApi.withNewTransaction(GormStaticApi.groovy:727)
at com.saviynt.ecm.services.JbpmWorkflowService.evaluateSODAndGenerateRequest(JbpmWorkflowService.groovy:1347)
at com.saviynt.ecm.services.WorkflowService$_createRequestFinalStep_closure266_closure501.doCall(WorkflowService.groovy:23477)
at java.lang.Thread.run(Thread.java:748)
2023-08-22/13:54:24.551 [{}] [Thread-2917] ERROR transaction.JDBCTransaction - JDBC rollback failed
java.sql.SQLException: Connection has already been closed.
at org.grails.datastore.gorm.GormStaticApi.withTransaction(GormStaticApi.groovy:814)
at org.grails.datastore.gorm.GormStaticApi.withTransaction(GormStaticApi.groovy:766)
at org.grails.datastore.gorm.GormStaticApi.withNewTransaction(GormStaticApi.groovy:727)
at com.saviynt.ecm.services.JbpmWorkflowService.evaluateSODAndGenerateRequest(JbpmWorkflowService.groovy:1347)
at com.saviynt.ecm.services.WorkflowService$_createRequestFinalStep_closure266_closure501.doCall(WorkflowService.groovy:23477)
at java.lang.Thread.run(Thread.java:748)
2023-08-22/13:54:24.555 [{}] [Thread-2917] ERROR support.TransactionTemplate - Application exception overridden by rollback exception
org.springframework.jdbc.UncategorizedSQLException: Hibernate operation: could not load an entity: [com.saviynt.ecm.workflow.ARS_Requests#6624]; uncategorized SQLException for SQL [select ars_reques0_.REQUESTKEY as REQUESTKEY139_0_, ars_reques0_.COMMENTS as COMMENTS139_0_, ars_reques0_.COMPLETEDATE as COMPLETE3_139_0_, ars_reques0_.DUEDATE as DUEDATE139_0_, ars_reques0_.ENDPOINTASCSV as ENDPOINT5_139_0_, ars_reques0_.FILEATTCHED as FILEATTC6_139_0_, ars_reques0_.FILETYPE as FILETYPE139_0_, ars_reques0_.JBPMPROCESSINSTANCEID as JBPMPROC8_139_0_, ars_reques0_.PROCESSINSTANCEIDNEW as PROCESSI9_139_0_, ars_reques0_.REQUESTORIGIN as REQUEST10_139_0_, ars_reques0_.REQUESTDATE as REQUEST11_139_0_, ars_reques0_.REQUESTOR as REQUESTOR139_0_, ars_reques0_.REQUESTTYPE as REQUEST13_139_0_, ars_reques0_.SODEVALUATED as SODEVAL14_139_0_, ars_reques0_.STATUS as STATUS139_0_, ars_reques0_.UUIDKEY as UUIDKEY139_0_, ars_reques0_.WORKFLOWNAME as WORKFLO17_139_0_ from ARS_REQUESTS ars_reques0_ where ars_reques0_.REQUESTKEY=?]; SQL state [null]; error code [0]; Uncaught underlying exception.; nested exception is java.sql.SQLException: Uncaught underlying exception.
at com.saviynt.ecm.services.JbpmWorkflowService$_evaluateSODAndGenerateRequest_closure32.doCall(JbpmWorkflowService.groovy:1380)
at org.grails.datastore.gorm.GormStaticApi.withTransaction(GormStaticApi.groovy:814)
at org.grails.datastore.gorm.GormStaticApi.withTransaction(GormStaticApi.groovy:766)
at org.grails.datastore.gorm.GormStaticApi.withNewTransaction(GormStaticApi.groovy:727)
at com.saviynt.ecm.services.JbpmWorkflowService.evaluateSODAndGenerateRequest(JbpmWorkflowService.groovy:1347)
at com.saviynt.ecm.services.WorkflowService$_createRequestFinalStep_closure266_closure501.doCall(WorkflowService.groovy:23477)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.sql.SQLException: Uncaught underlying exception.
... 7 more
Caused by: java.lang.NullPointerException

This is code level issue of connection time out. Raise FD ticket for same.

org.springframework.jdbc.UncategorizedSQLException: Hibernate operation: could not load an entity : https://forum.hibernate.org/viewtopic.php?p=2411332

 

Caused by: java.lang.NullPointerException : This is saviynt code issue

Preliminary Steps

You can check database timeout in v5.5 version

rushikeshvartak_0-1692762160764.png

 

 

Checking Current Timeout Settings

Before making any changes, it's a good idea to first check the current settings for wait_timeout and interactive_timeout. This way, you'll have a baseline to compare against when making adjustments. Here's how to do that.

 

To retrieve the current session-level settings, you can log into MySQL from the command line and run the following queries:

SHOW VARIABLES LIKE 'wait_timeout';
SHOW VARIABLES LIKE 'interactive_timeout';

To retrieve the current global settings, use these queries instead:

SHOW GLOBAL VARIABLES LIKE 'wait_timeout';
SHOW GLOBAL VARIABLES LIKE 'interactive_timeout';

 

 


Regards,
Rushikesh Vartak
If this helped you move forward, click 'Kudos'. If it solved your query, select 'Accept As Solution'.