JMS Trigger
Know the trigger and how to use it.
Let's say you want to use a trigger to make a subscription in a message queue. That way, you'll be able to trigger a pipeline that enables the consumption of one message at a time.
With the Auto Commit property disabled, it's possible to give the message ack only after the well succeeded pipeline execution. For the IBM MQ broker, it's necessary to keep this field enabled at all times, because it's not supported to control the message ack or reject.
The supported queues are:
- Oracle Advanced Queue
- Tibco EMS
- SQS
- IBM MQ
Take a look at the configuration parameters of the trigger:
- Account: sets the account which will be used by the trigger.
- Auto Commit: when enabled, the JMS’s auto commit strategy will be used. Otherwise, the manual commit will be used.
- Destination: sets the destination (Queue or Topic).
- Name of the Queue or Topic: single name given to the selected Queue or Topic.
- Which JMS Provider Will Be Used: sets the selected queue (Oracle Advanced Queue, Tibco EMS, SQS or IBM MQ). Depending on the queue, different parameters can be accessed:
- Hostname: name of the JMS connection string host.
- SID - Oracle Site Identifier: Oracle’s database instance name.
- Port: access port number to Oracle server.
- JDBC Type: Oracle jbdc driver (eg.: THIN or OCI).
- Durable Subscriber: message consumer that receives all the messages published in a topic, including the ones published while the subscriber is inactive; when this option is activated, it's necessary to inform the specific subscriber name in the "Subscriber Name" field.
- Set Client ID: property specifically used by a JMS provider to identify the client JMS connection and allow it to be durable.
- Message Selector: if your application needs to filter the received messages, you can use a JMS API messages selector, that allows the messages consumer to specify which of them matter - the message selector assigns the filter process to the JMS provider.
- Maximum Timeout: inform the maximum execution time of the trigger.
- Allow Redelivery of Messages: if activated, the option allows messages to be delivered again if the Pipeline Engine fails.
- Connection String: JMS connection string in the format tcp://{host}:{port}
- Durable Subscriber: message consumer that receives all the messages published in a topic, including the ones published while the subscriber is inactive; when this option is activated, it's necessary to inform the specific subscriber name in the Subscriber Name field.
- Set Client ID: property specifically used by a JMS provider to identify the client JMS connection and allow it to be durable.
- Message Selector: if your application needs to filter the received messages, you can use a JMS API messages selector, that allows the messages consumer to specify which of them matter - the message selector assigns the filter process to the JMS provider.
- Maximum Timeout: inform the maximum execution time of the trigger.
- Allow Redelivery of Messages: if activated, the option allows messages to be delivered again if the Pipeline Engine fails.
- Connection String: JMS connection string in the format https://{REGION_ENDPOINT}/queue.|api-domain|/{YOUR_ACCOUNT_NUMBER}/{YOUR_QUEUE_NAME}
- Region: AWS region where the queue is installed.
- Set Client ID: property specifically used by a JMS provider to identify the client JMS connection and allow it to be durable.
- Message Selector: if your application needs to filter the received messages, you can use a JMS API messages selector, that allows the messages consumer to specify which of them matter - the message selector assigns the filter process to the JMS provider.
- Maximum Timeout: inform the maximum execution time of the trigger.
- Allow Redelivery of Messages: if activated, the option allows messages to be delivered again if the Pipeline Engine fails.
IMPORTANT: Visibility Timeout in Broker SQS must have a value equal or greater than the timeout of the pipeline. That's necessary, because Broker SQS is a distributed system and doesn't delete the message after its consumption, since there's no guarantee that's actually been consumed. If the Visibility Timeout isn't configured in the mentioned conditions, a message under processing can be resent. Broker SQS sends the message again if it doesn't receive ACK or REJECT within the time configured in Visibility Timeout. To understand it better, click here.
There's still no support for the authentication using TLS.
- Hostname: string JMS connection host name.
- Channel Name: name of the channel to be used in the broker communication.
- Queue Manager: name of the IBM MQ queue manager.
- Port: number of the access port to the Oracle server.
- Durable Subscriber: message consumer that receives all the published messages in a topic, including the ones published when the subscriber is disabled; when this option is enabled, it's necessary to inform the specific name of the subscriber in the Subscriber Name field.
- Set Client ID: property specifically used by a JMS provider to identify the client JMS connection and allow it to last.
- Message Selector: if your application needs to filter the received messages, you can use a JMS API message selector, which allows the message consumer to specify which one of them matters - the message selector repasses the filtering to the JMS provider.
- Maximum Timeout: maximum time for the trigger execution.
- Allow Redelivery of Messages: if activated, the option allows messages to be delivered again if the Pipeline Engine fails.
If you want to deploy the trigger, it's necessary to publish the pipeline.
Check how to do it:
- Click on "Run", located in the superior part of the screen.
- Select the environment, which can be test or prod.
- Click on "Create a new implantation".
- Select the pipeline with its version and capacity.
- Click on "Confirm".
When triggered, the pipeline will receive a payload similar to the following one:
{
"data":"mensagem"
}
- data: content of the message sent
JMS Trigger supports the consumption of messages in a parallel way - the number of consumers configured when deploying the pipeline will be exactly the same for the JMS queue/topic.
Therefore, if 10 consumers are configured in the deploy, 10 consumers will be created for the JMS queue/topic.
That increases the throughput consumption of the messages, besides allowing the user to have control over how many simultaneous consumers can be created.
Formerly, there was only one consumer per trigger.
IMPORTANT: if you deploy a pipeline with JMS Trigger attached to a topic, it will be necessary to configure just 1 consumer when making the deploy.
Last modified 5mo ago