This topic provides information specific to dealing with messages that belong to the BLOB domain, and that are parsed by the BLOB parser.
You cannot manipulate the contents of a BLOB message, because it has no predefined structure. However, you can refer to its contents using its known position within the bit stream, and process the message with a minimum of knowledge about its contents.
The BLOB message body parser does not create a tree structure in the same way that other message body parsers do. It has a root element BLOB, that has a child element, also called BLOB, that contains the data.
You can refer to message content using substrings if you know the location of a particular piece of information within the BLOB data. For example, the following expression identifies the tenth byte of the message body:
InputBody.BLOB.BLOB[10]
The following expression references 10 bytes of the message data starting at offset 10:
SUBSTRING(InputBody.BLOB.BLOB from 10 for 10)
This example shows how to manipulate a variable length BLOB message. The example assumes that you have configured a message flow that receives a variable length BLOB message, parses some of the fields by invoking the MRM parser, and routes the output message to the correct output queue based on the information parsed.
The input message is in BLOB format and is assumed to contain embedded NULLs ('x00'), so it cannot be defined as null terminated.
This example shows the ESQL needed to:
By doing this, you can define the message model with an integer length field followed by the BLOB message.
This example also shows how to convert the BLOB message to CWF, process the message, and strip off the added length field.
In this example the input record has the following format:
This field is used as an integer to route the message to different queues depending on customer-defined criteria.
Define a new message BLOB_Example that includes the following elements and types:
This section describes the characteristics of the message flow. If you want to implement this example flow, you must complete the message flow definition (for example, by creating the three subflows to replace the output nodes used here to handle false, unknown, and failure cases) and provide any required support for its deployment and execution (for example, creating the inbound and any outbound queues on the queue manager for the broker to which you deploy the flow).
This subflow handles a message that has the expected format (the test performed in the Filter node returned true). The successful message is written to the output queue in its original form; the message is converted back to BLOB from MRM and the four bytes that were added (field B_LEN) are removed.
For this subflow:
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
ac11640_ |