Signals

Signals can be local or global. Local signals are thrown and caught within a single process instance. Independent processes may need to collaborate through swapping events and data when you have more than one inter-related process with an interest in the same thing. Global signaling provides an inter process version of the signaling capability, with the capability to pass data as a payload.

Local signals are thrown and caught within a single process instance. They can be used for triggering event handlers, task cancellations and to halt and resume parallel flows.

Global signals are thrown and caught across process instances allowing processes to collaborate with each other.

Note: Global signals are defined separately in Global Signal Definition Projects. See Creating a Global Signal Definition Project.

You can throw (publish) a global signal and it can be caught by subscribing events in more than one process. You can also throw a global signal which will be available for a define period of time. During that time any processes that subscribe to the signal with the required correlation data will catch the signal. However the signal does not "go away" if it is caught by a single process during that period of time.

A global signal can be published from anywhere and consumed by multiple processes so you need to identify the process instances that are waiting for a particular instance of a global signal. You define signal correlation data that will identify the process instance waiting for the global signal. Data and parameters from the signal that are used for correlation are defined in the signal specification.

As global signals do not specifically belong to either the publisher or consumer of the signal (signals may be published and consumed from multiple locations), they are defined separately from where they are used or referenced (in the Global Signal Definition project).

Global signals have a data payload. Payload data is defined in the Global Signal Definition project.

Catching of global signals is supported from event handlers and event sub-processes, and is supported from within business processes. Throwing of global signals is supported from business processes, service processes, pageflows and business services.

Correlation parameters are defined in the global signal specification and all subscribers to a particular signal will use these parameters to identify the global signal instances of interest. Correlation mappings in the catch global signal specify the process instances that should receive the event (those whose mapped correlation data value matches the signal payload correlation value at runtime). Global signals may correlate immediately or correlate with process instances for a period of time after they have been generated.

A transitory global signal will only exist for the period of time it takes to identify the set of process instances that are waiting/attempting to correlate with this signal instance. As soon as the currently waiting process instances have received the global signal it is destroyed.
For persistent signals, after the signal has been generated it will exist for a defined period of time and correlate with any global catch signals that try to correlate with it during that period, in addition to those waiting when the signal was generated. When the period expires, the signal is purged.

Note: Correlation data payload changes are not permitted on Global Signal project upgrade. Therefore signal correlation parameters cannot be changed unless the major version is changed.

Note: The number of process instances pending on a particular global signal with the same correlation data values is limited to 100. If more than this number attempt to correlate to the global signal using the same correlation data values, then an error is generated for each of the further attempts, and the attempt to initialize the signal handler for the defined correlation data in that process instance will fail.

Subtopics