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.
Name |
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. |
Process identifier | Unique identifier for this process, shared between all the workers that collaborate on the process. |
Worker active | Indicates if the worker is active. If it is inactive, it will reject all requests from the partner. |
Of interest | Indicates that this worker is of interest, typically because there is an action or there has recently been a significant activity. You could consider this as an "unread" indicator, which tends to be how it is used. |
Action required | Indicates that action is required for this worker. |
Process owner | 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 | 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". |
Message | Latest message associated with this worker process. |
Connections | The channels to which this worker is connected. Each has a role. |
Process definition | Defines a process. |
Status rules definition | Definition of status rules. |
Folders | 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". |
Private | This controls whether a connection group should be added to the list of groups for a worker when the worker uses the connection. When set on a worker, indicates that the worker should not include connection groups in its list of groups. This makes the worker "private" in the sense that you cannot navigate from the connection group to the worker. When set on a connection group, indicates that the connection group should never be added to the list of groups for a worker. Does not apply to a group that is not a connection 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).