Message types and message mappings for WebSphere® Bridge for HTTP

IBM® MQ bridge for HTTP supports four message classes, TEXT, BYTES, STREAM and MAP. The message classes are mapped to JMS message types and HTTP Content-Type.

HTTP POST

The message type that arrives at the destination depends on the value of the x-msg-class header or the Content-Type of the HTTP request. Table 1 shows the HTTP Content-Type type that corresponds to each x-msg-class. Either field can be used to set the message type and message format. If both fields are set, and are set inconsistently, then a Bad Request exception is returned ( HTTP 400, MQHTTP20004).

Table 1. Mapping between x-msg-class and HTTP Content-Type
x-msg-class HTTP Content-Type
BYTES
application/octet-stream
application/xml
TEXT
text/*
MAP
application/x-www-form-urlencoded
application/xml (optional)
STREAM
application/xml (optional)

If the JMS message type is set in the MQRFH2 header, it is mapped according to Table 2.

Table 2. Mapping between x-msg-class and JMS message types.
x-msg-class JMS message type
BYTES jms_bytes
TEXT jms_text
MAP jms_map
STREAM jms_stream

The JMS message type is always set for a message class of MAP or STREAM. It is not always set for a message class of BYTES or TEXT. If a MQRFH2 is to be created for the request, the JMS message type is always set. Otherwise, if no MQRFH2 is created, no JMS message type is set. An MQRFH2 is created if user properties are set in the request, using the x-msg-usr header.

If the JMS message type is set, then the message format is set to MQFMT_NONE, see Table 4:

Table 3. Mapping between x-msg-class and IBM MQ message format
x-msg-class Message format with MQRFH2 present in message Message format with no MQRFH2 present in message
BYTES MQFMT_NONE MQFMT_NONE
TEXT MQFMT_NONE MQFMT_STRING
MAP MQFMT_NONE Not possible
STREAM MQFMT_NONE Not possible

HTTP GET or DELETE

The message type or format retrieved determines the value of the x-msg-class header and the Content-Type of the HTTP response. The x-msg-class header is returned only if requested in a x-msg-headers request.

Table 4 describes the mappings between x-msg-class and Content-Type, and the message type retrieved from the queue or topic.

Table 4. Mapping message types to x-msg-class and Content-Type
Message format JMS Message type x-msg-class Content-Type
Anything except MQFMT_STRING None BYTES application/octet-stream
MQFMT_STRING None TEXT text/plain
MQFMT_NONE jms_bytes BYTES application/octet-stream
MQFMT_NONE jms_text TEXT text/plain
MQFMT_NONE jms_map MAP application/xml
MQFMT_NONE jms_stream STREAM application/xml

MAP and STREAM message class serialization

MAP and STREAM message classes are serialized back to the client in the HTTP response in the same way as a message is serialized to a queue.

For MAP, the XML name, type, and value triplets are encoded as: 

<map>
	<elt name="elementname1" dt="datatype1">value1</elt>
	<elt name="elementname2" dt="datatype2">value2</elt>
	...
</map>
STREAM is like MAP, but it does not have element names: 

<stream>
	<elt dt="datatype1">value1</elt>
	<elt dt="datatype2">value2</elt>
	...
</stream>
Note: datatype is one of the data types defined for defining user-defined properties and listed in usr: HTTP x-msg-usr entity-header. The attribute dt=string is omitted for string elements because the default data type is string.