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:  

Setting up the record and replay database

To store recorded messages, WebSphere Message Broker uses a database. Therefore you need to set a database with the necessary tables, and configure the broker to use them.

This tutorial uses IBM DB2. To define the necessary tables, the broker installation includes an SQL script , located at {install path}/ddl/db2/DataCaptureSchema.sql. You will need to customize the script to suit your recording needs and database naming standards. At the top of the file, you will find the database name MBRECORD, and you can optionally use a database schema:

. . . 
CREATE DATABASE MBRECORD;
CONNECT TO MBRECORD;
-- If you want to use a different schema, edit and uncomment the following lines
--CREATE SCHEMA WMB;
--SET SCHEMA WMB;
. . .

Consider the size of messages that you want to record. If you are capturing large message payloads, you may need to increase the amount of space allocated from the default of 5 MB. You can change the size in bytes for the DATA field in the WMB_BINARY_DATA table:

. . .  
CREATE TABLE WMB_BINARY_DATA                    
(                                              
   WMB_MSGKEY    VARCHAR(100) NOT NULL,          
   DATA_TYPE     INTEGER      NOT NULL,          
   ENCODING      VARCHAR(50)  NOT NULL,          
   DATA          CLOB(5242880)                
 )  
 . . .

In this case, leave the settings at their default values and create a database MBRECORD that can hold 5 MB. Then run the script using the command db2 -tvf DataCaptureSchema.sql from a db2 command shell. Check that the statements executed correctly before continuing.

The next task is to create an ODBC datasource for this database so that the broker can connect to it. This task is platform-dependent -- for more information, see Enabling ODBC connections to databases in the WebSphere Message Broker V8 information center.

Important: If you are using a 32-bit installation of WebSphere Message Broker on Microsoft® Windows® 64-bit, then make sure you are using the 32-bit version of the ODBC configuration panel, because the configurations are separate. For details, see the information center topic above. In this example, use the name MBRECORD for the ODBC definition to match the database name.

The database should now be configured and ready to use, and you can now connect the broker to the database. Since the broker is called MB8BROKER, use the following mqsisetdbparms command to store the database credentials:

mqsisetdbparms MB8BROKER -n odbc::MBRECORD -u {DBUSER} -p {DBPASSWORD}

After this command completes successfully, restart the broker to pick up the new credentials. Then use the themqsicvp command to verify that the database connection is correct:

mqsicvp MB8BROKER -n MBRECORD -u {DBUSER} -p {DBPASSWORD}

If successful, this command returns a list of supported operations against the database.

The final task here is to configure the database for record and replay by introducing the first of three new configurable services, the DataCaptureStore. This configurable service definition is important, since it represents access to the recorded messages for a number of purposes, as you will see later. Messages are recorded, viewed, and replayed using this DataCaptureStore. This DataCaptureStore configurable service is dynamic, meaning that you won't need to restart the broker for the changes to be picked up. The other two configurable services described below are also dynamic -- DataCaptureSource, and DataDestination.

You can define a DataCaptureStore either via the command line or in Message Broker Explorer. The image below uses the Explorer, but command-line equivalents are also shown. This example assumes that you have already created and started MB8BROKER. Note that it is the execution groups that will record, view, and replay the message data, and you need to specify which execution groups have that task. You can have different execution groups (and even different brokers) perform these tasks to a single database.

  1. Open up the Message Broker Explorer interface and navigate to the Configurable Services section in the left-hand tree view under MB8BROKER. Right click and select New => Configurable service: Add Out monitoring
  2. Change the configurable service type to be a DataCaptureStore. Initially, you will see values created based on the IBM-provided template definition, which you can then change.
  3. For the broker to access the database, you just need to configure the dataSourceName to match the name of your ODBC definition above (MBRECORD). If you defined a database schema in the SQL, it will also need to be put in the schema property.
  4. The other properties are used when recording messages. The first important (and mandatory) property to set is egForRecord, which denotes which execution group performs the recording. You can leave the remaining properties at their default values. When configured to record messages, the designated execution group creates a number of threads that wait for messages and place them in the database. Tuning this thread pool in order to get the maximum throughput for the message workload is the purpose of the other properties shown here.

3 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=