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.