PARTNERS - Please join us for our upcoming webinar:
Leveraging Intelligent Recommendations for Operational Transformation.
AMS Partners click HERE | EMEA/APJ Partners click HERE

UPDATEUSER JSON To write email back to Workday

krecpond
New Contributor III
New Contributor III

I have the below USERUPDATE JSON configured on the REST connector to write email changes back to Workday from Saviynt. This uses a REST connection because the attribute that needs to be updated on Workday is a custom object and cannot be done via SOAP (according to Workday team).

 

{
"actions": {
"Update Login": {
"call": [{
"name": "Update Login",
"connection": "userAuth",
"url": "https://xxxx.xxxx.com/ccx/api/v1/xxx/customObjects/upn/upn?updateIfExists=true",
"httpMethod": "POST",
"httpParams": "{\"worker\":{\"id\": \"${user.customproperty41}\"}, \"upn\":\"${user.email}\"}",
"httpHeaders": {
"Authorization": "${access_token}"
},
"httpContentType": "application/json",
"successResponses": {
"statusCode": [200, 201, 204]
},
"unsuccessResponses": {
"statusCode": [400, 401, 500, 503, 404, 403, 409]
}
}]
}
}
}

When I changed the email ID, the Update User pending task is successfully created however, it is not getting picked by the WS-RETRY job.

The task configuration is as follows:

krecpond_0-1666030039515.png

 

I tried the user update rule with and without Update Login and made similar changes to the USERUPDATE JSON but still was unsuccessful in getting the pending task processed.

Note - For writing the network ID back to workday, the update rule with Update Login (and the same action configured in the USERUPDATE JSON) resulted in a successful update of the Login ID in Workday (again a custom object). 

Any thoughts on how this issue can be resolved would be helpful.

 

18 REPLIES 18

KirtiAjrot
Saviynt Employee
Saviynt Employee

 Does the same thing work when tried from Postman? 

it could be that the input bindings are not getting resolved properly and hence resulting in some error.

Please try to perform below 2 steps:

1. Check the response when the call is made with hardcoded values from postman.

2. If above is successful, use the Config Json in the REST connector = {"showLogs":true} , and when the WS retry job runs , try to capture the error in logs. 

KA

krecpond
New Contributor III
New Contributor III

Hi Kirti,

The same works perfectly fine from postman with hardcoded values. The structure of the request body is no different from the structure of the request body to write back the network ID and the later works fine with the same JSON structure. The only difference between the 2 JSONs are the REST endpoints (URLs) and the attribute name to be passed for being updated. In one it is "loginId" while in the other it is "upn".

I will try the recommendation to include the Config JSON to show logs and figure out what could be the cause of the issue.

  • Can you share logs ?
  • Can you share postman screenshot?

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

krecpond
New Contributor III
New Contributor III

Below is the postman screenshot showing the return response is 200 OK.

krecpond_0-1666189351200.png

WSRETRY for Update user task job history run time:

krecpond_1-1666189450387.png

 

 

Can you check if your connection is working ? also share task key

"ecm-worker","2022-10-19T14:13:03.417+00:00","{"log":"2022-10-19 14:13:02,610 [quartzScheduler_Worker-4] DEBUG services.ArsTaskService - Calling REST method with Connection - Connection-Workday-Writeback-UPN and tasklist - [E90080006:[com.saviynt.ecm.task.ArsTasks : 27530], E90080015:[com.saviynt.ecm.task.ArsTasks : 27182]]\n","stream":"stdout","time":"2022-10-19T14:13:02.610076776Z"}"
"ecm-worker","2022-10-19T14:13:03.417+00:00","{"log":"2022-10-19 14:13:02,610 [quartzScheduler_Worker-4] DEBUG rest.RestProvisioningService - Processing User Update Task for REST\n","stream":"stdout","time":"2022-10-19T14:13:02.610087345Z"}"
"ecm-worker","2022-10-19T14:13:03.417+00:00","{"log":"2022-10-19 14:13:02,611 [quartzScheduler_Worker-4] ERROR rest.RestProvisioningService - Connection Failed to LDAP or UPDATEUSERJSON value not found in connection\n","stream":"stdout","time":"2022-10-19T14:13:02.61164826Z"}"


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

That highlighted error that does make sense because the connection type is a REST connector. That is the reason I ignored that error in the logs. The UPDATEUSER JSON structure has been validated and there are no errors in it. The same connection JSON has been used on another REST connector to write back network ID and that works successfully but the email writeback is not successful.

Its valid can you connection screenshot that you have UPDATEUSERJSON 


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

krecpond
New Contributor III
New Contributor III

Below is the UPDATEUSER JSON screenshot

krecpond_0-1666196325624.png

Question - In the user update rule, while configuring CREATE UPDATE USER TASK, do any of the 3 options have to be selected - Update Login, Disable User, Enable User? I had to use Update Login to be able to successfully writeback the network ID to Workday. I tried with and without the option for email updates, but neither of the options have worked for me.

Can you hardcode access_token in SAviynt & try


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

krecpond
New Contributor III
New Contributor III

Sorry but I did not understand your response about "hardcode access_token in SAviynt". The connection JSON will issue a new access token and any token that I hard code will be invalid.

  • Generate token from postman
  • Hard code token in highlighted area 
  • Run WSRETRY

rushikeshvartak_0-1666198074742.png

 

 


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

I gave it a try and still did not work. I don't see anything unique in the logs either this time.

I still feel your connection is not working. Please validate same


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

krecpond
New Contributor III
New Contributor III

The same connection parameters work through Postman. Is it possible to get on a call to look at the issue?

krecpond
New Contributor III
New Contributor III

We checked internally with Workday team and they don't see a request coming from Saviynt for UPN update although the same connection JSON works for login ID update.

2 of my questions on this thread did not get answered:

1. Why does log show an error on LDAP for REST provisioning service?

2. What is the configuration in the user update rule - Does it always need to be Update Login for the update user task to write the data back to Workday?

This is tending to be a product issue now.

krecpond
New Contributor III
New Contributor III

Any updates on this issue or how this issue can be resolved?

Check with Saviynt OPS with Fresh desk ticket. if your URL is able to hit from server using curl command


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

benjaminp
New Contributor
New Contributor

Hello,

We are facing the exact same issue as described by @krecpond 

We are working with SuccessFactors API to try to send back username and email (we already use this connection for user import). I've configured a user update rule that creates a user update task (Update Login) and configured the UpdateUserJSON accordingly.

But the task is not picked up by WSRETRY job with the same traces in logs ( ERROR rest.RestProvisioningService - Connection Failed to LDAP or UPDATEUSERJSON value not found in connection) even though the connection is working (user import is ok).

Have you found the solution for this issue ?

Thanks in advance.

Regards

Benjamin