Message Sets: Physical formats in the MRM domain

Each message definition file within a message set describes both the logical structure of your messages, and the physical formats that describe the precise appearance of your message bit stream during transmission.

Tip: A message set is the original container for message models used by IBM® Integration Bus. In WebSphere® Message Broker Version 8.0 and later, message model schema files contained in applications and libraries are the preferred way to model messages for most data formats. Message sets continue to be supported, and are required if you use the MRM or IDOC domains. If you need to model data formats for use in the MRM or IDOC domains, you must first enable message set development in the IBM Integration Toolkit. For more information, see Enabling message set development .

If you are using the MRM domain or the IDOC domain, physical format information must be provided, as it tells the parser exactly how to parse the message bit stream.

You can think of a message as a packet of data that is sent from one place to another. The sender and receiver of the message will have agreed the structure of the message and what each field in the message means. This is the platform and protocol independent logical structure.

The sender and receiver will have also agreed on the physical representation of the message, how the data is physically laid out on the wire. For example, if you define a message that conveys information about a debit of an individual's bank account, it can be represented in different physical forms (examples are XML, or a fixed structure such as a COBOL copybook). The meaning and data are the same in both cases: only the physical layout has changed.

If you are using the MRM domain, you can model various different physical representations by using named physical formats.

Use the Custom Wire Format (CWF) physical format to model fixed-format messages from applications that are written in C, COBOL, PL/I and other languages. This support includes the ability to create a message model directly from a C header file or COBOL copybook.
Use the Tagged Delimited String Format (TDS) physical format to model formatted text messages, perhaps with field content identified by tags or separated by specific delimiters or both. This support is rich enough to model industry standards such as SWIFT, EDIFACT, and X12.
Use the XML physical format to model XML messages, including those that use XML namespaces. This support includes the ability to create a message model directly from an XML DTD or XML Schema file.

Different physical representations

The following example shows how a simple logical message can have different physical representations.

The logical model defines the structure and order of the message. In the following example, the three fields are simple integers, and C follows B, which follows A:

int   A;
int   B;
int   C;

A typical Custom Wire Format representation for this logical message would be 12 bytes of data, with each of A, B and C occupying 4 bytes. Alternatively, perhaps A is 4 bytes long, but B and C are only 2 bytes long. You supply the precise physical information for each field in the message as CWF properties.
TDS enables several different representations to be modeled. Each integer can be preceded by a tag to identify it and a delimiter to terminate it, as follows:
```
{A_tag:xxxxxxxx;B_tag:xxxxxxxx;C_tag:xxxxxxxx}
```
An alternative might rely on the data being ordered so only the terminating delimiter must be specified, as follows:
```
[xxxxxxxx;xxxxxxxx;xxxxxxxx]
```
You supply the precise identification regime as TDS properties.
A typical XML representation of this model is as follows:
```
<Msg><A>xxxxxxxx</A><B>xxxxxxxx</B><C>xxxxxxxx</C></Msg>
```
where xxxxxxxx is the value of the integer represented as a string (XML deals only with strings). An alternate representation might be:
```
<Msg A="xxxxxxxx" B="xxxxxxxx" C="xxxxxxxx"/>
```
where the values of the integers are stored as XML attributes rather than XML elements. You supply the precise XML rendering for each field in the message as XML properties.

This shows that the logical model is unchanged. It is constant, regardless of the physical representation that you choose to model on top of it, using the physical format support provided by the MRM domain. The MRM parser is able to transform the message from the input physical representation to any number of output representations, based on the physical format layers that you have defined.

Creating physical formats

When you have created your message set, you can create physical formats. You do this using the Message Set Editor. When you next save the messageSet.mset file, any new physical formats are added to all the objects in all the message definition files in that message set.

The next time you edit an object in a message definition file, you see the physical formats in the properties hierarchy pane of the Properties tab. If you click a physical format for an object, you are presented with a property sheet where you can enter the information for that physical format for that object.

Not all objects have properties in all physical formats. For example:

CWF properties apply only to local elements and attributes, and element and attribute references.
Complex types and groups have only TDS properties.
Messages have only XML properties.

These differences occur because of the different nature of each physical format, and are explained in more detail in the section for each physical format.

There is no limit to the number of physical formats you can create in a given message set. However there are some recommendations that apply if you want to mix physical formats of different kinds in the same message set.

Physical formats can be deleted if no longer required.