Managing a Healthcare: HL7 to reports pattern instance

The pattern assumes a simple topology, with all message flows running on a single message broker. Information about deploying and managing a pattern instance that uses this simple topology and how you can manage the pattern instance is included in this topic.

This topic contains the following sections:

Set up
Pattern deployment
Monitoring and Error handling

Set up

Queues

You can choose to generate an MQSC script for defining the queues that are required by the pattern by selecting the Generate scripts check box in the General section of the Configure Pattern Parameters tab, before you generate the pattern instance. This script, which is called queues.mqsc, is in the root directory of the pattern instance project; it defines basic queues and topics.

You can run the MQSC script by using the following command, where MBQMGR is the name of the queue manager for your broker:

runmqsc MBQMGR < queues.mqsc

You can edit this MQSC script to add descriptions for your environment and to set appropriate queue depths.

In particular, you must check the depth of the queue, flowprefix.DUPID, which holds the duplicate data store. This queue stores all data that is used for duplicate checking. If duplicate checking is enabled, the required depth of this queue is calculated by multiplying the maximum receiver message rate by the duration of the expiry setting. For example, if the maximum rate is 10 messages per second and the expiry setting is 24 hours (86,400 seconds), the required depth is 864000.

It is expected that other queues are monitored and regularly cleared. These queues are created with a default size, but you must review their use and ensure that the depth is sufficient.

You must run the MQSC script before you deploy the pattern instance.

Pattern deployment

Create a new broker archive (BAR) file in the location where you want to store these resources.

The HL7v25P message set must be packaged in its own BAR file:

  1. Select the HL7v25P message set, and build the BAR file.
  2. Deploy the BAR file to all execution groups on which you want the pattern, or parts of the pattern, to run.
  3. After the HL7v25P message set is deployed, ensure that all required queues are defined and that any configurable service files are deployed.
  4. Create one or more BAR files that contain the flows that you want to deploy to a specific execution group. In the simplest case, where everything runs in a single runtime environment, include the Receiver flow and Processor flows.
  5. To gain improved performance after the flows have built, you might want to increase the Additional instances setting for any flow that does not have sequencing requirements:
    1. Click the Manage tab.
    2. Select the properties of flows that you want to configure, and set values that are required by your implementation.

Monitoring and Error handling

Error notifications are written to an error queue for all message flows in the pattern. A queue trace is also output to the location that you defined during pattern generation. The MQRFH2 header of the error message contains information indicating where the error occurred. Details about the behavior of each message flow are specified in this section.

Errors in the Receiver flow

The Receiver flow is run as a transaction and all output messages are committed on successful completion of the message flow. If acknowledgments are required, the last action of the Receiver flow is to send the acknowledgment (ACK). When processing the acknowledgment is successfully completed, the flow ends and the messages are committed.

For each action in the Receiver flow:

If there is an error, the following events occur:

The administrator must monitor the error queue and Event log to determine when messages have not been processed by the receiver queue, and take the necessary remedial action to resolve the error.

Errors in Processor flow

A Processor flow is run as a single transaction. On successful completion of the message flow, the input message is removed from the input queue.

If there is an error, the following events occur:

The administrator must check the error queue and Event log to determine what errors have occurred. Both the error queue and the backout queues contain information, and after a corrected message is processed this information must be cleared to prevent the queue from filling.

The administrator must configure a backout queue for the input queue.

When a message is rolled back by the Processor flow, later messages are still processed and generate reports. Therefore, errors in the Processor flow must be corrected as soon as possible.

Two options are available for correcting an error in the Processor flow:

Back to the Healthcare: HL7 to reports pattern specification