For this field... | Specify... | |||
Connection Alias Name | Name of the connection alias. Each connection alias represents a connection factory to a specific JMS provider. | |||
Description | A description of the JMS connection alias. | |||
Transaction Type | Whether sessions that use this JMS connection alias will be transacted. | |||
Select... | To... | |||
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. | |||
Connection Client ID | The JMS client identifier associated with the connections established by this JMS connection alias.
| |||
User (optional) | 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 (optional) | 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. |
For this field... | Specify... | |||
JNDI Provider Alias Name | 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. | |||
Connection Factory Lookup Name | 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. | |||
Monitor webMethods Connection Factory | 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. | |||
Select... | To... | |||
No | Indicate that Integration Server will not monitor the connection factory. This is the default. | |||
Poll for changes (specify interval) | Monitor the connection factory by polling for changes at an interval that you specify. | |||
Poll for changes (interval defined by webMethods Connection Factory) | 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. | |||
Register change listener | Monitor the connection factory by registering an event listener. | |||
Polling Interval (minutes) | The number of minutes between polling attempts. The polling interval must be a positive integer. The default value is 60 minutes.
| |||
|
For this field... | Specify... | ||
Broker Host | Name (DNSname:port or ipaddress:port) of the machine on which the Broker Server resides. | ||
Broker Name | Name of the webMethods Broker as defined on the Broker Server. The default name is Broker #1. | ||
Client Group | 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. | ||
Broker List | 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]
| ||
Keystore | 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. | ||
Keystore Type | The file type of the Integration Server's keystore file, which can be either PKCS12 or JKS. | ||
Truststore | 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. | ||
Truststore Type | The file type of the Integration Server's truststore file, which is JKS. | ||
Encryption | Specify whether or not to encrypt the connection between the Integration Server and the webMethods Broker. |
For this field... | Specify... | ||
Class Loader | 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. | ||
Maximum CSQ Size (messages) | 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. | ||
Drain CSQ in Order | 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.
| ||
Create Temporary 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. | ||
Enable Request-Reply Listener for Temporary Queue | 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. | ||
Manage Destinations | 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
. | ||
Create New Connection per Trigger | 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. |
Note: | You can configure producer caching for non-transacted JMS connection aliases only. |
For this field... | Specify... | |||
Caching Mode | Whether to enable caching of JMS Session and MessageProducer objects for this JMS connection alias. | |||
Select... | To... | |||
DISABLED | Indicate that Integration Server does not cache JMS Session or MessageProducer objects. | |||
ENABLED PER DESTINATION | Enable caching of JMS Session and MessageProducer objects. | |||
Minimum Session Pool Size (unspecified destinations) | The minimum number of entries in the default session pool. The default is 1. | |||
Maximum Session Pool Size (unspecified destinations) | The maximum number of entries in the default session pool. The default is 30. | |||
Minimum Pool Size per Destination | The minimum number of entries in each destination- specific pool. | |||
Maximum Pool Size per Destination | 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. | |||
Destination Lookup Name List | A semicolon delimited list of the lookup names for the destinations for which you want Integration Server to create separate pools.
| |||
Queue List | A semicolon delimited list of the queues for which you want Integration Server to create separate pools.
| |||
Topic List | A semicolon delimited list of the topics for which you want Integration Server to create separate pools.
| |||
Idle Timeout | 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 |
For this field... | Specify... |
Max Retry Count | 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. |
Retry Interval (milliseconds) | The number of milliseconds that Integration Server waits between retry attempts. The default is 1000 milliseconds (1 second). |
Note: | If the JMS connection alias is transacted or uses a connection factory to which the multi-send guaranteed policy is applied, Integration Server ignores the producer retry values. |