+

Search Tips   |   Advanced Search

Mapping additional MQRFH2 header fields in service integration

In the IBM MQ message header (MQRFH2), there are additional fields specific to the service integration bus and that allow for functions that are not used in IBM MQ. When IBM MQ transports a message from one service integration bus to another service integration bus, these fields convey information that can be used by service integration applications but is not required by IBM MQ.

The additional fields are inserted in the MQRFH2 header of application messages, in the <sib> and <jms> folders. These fields do not appear as JMS message fields or properties.

When a message is sent to IBM MQ, a <sib> folder is included in the MQRFH2 header of the message if both of the following are true:

MQRFH2 header and field (<jms> folder) SIBusMessage field or property
Frp (appended to Dst field) Forward routing path header field
Rrp (appended to Rto field) Reverse routing path header field

MQRFH2 header and field (<sib> folder) SIBusMessage field or property
RTopic Reply topic
RPri Reply priority
RPer Reply persistence
RTTL Reply time to live
JsApiUserId Application user ID (JMSXUserId) for the service integration application
JsDst JMS destination
JsFmt Message format
JsSysMsgId System message identifier


Mapping the JMS Destination property between service integration and IBM MQ

The properties of service integration destinations differ from those used by IBM MQ queues, and they cannot be mapped exactly. When service integration uses IBM MQ to transport a message, it is useful to keep both representations of the JMS destination property in the message. To address this, when a message leaves service integration and enters IBM MQ, an additional RFH2 property is introduced into the RFH2 header to store the service integration destination property.

The service integration destination property is serialized, formatted as a hexadecimal string, then stored using the JsDst property of the service integration RFH2 folder, the <sib> folder. IBM MQ applications do not make use of this folder, but if the message is to be retrieved by another service integration application, it can use the information.

For example, a service integration destination SIQ1 is localized on an IBM MQ queue MQQ1, residing on queue manager QM1. The following actions occur when a service integration application sends a message to SIQ1:

This follows the convention used by the IBM MQ messaging provider to encode JMS destinations. If the message is retrieved by a service integration application, the JMS destination can be recovered from the <sib> folder of the RFH2 header. If the message is retrieved by an IBM MQ application, the JMS destination can be recovered from the contents of the <jms> folder of the RFH2 header.

If an IBM MQ server bus member is configured so that it does not use RFH2 headers, the JMS destination is not preserved when the message enters IBM MQ. In this situation, a service integration application can still retrieve the JMS message, but any attempt to examine the JMS destination property causes a JMS exception.