Generating an MQ JMS import binding

Alternately, select Import under Component on the palette and drag it on to the canvas. An import with no implementation and no interface is created. Right-click the import, select Add Interface from the menu and add an interface describing your interaction with a WebSphere MQ client. Generate the MQ JMS binding by right-clicking the import and from the menu selecting Generate Binding > Messaging Binding >MQ JMS Binding.

Select the messaging domain: Point-to-Point or Publish-Subscribe.

Select if you want to Configure new messaging provider resources (the default) or Use pre-configured messaging provider resources.

If you choose Configure new messaging provider resources, enter the WebSphere MQ queue name for the send destination for a one-way request operation, and send and receive destination for a request-response operation. You may specify the WebSphere MQ queue manager or use the default queue, which is preselected.

If you choose Use pre-configured messaging provider resources, enter the JNDI name for the ActivationSpec and send destination for a one-way operation. Enter send and receive destinations for a request-response operation and the connection factory JNDI name.

If you are using a remote queue manager, specify the name and, after you generate the binding, update the CLIENT transport properties in the endpoint configuration section.

You should periodically check your binding configuration information at run time in the administrative console. In particular check the state of the endpoint. Under some conditions the endpoint may go into a paused state and you will need to restart it (see Viewing or changing the state of an endpoint).

If you specify JNDI names and then switch to specifying your own configuration properties both sets of values remain in memory until you close the editor. You are saved from reentering the values while you decide.

In the Default data format field, select how the data will be serialized between the business object and the JMS message with a binding. To change the default, click Select beside the field to launch the Data Transformation Configuration window. Your selections are as follows:

In the next section, if you want to use the TargetFunctionName message header property to be used with module to module communication, select it. If you want to use the default module to module fault handling, which is a SOAP transport, select it.

A common way for specifying a userid and password is through using the Java™ EE Connector (J2C) authentication data entries. The entries are defined on the server. In the Security configuration section, select Specify a Java Authentication and Authorization Services (JAAS) alias security credential when server security is enabled, if it is used by your organization. Enter the Java EE Connector (J2C) authentication data entry.

Click OK. The MQ JMS binding is created and shown in the properties view when the Binding tab is selected. Sub tabs under the binding tab provide binding information details, which are discussed in the next steps.

The Connection Factory Properties section specifies the connection factory properties such as the transport mode, which defaults to BINDINGS. With the bindings mode, WebSphere MQ JMS classes use the Java Native Interface (JNI) to call directly into the existing queue manager API rather than communicating through a network. Since bindings is a shared memory protocol, it may offer better performance.

If you are using a remote queue manager requiring a client binding or you have chosen to use a client binding, then select CLIENT. The client configuration properties become active requiring you to either specify the host name, channel and port or the client channel definition table URI. See Using binding or client transports for more information. Further down this page, though not shown in the screen capture below, are MQ local address properties. Advanced reveals connection pool properties that you can override.

Enable connection on startup specifies that a connection should be made according to the messaging endpoints when the application starts (default). If deselected, the connection will not be made and the application can determine the flow of messages.

Enable XA specifies whether the connection factory is for XA or non-XA coordination of messages. XA should be selected if multiple resources are used in the same transaction (default). If deselected, the resource manager is used for local transaction calls (session.commit and session.rollback) instead of XA calls. This selection can mprove performance but only a single resource can be enlisted in a transaction.

It also specifies also the receive destination properties similar to the send destination properties under Receive Destination Properties.

If you selected pre-configured resources earlier, you will see JNDI names for the ActivationSpec properties and receive destination properties, in the case of a request-response operation configuration. You will also see a JNDI lookup name field for Failed Event Replay Connection Factory, which lets you replay events that have failed. Use the select button or enter the JNDI lookup name for the connection factory configuration that is used to replay failed events.

The Generic tab lets you add a description of the method binding.

The Data Serialization tab lets you specify the input and output serialization types, which determines how the data will be serialized between the business object and the JMS message.

Message type is used by the server to create and send the outgoing message. It is used with some data format transformers. If the server does not use the message type specified then it is disabled. Valid types are byte, map, object, stream or text.

Under JMS Headers, the properties you can specify are as follows. The JMS type property conforms to the JMSType specified in the JMS specification . This property contains a message type identifier supplied by a client when a message is sent. The JMS correlation ID property conforms to the JMSCorrelationID in the JMS specification. A typical use is to link a response message with its request message. In IBM® Integration Designer, the ID is used by the message selector to select only messages with that ID. It can be any string value specified at run time.

JMS delivery mode can be either persistent, guaranteed delivery is required, or non-persistent, an occasional lost message is tolerable. JMS priority specifies a level priority value with 0 as the lowest and 9 as the highest. 4, the default, is considered normal priority.Custom Headers allow you to specify a name, type and value for a property. The default TargetFunctionName property used by the function selector appears in this table.

Clicking Advanced found lower on this page and not shown in this screen capture lets you specify the input and output serialization types, which determines how the data will be serialized between the business object and the JMS message.

If fault configuration is new to you, see Handling faults in bindings for an overview.

Click Select beside Fault selector to configure a fault. Your selections are as follows:

Expanding Advanced, lets you also specify the data format for a runtime exception.

Failed message recovery mode lets you allow the binding to manage the recovery of failed messages (the default) or rely on the transport-specific method of recovery. Allow binding to manage recovery for failed messages creates a recovery queue on deployment to handle failed messages. Binding errors are handled as failed events that can be retrieved later. Rely on transport-specific recovery for failed events does not set up a recovery mechanism.