A worker is a node that can respond to requests forwarded to it from a channel.
A worker must support a process and have a Process identifier field from which an identifier for the process instance can be read.
The Worker type provides a suitable node type for a worker.
Suitable name for the process, such as "Supplier survey".
|Process type name||
Name for the process type.
|Process type reference||
A reference for the type of the process.
Unique identifier for this process, shared between all the workers that collaborate on the process.
Indicates if the worker is active. If it is inactive, it will reject all requests from the partner.
Indicates that this worker is of interest, typically because there is an action or there has recently been a significant activity.
Indicates that action is required for this worker.
Indicates that the worker owns the process.
DEPRECATED - this is not used for anything.
|Last activity timestamp||
Date and time of the last significant activity.
Status of the worker's process.
If this has a / in it, then the value before the slash is the status from the processing point of view, and the bit after the / a display version, e.g. "sentToSupplier/Sent to the supplier".
Latest message associated with this worker process.
The channels to which this worker is connected. Each has a role.
Defines a process.
|Status rules definition||
Definition of status rules.
Groups in which the worker is displayed.
This is typically built from a group in which the worker was created and a derived list of groups that represent the different connections that the worker has. The first group in the list, typically the one in which the group was created, is know as the "primary group".
When set on a worker, indicates that the worker should not automatically be included in the connection groups of the connections that are associated with the worker.
When set on a group, provides a default for the value used when creating new workers in that group, i.e. makes workers in that group private to the group.
Most processes will need to access data and record events. By convention, the worker will contain two sub folders: an events sub folder that holds events, and a data sub folder that holds data. The events use the Event data type. This holds the event timestamp, event type, a suitable description, an indication of the new worker state set by the event, and an options field to hold data related to the event. Data is held in nodes of type Data.
Note that the state and the process type are just strings and (unlike other solutions) not links to nodes. This is to allow different parties to run the processes without the need for application-specific status nodes.
The Dynamic Worker type works the same as a normal worker, but it maintains a link to a process node and status rules node, and derives its process and status rules from these. This can be useful for long-running workers, where there may be a need to update these. Dynamic Worker nodes cannot be created when sending a process to a partner.
Worker processes can do anything. However, processes sent to other parties are by default limited to the step types in Standard step types, which are considered sufficiently safe to be accepted in processes sent from external parties.
Some worker action names have special meanings, typically denoted by an @. As well as those built into the process engine (@start, @end, @default, @error), @init is by convention used to initialise a process, and @display is used by the process client to replace the standard view of a worker (which shows events and available actions) with an invocation of the @display action. This can be used to provide a different UI within the process client.
When @display is used, the step will by default redirect back such that the display is closed. Setting the steps' config.redirectToSelf property to true will instead redirect the step back to itself. This can be used for display steps that have multiple actions (in the same way that the default display has multiple actions).