Name of the connection alias. Each connection alias represents a connection factory to a specific JMS provider.

A description of the JMS connection alias.

Whether sessions that use this JMS connection alias will be transacted.

NO_TRANSACTION

Indicate that sessions that use this JMS connection alias are not transacted.

LOCAL_TRANSACTION

Indicate that sessions that use this JMS connection alias are part of a local transaction.

XA_TRANSACTION

Indicate that sessions that use this JMS connection alias are part of an XA transaction.

The JMS client identifier associated with the connections established by this JMS connection alias.

User name needed to acquire a connection from the connection factory.

For more information about whether or not the JMS provider requires a user name and password to obtain a connection, refer to the product documentation for the JMS provider.

Password needed to acquire a connection from the connection factory.

For more information about whether or not the JMS provider requires a user name and password to obtain a connection, refer to the product documentation for the JMS provider.

The alias to the JNDI provider that you want this JMS connection alias to use to look up administered objects. For information about creating a JNDI provider alias, see Creating a JNDI Provider Alias.

The lookup name for the connection factory that you want to use to create a connection to the JMS provider specified in this JMS connection alias.

If the JMS connection alias connects to webMethods Universal Messaging, specify the Universal Messaging connection factory that you created when you set up your Universal Messaging environment.

If you are using SonicMQ as the JMS provider, specify the lookup name that refers to the serializable Java object file containing the SonicMQ object definitions. Include the .sjo extension as part of the lookup name.

How Integration Server monitors the connection factory object for changes, if at all This only applies if a JMS connection alias connects to the webMethods Broker using a webMethods Connection Factory object in a JNDI server.

Indicate that Integration Server will not monitor the connection factory. This is the default.

Monitor the connection factory by polling for changes at an interval that you specify.

Monitor the connection factory at an interval determined by the refresh interval specified for the webMethods Connection Factory object. For more information about configuring a cluster connection factory, see Administering webMethods Broker and webMethods Broker Messaging Programmer’s Guide.

Monitor the connection factory by registering an event listener.

The number of minutes between polling attempts. The polling interval must be a positive integer. The default value is 60 minutes.

Name (DNSname:port or ipaddress:port) of the machine on which the Broker Server resides.

Name of the webMethods Broker as defined on the Broker Server. The default name is Broker #1.

The name of the client group to which you want Integration Server to belong when it acts as a JMS client. The client group that you specify must already exist on the Broker Server. The default is IS-JMS.

A comma delimited list of Broker Servers on which the connection between the Integration Server (acting as the JMS client) and the Broker (acting as the JMS provider) can exist. This provides connection failover. If a connection failure occurs to the first Broker Server in the list, a connection attempt will be made to the next Broker Server listed. Use the following format for each webMethods Broker:

{webMethods Broker Name]@<host>[:port]

The full path to this Integration Server's keystore file. A keystore file contains the credentials (private key/signed certificate) that an entity needs for SSL authentication. If the Broker Server requires an SSL connection, then the information in this file is used to authenticate the Integration Server client to that Broker Server.

The Integration Server's keystore file is stored on the machine on which the Integration Server resides.

The file type of the Integration Server's keystore file, which can be either PKCS12 or JKS.

The full path to this Integration Server client's truststore file. A truststore file contains trusted root certificates for the authorities responsible for signing SSL certificates. For an SSL connection to be made, a valid trusted root for the SSL certificate stored in the keystore must be accessible in a truststore file.

The Integration Server's truststore file is stored on the machine on which the Integration Server resides.

The file type of the Integration Server's truststore file, which is JKS.

Specify whether or not to encrypt the connection between the Integration Server and the webMethods Broker.

The name of the class loader that you want to use with this JMS connection alias. Integration Server will use the specified class loader when performing certain activities with the JMS connection alias (send a message, receive a message, create a connection, create a destination, etc.)

By default, Integration Server uses the server class loader. However, you can specify the class loader for a package instead. This may be helpful when working with third party JMS providers. For example, you might place the third party jars needed for each JMS provider in separate packages, specifically, in the Integration Server_directory /instances/instance_name/packages/packageName/code/jars directory. This can help prevent conflicts between the jars required for different JMS providers.

The maximum number of messages that can exist in the client side queue for this JMS connection alias. Integration Server writes messages to the client side queue if the JMS provider is not available when messages are sent. Each JMS connection alias has its own client side queue.

Specify -1 if you want the client side queue to be able to contain an unlimited number of messages. That is, specify ‑1 if you do not want to set a maximum limit.

If you specify 0, Integration Serverwill not write messages to the client side queue for this JMS connection alias.

Whether Integration Server drains the client side queue by sending the messages to the JMS provider in the same order in which Integration Server placed the messages in the client side queue.

Select the check box if you want Integration Server to send messages from the client side queue in the same order in which Integration Server originally placed the messages in the client side queue.

When the Drain CSQ in Order check box is selected, after the connection to the JMS provider is re-established, Integration Server continues to write new messages to the client side queue until the client side queue is completely drained. If the Drain CSQ in Order check box is not selected, after the connection to the JMS provider is re-established, Integration Server sends new messages directly to the JMS provider while it drains the client side queue.

Whether Integration Server creates a temporary queue on the JMS provider to handle request-reply operations that do not specify a replyTo destination.

Select the check box if you want Integration Server to create a temporary queue. Clear the check box if you do not want Integration Server to create a temporary queue.

You must select the Create Temporary Queue check box if you want to select the Enable Request-Reply Listener for Temporary Queue check box.

Specifies whether or not Integration Server creates a single dedicated MessageConsumer for receiving synchronous replies delivered to the temporary queue for this JMS connection alias. When this check box is cleared, Integration Server creates a new JMS MessageConsumer for each reply message. In many situations, creating one MessageConsumer per response does not impact performance. However, in some situations, such as when many threads invoke pub.jms:sendAndWait concurrently, creating a MessageConsumer for every expected response can impact performance. When this check box is selected, Integration Server creates a dedicated consumer for receiving replies to requests published using this JMS connection alias. For more information about creating a dedicated listener for receiving replies, see Creating a Dedicated Listener for Receiving Replies.

Whether users can use Designer to create, list, and modify destinations on the webMethods Broker or webMethods Universal Messaging when working with JMS triggers.

Select the check box if you want Designer users to be able to create, list, and modify destinations using a JMS trigger that uses this JMS connection alias.

If this JMS connection alias connects to a webMethods Broker in a production environment, Software AG recommends that you prevent Designer users from managing destinations. That is, in a production environment, the Manage Destinations check box should be cleared.

For more information about using Designer to manage destinations, see Allowing Destinations to be Managed through the JMS Connection Alias and Designer .

Whether Integration Server creates a separate connection to the JMS provider for each JMS trigger.

Select the check box if you want Integration Server to create a separate connection for each JMS trigger that uses this JMS connection alias.

If you want a concurrent JMS trigger that uses this JMS connection alias to use multiple connections to the JMS provider, you must configure the alias to create a separate connection per trigger.

For more information, see Allowing Multiple Connections for a JMS Connection Alias.

Whether to enable caching of JMS Session and MessageProducer objects for this JMS connection alias.

Indicate that Integration Server does not cache JMS Session or MessageProducer objects.

Enable caching of JMS Session and MessageProducer objects.

The minimum number of entries in the default session pool. The default is 1.

The maximum number of entries in the default session pool. The default is 30.

The minimum number of entries in each destination- specific pool.

The maximum number of entries in each destination-specific pool. A value of 0 (or blank) indicates that Integration Server does not create separate pools for any of the destinations associated with the JMS connection alias.

A semicolon delimited list of the lookup names for the destinations for which you want Integration Server to create separate pools.

A semicolon delimited list of the queues for which you want Integration Server to create separate pools.

A semicolon delimited list of the topics for which you want Integration Server to create separate pools.

The number of milliseconds before Integration Server removes an inactive pool entry. The timeout value applies to the default session pool and the destination-specific pools.

A value of 0 indicates that pool entries never expire. A value of -1 indicates that Integration Server uses the system default as defined by the watt.server.jms.producer.pooledSession.timeout parameter.

This default is 60000 milliseconds

The maximum number of times that Integration Server will automatically retry a pub.jms:send service that fails because of a transient error. A value of 0 indicates that automatic retry is disabled for this JMS connection alias. The default is 0.

The number of milliseconds that Integration Server waits between retry attempts. The default is 1000 milliseconds (1 second).