Tasks to complete before applying the
Message Correlator for WebSphere MQ: request-response without persistence
pattern
Before applying the pattern to produce a pattern instance, you must determine
which of the following tasks are required. If required, complete the following tasks:
Select a unique name for the pattern instance.
You can use the pattern multiple times and create multiple different instances, which can be distinguished
by their unique names. Identify the purpose of the pattern instance so that you can decide on an appropriate
or meaningful unique name.
Select the WebSphere MQ queue managers and queues that you want the pattern instance to use,
for example, to access the provider application. If you are using existing queues, these must be recorded.
If you want to create new queue managers and queues, you must decide on the names for these resources.
Identify any additional queue managers and queues that are required for this pattern and decide
on the names that you want to use. Take into account any policies, standards, or naming conventions that must
apply.
Decide if validation of the incoming request messages or the provider response messages is required.
If your requester and provider applications generate correct messages, validation might not be necessary.
If you want to validate your messages, you must already have a message set to provide the message definitions,
or you must create a message set to provide the message definitions.
Decide whether you require logging of request messages, responses messages, or both.
If logging is required, you must decide to which queue manager and queue the logging messages are sent.
You can send logging messages to a general log queue that is used by multiple message flows,
or you can use a queue specifically for the pattern instance.
Decide if you want to produce error messages for the pattern instance.
If this pattern instance handles updates, use error handling to ensure that you do not lose any data.
You can send error messages to a general error queue that is used by multiple message flows,
or you can use a queue specifically for the pattern instance. If you choose to send error messages
in the pattern instance, you can turn this function on or off by configuring the broker archive (BAR) file
before deployment.