About the Video Rental sample message set

The figure shows the logical format and objects that make up messages in the Video message set. For a description of the diagram, see Structure of the message model.

The Video sample message model. For a description of the figure, follow the link to the Structure of the message model.

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, see The message model 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, and the unshaded boxes represent elements that are based on simple types. 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, but 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 be used only 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 can 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, see 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 can 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 have 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 can 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 can have several meanings; it can mean the name of a customer, or the name of a product. One way of avoiding the problem is to create objects with names like CustomerName and ProductName, but this format 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, see Namespaces in the message model 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, see Physical formats in the MRM domain in the WebSphere Message Broker documentation.

The CWF input message

The following example shows the Video customer message in the CWF physical format (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. The following example is what the Video customer message looks like in the Custom Wire Format if the different fields are 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 shown in the following example:

<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 following example shows the Video customer message in the TDS format (the data is 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 by using tags and delimiters in the messages themselves. However, the CWF message does not contain tags or delimiters, therefore, the choice must be resolved by 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, which 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 preceding diagram of the message structure. For example, to explore the element Name:

  1. In the Broker Development view, double-click Customer.mxsd.
  2. In the Outline view, click Types.
  3. In the Message Definition editor, expand the type called NameType.
  4. Click one of the elements (Title, FirstName, or 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