About the Video message set

The figure shows the logical format and objects that make up messages in the Video message set. You can also read a description of the figure here .

The Video sample message model. To read a description of the figure, follow the link above it.

The Video message set is a component of the Video Rental sample message model. From the message model you can see how to build up a logical message model and its associated physical formats. In the Video Rental sample, the message model contains data for a customer who is borrowing videos. Data contained in the messages includes:

For more information, read about message models in the WebSphere Message Broker documentation.

Elements in the message model

The elements in the message model are based on complex and simple types. The shaded boxes represent the elements that are based on complex types, while the unshaded boxes represent elements that are based on simple types. As you can see in the figure, the message model contains fourteen elements based on simple types. Simple types are data types, such as string, integer, and byte. These simple types are the basis of the unshaded elements in the figure. Except for the elements ID and Magazine which are direct children of Customer, all simple elements in the message model are children of complex elements or a group. These complex elements and the group are children of the complex type Customer. A complex type is a structure definition, which is effectively a template for the data contained within it. These complex types are the basis of the elements that are shaded grey in the figure.

Complex types can be either named or anonymous. In the Video message model, Address and Borrowed have anonymous (local) complex types, while Name has a named (global) complex type. A named complex type can be used elsewhere, for example in other schemas, whereas an anonymous complex type can only be used in the declaration that contains it. Using named complex types has some clear advantages. By using named complex types you can, for example, share information more easily across your organization. However, there are circumstances in which it can be preferable to use anonymous complex types, such as when a complex type must not be reused elsewhere.

The object called IdGroup is different from the other elements in the message in that it is a group. IdGroup helps define the way in which the elements PassportNo, DrivingLicenseNo, and CreditCardNo behave. When a customer opens a new account at the video store, only one type of identifier is needed to prove identity. By creating a group, and defining PassportNo, DrivingLicenseNo, and CreditCardNo as members of that group, you can configure the message model so that you can choose only one of the three types of identifier. That is, the three elements are treated as a choice within the type above. If you include the elements directly in a type, all three elements could be entered at the same time.

To demonstrate different ways of constructing a message model, the object called LastName is created as an attribute rather than as an element. Creating an object as an attribute affects the way the XML is constructed.

For more information, read about message model objects in the WebSphere Message Broker documentation.

Namespaces

The Video Rental sample also demonstrates the use of namespaces in the message model, in the XML input message, and in the ESQL that is used by the message flow to reference parts of the message. The Video Rental sample has three message definitions. The message definition file for the Customer information does not have a target namespace. However, the message definition files for the Address and Borrowed information do have target namespaces. The message definition files for Address and Borrowed are imported into the message definition file for the Customer information. Placing Address and Borrowed in separate namespaces means that these elements could be easily used elsewhere for other business purposes.

Grouping information logically means that the data collected by, for example, the customer service department of a company can then be easily shared by other departments, such as invoicing or sales. It is not necessary to place objects that need to be shared in different namespaces, but there are circumstances in which this can assist sharing. For example, different developers working independently of each other could create objects with the same name, but with a different business meaning. By placing the objects in different namespaces, the sets of objects can be developed independently without name clashes.

Namespaces can be helpful even when objects are being developed by one group of developers. For example, an object called Name could have several meanings; it could mean the name of a customer, or the name of a product. One way of avoiding the problem would be to create objects with names like CustomerName and ProductName, but this can mean having excessively long names. An alternative solution is to place all the objects relating to customer information in one namespace, and all the objects relating to products in another. This way you can let the namespace that an object belongs to determine its context.

For more information, read about namespaces in the WebSphere Message Broker documentation.

Physical formats

WebSphere Message Broker supports several physical formats that let you define the physical representation of your messages in detail. For example, by adding a custom wire format (CWF) to your message sets you can process input messages in this format, construct output messages in this format, and transform messages from CWF to TDS or XML, or from TDS or XML to CWF. The input messages for the three physical formats are described in the following sections.

For more information, read about physical formats in the WebSphere Message Broker documentation.

The CWF input message

The Video customer message in the CWF physical format is shown below (note that you might need to scroll to the right to see the entire message):

Mr Fred                Bloggs              12  Willow Avenue       Salisbury           CJ123456TT          Fast Cars           2003-05-233.00Cut To The Chase    2003-05-233.751

The custom wire format does not use tags. For example, in the message above, the first field (with the value Mr) has a length of 3, but there is no tag to indicate where the field ends. Here is what the Video customer message would look like in the custom wire format if the different fields were separated onto different lines for easier reading:

Mr 
Fred                

Bloggs
12  Willow Avenue       
Salisbury           
C
J123456TT          
Fast Cars           
2003-05-23
3.00
Cut To The Chase    
2003-05-23
3.75
1

The XML input message

The Video customer message is rendered in XML as follows:

<Customer xmlns:addr="http://www.ibm.com/AddressDetails" xmlns:brw="http://www.ibm.com/BorrowedDetails">
<Name LastName="Bloggs">
<Title>Mr</Title>
<FirstName>Fred</FirstName>
</Name>
<addr:Address>
<HouseNo>13</HouseNo>
<Street>Oak Street</Street>
<Town>Southampton</Town>
</addr:Address> <ID>P</ID>
<PassportNo>J123456TT</PassportNo>
<brw:Borrowed>
<VideoTitle>Fast Cars</VideoTitle>
<DueDate>2003-05-23T01:00:00</DueDate>
<Cost>3.50</Cost>
</brw:Borrowed>
<brw:Borrowed>
<VideoTitle>Cut To The Chase</VideoTitle>
<DueDate>2003-05-23T01:00:00</DueDate>
<Cost>3.00</Cost>
</brw:Borrowed>
<Magazine>0</Magazine>
</Customer>

The TDS input message

The Video customer message in the TDS format is shown below (the data has been split into separate lines for readability):

{Name:[Title:Mr*FirstName:Fred*LastName:Bloggs]
&Address:[HouseNo:12*Street:Willow Avenue*Town:Salisbury]
&ID:P
&PassportNo:J123456TT
&Borrowed:[Fast Cars+2003-05-23+3.00]
&Borrowed:[Cut To The Chase+2003-05-23+3.75]
&Magazine:1}

Unresolved choice handling

The object IdGroup in the message represents a choice of types of identifier for the customer borrowing videos. The identifier can be either a passport number, a driving license number, or a credit card number. The number supplied in the input message maps to one of three possible (choice) fields: PassportNo, DrivingLicenseNo, or CreditCardNo. With XML and TDS messages, the choice can be resolved using tags and delimiters in the messages themselves. However, the CWF message does not contain tags or delimiters, so the choice must be resolved using ESQL and the value of the ID field in the message. The ID field contains a single character representing the type of identifier supplied by the customer: P for PassportNo, D for DrivingLicenseNo, or C for CreditCardNo.

When a CWF message containing an unresolved choice comes to an input node, the MRM parser triggers a warning message (which you can view if you trace the message flow). The processing of the message continues, but cannot be completed unless there is a subsequent node containing ESQL code that resolves the choice. ESQL code in a Compute node provides a way of referring to the logical message tree that was built as a result of the initial parsing. Because the input message was unresolved, references to the tree return null.

To decide which field (PassportNo, DrivingLicenseNo, or CreditCardNo) the identifier number is assigned to, an additional field called ID is used. The ID field contains a character to represent the type of identifier used: P, D, or C. In the message tree, this field comes before the IdGroup choice field. This means that the value of the ID field can be parsed before there is an attempt to resolve the choice. With the ID field parsed, the value can then be used in ESQL statements to resolve the choice.

To see how choice handling works, see Running the Video Rental sample and try the optional trace task. To find out what the ESQL for the sample looks like, see Creating the message flow.

Exploring properties of the elements

When you have imported the message set files into the workbench, you can explore the properties of the elements in the Video message model. What you see in the workbench corresponds to the figure of the message structure above. For example, to explore the element Name:

  1. Switch to the Broker Application Development perspective.
  2. In the Broker Development view, double-click Customer.mxsd.
  3. In the Outline view, click Types.
  4. In the Message Definition editor, expand the type called NameType.
  5. Click one of the elements (Title, FirstName, and LastName) displayed under NameType. To view the properties of these elements, click the Properties tab, and click items in the Properties Hierarchy tree to see their current settings.

You can view the other elements in a similar way. For more detailed information about how the message structure is constructed, see Building the Video Rental sample.

Back to sample home