The JMS sender caches a single connection starting with the primary queue.
When the message sending fails, the JMS sender retries to send the message a configurable number of times with a configurable delay between each attempt as defined in the Reconnect Tab of the following table. An exception is thrown if the retries are exhausted and there is no backup queue.
If a backup queue is set up, a connection is made to the backup queue. The backup queue becomes the current queue for the next message sending attempt. The sender can be configured to reconnect to the primary queue. If the primary queue is found to be working, then a switch is made so that the primary queue becomes the current queue.
The following are the configuration properties of these nodes:
Property | Description |
---|---|
Runtime Tab You need to use the settings in this tab for the primary JMS server. |
|
Destination Name | Enter the name of the queue to which the message is sent. |
Time To Live (seconds) |
Enter the time period after which the messages are to be deleted
from the queue. A value of zero causes the message to never be deleted
from the queue. If this is set to a non-zero value, messages in the queue that are not consumed for the specified time interval are automatically deleted from the queue by the provider. |
Provider URL | Enter the provider URL of the JMS implementation used. This
is the URL to use for JNDI lookups.
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 Queue, set to 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 WebSphere MQ if you are using IBM WebSphere Default Messaging JMS Queue. This sets the class name to com.ibm.websphere.naming. |
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 any unique identifier for the connection factory. This name must be the same as that configured in the IBM WebSphere administration console. |
Persistent | Select this option if you want the messages to be persistent when dropped into the queue. |
Non Persistent | Select this option if you want the messages to be not persistent when dropped into the queue. |
Needs compression | Optional. Check this box if the message needs to be compressed before dropping into the queue. |
Commit of this message depends on parent transaction | Check this box if you want the message to be committed to the
queue only after the service is completed. Uncheck this box if you want the message to be committed to the queue immediately. For example, if the ON_SUCCESS event of any standard Sterling Selling and Fulfillment Foundation API is attached to a service in which the message is transactionally written to the queue, the message is committed to the queue only upon successful completion of the ON_SUCCESS event. The message is then rolled back from the queue if there is any error in the ON_SUCCESS event after the message is staged. However, in non-transactional mode, the message remains in the queue once it is staged and is not rolled back. Note: If you check this box, the system synchronizes
the JMS commit along with the DB commit. However, it is not a two-phase
commit. Therefore, it may cause some errors, thus resulting in duplicate
messages.
|
Enable JMS Security | Check this box if you want JMS Security to be enabled. Once
selected, the JMS Security Properties tab is enabled to configure
destination and/or JNDI based JMS security. Note: Oracle WebLogic 12.1.2 only supports JNDI based JMS security.
If destination based security is enabled, it is altogether bypassed.
Therefore, you must configure JNDI based JMS security if using Oracle
WebLogic 12.1.2.
|
Header Tab | |
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>'. |
Reconnect Tab You need to use the settings in this tab for the backup JMS server. |
|
Retry Interval (milliseconds) | In the event that the connection to the primary JMS server is lost, enter the amount of time between attempts to re-establish contact with the primary JMS server. This parameter is used in conjunction with the Number of Retries parameter. The default value is 0 which means no delay time between retry attempts. |
Number of Retries | In the event that the connection to the primary JMS server is lost, enter the number of attempts to re-establish contact with the primary JMS server before failing over to the backup JMS server, if enabled, or throwing an exception. This parameter is used in conjunction with the Retry Interval parameter. The default value is 0 which means there are no retries if the connection is lost and either failover occurs, if enabled, or an exception is thrown immediately. |
Use Backup JMS | Check this box if you want to enable a backup JMS queue. Only upon selecting this checkbox, other controls in this tab are enabled. |
Provider URL | Enter the backup JMS server provider URL of the JMS implementation
used. This is the URL to use for JNDI lookups.
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 Queue, set to 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 WebSphere MQ if you are using IBM WebSphere Default Messaging JMS Queue. This sets the class name to
|
Destination Name | Enter the name of the backup queue to which the message is sent. |
Connection Factory | Enter the back JMS server's 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 any unique identifier for the connection factory. This name must be the same as that configured in the IBM WebSphere administration console. |
Reconnect to Primary JMS Server | Check this box if you want to reconnect to the primary JMS server after a failover to the backup JMS server has occurred. Once this checkbox is selected, enter the wait time before it reconnects. |
Time Before Reconnect (seconds) | Enter the maximum amount of time between attempts to re-establish contact with the primary JMS server after a failover to the backup JMS server. If contact is re-established with the primary JMS server, it reverts back to using the primary JMS server. If contact with the primary JMS server cannot be established, it continues to use the backup JMS server. The default value is 600 seconds. |
JMS Security Properties Tab This is enabled upon selecting 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. Note: Oracle WebLogic 12.1.2
only supports JNDI based JMS security. If destination based security
is enabled, it is altogether bypassed. Therefore, you must configure
JNDI based JMS security if using Oracle WebLogic 12.1.2.
|
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" section. |
|
Parameter Name | Enter the name of the security parameter. |
Parameter Value | Enter the value of the security parameter. |