Messages that flow through your integration node domain represent business
data that you want to safeguard. Configure the messages, your environment,
or both, to ensure that you do not lose messages.
About this task
Messages that are generated
by your applications and by runtime components for inter-component
communication are important to the operation of your integration nodes.
For messages
traveling across WebSphere® MQ, two techniques
can protect against message loss:
- Message persistence
If a message is persistent, WebSphere MQ ensures that it is not lost
when a failure occurs, by copying it to disk.
- Sync point control
An application can request that a message
is processed in a synchronized unit-of-work (UOW)
For more information about how to use these options, refer
to the System Administration Guide section of the WebSphere MQ Version 7.5 product
documentation online.
If delivery
of application messages is critical, you must design application programs
and the message flows that they use to ensure that messages are not
lost. The techniques used depend on the protocol used by the applications.
- WebSphere MQ
Enterprise Transport
- If you are using the built-in input nodes that accept messages
across the WebSphere MQ protocol, you
can use the following guidelines and recommendations:
- Using persistent messages
WebSphere MQ messaging
products provide message persistence, which defines the longevity
of the message in the system and guarantees message integrity. Nonpersistent
messages are lost in the event of system or queue manager failure.
Persistent messages are always recovered if a failure occurs.
You
can control message persistence in the following ways:
- Program your applications that put messages to a queue using the
MQI or AMI to indicate that the messages are persistent.
- Define the input queue with message persistence as the default
setting.
- Configure the output node to handle persistent messages.
- Program your subscriber applications to request message persistence.
When an input node reads a message from an input queue,
the default action is to use the persistence defined in the WebSphere MQ message header (MQMD), that
has been set either by the application creating the message, or by
the default persistence of the input queue. The message retains this
persistence throughout the message flow, unless it is changed in a
subsequent message processing node.
You can override the persistence
value of each message when the message flow terminates at an output
node. This node has a property that allows you to specify the message
persistence of each message when it is put to the output queue, either
as the required value, or as a default value. If you specify the default,
the message takes the persistence value defined for the queues to
which the messages are written.
If a message passes through
a Publication node, the
persistence of messages sent to subscribers is determined by the registration
options of the subscribers. If a subscriber has requested persistent
message delivery, and is authorized to do so by explicit or implicit
(inherited) ACL, the message is delivered persistently regardless
of its existing persistence property. Also, if the user has requested
nonpersistent message delivery, the message is delivered nonpersistent
regardless of its existing persistence property.
If a message
flow creates a message (for example, in a Compute node), the persistence
in the MQMD of the new message is copied from the persistence in the
MQMD of the incoming message.
- Processing messages under sync point control
The default action of a message flow is to
process incoming messages under sync point in a transaction that
is controlled by the integration node. This means that a message
that fails to be processed for any reason is backed out by the
integration node. Because it was received under sync point, the
failing message is reinstated on the input queue and can be
processed again. If the processing fails, the error handling
procedures that are in place for this message flow (defined
either by how you have configured the message flow, or by the
integration node) are executed.
- WebSphere MQ
Web Services Transport
- If you are using the HTTPInput, HTTPRequest, SOAPInput, SOAPRequest nodes, or a SOAPAsyncRequest and SOAPAsyncResponse node pair
that accept messages from web services applications, no facilities
are available to protect against message loss. You can, however, provide
recovery procedures by configuring the message flow to handle its
own errors.
- Other transports and protocols
- If you have created your own user-defined input nodes that receive
messages from another transport protocol, you must rely on the support
provided by that transport protocol, or provide your own recovery
procedures.