It is important to safeguard that messages that flow through your broker domain. This is true of both application-generated messages and those used internally for inter-component communication. Messages used internally between components always use the WebSphere MQ protocol. Application messages can use all supported transport protocols.
For application and internal messages travelling across WebSphere MQ, two techniques protect against message loss:
If a message is persistent, WebSphere MQ ensures that it is not lost when a failure occurs, by copying it to disk.
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 WebSphere MQ System Administration Guide.
WebSphere Event Broker components use WebSphere MQ messages to communicate events and data between broker processes and subsystems, and the Configuration Manager and User Name Server. The components ensure that the WebSphere MQ features are exploited to protect against message loss. You do not need to take any additional steps to configure WebSphere MQ or WebSphere Event Broker to protect against loss of internal messages.
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 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.
When an input node reads a message is read 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 subscribers' registration options. 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.
The default action of a message flow is to process incoming messages under syncpoint in a broker-controlled transaction. This means that a message that fails to be processed for any reason is backed out by the broker. Because it was received under syncpoint, 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 broker) are executed.
For full details of input node processing, see Managing errors in the input node.
If a persistent SCADA message is published, it might be downgraded to the highest level that the client can accept. In some circumstances this might mean that the message becomes nonpersistent.
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
ac00420_ |