In TQL, each instance of a workflow (or process) can only be executed once. However, in many circumstances, you may want a workflow to be executed multiple times, for instance, the process to update an attribute value may needs to be repeated every time a sensor event comes in. Such "repeatable workflows" are represented as process streams where each process instance is a self-contained independent copy of the original workflow [definition] running with specific arguments.
Repeatable versus non-repeatable workflows
a. Non-repeatable (single-run, non-stream) workflows (used in AppFacets)
Such workflows runs for a single time and never repeats. If you do not specify the "While" modifier for the first workflow task, a workflow will run only once. (By default a task's while = "false".) Non-repeatable workflows should be started immediately after compilation (i.e. after it is deployed) without waiting for any events for it to be activated or continued. The originating pipeline, which instantiated the workflow, will wait until the workflow completes.
Examples of non-repeatable workflows are often used in AppFacets.
place holder for example of non-repeatable workflow
b. Repeatable (multi-run, stream) workflows
Such 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. They are usually used to process sequences of events. Repeatable workflows are defined by using the "While" modifier (While = "true") for its tasks. The originating pipeline, which instantiated the workflow, does not wait for the workflow (fire-and-forget).
While for first task
Due to the current compiler limitation, you must use While = "true" for the first task that appears in your workflow definition (source code) in order for the compiler to recognize that this is a repeatable workflow. You do not need to specify While = "true" for the subsequent tasks in the same workflow definition.
Non-waiting versus externally-activated workflows
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