Sav4SavREST disable account success message

[flegare]

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

[SB]

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.

[flegare]

I do run into a 403 error, somehow, even though the connector is able to perform the operation.  I attached the error within this post.  How can the connector work if it cannot actually login?

[SB]

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.

[flegare]

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

[SB]

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. 

[flegare]

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...

[SB]

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.

[rushikeshvartak]

share full json

[flegare]

Hi @rushikeshvartak 

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!

[rushikeshvartak]

statusCode mapping is missing 

[SB]

@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.

[flegare]

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
  ]
  }
]
}
]
}

[flegare]

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!!

[SB]

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

[flegare]

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

[SB]

To be clear, do you mean the User remains active after import or the account? 

[flegare]

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

[renatogiron]

Please confirm the following assumptions I am making: 

1. This is for Saviynt for Saviynt REST connection
2. The task for disabling the account is triggered and the task remains pending even though the Saviynt account is successfully disabled
3. You have validated that the account is actually disabled as expected
4. The REST response is 200 when successful. This has been validated via REST tool (i.e.: postman)

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]}]

[flegare]

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.