A number of constraints apply when you use this pattern.
You can use the Message Correlator for WebSphere MQ: request-response without persistence pattern
only if you meet all of the following constraints:
- Your requester and provider applications must use WebSphere MQ
as the transport mechanism.
- Your provider applications must follow the convention of copying the message identifier to
the correlation identifier so that
the broker can match the responses to their original request.
- Your requester and provider applications must send and accept compatible messages, unless
you include a transformation
capability in the customizable RequestProcessor subflow.
- The business purpose for which you use this pattern must be able to
tolerate timeouts and any consequent failure to receive a reply.
- If you choose to enable logging in the pattern, the log messages are sent to a queue.
The processing of these log messages is outside the scope of this pattern
and you must process the logging messages
in the way most appropriate for your organization.
When logging is selected, log messages are written to
the log queue as persistent messages, which affects performance.
Persistent messages are used because it is assumed that
logging is being used for audit purposes.
If logging is for test or information only,
logging can be switched off in production systems by configuring the following
user-defined properties (UDPs):
RequestLoggingOn and ResponseLoggingOn.
- If you choose to enable error messages in the pattern, error messages are sent to a queue
when an exception occurs.
Monitoring errors and taking corrective action is outside of the scope of the pattern,
and you must process the error
messages in the way most appropriate for your organization.
- The pattern defines its own format for the logging and error messages and it is assumed
that these are sufficient to meet the requirements in your own environment.