JMS Trigger

Know the trigger and how to use it.

Micaella Mazoni avatar
Written by Micaella Mazoni
Updated over a week ago


JMS Trigger requires a dedicated infrastructure. Due to security matters, when you use the trigger for the first time, make an activation request to our support team through the chat. 


To use this trigger, it's necessary to get in touch with our Support Team to obtain the liberation.

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.

Commit with delivery guarantee

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:

  • ActiveMQ

  • Oracle Advanced Queue

  • Tibco EMS

  • SQS

  • IBM MQ

 
Take a look at the configuration parameters of the trigger:   

Active MQ and Tibco EMS

  • Connection String: JMS connection string in the format tcp://{host}:{port}

  • Destination: name of the QUEUE/TOPIC which you need to send some message to.

  • Name of the QUEUE or TOPIC: single name given to the queue.

  • 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.

    

SQS

  • 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.

  • Destination: name of the QUEUE/TOPIC which you need to send some message to.

  • Name of the QUEUE: single name given to the queue.

  • Set Client ID: property specifically used by a JMS provider to identify the client JMS connection and allow it to be durable.

  • Maximum Timeout: inform the maximum execution time of the trigger.

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.

Oracle AQ

  • hostname: name of the JMS connection string host.

  • port: access port number to Oracle server.

  • sid: Oracle’s database instance name.

  • jdbcDriver: Oracle jbdc driver (eg.: THIN or OCI).

  • Destination: name of the QUEUE/TOPIC which you need to send some message to.

  • Name of the QUEUE or TOPIC: single name given to the queue.

  • 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.

IBM MQ

There's still no support for the authentication using TLS.

  • Hostname: string JMS connection host name.

  • Port: number of the access port to the Oracle server.

  • Channel Name: name of the channel to be used in the broker communication.

  • Queue Manager: name of the IBM MQ queue manager.

  • Destination: name of the QUEUE/TOPIC which you need to send some message to.

  • Name of the QUEUE or TOPIC: single name given to the queue.

  • 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.

If you want to deploy the trigger, it's necessary to publish the pipeline.

Check how to do it:

- Click on "Runtime", 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 concurrent executions configured when deploying the pipeline will be exactly the same for the JMS queue/topic.

Therefore, if 10 concurrent executions are configured in the deploy, 10 concurrent executions 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 concurrent executions can be created.

Formerly, there was only one concurrent execution per trigger.
​                  

IMPORTANT: if you deploy a pipeline with JMS Trigger attached to a topic, it will be necessary to configure just one concurrent execution when making the deploy.

Did this answer your question?