This topic introduces you to concepts you should consider before developing a user-defined parser. When you are ready, use the instructions in Creating a parser in C to construct your parser.
Before you start to create your own parser, be clear about what you want it for. You can perform most tasks using the functions already provided with WebSphere Message Broker, so you might not need to create a user-defined parser for your particular task.
Most tasks you need to perform can be performed using functions provided with WebSphere Message Broker. You should make sure that the task you want to perform cannot be done using built-in WebSphere Message Broker function before creating your own parser. If the available parsers in WebSphere Message Broker are not appropriate for your needs, you can define your own parser to parse internal, customer-specific, or generic commercial message formats.
For details of message domains that the supplied WebSphere Message Broker parser can accept input messages in, and message headers that the supplied parser can work with, see Parsers.
WebSphere Message Broker does not support multi-part multi-format messages. A multi-part MRM message must consist of messages which are all in the same format
WebSphere Message Broker supports partial parsing, which allows your parser to only parse relevant fields in a message. Using partial parsing can save system resources.
WebSphere Message Broker supports what is called partial parsing. If an individual message contains hundreds or even thousands of individual fields, the parsing operation requires considerable memory and processor resources to complete. Because an individual message flow might reference only a few of these fields, or none at all, it is inefficient to parse every input message completely. For this reason, WebSphere Message Broker allows parsing of messages on an as-needed basis. (This does not prevent a parser from processing the entire message all at once, and some parsers are written to do exactly this.)
Each syntax element in a logical message has two bits that indicate whether or not all the elements on either side of an element are complete, and whether its children are complete as well. Parsing is normally completed in a bottom to top, left to right manner. When a parser has completed the siblings of a particular element that precede the given element and the first child, it sets the first completion bit to one. Similarly, when the pointer to the next sibling of an element is complete, as well as its last child pointer, the other completion bit is set to a one.
In partial parsing, the broker waits until a part of the message is referenced, and invokes the parser to parse that part of the message. WebSphere Message Broker message processing nodes refer to fields within a message using hierarchical names. The name begins at the root of the message and proceeds down the message tree until the particular element is located. If an element is encountered without its completion bits set, and further navigation from this element is required, then the appropriate parser entry point is called to parse the necessary part of the message. The relevant part of the message is parsed, appropriate elements are added to the logical message tree, and the element in question is marked as complete.
If you do not need to parse the full bit stream, you can use partial parsing, also known as lazy parsing. During partial parsing, a parser is called recursively until the requested element is returned, or until the message tree has been marked as complete and the requested element is known not to exist.
Whether you choose to perform a full or partial parse very much depends on how you anticipate the message will be processed within WebSphere Message Broker. If most field elements within the message are likely to be accessed during processing within WebSphere Message Broker, then performing a full parse of the message when an attempt is made to access it will probably prove more efficient. This is more likely to be true for smaller messages.
However, if most field elements within the message are not likely to be accessed during processing within WebSphere Message Broker, then performing a lazy parse of the message when an attempt is made to access a specific field would probably prove more efficient. This is especially true as the message size grows.
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
as01403_ |