Running the Message Routing sample

The running of the Message Routing sample can be split into two main parts:

• Using a direct connection to the database table to retrieve routing information for each message processed
• Using shared variables to store a copy of the database table in the message flow, which each message processed can make use of

These two parts are described separately. All of the test messages mentioned in this section can be found in the Test messages directory in the message flow project called Message routing sample message flows.

Input test messages

All the test messages used in running this sample are based on the following format:

<SaleEnvelope>
  <Header>
    <SaleListCount>1</SaleListCount>
  </Header>
  <SaleList>
    <Invoice>
      <Initial>T</Initial>
      <Initial>D</Initial>
      <Surname>Montana</Surname>
      <Item><Code>00</Code>
        <Code>01</Code><Code>02</Code>
        <Description>Twister</Description>
        <Category>Games</Category>
        <Price>00.30</Price>
        <Quantity>01</Quantity>
      </Item>
      <Item>
        <Code>02</Code><Code>03</Code><Code>01</Code>
        <Description>The Times Newspaper</Description>
        <Category>Books and Media</Category>
        <Price>00.20</Price>
        <Quantity>01</Quantity>
      </Item>
      <Balance>00.50</Balance>
      <Currency>Sterling</Currency>
    </Invoice>
  </SaleList>
  <Trailer>
    <CompletionTime>12.00.00</CompletionTime>
  </Trailer>
</SaleEnvelope>

The fields <Initial> and <Surname> are used for routing the message.

Running the sample

Using a direct connection to the database table to route the message

This part of the sample uses the Routing_using_database_table message flow. It contains one input queue called ROUTING.DATABASE.IN1. The message flow can route the message to one of 20 output queues based on the content of the message (ROUTING.OUT followed by a number from 1-19 plus a queue called ROUTING.DEFAULT). To run this part of the sample:

1. In the Message Brokers Toolkit, switch to the Broker Application Development perspective.
2. In the Broker Development view, expand the Message routing sample message flows project.
3. Double click on Direct_database_message1.mbtest to open the file in the Test Client.
4. In the Test Client click Enqueue.
5. Click Send Message. A message is sent to the ROUTING.DATABASE.IN1 queue. The message flow routes the message to the ROUTING.OUT1 queue.
6. In the Test Client click Dequeue.
7. Click Get Message to read a message from the ROUTING.OUT1 queue.
8. Double click on Direct_database_message2 to open the file in the Test Client
9. In the Test Client click Enqueue.
10. Click Send Message to get the routed message from the ROUTING.OUT19 queue.

If all the steps above are successful, then the first part of the sample is complete. Take a look at the ESQL in the message flow Routing_using_database_table to see how the routing was done.

Using an in memory cache of the database table to route the message

This part of the sample makes use of the message flow Routing_using_memory_cache. It contains two input queues called ROUTING.MEMORY.IN1 and ROUTING.REFRESH.IN1 and the message flow can route the message to one of 20 queues based on the content of the message (ROUTING.OUT followed by a number from 1-19 plus a queue called ROUTING.DEFAULT). The routing logic is the same as in the non-cached version. The only difference is the database is cached in memory using shared variables. The steps to run this part of the sample are:

1. Open Memory_cache_message1.mbtest in the Test Client, and use Enqueue to write the message to the queue.
2. Use Dequeue to get the message from the ROUTING.OUT1 queue.
3. Open Memory_cache_message2.mbtest in the Test Client, and use Enqueue to write the message to the queue.
4. Use Dequeue to get the message from the ROUTING.OUT19 queue.
5. Up to this point the flow is behaving exactly the same as the last flow as far as functionality is concerned but it is using a cached version of the database table. To test the effect of using the cache, the database table will be modified to show how the in memory cache can be refreshed. To modify the database table:

   DB2

   1. Enter the following command in a DB2 Command Window (on Windows) or a command console (on Linux):

      db2cmd

   2. From the command prompt type db2 to start the DB2 command line.
   3. Connect to the ROUTING database:

      DB2> connect to ROUTING user user using password

      where user is a user that has the authority to access the ROUTING database. This is normally the
      same user as was used to create the sample broker. password is the password used for that user.

   4. Update the last entry in the routing_table to Send Message ROUTING.OUT18

      DB2> update routing_table set queue_name='ROUTING.OUT18' where Variable3='Braithwaite'

   Derby

   1. Start the ij command line. If you have not already set up the batch file for the ij command line, see Viewing the contents of a Derby database.
   2. Update the last entry in the routing_table to Send Message ROUTING.OUT18:

      ij>update routing_table set queue_name='ROUTING.OUT18' where Variable3='Braithwaite';

6. Open Memory_cache_message2.mbtest in the Test Client, and use Enqueue to write the message to the queue.
7. Use Dequeue to get the message from the ROUTING.OUT19 queue. Notice that the message is not being routed to the new queue name because the database table has not been reread.
8. To make the flow reread the database open Refresh_cache_message1.mbtest, and use Enqueue to write the message to the queue.
9. Repeat step 3 to send a test message to the message flow.
10. Use Dequeue to get the message from the ROUTING.OUT18 queue. The database table stored in memory has now been refreshed.

Steps 5-10 can be repeated by changing the queue_name in the database to one of the other queue names that are available. Instead of using the Refresh_cache_message1 message the message flow can be stopped and restarted. This will also cause the cached database table to be refreshed.

If all the steps above are successful, then the running of the sample is complete. Take a look at the ESQL in the message flow Routing_using_memory_cache to see how the storing of the database in shared variables was done.

Understanding the results

The Message Routing sample routes the input test message to various output queues without modifimg the output. The output message is identical to the input test message. The steps given in the two parts, detail where the messages are routed to. It can be checked that the messages are routed to the correct queue using WebSphere MQ Explorer as well as using Dequeue in the Test Client.

Back to sample home