With the issue that we had today with Workflows, I see they mentioned the ability to “replay” a workflow? Can someone let me know how we would do that? Not finding anything in the API documentation that can put a workflow into a replay status.
By “replayed”, they mean you will need to cause the event to happen again. For example, if you have a workflow that triggers on an access request, you will need to resubmit that access request to get the workflow to process it again. There is no button or API that will directly replay a workflow.
However, I think you could use the test workflow endpoint to make this easier. You can grab the trigger payload of the failed workflow either from the UI or by API and then feed that payload into the test workflow endpoint to essentially “replay” the workflow. Although, this doesn’t seem to work for queued workflow executions that were cancelled. Only in progress workflows that were cancelled.
1 Like
It looks like we can cancel the “queued” executions via the API, but there doesn’t seem to be an option to retrieve any information about queued or canceled executions from the API. When I call the Get Workflow Execution or Get Workflow Execution History endpoints for a queued or canceled execution ID, I get a 404. Is this expected behavior?
We only have one enabled Workflow running in our environment, but it’s got about 100 executions that are hung because of this issue, so manually re-running each of these isn’t an option. I’d love to be able to script out rerunning these using the Test Workflow by ID endpoint, but without being able to pull the trigger for the canceled/queued executions, that’s not going to be possible.
I don’t have any queued workflows to test against, but I did create a workflow with a wait step so I could cancel it.
I initiated a test of this workflow, then found the execution ID of it by running get-workflow-executions | SailPoint Developer Community using the ID of the workflow, which I found in the URL on the test screen.
This produced the following JSON response:
[
{
"id": "37189a91-b06f-47cf-a032-43beef9b324a",
"workflowId": "e9b69b9e-a072-4814-b1fb-30ecadfdaf68",
"requestId": "f0d22f6235a94d6b9b7b80ca65fc083e",
"startTime": "2024-06-11T15:33:39.24927257Z",
"closeTime": null,
"status": "Executing"
}
]
I then took the id, which is the execution ID, and cancelled it using cancel-workflow-execution | SailPoint Developer Community.
I then used get-workflow-execution-history | SailPoint Developer Community using that same id and it produced the following response, which includes the trigger input.
[
{
"type": "WorkflowExecutionStarted",
"timestamp": "2024-06-11T15:33:39.795603277Z",
"attributes": {
"input": {
"hello": "world"
}
}
},
{
"type": "ActivityTaskScheduled",
"timestamp": "2024-06-11T15:33:40.030895771Z",
"attributes": {
"displayName": "Wait",
"input": {
"date": null,
"duration": "1d",
"time": null,
"type": "waitFor"
},
"stepName": "wait",
"task": "sp:sleep"
}
},
{
"type": "ActivityTaskStarted",
"timestamp": "2024-06-11T15:33:40.089969604Z",
"attributes": {
"attempts": 1,
"displayName": "Wait",
"stepName": "wait",
"task": "sp:sleep"
}
},
{
"type": "ActivityTaskCompleted",
"timestamp": "2024-06-11T15:33:40.138573175Z",
"attributes": {
"displayName": "Wait",
"result": {
"duration": "24h0m0s"
},
"stepName": "wait",
"task": "sp:sleep"
}
},
{
"type": "TimerStarted",
"timestamp": "2024-06-11T15:33:40.272923715Z",
"attributes": {}
},
{
"type": "WorkflowExecutionCancelRequested",
"timestamp": "2024-06-11T15:35:23.46517715Z",
"attributes": {}
},
{
"type": "TimerCanceled",
"timestamp": "2024-06-11T15:35:23.569605536Z",
"attributes": {}
},
{
"type": "WorkflowExecutionCanceled",
"timestamp": "2024-06-11T15:35:23.569609696Z",
"attributes": {}
}
]
If you are getting a 404 then that means you are using the wrong ID, an old execution ID (execution history is only saved for 90 days), or there is an issue with queued/cancelled items from an outage like this that prevent the history from being saved.
All of ours that we cancelled are returning 404s
Were they queued or executing? My demonstration above was for an executing workflow, but if yours were queued then I suppose they wouldn’t have any execution history.
These were queued, and sat for 2 days prior to us cancelling them.
Using PowerShell to call the API endpoints, this is one of the Workflow Executions in question:
id : e5fe2e25-c553-42a5-9ce6-b88c32a5a764
workflowId : 158f1118-fc2d-45b4-87de-6ebc035a2715
requestId : 3a091c25-a8df-451f-8a32-e614707a7231
startTime : 2024-06-10T13:06:42.735315654Z
closeTime :
elapsed :
status : Queued
I then tried to retrieve the execution history for that specific id value, and got a 404.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.