Workflows and transaction processing
The SOAR Platform uses transaction processing to divide work into individual and indivisible operations called transactions.
All API methods and background jobs (such as artifact rescanning) use transactions. When an API method or background job causes a workflow operation to be initiated, the workflow becomes part of the transaction. It includes, but is not limited to any subworkflows that might start or run, functions that are started, scripts started, or messages sent to message destinations. If any failures occur in a workflow (such as an error in a script), the transaction fails and the API request or background process is aborted. When it happens, all effects of the workflow transaction are undone and the workflow is left in its previous state, if it is running at all.
When all workflows in a transaction enter a wait state and all other transaction operations complete, the transaction ends. A subsequent API operation causes the workflow to exit the wait state and proceed as part of that API operation's transaction.
- Encountering an open task, where the workflow inserted a task or one previously existed and remains open.
- Posting to a message destination where Expect Acknowledgement is enabled.
- Calling a function.