The WebSphere MQ connector for XA transactions. The default WebSphere MQ connector. The name of the QueueManager to use.The host name of the QueueManager to use.The port of the QueueManager to use. The temporary destination model to use when creating temporary destinations from this connector. The WebSphere MQ CCS ID.Whether to use a local binding or client/server TCP binding. Possible values are: BINDINGS_MQ, CLIENT_MQ_TCPIP, DIRECT_HTTP, DIRECT_TCPIP, and MQJD. The name of the channel used to communicate with the QueueManager. When using remote queue definitions, WMQ uses the JMSReplyTo property to channel responses. When set to true this property will cause Mule to ignore ReplyTo queue destinations and not interfere with WMQ's remote queue mechanism. By default this is set to false. This also means that by using WMQ's remote queue definitions it is not possible to use some of Mule's request/response patterns when this properrty is true. The fully qualified class name of the receive exit handler implementation. An initialization parameter for the receive exit handler. The fully qualified class name of the send exit handler implementation. An initialization parameter for the send exit handler. The fully qualified class name of the security exit handler implementation. An initialization parameter for the security exit handler. Specifies whether this is in JMS or non-JMS format. Possible values are: JMS_COMPLIANT or NONJMS_MQ (default). Converts a com.ibm.jms.JMSMessage or sub-type into an object by extracting the message payload. Converts an object back into a com.ibm.jms.JMSMessage. An endpoint on which WMQ messages are received. An endpoint to which WMQ messages are sent. A global WMQ endpoint definition. Note that global endpoints are like endpoint factories from which new endpoints can be created. As such this endpoint has a union of inbound and outbound endpoint properties. Depending on how this endpoint is used the unneeded properties will ignored. The queue name. If this is set to false (the default), when Mule performs request/response calls a temporary destination will automatically be set up to receive a response from the remote WMQ call. A client can use the correlation ID header field to link one message to another. A typical use case is to link a response message with its request message. The CorrelationID must be a 24-byte String. WebSphere will pad shorter values with zeroes so that the fixed length is always 24 bytes. Because each message sent by a WMQ provider is assigned a message ID value, it is convenient to link messages via the message ID. All message ID values must start with the 'ID:' prefix. Indicates the message type. Each of the message types have specific behavior associated with them. The following message types are defined:

• MQMT_REQUEST: The message requires a reply. Specify the name of the reply queue using the <ReplyTo> element of outbound routers. Mule handles the underlying configuration.
• MQMT_DATAGRAM: The message does not require a reply.
• MQMT_REPLY: The message is the reply to an earlier request message (MQMT_REQUEST). The message must be sent to the queue indicated by the <ReplyTo> configured on the outbound router. Mule automatically configures the request to control how to set the MessageId and CorrelationId of the reply.
• MQMT_REPORT: The message is reporting on some expected or unexpected occurrence, usually related to some other message (for example, a request message was received that contained data that was not valid). Sends the message to the queue indicated by the <ReplyTo> configuration of the message descriptor of the original message.

The message requires a reply. Specify the name of the reply queue using the <ReplyTo> element of outbound routers. Mule will handle the underlying configuration. The message is the reply to an earlier request message (MQMT_REQUEST). The message must be sent to the queue indicated by the <ReplyTo> configured on the outbound router. Mule automatically configures the request to control how to set the MessageId and CorrelationId of the reply. The message is one that does not require a reply. The message is reporting on some expected or unexpected occurrence, usually related to some other message (for example, a request message was received that contained data that was not valid). Send the message to the queue indicated by the <ReplyTo> configuration of the message descriptor of the original message. If set, this property overrides the coded character set property of the destination queue or topic. If set to true, the JMS provider logs the message to stable storage as it is sent so that it can be recovered if delivery is unsuccessful. A client marks a message as persistent if the application will have problems if the message is lost in transit. A client marks a message as non-persistent if an occasional lost message is tolerable. Clients use delivery mode to tell a JMS provider how to balance message transport reliability/throughput. Delivery mode only covers the transport of the message to its destination. Retention of a message at the destination until its receipt is acknowledged is not guaranteed by a PERSISTENT delivery mode. Clients should assume that message retention policies are set administratively. Message retention policy governs the reliability of message delivery from destination to message consumer. For example, if a client's message storage space is exhausted, some messages as defined by a site-specific message retention policy may be dropped. A message is guaranteed to be delivered once and only once by a JMS provider if the delivery mode of the message is persistent and if the destination has a sufficient message retention policy. Define the default length of time in milliseconds from its dispatch time that a produced message should be retained by the message system. Time to live is set to zero (forever) by default. Sets the message priority. JMS defines a ten-level priority value with 0 as the lowest priority and 9 as the highest. In addition, clients should consider priorities 0-4 as gradations of normal priority and priorities 5-9 as gradations of expedited priority. JMS does not require that a provider strictly implement priority ordering of messages. However, it should do its best to deliver expedited messages ahead of normal messages. Specifies whether this is in JMS or non-JMS format. Possible values are: JMS_COMPLIANT or NONJMS_MQ (default). Transactions allow a series of operations to be grouped together so that they can be rolled back if a failure occurs. Set the action (such as ALWAYS_BEGIN or JOIN_IF_POSSIBLE) and the timeout setting for the transaction. Used for encoding IDs suitable for WebSphere's restrictive correlation mechanism. Sets a selector on the underlying WMQ queue. It is not a standard Mule filter and cannot be combined with other filters. The expression filter criteria to apply to the queue when consuming messages. A custom xsd:int type that also allows for Ant-style property placeholders and restricts the int value to a valid priority number.