WAS v8.5 > Reference > Developer best practices

Map 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:

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:

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


+

Search Tips   |   Advanced Search