Use a client channel definition table
As an alternative to creating a client connection channel definition by setting certain properties of a ConnectionFactory object, a WebSphere MQ JMS client application can use client connection channel definitions that are stored in a client channel definition table. These definitions are created by WebSphere MQ Script (MQSC) commands or WebSphere MQ Programmable Command Format (PCF) commands. When the application creates a Connection object, the WebSphere MQ JMS client searches the client channel definition table for a suitable client connection channel definition, and uses the channel definition to start an MQI channel. For more information about client channel definition tables and how to construct one, see WebSphere MQ Clients.
To use a client channel definition table, the CCDTURL property of a ConnectionFactory object must be set to a URL object. The URL object encapsulates a uniform resource locator (URL) that identifies the name and location of the file containing the client channel definition table and specifies how the file can be accessed. We can set the CCDTURL property by using the WebSphere MQ JMS administration tool, or an application can set the property by creating a URL object and calling the setCCDTURL() method of the ConnectionFactory object.
For example, if the file ccdt1.tab contains a client channel definition table and is stored on the same system on which the application is running, the application can set the CCDTURL property in the following way:
java.net.URL chanTab1 = new URL("file:///home/admdata/ccdt1.tab"); factory.setCCDTURL(chanTab1);As another example, suppose the file ccdt2.tab contains a client channel definition table and is stored on a system that is different to the one on which the application is running. If the file can be accessed using the FTP protocol, the application can set the CCDTURL property in the following way:
java.net.URL chanTab2 = new URL("ftp://ftp.server/admdata/ccdt2.tab"); factory.setCCDTURL(chanTab2);In addition to setting the CCDTURL property of the ConnectionFactory object, the QMANAGER property of the same object must be set to one of the following values:
- The name of a queue manager
- An asterisk (*) followed by the name of a queue manager group
- An asterisk (*)
- An empty string, or a string containing all blank characters
These are the same values that can be used for the QMgrName parameter on an MQCONN call issued by a client application that is using Message Queue Interface (MQI). For more information about the meaning of these values therefore, see the WebSphere MQ Application Programming Reference and WebSphere MQ Clients. We can set the QMANAGER property by using the WebSphere MQ JMS administration tool, or an application can set the property by calling the setQueueManager() method of the ConnectionFactory object.
If an application then creates a Connection object from the ConnectionFactory object, the WebSphere MQ JMS client accesses the client channel definition table identified by the CCDTURL property, uses the QMANAGER property to search the table for a suitable client connection channel definition, and then uses the channel definition to start an MQI channel to a queue manager. The way that the WebSphere MQ JMS client uses the QMANAGER property to search the client channel definition table is also as described in the WebSphere MQ Application Programming Reference and WebSphere MQ Clients
. If your application uses connection pooling, see also Controlling the default connection pool.Note that the CCDTURL and CHANNEL properties of a ConnectionFactory object cannot both be set when the application calls the createConnection() method. If both properties are set, the method throws an exception. The CCDTURL or CHANNEL property is considered to be set if its value is anything other than null, an empty string, or a string containing all blank characters.
When the WebSphere MQ JMS client finds a suitable client connection channel definition in the client channel definition table, it uses only the information extracted from the table to start an MQI channel. Any channel related properties of the ConnectionFactory object are ignored.
In particular, note the following points if you are using Secure Sockets Layer (SSL):
- An MQI channel uses SSL only if the channel definition extracted from the client channel definition table specifies the name of a CipherSpec supported by the WebSphere MQ JMS client.
- A client channel definition table also contains information about the location of Lightweight Directory Access Protocol (LDAP) servers that hold certificate revocation lists (CRLs). The WebSphere MQ JMS client uses only this information to access LDAP servers that hold CRLs.
For more information about using SSL with a client channel definition table, see WebSphere MQ Clients.
Note also the following points if you are using channel exits:
- An MQI channel uses only the channel exits and associated user data specified by the channel definition extracted from the client channel definition table.
- A channel definition extracted from a client channel definition table can specify channel exits that are written in Java™. This means, for example, that the SCYEXIT parameter on the DEFINE CHANNEL command to create a client connection channel definition can specify the name of a class that implements the WebSphere MQ base Java interface, MQSecurityExit. Similarly, the SENDEXIT parameter can specify the name of a class that implements the MQSendExit interface, and the RCVEXIT parameter can specify the name of a class that implements the MQReceiveExit interface. For more information about how to write a channel exit in Java, see Using channel exits.
The use of channel exits written in a language other than Java is also supported. For information about how to specify the SCYEXIT, SENDEXIT, and RCVEXIT parameters on the DEFINE CHANNEL command for channel exits written in another language, see the WebSphere MQ Script (MQSC) Command Reference.
uj25030_