• This exercise presumes successful completion of Exercise 1. Consult with your instructor if you have doubts about your success with Exercise 1.
• Having completed Exercise 1, an instance of the WebSphere Message Broker Toolkit should be running.
• This exercise maps directly to the order of the lecture material as it appears in Unit 3 of your Student Notebook.
Part 1: Work with a simple message flow
Hint
See topic 2 of Unit 3 in your Student Notebook.
__ 1. Import a message flow project into your workspace.
__ a. Switch to the WebSphere Message Broker Toolkit, and, if not already open, open the Broker Application Development perspective. One way is to click Window >
Open Perspective > Other > Broker Application Development.
__ b. From the menu bar, select File > Import.
__ c. In the Import window, expand Other.
__ d. Click Project Interchange from the list and then click Next.
__ e. Click Browse next to From zip file and go to the C:\Labs\Lab2\resources directory.
__ f. Click EX2_PROJECT.zip and then click Open.
__ g. Check EX2_PROJECT.
__ h. Click Finish.
WebSphere Message Broker imports the project and constructs the workspace.
The EX2_PROJECT should now appear in your Broker Development navigator view.
EXempty __ b. Open the Message Flow editor by double-clicking Ex2Flow.msgflow. The Message Flow editor initializes in the Editor pane.
__ 3. Examine the message flow. Verify that it agrees with the figure that appears at the beginning of the exercise.
__ 4. The properties of each node in the message flow have been preset to perform the transformation described in the beginning of the exercise. Node properties should agree with the following table.
__ a. You can verify (or change) a property by right-clicking a node and selecting the Properties view.
__ b. Node properties are grouped in pages. The Basic page is initially visible.
Part 2: Deploy a message flow with a broker archive file
Hint
See topic 3 of Unit 3 in your Student Notebook.
__ 1. The project you imported does not contain a Broker Archive file (.bar).
Import the broker archive file, Ex2.bar, that contains the Ex2Flow.msgflow in a form suitable to be delivered to a broker.
__ a. From the menu bar, select File > Import.
Node name Node type Properties
EX2_IN MQInput (Basic) Queue name = EX2_IN
(Input Message Parsing) Message Domain = XMLNSC
(Advanced) Transaction mode = Yes TraceExList Trace (Basic) Destination = User Trace
REPLYQ MQReply no changes
FAILUREQ MQOutput (Basic) Queue name = FAILURE Test_Version=2 Filter ESQL (see node properties) Add_Date_Time Compute ESQL (see node properties)
CATCHQ MQOutput (Basic) Queue name = CATCH
UNKNOWNQ MQOutput (Basic) Queue name = UNKNOWN
FALSEQ MQOutput (Basic) Queue name = FALSE
__ b. In the Import Select window, expand General.
__ c. Click File System from the list and then click Next.
__ d. Click Browse for the From directory and go to the C:\Labs\Lab2\resources directory.
__ e. Click OK.
__ f. Check the box next to Ex2.bar. Use the second Browse button (beside the Into Folder text entry box) to go to your workspace, select the EX2_PROJECT, and then click OK.
__ g. On the Import File System window, click Finish.
WebSphere Message Broker imports the broker archive file into the project under the Broker Archives subtree.
__ 2. Examine the BAR file, Ex2.bar, that contains the Ex2Flow.msgflow in a form suitable to be delivered to a broker:
__ a. In the Navigator, fully expand the Broker Archives subtree.
__ b. Open the Broker Archive editor by double-clicking the file Ex2.bar.
__ c. The Broker Archive editor should open on the Manage tab; if not, click the Manage tab to show the BAR file contents.
The top-level component in the BAR file is the compiled message flow (.cmf).
__ d. View the contents of message flow file by clicking the plus (+) sign. The BAR file should contain one message flow named Ex2Flow.
__ e. View the contents of message flow by clicking the plus (+) sign next to Ex2Flow.
You should see an entry for each node in the message flow. The nodes are listed in alphabetic order.
__ f. Look at the contents of the Properties tab as you click each node in the Broker Archive editor. These are the node properties that can be overridden in the BAR file.
__ 3. Deploy the broker archive file (.bar) from the Broker Development Navigator view.
__ a. In the Broker Development Navigator view, right-click Ex2.bar and then select Deploy from the context menu.
__ b. Select the execution group named EXGRP1 as the target for the deployment.
EXempty __ b. Expand the Brokers tree in the Brokers view until you see the message flow, Ex2Flow, as a child element of the EXGRP1 execution group for broker
DEVBROKER.
If the icon next to message flow is a green, up arrow, the flow has been successfully deployed and is running.
If the icon is a yellow triangle, examine the Problems view (to the right) for additional status information. It might be that the message flow is deployed but not yet running. The icon might disappear on its own (it might take several seconds) or the flow might require a manual start (right-click Ex2Flow and select Start).
__ c. Click the Deployment log tab. The Deployment log shows whether the BAR file has been deployed successfully.
__ d. Expand the message in the Deployment log by clicking the plus sign (+).
BIPnnnns messages preceded with a blue icon imply success; a yellow icon serves as a warning, and a red icon indicates a failure.
Part 3: Test the message flow
There are two main test tools available for testing message flows: the WebSphere
Message Broker Toolkit Integrated Test Client and RfhUtil. For this exercise, you will use WebSphere Message Broker Explorer and the RfhUtil program contained in SupportPac IH03.
Hint
See topic 4 of Unit 4 in your Student Notebook.
__ 1. Use the WebSphere MQ runmqsc command to define the queues required for this exercise. A script has been prepared for this purpose.
__ a. Start a WebSphere Message Broker command console.
__ b. Change to the C:\Labs\Tools directory: cd C:\Labs\Tools __ c. Enter the command: runmqsc DEVQMGR < Ex2_Q_Defs.txt
__ d. Examine the screen and verify success. The following queues required by the message flow should have been created: EX2_IN, EX2_REPLY, FAILURE, UNKNOWN, FALSE, and CATCH. A seventh queue, EX6_IN, used in a later exercise is also created.
__ 2. The message flow is waiting for a message to appear on the EX2_IN queue. After it does, the message flow dequeues the message and sends it through the message
flow. You use RfhUtil to read a message from a file and put the message on the queue to start the process.
__ a. In the WebSphere MQ Explorer navigator pane, under the DEVQMGR queue manager, click Queues.
__ b. Examine the EX2_IN queue. The Open input count value is 1. This means that an application (message flow) is waiting for a message to be put on that queue.
__ 3. Start RfhUtil by double-clicking rfhutil.exe in the C:\Labs\Tools directory or the shortcut icon on the Windows desktop.
__ 4. Enter the following parameters on the Main tab in RfhUtil:
• Queue Manager Name: use the drop-down list to select DEVQMGR • Queue Name: use the drop-down list to select EX2_IN
__ 5. Click Open File. A file selection window is displayed.
__ 6. Go to C:\Labs\Lab2\data, select the file Test_V2_msg.xml, and then click Open.
EXempty __ 7. The RfhUtil Main tab should now be displayed.
The message reports that 35 bytes were read from the file.
__ 8. Examine the data that was read into RfhUtil by switching to the Data tab.
The input file name and byte count are displayed in the message above the data display window. Based on the format, the data appears to be XML. To the right of
the data window is a set of radio buttons labeled Data Format. Select XML and note how the data format changes. Try some of the other formats to see the other formats that are available.
__ 9. In the message flow, the REPLYQ message flow node is an MQReply node. A message routed to an MQReply node must have an MQ queue name included in the message (as part of the MQMD) so that the MQReply node knows where to send the message.
You can specify that value (and any other MQMD values) in RfhUtil in the MQMD tab. Switch to the MQMD tab.
For Reply To Queue, enter: EX2_REPLY.
__ 10. You are ready to send the test message to the queue for processing by the message flow. Before you do, re-examine the message flow diagram. Given the test data that you are about to send to the queue, what do you think the message flow will do with the message? Where will the message end up?
________________________________________________________________
_______________________________________________________________
__ 11. To send the test data:
__ a. Switch to the Main tab.
__ b. Since you want to write the test data to the queue you have specified, click Write Q. Note the message that reports the number of bytes written and to which queue.
__ 12. Based on your answer to step 10, where did the message go? The possible destination queues are EX2_IN, EX2_REPLY, UNKNOWN, FALSE, CATCH, and FAILURE.
Use WebSphere MQ Explorer to determine the location of your test message. One way to determine which queue was the destination is to examine the Current queue depth column. A queue depth greater than zero indicates a message is waiting on that queue, as shown here:
EXempty Select Refresh Interval. Enter the wanted refresh frequency in seconds and click OK.)
__ 13. You can browse the data in the queue using either WebSphere MQ Explorer or RfhUtil:
__ a. To browse using WebSphere MQ Explorer:
• Right-click the queue to be browsed • Click Browse messages
__ b. To browse using RfhUtil:
• Click the desktop shortcut icon to start a second instance of RfhUtil (you can use the instance you already have open, but when you are testing and working with several queues at one time, it can be more efficient to have a separate instance of RfhUtil open for each queue you are working with).
• Enter the queue manager and queue name you want to browse.
• Click Browse Q. Note the message that appears to report the size of the message you are browsing.
You can instead click Read Q instead of Browse Q. What is the difference between the two operations?
______________________________________________________________
_____________________________________________________________
• Switch to the Data tab to view the data. Again, click the appropriate Data Format radio button to display the data in the wanted format.
Using this test data, the resulting message should appear as follows:
<OutMsg>
<Version>2</Version>
<TimeIs>current time stamp</TimeIs>
<DateIs>current date stamp</DateIs>
</OutMsg>
__ 14. The message should have appeared on the EX2_REPLY queue. If your message is not on EX2_REPLY, perform the following checks:
- Is the message still on the EX2_IN queue?
YES NO
• Is there a message flow running that consumes messages from EX2_IN (Open Input Count= 1)?
• The message flow might be deployed, but in a stopped state. Check the Brokers view in the WebSphere Message Broker Toolkit or WebSphere MQ Explorer.
Examine the icon next to the message flow. If necessary, start the message flow.
- Is the message on the CATCH queue? If so, check the Windows Event Log to determine the cause of the runtime error.
- Is the message on the FALSE or UNKNOWN queue? If so, check your test message. Is the <Version> field present? Does <Version> = 2?
__ 15. Test your message flow with the other test files that exist in the C:\Labs\Lab2\Data directory.
Given the data in the message you submit for each test, you should be able to predict how the message flow will process the message and where the message ends up.
__ 16. As a further test, use WebSphere MQ Explorer to set the Put Message property of the EX2_REPLY queue to Inhibited; then repeat the test using the original
(<Version> =2) test message. To what queue will your message be routed? Where else might your message end up? Can you explain why? The upcoming unit on Problem determination will help with the answer.
__ 17. After you have completed testing, stop the message flow by right-clicking the message flow in the Brokers view and selecting Stop from the menu.
__ 18. Remove the message flow from the execution group by right-clicking the message flow in the Brokers view and selecting Delete from the menu.
END OF EXERCISE
• Is the message backout counter > 0 and increasing?
• If Open Input Count for EX2_IN = 0, but the deployment was successful, then you might have a typographical error in the input queue name of the MQInput node.
This should also be visible in the Windows Event Log.
• Is the message backout counter > 0 and increasing?
• If Open Input Count for EX2_IN > 1, there are multiple message flows consuming messages from EX2_IN. In this case, input messages are randomly processed by different flows (this is more likely to happen in later exercises, should you duplicate one flow to serve as a starting point for another).