Running the Video Rental sample

Before you start you must have imported and deployed the Video Rental sample. When you imported the sample there might have been a number of warnings relating to .msgflow files. These are database related and will not affect the running of the sample.

This topic explains how to put the CWF, XML, and TDS input messages through the Video message flow. It also explains how to check that the sample works and you received the correct result.

If you encounter any problems when you run the sample, see Diagnosing problems.

Running the sample

To run the sample, you must put messages on the input queues and get messages from the output queue. Start by putting one of the messages on the corresponding input queue, as indicated in the table below. If you have set up the sample correctly, a reply message is put on the VIDEO_OUT queue. You can then repeat the process for the other messages.

File Input queue
videomsgcwf.mbtest VIDEO_CWF_IN
videomsgxml.mbtest VIDEO_XML_IN
videomsgtds.mbtest VIDEO_TDS_IN

To put a message on the relevant queue:

  1. In the Message Brokers Toolkit, switch to the Broker Application Development perspective.
  2. In the Broker Development view, expand the Video Message Flows project, then double-click one of the .mbtest files to open it in the Test Client.
  3. In the Test Client click Enqueue.
  4. Click Send Message to put the message to the input queue.

To get a message from the VIDEO_OUT queue:

  1. In the Test Client click Dequeue.
  2. Click Get Message to read a message from the VIDEO_OUT queue.

Understanding the results

When you put a message through the message flow, you receive a message on the VIDEO_OUT queue. The following transformation has taken place in the message:

Optional: Changing the value of the identifier field

In the three input messages, the ID field contains a single character representing the type of identifier supplied by the customer:

The IdGroup field in the message indicates what the number of that passport, driving license, or credit card was. To find out why the messages are organised like this, see Structure of the message model.

In the XML and TDS messages, the type of identifier used is a passport. In the CWF message, the identifier is a credit card. If you want to see the effect of changing the type of identifier used to a driving license, make the changes shown in the table below and then put the messages on the corresponding input queues as usual. To edit the files in the workbench, double-click the file in the Broker Development view. This opens the file in the editor view. When you make the changes, take the following into account:

File name Old value New value
videomsgxml.mbtest <ID>P</ID> <ID>D</ID>
<PassportNo>J123456TT</PassportNo> <DrivingLicenseNo>xxxxxx</DrivingLicenseNo>
videomsgtds.mbtest &ID:P&PassportNo:J123456TT &ID:D&DrivingLicenseNo:xxxxxx
videomsgcwf.mbtest C (between Salisbury and J123456TT) D

 

Optional: Tracing the message flow

To explore how the CWF parser handles unresolved choices, you can trace the message flow. To find out more about unresolved choice handling in this sample, go to the Related information section at the end of this topic and follow the link for Exploring the message set.

To explore how unresolved choice handling works:

  1. Insert a Trace node between the Extract Fields node and the VIDEO_OUT node, with the Pattern property set to ${Root}.
  2. Put the videocwfmsg.mbtest file through the message flow, and trace the message flow. The trace will show the message tree with the identifier number placed in the correct choice field. You can also view a part of the trace relating to unresolved choice handling:

    The following part of the trace relates to unresolved choice handling:

    (0x0100001B):MRM = (
      (0x01000013):Name = (
        (0x0300000B):LastName = 'Bloggs '
        (0x0300000B):Title = 'Mr '
        (0x0300000B):FirstName = 'Fred '
    
      )
      (0x01000013)http://www.ibm.com/AddressDetails:Address = (
        (0x0300000B):HouseNo = 12
        (0x0300000B):Street = 'Willow Avenue '
        (0x0300000B):Town = 'Salisbury '
      )
      (0x0300000B):ID = 'C'
      (0x0300000B):CreditCardNo = 'J123456TT '
      (0x01000013)http://www.ibm.com/BorrowedDetails:Borrowed = (
        (0x0300000B):VideoTitle = 'Fast Cars '
        (0x0300000B):DueDate = TIMESTAMP '2003-05-23 00:00:00'
        (0x0300000B):Cost = 3.00
      )
      (0x01000013)http://www.ibm.com/BorrowedDetails:Borrowed = (
        (0x0300000B):VideoTitle = 'Cut To The Chase '
        (0x0300000B):DueDate = TIMESTAMP '2003-05-23 00:00:00'
        (0x0300000B):Cost = 3.75
      )
      (0x0300000B):Magazine = TRUE

    Notice that in the trace, the fields Title, FirstName, and LastName do not appear in the same order as they do in the CWF input message. In the input message, the fields appear in the order Title, FirstName, and LastName, but when the message is parsed, the parser puts the attribute LastName in the logical tree above the name-value pairs which represent the child elements (Title and FirstName) of NameType.
  3. Change the value of the ID field in the videocwfmsg.mbtest file from C to either P or D.
  4. Put the modified message through the message flow, and observe the different results in the trace.

Back to sample home