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.
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.
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:
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.
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:
DB2
db2cmd
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.
DB2> update routing_table set queue_name='ROUTING.OUT18' where Variable3='Braithwaite'
Derby
ij>update routing_table set queue_name='ROUTING.OUT18' where Variable3='Braithwaite';
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.
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.