Following types of workflows supported
Stream workflow, deploying pipeline, triggering pipeline (in repeatable workflows, they are often differently from deploying pipelines)
(each incarnation of workflow only executed once,
In TQL, each instance of a workflow (or process) can only be executed once. Repeatable workflows are represented as process streams where each process instance is a self-contained independent copy of the original workflow [definition] run with specific arguments.
1. Non-repeatable (single run, non-stream) workflows (used in AppFacets)
Such workflow is started immediately after compilation (it is deployed) and executes synchronously (in relation to the originating pipeline). That is the pipeline will wait until workflow completes. This precludes such workflow from waiting on any events.
(initial task(s) should start without waiting) - recommended
example Broadcast to a number of http end points concurrently
If it is waiting for a value, the whole pipeline will be waiting
2. Repeatable (multi-run, stream) workflows - usually used to process (sequence of) events
These are workflows which have while=”true” on one of its tasks (it must be the first task due to compiler limitation, needs to be "texally" first - the the order of appearance in your source code. All others can have it, but it does not matter). 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:
Default behavior is to be asynchronous (fire-and-forget) start (the originating pipeline does not wait, it continues)
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. (initial task(s) starts right away, make sure all inputs already have values assigned in your source code)
b) Externally-activated workflows
These are workflows which have explicit “event handler” (i.e. a special type of task with no inputs and no invokes) (output, "event"). Instances of these can be waiting for the external event to come and then start. other tasks can have the event handler outputs as their inputs
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. (wait for is not associated with any pipeline)
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. (event originator is within the workflow itself, waiting for pipeline operation to happen, such as a message from a device coming, or from a remote system coming, it is a synchronous execution on the pipeline. not an event handler) timeout