Serialization of input in an integration server on z/OS
To allow concurrent processing
within a message flow, while still serializing messages between message
flows in separate integration servers, the scope of the serialization
token is restricted within a single integration server.
This example demonstrates that the serialization token is restricted
within a single integration server running on a broker::
- Two MQInput nodes in separate message flows
(in this case MyFlowA and MyFlowB )
are running within the same integration server MyGroupA.
Both MQInput nodes concurrently get messages from
the shared input queue even though they are using the same serialization
token.
- If serialization is required within a single message flow, the message flow attribute additional instances must
be set to zero which is the default setting. However, if greater throughput
is required and serialization of input within the flow is not important,
you can set additional instances to a value greater
than zero.
- The use of the serialization token attribute
on the MQInput node does not serialize input between
message flows operating within the same integration server. However,
setting the attribute has no adverse affect on the processing within
that integration server
- In this way it is possible to maximize throughput in a message
flow on one broker while still serializing input between brokers.
This is useful where the requirement is to have one or more brokers
acting as an immediate standby, should the currently active broker
need to be stopped for servicing, or fail unexpectedly.