Which Json is used in Database Connector for Extend endDate functionality?

[KT]

Where should we configure the JSON for Extend endDate functionality in Database connector?

We tried to use UPDATEACCOUNTJSON, GRANTACCESSJSON, REVOKEACCESSJSON to use this functionality, we are not able to update the extended endDate into the target system using these JSONs.

[sahajranajee]

Hi @KT ,

Could you please elaborate on your use case and let us know what is the target system you are integrating with?

[KT]

We are using this database connector to integrate with the EBS target system. We want to use extend feature of ARS for EBS responsibilities(entitlements). To use this feature, we want to know which JSON it will invoke from database connector after selecting extend feature. Thank you.

[sahajranajee]

Hello @KT ,

Since you are using the DB connector and provisioning the access to the target, are you provisioning the dates as well to the target when someone initially gets the access? 

[KT]

Yes, correct. Dates are getting set when access was requested initially. Now user wants extend access dates.

[sahajranajee]

Hello,

It should ideally be using the same connector JSON (GrantAccessJSON) . In this exercise, when you are extending the end date, what are the types of tasks being generated (if any)?

[KT]

Hi,

We tried to use GrantAccessJSON, but it was not invoking this JSON.

REQUEST TYPE: UPDATE ACCESS END DATE

TASK TYPE: Access

[avinashchhetri]

@KT ,

In your screenshot the End Date and the New End Date are exactly the same, perhaps that's why it isnt getting updated ?

Also the task says completed, can you share the logs from the Provisioning run ?

[KT]

Hi Avinash

As per your request I have uploaded the logs. Can you please analyze the logs and confirm if this is an issue or please provide your thoughts on this?

Thanks 

[Dave]

I'm sorry @KT , where were the logs uploaded to? I'm not seeing them in the thread.  Thanks!  
Ah!  Nevermind, I see them now. 

[KT]

Hi,

In this example I have requested with End Date and New End Date as different values, I have attached the screenshot for the same below. To give a clear idea of how the tasks are getting processed, I have requested one add access task which invokes the grant access JSON, along with extend end date task which is added under the following section in the logs.

2022-07-20 00:31:00,497 [quartzScheduler_Worker-4] DEBUG services.ArsTaskService - Query Update Access End Date Tasks=
select rr from ArsTasks rr where
rr.securitysystem.automatedProvisioning = true and
rr.accountKey != null
and rr.tasktype = 31 and rr.entitlement_valueKey != null
and rr.id in (126083,126082 )

In this section we can clearly see that it does not invoke any JSON as part of the processing, rather just updates the account_entitlements1 table with the new value, marks the task as completed and does not push any update in the target system.

The current Saviynt version which we are using is SSM 5.5 SP3.11.

Can you confirm if this version supports this functionality, if it does then is there any other JSON that we should consider giving a try?

Thanks

[rushikeshvartak]

Extend access Date feature Specially designated for SAP based Application. 

For DB based application, i don't think this will work. If technically this will work then we need to write if else logic in grant json / new json block for access extend

[draut]

let me know if you find any solution for the extension, having a similar type of issue.

[timchengappa]

Hello @KT & @draut 

I wanted to circle back on this post and provide the below update to close the loop...

The provisioning of "end-date" as metadata during Saviynt's "Extend End Date" functionality is not an OOTB-supported feature. The task created during this action is task-type 31(TASKTYPE_EXTENDACCESS) which is used for internal processing only where the end-date is updated in Saviynt's Account_Entitlement1 table(except for connection Type: SAP where a backend BAPI call is made to update the acc-role's update date).

Also, the processing behavior for task-type 31(TASKTYPE_EXTENDACCESS) is by design. When a request to extend the end date for access has been submitted, the corresponding task updates the end date as requested and records the new end date in Saviynt. When we breach the end date or it's past the end date, the system creates a remove access task and when the provisioning job(WSRetry) processes this task, it removed the corresponding access in the target application as well...

As for your use case, it will have to be an enhancement, and request you to submit a request in our Ideas portal.

Thank you