Synchronous IBM WebSphere default messaging

The synchronous IBM® WebSphere® Default Messaging transport nodes allow request and response operations using JMS queues and topics. If the response is not received within a defined period, an exception is thrown.

Identification of appropriate response messages is done with a header field named MESSAGEID. When the request message is put into the queue or topic, the MESSAGEID header is set to a unique value based on the current time and a counter. The response headers must have this same message ID in order for it to be picked up and processed correctly.

Configuration properties

The following are the properties of this node:

Table 1. Synchronous WAS default messaging properties
Property Description
Runtime Tab
Provider URL Enter the provider URL of the JMS implementation used. URL to use for JNDI lookups using the IBM WebSphere Default Messaging JMS:

corbaloc::<DNS Server Name or IP Address>:<bootstrapport>

For clustered JMS configurations, use a comma-separated value comprising the host/IP and port of each node in the cluster. For example, for IBM WebSphere Default Messaging JMS, enter the URL as: corbaloc::<DNS Server Name or IP Address>:<bootstrapport>,<DNS Server Name or IP Address>:<bootstrapport>.

Initial Context Factory The class name of the initial context factory. This is the starting point for the resolution of names for naming and directory operations.

Select synchronous WebSphere MQ if you are using MQSeries® accessed through an IBM WebSphere corbaloc URL. This sets the class name to IBM corbaloc::<DNS Server Name or IP Address>:<bootstrapport>.

Connection Factory Enter the connection factory name. This is used to retrieve the connection factory from JNDI. A client uses a connection factory to create connections with a JMS provider. Enter unique identifier for the connection factory. This name must be the same as that configured in the WAS administration console.
Needs Compression Select this option if the message needs to be compressed.
Enable JMS Security Check this box if you want JMS Security to be enabled. Once checked, the JMS Security Properties tab is enabled to configure destination and/or JNDI based JMS security.
Request Tab
Destination Name Enter the name of the queue or topic to which the request message is sent.
Header Name The name of the message header. For example, APINAME.
Note: The header name must be unique. Two headers cannot have the same header name.

Choose the Create New icon to add a new header name and value.

Choose the Details icon to modify an existing header name and value.

Choose the Delete icon to delete an existing header name and value.

Header Value The value associated with the Header Name. These name-value pairs are stored as message headers and can be queried by using message selectors.

This can be set to a static value. For example, ‘createOrder' results in the message having a header APINAME=createOrder'.

It can also be set to be dynamically extracted from the message using the syntax, xml://<full path of the element from root>/@<attribute name>, which results in the message with a header APINAME='<value of attribute name in the XML>'.

Response Tab
Destination Name Enter the name of the queue or topic in which the response message is received.
Selector Enter the selectors based on the message headers. When specifying a selector, use only single quotation marks. For example, specifying the selector APINAME='createOrder' selects all messages with a header name='APINAME' and value='createOrder'.
Time Out (seconds) This is a mandatory parameter. Enter the time interval (in seconds) after which the request times out.
Reconnect Tab
Retry Interval (milliseconds) In the event that the connection to the JMS server has been lost, enter the amount of time between each attempt to re-establish contact with the JMS server. This parameter is used in conjunction with the Number of Retries parameter. The default value is zero, implying no delay time between retry attempts.
Number of Retries In the event that the connection to the JMS server has been lost, enter the number of attempts to re-establish contact with the JMS server before throwing an exception. This parameter is used in conjunction with the Retry Interval parameter. The default value is zero, implying no retries if the connection is lost and an exception is thrown immediately.
JMS Security Properties Tab

This is enabled when you select Enable JMS Security in the Runtime Tab.

Note: You can override the JMS security properties specified here by defining the agent and flow authorization parameters in the <INSTALL_DIR>/properties/customer_overrides.properties file.
Destination based security Check this box if you want to provide destination based security for JMS service.
JNDI based security Check this box if you want to provide JNDI based security for JMS service.
JMS Security Parameters.

For more information about application server-specific JMS security parameters, see "Setting up the JMS Security Properties".

Parameter Name Enter the name of the security parameter.
Parameter Value Enter the value of the security parameter.
Note: The JMS session objects can be pooled based on the service being executed. Hence, whenever the JMS sender requires a session object, the Application Platform framework tries to get a free session object from the pool. If there are no free sessions available, a new session object is created to send the message and then added to the pool. Any session object that is idle for a certain configurable period of time is closed by the framework. The yfs.jms.session.reaptime property in the yfs.properties file is used to set the JMS session reaptime. To modify this property, add an entry for it in the <INSTALL_DIR>/properties/customer_overrides.properties file.

Connection properties

The following are the synchronous MQSeries nodes' connection properties:

Table 2. Synchronous WAS default messaging properties
Connection Node Connection Rules
Can be the first node after the start node Only for services invoked synchronously.
Can be placed before
  • Any transport node except for FTP or File I/O
  • Any other component node
Can be placed after
  • Start node
  • Any synchronous transport node
  • Any other component node
  • Any asynchronous transport node (except for FTP or File I/O); use Pass-through node to connect.
Passes data unchanged Transport nodes do not modify data.