CentraSite Documentation : Runtime Governance with CentraSite : Run-Time Governance Reference : Built-In Run-Time Actions Reference for APIs : Run-Time Actions Reference : JMS Routing Rule
JMS Routing Rule
This action allows you to specify a JMS queue to which the Mediator is to submit the request, and the destination to which the native API is to return the response.
To use the JMS Routing Rule action, you publish multiple APIs for a single native API. For example, to make a particular native API available to clients over both HTTP and JMS, you would create two APIs for the native API: one that accepts requests over HTTP and another that accepts requests over JMS. Both APIs would route requests to the same native API on the back end.
Note:  
To make it easier to manage APIs, consider adopting a naming convention like the one shown above. Doing so will make it easier to identify APIs and the native API with which they are associated. Keep in mind however, that unlike native APIs, the names of APIs cannot contain spaces or special characters (except _ and -). Consequently, if you adopt a convention that involves using the name of the native API as part of the API name, then the names of the native APIs themselves must not contain characters that are invalid in API names.
To use this action the following prerequisites must be met:
*Create an alias to a JNDI Provider (in the Integration Server Administrator, go to Settings > Web Services).
*To establish an active connection between Integration Server and the JMS provider, you must configure Integration Server to use a JMS connection alias (in the Integration Server Administrator, go to Settings > Messaging > JMS Settings).
*Create a WS (Web Service) endpoint alias for provider Web Service Descriptor (WSD) that uses a JMS binder. In the Integration Server Administrator, navigate to Settings > Web Services and complete the Alias Name, Description, Descriptor Type, and Transport Type fields.
*Configure a WS (Web Service) endpoint trigger (in the Integration Server Administrator, go to Settings > Messaging > JMS Trigger Management).
*Create a WS (Web Service) endpoint alias for consumer Web Service Descriptor (WSD) that has a JMS binder. In the Integration Server Administrator, navigate to Settings > Web Services and complete the Alias Name, Description, Descriptor Type, and Transport Type fields.
*Additionally, in the proxy API's Message Flow area, make sure that you delete the predefined Straight Through Routing and HTTP Basic Authentication actions from the Receive stage. This is because, these actions are mutually exclusive.
For detailed information and procedures, see the webMethods Integration Server Administrator’s Guide.
Input Parameters
Connection URL
String. Mandatory. Specify a connection alias for connecting to the JMS provider (for example, an Integration Server alias or a JNDI URL). For example, a JNDI URL of the form:jms:queue:dynamicQueues/MyRequestQueue? wm-wsendpointalias=MediatorConsumer &targetService=vs-jms-in-echo
Note that the wm-wsendpointalias parameter is required for Integration Server/Mediator to look up the JMS consumer alias to send the request to the specified queue (for example, MyRequestQueue), which is a dynamic queue in ActiveMQ. Also, the targetService parameter is required if sending to another API that uses JMS as the entry protocol.
Reply to Destination
Optional. Specify a queue name where a reply to a message should be sent.
Priority
Enter an integer that represents the priority of this JMS message with respect to other messages that are in the same queue. The priority value determines the order in which the messages are routed. The lower the Priority value, the higher the priority (that is, 0 is the highest priority, and messages with this priority value are executed first).
*Priority values 0 through 10.
*The default priority for a JMS message is 0.
Time to Live
Optional. A numeric value (in milliseconds) that specifies the expiration time of the JMS message. If the time-to-live is specified as zero, expiration is set to zero which indicates the message does not expire.
The default value is 0.
Delivery Mode
Optional. The type of message delivery to the endpoint.
Value
Description
Persistent
The message is stored by the JMS server before delivering it to the client.
Non-Persistent
Default. The message is not stored before delivery.
What Happens if a Queue Includes Multiple JMS Messages?
To determine the order in which to execute the JMS messages in a queue, Mediator examines each message's Priority setting.
The Priority setting contains a non-negative integer that indicates the JMS message's priority. A priority value of 0 represents the highest possible priority.
Note:  
A JMS message's Priority property is used only when there are multiple JMS messages to route in the queue. If the queue has only one message to route, the Priority property is ignored entirely.
When a queue includes multiple JMS messages, Mediator routes the messages serially, in priority order from lowest to highest (that is, it routes with message the lowest priority value first). Each messages in the queue is routed to completion before the next one begins.
If two or more messages have the same priority value, their order is indeterminate. Mediator will route these messages in serial fashion after all lower priority messages and before any higher priority messages. However, you cannot predict their order
Example
If Mediator were given the following JMS messages to route for an API:
JMS Message
Priority
JMS Message A
11
JMS Message B
25
JMS Message C
11
JMS Message D
0
It would route the messages in the following order:
JMS Message
Priority
JMS Message D
0
JMS Message A then JMS Message C (or vice versa) The order of these two messages cannot be controlled or predicted because they have the same priority.
11
JMS Message B
25
Copyright © 2005-2016 Software AG, Darmstadt, Germany.
Product LogoContact Support   |   Community   |   Feedback