...
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
place holderplaceholder for example of non-repeatable workflow |
...
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. Most workflows used in ThingFacets (to interact with things) are repeatable workflows. The originating pipeline, which instantiated the workflow, does not wait for the workflow (fire-and-forget).
...
Non-waiting versus externally-activated workflows
a. Non-waiting workflows
Instances of these such workflow are started right after creationthey are created. This is done by ensuring that all the input values of the workflow's initial task(s) have their values assigned in your source code (versus waiting for external events to give value). 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
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
Placeholder for example of non-waiting workflow |
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 workflows wait for the external event to come and then start . other tasks can have the event handler outputs as their inputs c) ("external" here means external to the workflow itself). The "event handler" is written as "Event" in the workflow definition. In ThingFacet (and AppFacet) workflows, the Event is typically the ActionArgument, which is triggered by the modification of actionable attributes of the model facet.
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
Placeholder for example of externally-activated workflows. |
Externally-continued versus internally continued workflows
a. Externally-continued workflows
These have an invoke with waitFor=”…” constructthe WaitFor modifier. Instances of such workflows 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 the next waitFor 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(The "external" here means external to the workflow itself).
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
Placeholder for example of externally-continued workflow |
b. Internally continued workflows
Instances of these workflows suspend on pipeline operations. Conceptually it’s the same as waiting for a response after an HTTP request, only without the actual request. RFID reader is an example. The process starts by itself (1, 2a) of itself or by an external event (2b, 2c) and , but then suspends on the pipeline operation. Once a “response” is received from the device, the process continues to the next wait suspension 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) timeoutThe "internal" here means the pipeline operations is internal to the workflow itself. "Internal" is not related to the source of the "response". For example, the response may come from a device outside the application.
In such workflows, it is a good practice to have a Timeout modifier on the workflow.
| Expand | |||||
|---|---|---|---|---|---|
| |||||
|