Running the Message Routing sample

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

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. Open the test message enqueue file called: Direct_database_message1.
  2. Click Write to queue. A message is sent to the ROUTING.DATABASE.IN1 queue. The message flow routes the message to the ROUTING.OUT1 queue.
  3. To check the message has reached the correct queue use WebSphere MQ Explorer:
    1. Start WebSphere MQ Explorer
    2. Right-click the Queue Managers folder and select Show queue manager. Enter WBRK6_DEFAULT_QUEUE_MANAGER.
    3. Expand the folders under the queue manger and select Queues. Refresh the queue display to show the current number of message on each queue. If you are using WebSphere MQ v5.3 on Windows, when you refresh WebSphere MQ Explorer make sure that the Queues folder is selected and not an actual queue name otherwise not all the queues shown will be refreshed.
    4. Use WebSphere MQ Explorer for the rest of the sample to make sure messages are routed to the correct location.
  4. Open the enqueue file called Direct_database_message2 and write the message to the queue.
  5. Refresh WebSphere MQ Explorer. A message should appear on the ROUTING.OUT19 queue.

If all the steps above have worked 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 the test message enqueue file called: Memory_cache_message1 and write the message to the queue.
  2. Refresh WebSphere MQ Explorer. A new message should appear on the ROUTING.OUT1 queue (a total of two messages).
  3. Open the test message enqueue file called Memory_cache_message2 and write the message to the queue.
  4. Refresh WebSphere MQ Explorer. A new message should appear on the ROUTING.OUT19 queue (a total of two messages).
  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 write to queue 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 write to queue ROUTING.OUT18:

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

  6. Open the Test message enqueue file called: Memory_cache_message2 and write the message to the queue.
  7. Refresh WebSphere MQ Explorer. A new message should appear on the ROUTING.OUT19 queue (a total of three messages). 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 enqueue file: Refresh_cache_message1 and write the message to the queue.
  9. Repeat step 3 to send a test message to the message flow.
  10. Refresh WebSphere MQ Explorer. A new message should appear on the ROUTING.OUT18 queue (a total of one message). The database table stored in memory has now been refreshed.

Steps 5-10 can be repeated but 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 have worked 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 detailed in the steps above). Also, it is possible to check the content of the messages on the queues using the dequeue program which is part of the Message Brokers Toolkit. To access the dequeue program click on the dequeue icon on the toolkit tool bar:

location of the dequeue program

Main Page icon   Back to sample home