Push message

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.

images/download/attachments/177905205/image-2024-12-17_17-50-45-version-1-modificationdate-1734454245206-api-v2.png

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:

  1. Are already being executed at the time the push message is sent,

  2. Relate to the Topic in question,

  3. Are affected by any criteria parameterised 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:

  • If the option is unchecked (default), the Payload is transferred to relevant subscribers in all active sessions.

  • If this option is checked, only relevant subscribers within the session receive the Payload in which the Push message event action is executed.


images/download/attachments/177905205/image-2024-12-17_17-53-41-version-1-modificationdate-1734454421255-api-v2.png


images/download/attachments/177905205/image-2024-12-17_17-53-24-version-1-modificationdate-1734454404244-api-v2.png

Topic
Text field/value configuration


The Topic parameter is used to uniquely designate a ‘channel’ for push messages using a text value:

  • A Text field element appears by default, which can be used for the direct input of static text.

  • Alternatively, a value configuration can be defined (by clicking on the small grey arrow at the bottom left of the Text field) whose return value is a string or is converted into a string.

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.

images/download/attachments/177905205/image-2024-12-17_17-54-3-version-1-modificationdate-1734454443038-api-v2.png

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 (name) is returned instead of a dynamic enumeration value. Within client workflows that are qualified as subscribers for the same Topic, the same value configuration may return a different string image depending on the data type of the return value. For example, the localisation applicable in the client is provided for a dynamic enumeration value, which is generally not identical to the internal name. The risk of a ‘misunderstanding’ when assigning push messages to subscribers can be minimised by explicitly setting up value configurations for the sender and the subscriber that reliably deliver matching strings. For the example in the image, the Object property value resolver clarifies that the internal name (name) for the Country from the ‘Country’ (countryCode) address field of the Company of session is used as the Topic. For a company address in Switzerland, the character string CH would be assigned as the Topic.

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 (String[]) from a variable is assigned as a Payload, which different subscribers can process in a specific form.


images/download/attachments/177905205/image-2024-12-17_17-54-29-version-1-modificationdate-1734454469182-api-v2.png


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.

images/download/attachments/177905205/image-2024-12-17_17-54-55-version-1-modificationdate-1734454494682-api-v2.png