See also: Client workflows, Subscribe to message (Form)
Event action – Abstract
Purpose: This sends any message designated as a Payload to subscribers for a Topic referenced via a unique string.
Tooltip
Usage: The event action uses the Restrict to own session, Topic and (optionally) Permissions parameters to define which subscribers (assigned Client workflows or open forms with Subscribe to message (Form) elements in active sessions) should receive a Payload that can be defined as required. Whether/how the transferred data object is processed by the subscriber is determined by configurations there (Client Workflow, Behaviours).
Parameter:
The Restrict to own session option (unchecked by default) can only be selected to address subscribers within the same session in which the event action is triggered.
The Topic parameter is used to uniquely designate a 'channel' for push messages using a static or value configuration text value, which must be defined exactly the same in subscriber configurations in order for messages to be received.
The value configuration for the Payload parameter optionally defines the 'payload' of the message: an arbitrary data object that is passed to all legitimate subscribers for specific processing.
Optionally, requirements for the Permissions for relevant subscribers can be defined in the same way as for the Has permission rule type.
Note: The event action is only available in Event handling. Messages are always 'pushed' from the server to client sessions.
Warning: Extensive data objects (e.g. media files) should not be pushed as the Payload of a message, if possible, in order to improve performance.
The Push message event action sends any message known as a Payload to subscribers for a Topic referenced by a unique string.
â–ºNOTEâ—„ The message content defined as a Payload can technically be 'No value' ($null), a simple value (e.g. string, numerical value, etc.) or a complex data object with any desired structure. As the Payload data may have to be 'delivered' to a large number of sessions at the same time, sending large amounts of data (such as a media file or a 'large' document) should be avoided with a view to performance.
A subscriber is defined as all processes in client sessions connected to the Lobster Data Platform / Orchestration server that:
Are already being executed at the time the push message is sent,
Relate to the Topic in question,
Are affected by any criteria parameterized in the Push message event action (with the option Restrict to own session and requirements for Permissions – see section 'Configuration').
On the one hand, Subscriber processes can be Client workflows that are included in the menu structure of the relevant client session due to applicable Association criteria (possibly also with the 'Hidden' mode).
On the other hand, a 'subscription’ can be based on service elements of the Subscribe to message (Form) type placed in forms (Input forms, Portals, Dashboard) that are open in the relevant client session.
Whether and how the respective subscriber reacts to the arrival of a push message is determined by the assigned Event actions for Client workflows and for forms by the Behaviours triggered via the 'Receive message' Events (Form designer).
â–ºIMPORTANTâ—„ As long as no process (Client Workflow or Behaviours) is defined for a subscriber, no effect can be expected for the Push message event action in the relevant client session.
Configuration
No specific reference object is expected by the Push message event action. However, an existing reference object is available as an input value for value configurations in parameters.
Parameter | Description | Example |
|---|---|---|
Restrict to own session Option | The Restrict to own session option is defined in the user interface as a Check box element with two states:
|
|
Topic Text field/value configuration | The Topic parameter is used to uniquely designate a 'channel' for push messages using a text value:
The text value defined as a Topic must match exactly (case-sensitive) the character string in configurations for a subscriber to respond to the message. |
|
â–ºIMPORTANTâ—„ If a string image must be created from the return value of the value configuration for the Topic, this is done according to the server-side defaults because this corresponds to the execution context of the event handling. For example, the internal name ( | ||
Payload Value configuration | The Payload for the push message can optionally be defined via a value configuration, the return value of which is transferred directly (and not as a string image) to all relevant subscribers. In the example on the right, a list of text values ( |
|
Permissions Expandable element | Within the Expandable element for the Permissions parameter, the parameters for the Has permission rule type (see there for details) can optionally be used to link the delivery of a push message to permissions within a subscriber session for the Topic. In the example on the right, the view and create permissions for Documents have been selected via the Select Button, which, with the All must match option selected, must both be present in the subscriber session so that the push message can be received there. |
|
