Running the Error Handler sample

Running the Error Handler sample consists of putting each of the messages through the message flows. You can run the sample to learn what happens in the following situations:

For more information, see About the Error Handler sample.

If you have not configured DB2 and WebSphere MQ as described in the setup instructions, you cannot observe the effects of using different units of work in a message flow when you run the sample. However, you can still explore the other aspects of the sample.

If you are running the Error Handler sample on Windows, the following instructions assume that you have installed the full version of DB2 Universal Database. If you used the Express Installation method on the Launchpad to install only the ODBC drivers for Cloudscape, the DB2 Control Center is not available and you cannot use it to check for changes in the Error Handler sample's database tables.

When you run the sample, you might see error messages like Unresolvable database table reference T.CLASSTYPE in the Problems view. This warning indicates that definitions for the database tables have not been imported into the project. This does not affect the behaviour of the sample at run time.

If you have any problems when you run the sample, see Diagnosing problems.

Running the sample with a message that contains a valid staff number

To run the sample with the message that contains a valid staff number:

  1. In the Message Brokers Toolkit, switch to the Broker Application Development perspective.
  2. In the Broker Development view, double-click staffmsg.mbtest. The staffmsg.mbtest file opens in the Test Client.
  3. In the Test Client, click Enqueue.
  4. Click Send Message. The message that contains the valid staff number is put on the STAFF_IN queue.
  5. View the STAFF table in the STAFFDB database. The table has been updated with the staff information from the input message.
  6. In the Test Client click Dequeue.
  7. Click Get Message to get the input message from the STAFF_OUT queue. The input message has been written to the output queue.

Running the sample with a message that contains an invalid staff number

To run the sample with the message that contains an invalid staff number:

  1. Open invalidstaffmsg.mbtest in the Test Client and click Enqueue.
  2. Click Send Message.
  3. Observe the results:
  4. View the ERRORS table in the ERRORDB database. The data in the MSGID and MSGDATA fields in the ERRORS table is of the BLOB data type, which means that you cannot view this data using the DB2 Control Center. However, you can view the data using the the DB2 Command Line Processor:
    1. Start the DB2 Command Line Processor:
      • On Windows, click Start > Programs > IBM DB2 > Command Line Tools > Command Line Processor
      • On Linux, at a shell prompt, ensure that you are running as a DB2 instance, then type db2
    2. Enter the following commands:

      connect to ERRORDB
      select * from ERRORS

    The data in the ERRORS table is displayed. The table has been updated with details of the error.

  5. In the Test Client click Dequeue.
  6. Click Get Message to get the input message from the STAFF_FAIL queue. The input message has been written to the failure queue.

Running the sample with valid staff number and a put-inhibited queue

To run the sample with the message that contains a valid staff number but with the output queue put-inhibited:

  1. Change the STAFF_OUT queue to put-inhibited:
    1. In WebSphere MQ Explorer, click the WBRK61_DEFAULT_QUEUE_MANAGER queue manager's Queues folder to display the queue manager's queues.
    2. Right-click the STAFF_OUT queue, then click Properties. The Properties dialog opens.
    3. In the Properties dialog, from the Put Messages list, click Inhibited, then click OK.
  2. Open staffmsg.mbtest in the Test Client and click Send Message. The message is put on the STAFF_IN queue. The staff number in the message is valid so the message passes through the Update Staff Database node. However, the message cannot be put on the STAFF_OUT queue so an error is generated and the message is rolled back.
  3. Observe the results:
    1. View the STAFF table in the STAFFDB database. Because the database update was rolled back, there is no new entry in the table.
    2. View the ERRORS table in the ERRORDB database. The table has been updated with details of the error.
    3. Get the input message from the STAFF_FAIL queue. The input message has been written to the failure queue.

Back to sample home