Leveraging Intelligent Recommendations for Operational Transformation. AMS Partners Click HERE | EMEA/APJ Click HERE |
04/24/2023 07:29 AM
Disable account provisioning tasks remain in the pending task list after successful provisioning.
Values returned from api are:
statusCode: 200,
"message":{"errorCode":"0",
"message":" User Updated Successfully"}
I included the same under successResponses:
"successResponses": [
{
"errorCode":"0",
"message": "User Updated Successfully",
"statusCode": [
200,
201,
204,
205
]
}
What could I possibly be missing for this to be handled properly?
version 23.3
04/26/2023 10:16 AM - edited 04/26/2023 10:16 AM
Can you check the logs and confirm if you see any error. In case there is no error, can you check for the response you get.
04/26/2023 11:39 AM
04/26/2023 11:53 AM
This does not look like the right log. Can you update ConfigJSON param in the REST connection with value {"showLogs":true}. Run the prov job and search for Calling Webservice Url and then trace the thread forward to check for the error.
04/26/2023 02:31 PM
I tried to re-apply the transaction and took an excerpt of the log containing all the lines for a single task execution. I can't see any sort of error code in there that would explain the condition I see.
API response is: {"errorCode":"0","message":" User Updated Successfully"}, statusCode:200
05/01/2023 10:25 AM
I see you are using updateUser api and are possibly disabling the user. This will only disable the user and based on your further config, the disable account tasks will be generated. This api is not triggering those account tasks or any requests. So the provisioning of these tasks are independent of the updateUser api you are calling.
05/01/2023 12:04 PM
I understand the first two sentences here and you are right, disabling the EIC identity is the end goal.
I think I understand the next two sentences and I agree, a provisioning job must run for the task. We do execute such a task, I believe this is what is causing the call through the api.
What I don't understand is why do the tasks remain even though the provisioning calls are successful? What am I missing to clean and archive those tasks...
05/01/2023 02:36 PM
For this, you will need to check the logs for the account provisioning call. The logs you shared before are for the update user call which is different from the JSON's that will be used for account provisioning.
05/01/2023 08:47 PM
share full json
05/02/2023 05:11 AM
Here is the json used to disable the account:
{
"call": [
{
"name": "call1",
"connection": "userAuth",
"url": "https://ClientInfoRedacted.saviyntcloud.com/ECM/api/v5/updateUser",
"httpMethod": "POST",
"httpParams": "{\"username\":\"${user.username}\",\"statuskey\":\"1\"}",
"httpHeaders": {
"Authorization": "${access_token}"
},
"httpContentType": "application/json",
"successResponses": [
{
"message": "User Updated Successfully"
}
]
}
]
}
Thanks in advance!
05/04/2023 11:07 AM
statusCode mapping is missing
05/04/2023 10:32 AM
@flegare Can you share a screenshot of the task that you see is still pending. Also, please confirm the steps you are following for the use case.
05/04/2023 11:10 AM - edited 05/04/2023 11:15 AM
Hi @rushikeshvartak ,
We tried with this statement, too:
{
"call": [
{
"name": "call1",
"connection": "userAuth",
"url": "https://ClientInfoRedacted.saviyntcloud.com/ECM/api/v5/updateUser",
"httpMethod": "POST",
"httpParams": "{\"username\":\"${user.username}\",\"statuskey\":\"0\"}",
"httpHeaders": {
"Authorization": "${access_token}"
},
"httpContentType": "application/json",
"successResponses": [
{
"errorCode":"0",
"message": "User Updated Successfully",
"statusCode": [
200,
201,
204,
205
]
}
]
}
]
}
05/04/2023 11:13 AM
Hi @SB ,
Steps are as follows:
Status update is read in from hr source
User Update rule triggers leaver action tasks
Tasks are applied through wsretry job
Screenshots are attached
Thanks for your help!!
05/04/2023 11:29 AM
The url you are using is incorrect. These are account tasks and you need to use ECM/api/v5/updateAccount instead. Also, there are some mandatory parameters that need to be passed in the body. Below is the link to Saviynt's postman collection. You can refer the same for the format of Update Account JSON.
https://documenter.getpostman.com/view/1797923/RWaLwo21#intro
05/05/2023 06:47 AM
Hi @SB,
I gave this a try and I am able to disable the account, however the identity itself remains active after import. Is there something obvious I am missing?
Thanks again!
Francois
05/05/2023 07:36 AM
To be clear, do you mean the User remains active after import or the account?
05/05/2023 11:05 AM
Correct, when I mark the account as either "SUSPENDED FROM IMPORT SERVICE" or "Manually Suspended" through API and then import the account back, the identity to which the account is linked remains active.
However, why would we need to run an account update where an user update operation yielded a 200 return code? Not sure on what is missing in here
05/10/2023 09:46 AM
Please confirm the following assumptions I am making:
If all of this is true, the issue is that your account disable JSON is not properly configured. IT thinks the task failed even though it was successful. Try the below simplified success resonse config:
"successResponses": [ {"statusCode": [200]}]
05/11/2023 07:51 AM - edited 05/11/2023 07:52 AM
Hi @renatogiron ,
Assumptions 1 and 4 are correct. Assumptions 2 and 3 aren't. The identity itself is disabled but the account in S4S remains active.
I believe the issue is on our end though, the identity is actually being disabled from the authoritative source prior to our Disable account action. There is no need to have this additional activity triggered.
Thanks for your assistance in getting this figured out, though, it was much appreciated.