WAS v8.5 > Reference > Developer best practicesMap additional MQRFH2 header fields in service integration
In the WebSphere MQ message header (MQRFH2), there are additional fields specific to the service integration bus and that allow for functions that are not used in WebSphere MQ. When WebSphere 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 WebSphere 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 WebSphere MQ, a <sib> folder is included in the MQRFH2 header of the message if both of the following are true:
- The WebSphere MQ queue point attributes of the service integration destination are configured to use MQRFH2 headers.
- The fields that correspond to the <sib> folder content are set in the service integration message.
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
Map the JMS Destination property between service integration and WebSphere MQ
The properties of service integration destinations differ from those used by WebSphere MQ queues, and they cannot be mapped exactly. When service integration uses WebSphere 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 WebSphere 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. WebSphere 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 a WebSphere MQ queue MQQ1, residing on queue manager QM1. The following actions occur when a service integration application sends a message to SIQ1:
- A serialized representation of PMQ1 is placed in the <sib> folder of the RFH2 header, using the JsDst property.
- The message is stored on MQQ1.
- The string "queue://QM1/MQQ1" is also placed in the <jms> folder of the RFH2 header, using the Dst property.
This follows the convention used by the WebSphere 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 a WebSphere MQ application, the JMS destination can be recovered from the contents of the <jms> folder of the RFH2 header.
If a WebSphere MQ server bus member is configured so that it does not use RFH2 headers, the JMS destination is not preserved when the message enters WebSphere 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.
Related concepts:
Point-to-point messaging with a WebSphere MQ network
Related
Specify whether messages are forwarded to WebSphere MQ as JMS messages