eFTL Message Subscriber Trigger

The eFTL Message Subscriber trigger listens for a published message from the TIBCO eFTL service.

Important: See the outlined in the Overview section before using this trigger.
Note: This trigger supports engine-level flow limiting. For more information on engine-level flow limiting, see Flow Limit.

Trigger Settings

The Trigger Settings tab has the following fields:

Field Description
Connection Name of the TIBCO eFTL connection.
Send Reply Enables sending replies for received messages on the subscription side. When enabled, the trigger sends a reply message based on the configured Reply Settings and Content Matcher. By default, this field is set to false.

When set to true, the Reply Settings and Map from Flow Outputs fields become available.
Durable Subscriber By default, this field is set to False. Setting this field to True changes the subscriber to a durable subscriber. As a durable subscriber, if the app goes down, any incoming messages during the period when the app was down are preserved and delivered once the app comes back up again.
Note: A trigger marked as a durable subscriber should have been running at least once for it to receive pending messages that were sent while the app was down.

When this field is set to True, the following fields are displayed:

  • Durable Name: Enter a name for the subscription. This is a required field.
  • Durable Type: The following durable types are supported:
    • Shared- For multiple instances of an app, the messages received are distributed among the app instances in a round-robin manner.
    • Standard- For every unique instance of an app, all the apps receive all the messages. The messages are not distributed.
      Note:
      • In a single app, the same connection cannot be used for two or more TIBCO eFTL MessageReceiver triggers and two or more handlers in a single trigger for the Standard durable type. To configure the Standard durable type for two more triggers or handlers, create different connections.
      • In container deployment, if an app is scaled to more than one instance only the last instance receives all messages.
  • Message Ack Mode: The following acknowledgment types are supported:
    • Auto- In this mode, messages are auto acknowledged as soon as they are received from TIBCO eFTL. In case of failure in business logic, the messages are not redelivered.

      Use this mode if message redelivery is not preferred.

    • Explicit- In this mode, the message received by the eFTL Message Subscriber Trigger must be explicitly acknowledged within the flow by using the eFTL MessageAck activity. Any unacknowledged messages are re-delivered to the new durable subscriber configured with the same durable name.
Destination Name of the message destination. If this field is left blank, then it receives all the messages. If not, it only receives the messages with the specific destination set.
Processing Mode

The trigger processes the messages in one of the following modes:

  • Sync- The Sync mode is the default mode. The handler receives and processes only one message at a time. This mode guarantees the processing order of the messages.
  • Async- The handler receives messages concurrently. This mode does not guarantee the processing order of the messages. The total concurrent messages handled by the trigger are based on the type of the engine runner. You can set the engine runner type by using the FLOGO_RUNNER_TYPE variable. The following values are supported:
    • POOLED: The total concurrent messages handled by the trigger handler. To achieve higher concurrency, set FLOGO_RUNNER_WORKERS to a higher value.

      For an app, the total number of messages processed concurrently is equal to the number of trigger handlers configured with async processing multiplied by FLOGO_RUNNER_WORKERS. For example, if two TIBCO eFTL trigger handlers are configured with async mode and FLOGO_RUNNER_WORKERS is set to 10, 20 messages would be processed concurrently at a given time.

    • DIRECT: Currently, 200 concurrent messages are handled by the trigger handler.

      For an app, the total number of messages processed concurrently is equal to the number of trigger handlers configured with async processing multiplied by 200. For example, if two TIBCO eFTL trigger handlers are configured with async mode then 400 messages would be processed concurrently at a given time.
Enable Flow limit Enables flow limiting for the trigger. When enabled, the trigger limits the number of messages processed concurrently. This field is app property enabled and the default value is false.
Note: This field is available only when the trigger processing mode is set to Async.
Note: This is a trigger-level Flow limit feature. When enabled, the trigger processes messages concurrently up to the number specified in the Maximum concurrent messages to be processed field. At any given point, the trigger processes that many messages concurrently. As soon as a message finishes processing, the trigger picks up another message, maintaining the concurrency level until all messages are processed.
For example, if Maximum concurrent messages to be processed is set to 200 (default), the trigger begins processing 200 messages concurrently. When one of those messages completes, the trigger immediately picks up the next available message, ensuring that up to 200 messages are always being processed concurrently until there are no more messages remaining.
Note: It is not a best practice to use engine-level and trigger-level flow limiting together. When engine-level flow limiting and trigger-level Flow limit both are enabled, engine-level flow limiting takes precedence over the trigger-level Flow limit settings.
Maximum concurrent messages to be processed Specifies the maximum number of messages to process concurrently. This field is app property enabled and the default value is 200.
Note: This field is available only when the trigger processing mode is set to Async and Enable Flow limit field is set to true.
Content Matcher

To specify the attributes that match the incoming message click Add row. For each attribute, specify its name, type, and value.

Note:
  • You can configure the app property for Content Matcher. The value of the property must be a valid JSON object in the format: {"k1": "v1", "k2":"v2"}
  • For the Boolean data type content matcher (dynamic), messages are received for both true and false values
Important: You cannot have two subscribers with the same durable name but different destinations running concurrently. You must stop the subscriber that was already running before you start the second subscriber. This is also true for blue-green deployments supported by PaaS platforms, such as TIBCO Cloud Integration. So, do not update the destination name in blue-green deployments.

Output Settings

The field selected on this tab is available in the output schema of the Map to flow Inputs tab.

Field Description
Message Schema An example JSON object that you want to receive from the TIBCO eFTL service.

Map to flow Inputs

This tab displays the schema specified on the Output Settings tab in a tree structure format. The output of a trigger is displayed for informational purposes only and cannot be modified or altered.

The properties that are displayed on the Output tab schema correspond to the output of this trigger and can be used as input by subsequent activities in the flow.

The Map to flow Inputs tab has the following fields:

Field Description
message The message field is preconfigured to map the trigger output to the flow input.
metadata

The metadata includes the following details:

• messageId: The ID of the message
• deliveryAttempt: The number of times the message delivery is attempted by the message service. This field can be used to identify duplicate messages.

Reply Settings

The field selected on this tab is available in the reply schema of the Map from flow Outputs tab.

Field Description
Reply Message Schema An example JSON object that you want to send to the TIBCO eFTL service.

Map from flow Outputs

The Map from flow Outputs tab has the following field:

Field Description
Reply message Use this field to compose the response sent back to the client.