Following types of workflows supported
1. Non-repeatable (single run, non-stream) workflows
Such workflow is started immediately after compilation and executes synchronously. That is the pipeline will wait until workflow completes. This precludes such workflow from waiting on any events.
Default behavior is to be asynchronous (fire-and-forget) start.
2. Repeatable (multi-run, stream) workflows
These are workflows which have while=”true” on one of its tasks (it must be the first task). These workflows are implemented as a stream (i.e. a sequence) of single-run instances which are called “process”, thus “stream of processes” or “process stream” terms. These fall into following categories:
a) Non-waiting workflows
Instances of these are started right after creation. They are only useful if they are doing something or communicating with some other entities [en-masse] which is difficult with non-repeatable workflows.
b) Externally-activated workflows
These are workflows which have explicit “event handler” (i.e. a task with no inputs and no invokes). Instances of these can be waiting for the external event to come and then start
c) Externally-continued workflows
These have an invoke with waitFor=”…” construct. Instances can start, work for a while and then suspend and wait for an event in the middle of task (on the waitFor). Once wait is completed they continue until next waitFor or process completion.
d) Internally continued workflows
These may look like a, b or c, but suspend on pipeline operation instead of event handler or waitFor. Conceptually it’s the same as waiting for a response after an HTTP request, only without actual request. RFID reader is an example. The process starts by itself (1, 2a) of by an external event (2b, 2c) and suspends on the pipeline operation. Once a “response” is received from the device, process continues to next wait or completion.