The domain of the workflow: AWS docs as well as the README
The id of your particular workflow. See "WorkflowType" in the AWS docs as well as the README.
You can version workflows, although it's not clear what purpose that serves. Advice: just think of this as an administrative notation. See the README.
If you execute the same workflow in different environments, use different task lists. Think of them as independent sets of actors working on the same logical workflow, but in different contexts (like production/qa/development/your machine). AWS docs as well as the README
The AWS SWF client
How long to let the entire workflow run. This only comes in to play if 1) The decision threads die or 2) A step gets into an "infinite loop" in which it always returns InProgress without making any actual progress. The default is set to one month on the assumption that you'll monitor the workflow and fix either of those problems if they occur, letting the workflow resume and complete. If you prefer to let the workflow fail, you'll want to set it lower.
How long to keep _completed_ workflow information. Default: one month.
The duration you expect to pass _after_ a task is scheduled, and _before_ an actionWorker picks it up. If there is always a free actionWorker, this is just the polling interval for actions to execute. If all the actionWorkers are busy, though, the action may time out waiting to start. This isn't harmful, though, since the decisionWorker will simply re-schedule it. Advice: make your actionWorker pool large enough that all scheduled work can execute immediately, and set this timeout to the polling interval for action work. Default: 60s
See InputParser
List all the events from an execution of a workflow.
List all the events from an execution of a workflow.
The particular workflow id to list events for
The particular run of the workflow id to list events for
Use this method to generate signals for use with the Wait result
Use this method to generate signals for use with the Wait result
The format of the signal is publicly documented as 3 pipe-delimited fields with workflowId,runId, and a unique signal name.
a signal token for passing to Wait and for calling signalWorkflow with.
List all the executions for this domain, workflow, and workflowId within the time window.
List all the executions for this domain, workflow, and workflowId within the time window. (regardless of version)
Start time to search
End time to search
The particular workflow id to list executions for
an unmodifiable list of matching executions
List all the executions for this domain and workflow within the time window.
List all the executions for this domain and workflow within the time window. (regardless of version)
Start time to search
End time to search
an unmodifiable list of matching executions
Register the domain,workflow,and activities if they are not already registered.
Register the domain,workflow,and activities if they are not already registered. If you have marked any of these as DEPRECATED through the SWF api, this method will throw an exception telling you to delete the relevant config first.
Use this method to send a previously generated signal to the workflow that generated it.
Submit/start a workflow execution.
Submit/start a workflow execution.
A unique identifier for this particular workflow execution
Whatever input you need to provide to the workflow
tracking information for the workflow
This is where you register and start workflows.
In SWF, there are domains, workflow types, activities that need to be registered. You provide all the config we need for activities in the StepEnum. You give the parameters for domain and workflow type here.
This class is implemented so that you can call registerWorkflow() every time your app starts, and we will register anything that needs to be registered, so you should be able to manage your whole workflow from this library.
The enum containing workflow step definitions