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.

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:

• The message now contains information only about the customer's name, and the videos the customer has on loan. The message no longer contains information about things such as whether the customer has received a magazine, or which kind of identifier (passport, driving license, or credit card) was used.
• The cost of the videos has been multiplied by two.

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:

• P for PassportNo
• D for DrivingLicenseNo
• C for CreditCardNo

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:

• For the changes to the XML and TDS messages, xxxxxx in the table stands for any set of alphanumeric characters.
• When you make changes to the CWF message, ensure that the total length of all fields, including blanks, remains the same as before.

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