When you design and configure message flows that support aggregation,
there are some restrictions on the protocols that can be used by participating
client applications:
- Applications that send the original request message, and applications
that receive the final aggregated response message, can connect to the broker
using any of the supported protocols. You can include all the built-in input
and output nodes, and any user-defined input and output nodes, to interact
with these applications.
- Applications that receive and process the aggregate requests, and applications
that send responses to these requests, must be connected to the broker using
protocols that support the request/reply model. Each request/response pair
must be processed on the same protocol.
WebSphere
Business Integration Message Broker provides the following
protocols and input and output nodes to support the request/reply model:
- WebSphere MQ Enterprise Transport (MQInput and MQOutput nodes)
- WebSphere
MQ Mobile Transport (MQeInput and MQeOutput nodes)
The following transport protocols do not support a request/reply model:
- WebSphere MQ Web Services
Transport (HTTPInput, HTTPReply, and
HTTPRequest nodes)
- WebSphere MQ Real-time Transport (Real-timeInput and Real-timeOptimizedFlow
nodes)
- WebSphere MQ Telemetry Transport (SCADAInput and SCADAOutput
nodes)
If you choose to create user-defined nodes, and use an alternative
transport protocol, the protocol you use must meet the following criteria
for input and output nodes to support aggregation requests and responses:
- For each request, an identifier must be generated that is unique for that
message within that protocol. WebSphere MQ supports
this through the MsgId property.
- For each reply, the protocol must be able to identify the corresponding
request message. WebSphere MQ supports this by
copying the MsgId into the CorrelId.
- For each reply, the replyIdentifier created within the protocol must be
24 bytes or less.
The protocol-specific output node must:
- Propagate the sent message to an out terminal.
- Populate the LocalEnvironment with information about the destinations
that the message was sent to. The format of this information is shown in the
following diagram:
The field Protocol must be an unambiguous name describing
the transport. In the supplied MQOutput node, Protocol is MQ. In the supplied
MQeOutput node, Protocol is MQe.
For each destination that the message
is sent to, there must be a folder called DestinationData. The only field
underneath this required by aggregation is called ReplyIdentifier. You can
include additional information if you choose. For WebSphere MQ,
this field contains the MsgId from the MQMD.
If you are writing your
own plug-in node, you can put whatever information is useful and relevant
underneath the DestinationData folder. For example, the MQOutput node includes
the queue name and queue manager name.
The information that is contained
beneath WrittenDestination is valid only for the last output node that delivered
the message. For example, if you connect two MQOutput nodes in series, the
WrittenDestination relates only to the second node.
The protocol-specific input node must:
- Put the Protocol name into the Root.Properties.ReplyProtocol property
of the message. Protocol must be the same value as the value used in the corresponding
output node.
- Put the reply identifier into the Root.Properties.ReplyIdentifier property
of the message. The MQInput node uses the CorrelId as the identifier of the
reply..
When you write user-defined nodes, you can override these
properties by navigating to the Properties folder and using cniCreateElementAsFirstChild()
or equivalent. Ensure that the value used for the Protocol is consistent and
is unique for the protocol.