Skip to main content

By clicking Submit, you agree to the developerWorks terms of use.

The first time you sign into developerWorks, a profile is created for you. Select information in your profile (name, country/region, and company) is displayed to the public and will accompany any content you post. You may update your IBM account at any time.

All information submitted is secure.

  • Close [x]

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerworks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

By clicking Submit, you agree to the developerWorks terms of use.

All information submitted is secure.

  • Close [x]

developerWorks Community:

  • Close [x]

Getting started with record and replay in WebSphere Message Broker V8

Steve Haskey (haskey@uk.ibm.com), Software Engineer, WebSphere Message Broker UI Development team, IBM
Photo of Steve Haskey
Steve Haskey has worked for IBM for 12 years, both in California and the UK, on a number of WebSphere middleware products. You can contact Steve at haskey@uk.ibm.com.
Peter Masters (pmasters@uk.ibm.com), Software Engineer, WebSphere Message Broker Development team, IBM
Photo of Peter Masters
Peter Masters has worked for IBM for 13 years at the IBM Software Lab in Hursley Park, United Kingdom. His product expertise includes CICS, WebSphere Application Server, and WebSphere Message Broker. You can contact Peter at pmasters@uk.ibm.com.
Anton Piatek (anton.piatek@uk.ibm.com), Software Engineer, WebSphere Message Broker Development and Test team, IBM
Photo of Anton Piatek
Anton Piatek is a Software Engineer on the WebSphere Message Broker Development team at the IBM Software Lab in Hursley Park, United Kingdom. He has worked on many WebSphere Message Broker teams, including Development, Performance, Service, Functional Test, and Regression Test. You can contact Anton at anton.piatek@uk.ibm.com.
Dominic Storey (dstorey@uk.ibm.com), Software Engineer, WebSphere Message Broker Development team, IBM
Photo of Dominic Storey
Dominic Storey is a Software Engineer on the WebSphere Message Broker Development team at the IBM Software Lab in Hursley Park, United Kingdom. He has over 15 years of development experience on WebSphere MQ, WebSphere Message Broker, and related messaging technologies. You can contact Dominic at dstorey@uk.ibm.com.

Summary:  WebSphere Message Broker V8 introduces the new record and replay feature, which lets you record and view messages for audit or problem determination purposes, and replay them after problem resolution or other downtime issues. This tutorial shows you how to use event monitoring to emit a message from a flow, how to configure record and replay, and how to use the new web UI to view messages that you have recorded and replay them to a WebSphere MQ queue.

Date:  05 Dec 2012
Level:  Intermediate PDF:  A4 and Letter (1714 KB)Get Adobe® Reader®

Activity:  396 views
Comments:  

Adding monitoring to your flows for record and replay

In this section, you create a simple application containing a flow, then add monitoring events to the flow, which are picked up by the default execution group and stored in the datacapturestore database that you just defined and connected to MB8BROKER.

You can download the mbtest files and BAR files at the bottom of the article.

  1. Create a new application using the Message Broker Toolkit: New Application
  2. Create your TestFlow flow:
    Create Test Flow

    Here is a simple flow: MQInput Node (Queue Name=INQ) => PassThrough Node => MQOutput Node (Queue Name=OUTQ), with the Catch and Failure terminals connected to an MQOutput Node (Queue Name=FAILQ):

    Basic Flow
  3. Now you have a simple flow and can add monitoring events to it. You want an audit event to fire whenever the message leaves the Out terminal of the INQ, and an exception message to fire whenever the message goes down the Catch terminal to the FAILQ. Click on the INQ node to select the Monitoring tab in the Properties and then click Add.
  4. Select the Event Source as Out Terminal and tick Include bitstream in payload to include the bitstream in the event message, so that the broker emits an event every time a message goes out of this terminal and attaches the bitstream, which the recording broker can listen for and then place into the broker's record and replay database: Add Out monitoring
  5. For the failure case you want to add another monitoring event, but this time select the source as Catch Terminal, add in the data location as $ExceptionList, and include the bitstream as before. Any exception information will also be sent to the record and replay database and can be viewed there. At present the broker only records bitstreams and ExceptionLists, and any other environment properties set there are ignored: Add Catch monitoring
  6. Check that your monitoring has been correctly set up by looking at your flow overview. You should have two monitoring events created: Monitoring summary
  7. Before deploying this flow to the default broker, make sure that the queues are created and available. Using Message Broker Explorer, create the queues: INQ, OUTQ, and FAILQ: Setup Queues in MBX
  8. You are now ready to deploy the TestApplication. Right-click on the flow, select Deploy, and then select the default execution group. After a few seconds you should see your deployed application in the broker: Deploy Test Application The Test app running
  9. Every time you deploy, flow monitoring is turned off by default, so after you have deployed the application, make sure you turn on flow monitoring using the command:
    mqsichangeflowmonitoring MB8BROKER -e default -k TestApplication 
        -f TestFlow -c active

    Turn on flow stats
  10. Run the command below to verify that monitoring is enabled for your flow:
    mqsireportflowmonitoring MB8BROKER -e default -k TestApp

  11. Now that you have the application deployed, you need to test that the flow is working by sending some test messages using the Message Broker Toolkit test client. Select File => New Message Broker Test Client and create a message named TestMsg:
    New Test Message
  12. You want to enqueue a test message to the MQ queue INQ on the queue manager MB8QMGR, and make sure that it gets to OUTQ. Enter some test message data so that you can view this payload later in the Web Administration: The new test message properties
  13. After the message has been sent, you can check that it has been sent to OUTQ by looking in Message Broker Explorer and inspecting the queues. You will see a queue depth of 1 on OUTQ: Sent message in MBX
  14. Next, test the behaviour of FAILQ. Change OUTQ so that it is put-inhibited by using Message Broker Explorer: Put inhibit the OUTQ
  15. Now when you send a message, the flow will not be able to put the message to OUTQ, and the message will be caught and routed by the INQ MQInput node and routed to FAILQ. On its way there it will fire a monitoring event capturing the ExceptionList and payload of the message for the Record and Replay database. Here you can see that the second test message has been routed to the FAILQ as expected: Sent message on FAILQ

In the next section, you set up the broker to listen for the monitoring events you have set up here, so it can route them to the Record and Replay database.

4 of 10 | Previous | Next

Comments



static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=850776
TutorialTitle=Getting started with record and replay in WebSphere Message Broker V8
publish-date=12052012
author1-email=haskey@uk.ibm.com
author1-email-cc=
author2-email=pmasters@uk.ibm.com
author2-email-cc=
author3-email=anton.piatek@uk.ibm.com
author3-email-cc=
author4-email=dstorey@uk.ibm.com
author4-email-cc=