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:
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. 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.
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:
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.
The Medical Devices flow is run as a transaction and all output messages are committed on successful completion of the message 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 pattern instance, and take the necessary remedial action to resolve the error.
A Transform and Route flow is run as a single transaction. On successful completion of the message flow, all output messages are committed to the following locations:
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.
A message is written to the error queue outside the transaction, and the input message is rolled back to the input queue for the Sender flow.
The input queue must be configured with a backout queue.
An error can also occur after a message is delivered. This type of error happens if the destination application cannot process the message and sends a NACK. In this case, a message is written to the error queue. The administrator must check the error message and correct the problem at the destination application.