Creating a JMS Trigger

The JMS connection alias you want Integration Server to use to obtain connections to and receive messages from the JMS provider must already exist. Although a JMS connection alias does not need to be enabled at the time you create the JMS trigger, the JMS connection alias must be enabled for the JMS trigger to execute at run time.

If you use a JNDI provider to store JMS administered objects and the JMS provider is not webMethods Broker, the destinations (queues and topics) from which this JMS trigger will receive messages must already exist.

If the JMS provider is webMethods Broker or Software AG Universal Messaging, the destinations (queues and topics) from which the JMS trigger receives messages do not need to exist before you create the JMS trigger. Instead, you can create destinations using the JMS trigger editor. You can also create, modify, and delete durable subscribers via the JMS trigger. For more information, see Managing Destinations and Durable Subscribers on the JMS Provider through Designer .

If the JMS provider is Universal Messaging, administered objects can be created on demand. If you specify a destination that does not exist in the JNDI namespace and the JMS connection alias used by the JMS trigger is configured to create administered objects on demand, Integration Server creates the destination the first time the JMS trigger starts. For more information about creating administered objects on demand, see webMethods Integration Server Administrator’s Guide.

The transaction type of the JMS connection alias determines whether or not the JMS trigger is transacted (that is, it receives and processes messages as part of a transaction). Transacted JMS triggers have slightly different properties and operate differently than non-transacted JMS triggers. For more information about building a transacted JMS trigger, see Building a Transacted JMS Trigger.

The trigger service that you want to specify in the routing rule must already exist on the same Integration Server on which you create the JMS trigger. For more information, see Standard JMS Trigger Service Requirements.

A standard JMS trigger can contain multiple routing rules. Each routing rule must have a unique name. For more information about using multiple routing rules, see Building Standard JMS Triggers with Multiple Routing Rules.

A standard JMS trigger that contains an All (AND) or Only one (XOR) join can only have one routing rule and cannot have a batch processing size (Max batch messages property) greater than 1. A JMS trigger with an Any (Or) join can have multiple routing rules. For more information about batch processing, see About Batch Processing for Standard JMS Triggers.

5. In the JMS connection alias name field in the Trigger Settings tab, click

If a JMS connection alias has not yet been configured on Integration Server, Designer displays a message stating the JMS subsystem has not been configured. For information abut creating a JMS connection alias, see webMethods Integration Server Administrator’s Guide.

Select	To...
Standard	Create a standard JMS trigger.
SOAP-JMS	Create a SOAP-JMS trigger.

8. Under JMS destinations and message selectors, specify the destinations from which the JMS trigger will receive messages. For more information, see Adding JMS Destinations and Message Selectors to a JMS Trigger.

9. If you selected multiple destinations, select the join type. The join type determines whether Integration Server needs to receive messages from all, any, or only one of destinations to execute the trigger service.

Select...	If you want...
All (AND)	Integration Server to invoke the trigger service when the trigger receives a message from every destination within the join time-out period. The messages must have the same activation.
Any (OR)	Integration Server to invoke the trigger service when the trigger receives a message from any of the specified destinations. This is the default join type. Note: Using an Any (OR) join is similar to creating multiple JMS triggers that listen to different destinations. While a JMS trigger with an Any (OR) join will use fewer resources (a single thread will poll each destination for messages), it may cause a decrease in performance (it may take longer for one thread to poll multiple destinations).
Only one (XOR)	Integration Server to invoke the trigger service when it receives a message from any of the specified destinations. For the duration of the join time-out period, the Integration Server discards any messages with the same activation that the trigger receives from the specified destinations.