Hi,
I am working on a workflow where I am using the HTTP request action to create the campaign and then the action for activating the campaign.
My objective is to capture the non 2xx response i.e.basically the failure response and send the notification. Currently the workflow will fail at the very step and don’t go further…
Now I have explored over the community and found this limitation of the workflow.
On several links it has been mentioned that the idea is in backlog for SailPoint.
So do we have this capability implemented or it is still in consideration.
I am not sure if you are looking for capturing status code of HTTP request action or of the workflow itself.
To capture the status code of HTTP request action, you can use “Compare Numbers” operator with value1 as $.hTTPRequest.statusCode and compare it with if its equals to value2 as 200.
Hi Shailee,
I am aware of this snippet to get the status code. The idea is to capture the failed status code like 504,400 etc… so that we can continue the workflow execution rather than abrupt ending. Even after putting the compare number code=200 or 201, if any other failed response happen, the workflow won’t continue to go for the false condition and it will end instantly. I want to avoid this and send the notification of the failed status code.
Understood, in the same operator, when the result is false (i.e. HTTP action has failed), proceed to send the failure notification and/or continue with the further processing. Hopefully subsequent workflow blocks are not referencing to any fields from the HTTP action response, since it has failed.
Were you able to determine a solution for this problem? It is unfortunate that the HTTP action terminates the workflow on a 400 instead of allowing for retry or handling and thus I am running into the same issue.
At this time, HTTP Requests will fail the entire workflow if a non-2xx response code is returned. There currently is no way to prevent this. Error handling is a broader concept that is being explored by the workflow engineering team that will account for use cases like this. There is no ETA on when the improved error handling features will be available.