Send process

The role of the partner to which the process should be sent. This would typically be something like "respondent" or "supplier". Required.

Name for the newly-created worker. Defaults to the name of the sending worker.

If set to true (the default), send the process identifier from this worker. If set to false, do not send a process identifier. Otherwise, send the given value as the process identifier.

If set to true or omitted, this means that the partner's new worker will be paired with the originating worker. In this case, the role will be passed to the new worker to keep track of its role in the process. The role is not passed if a different process identifier is sent.

Process definition. Required.

This can contain a placeholder of the form ${processDefinition:binding}, where binding is a binding reference in the process definition. The process definition of the bound node will be resolved and copied by the worker instantiator.

Reference for the process type. Optional. If neither processTypeReference or processTypeName is passed in config, use those from the worker.

Name of the process type. Optional. If neither processTypeReference or processTypeName is passed is config, use those from the worker.

Set to true to register this worker with the channel through which the process is sent.

Workers are often registered with channels when the worker is created with the connections, but in other cases may need to be registered with the channel when the connection is made later.

Re-registering a channel has no effect, so if in doubt, set register to true.

When registering the new worker at the other end of the channel, allow it to overwrite an existing registration for the same process identifier and role. Note that role must be set and must not be owner.

This applies to the newly-created worker, not the sending worker.

Where within the recipient to create the new process relative to the originating connection's group. Defaults is to create it directly within the originating connection's group.

This is resolved to an array of objects with reference and name which can be used to navigate and if necessary create groups inside the recipient's connection group, such as the following which would create the new process in the projects/beta sub group, with names of Projects and Beta (names are only used if the groups need to be created in the recipient.)

[
  {"reference":"projects","name":"Projects"},
  {"reference":"beta","name":"Beta","config":{"icon":"fa fa-aeroplane"}}
]

If not given, name defaults to reference, and reference defaults to a normalized version of name.

A config property is also permitted. See New worker for details.

A path can be built to match the path of the primary group that contains the worker, i.e. the originator's path can be used as the basis for the recipient's path. In this case, the path may use and must start with a special element, which is "/" (for root group), "." (for current group) or ".." (for parent group) - though stating with "/" has no effect (it is the same as the default, making the path absolute). The originator's path is resolved and then the full path (relative to the root) is passed on. The relative root is not passed on - all paths that arrive at the recipient end are relative to the connection group of the originator.

If the recipient's connection group is within the path, then the path is resolved to be relative within the recipient's connection group. For example, if you are "Universal Imports", and the worker's primary group is "/Suppliers/ACME Limited/Orders", and you specified a path of ".", this would first be resolved to "/Suppliers/ACME Limited/Orders". Assuming "ACME Limited" is the connection group for the recipient, then this would be further resolved to "Orders". Within the recipient, assuming the connection group was "/Customers/Universal Imports", the incoming path would then resolve to "/Customers/Universal Imports/Orders", which is exactly what you would expect.

Be cautious of using a relative path when the worker has not been explicitly created in a project.

When building a path, you can, in place of the full form, use an array of strings or a slash-delimited string of path references. When a single string is used, it is considered to be the name, and a normalized version of it considered to be a reference. If the references have special characters (other than A-Z, 0-9 and underscore), then you must pass the path using an array of objects to prevent normalization of the references.

Reference from which data should be read. This can be used to pass data from a data node, rather than from a request parameter. Use this to send data from one party to another. dataReferenceFrom is ignored if the initData property is set. (Deprecated - better to use an initData value of %{data:dataReferenceFrom}.

Whether to replace runtime placeholders in the config. This additional control is required because the process definition may have runtime placeholders in it that should be preserved.

If omitted or set to a false-like value, no placeholders are replaced.

If set to true, runtime placeholders in %{..} sequences are replaced.

If set to a different character, that is used for runtime placeholders

By convention, if the process definition has runtime placeholders that should be preserved, the placeholders property is set to "@", and then runtime placeholders for all config items that need to replaced (not just the process definition) should be preceded by "@". This means that %{..} runtime placeholders in the processDefinition are not accidentally replaced.