When the ReplyToQ and ReplyToQmgr values of the original request message are saved in a WebSphere MQ message for later retrieval this is done by saving the whole of the MQMD of the request message, rather than just the ReplyToQ and ReplyToQMgr details. This is done because there is a need to store and retrieve three values, ReplyToQ, ReplyToQmgr, and CorrelID of the request message and the MQGet node only allows a single value to be stored or retrieved. Given this behaviour of the MQGet node the structure containing the values which are needed must be saved instead of the individual values. When making changes to the sample to store different values you need to remember this behaviour of the MQGet node.
The coordinated request reply sample is designed in such a way that different implementations of the subflows used in the Request and Reply flows can be used instead of those provided in the sample. One different implementation might be to use a database for storage of the ReplyToQ and ReplyToQmgr of the initial request message for example. Although this would not be suggested as a way to improve performance. Alternatively the subflows used to store and retrieve the ReplyToQ, ReplyToQmgr, and CorrelID of the request message in a WebSphere MQ message could be used in other message flows.
The subflow StoreOriginalMQMD_Sub can easily be used in other message flows to perform the same function of saving the MQMD of the request message in a WebSphere MQ message. To do this include the subflow at the appropriate point in the message flow in which it is to be used. It is possible to include the subflow without modification but this will result in potential problems:
Although the key parameters which may need to be changed have been identified above it is suggested that you review all parameter settings on nodes within the subflow to ensure that they are compatible with your requirements.
There are a number of ways in which you can modify the subflow to use an alternative storage facility for the data. One alternative might to be use a database for example. Instead of writing a WebSphere MQ message the subflow would need to insert data into a database.
You should be aware that changing the storage facility will change the performance characteristics of the subflow. It is important to ensure that the characteristics of the implementation you choose are consistent with the performance requirements for the message flow. Use of a database to hold the information would make the message flow much more likely to be I/O-bound in processing, as each insert to the database would require a write to the database manager log.
Use of an alternative storage facility can also change the transactional properties of the subflow. When data is stored using a WebSphere MQ message this uses the same resource manager as the WebSphere MQ messages that are read elsewhere in the message flow. If there is only processing of WebSphere MQ messages in the message flow, only a single resource manager is involved. Use of a database or other recoverable resource manager would necessitate the use of a two-phase-commit recovery protocol between the Message Broker queue manager and the database manager of the database in which data is stored in order to ensure data integrity.
When making changes it is suggested that you review all parameter settings on nodes within the subflow to ensure that they are compatible with your requirements.
The subflow RestoreOriginalMQMD_Sub can easily be used in other message flows to perform the same function of retrieving the MQMD of the initial request message from a WebSphere MQ message. To do this include the subflow at the appropriate point in the message flow in which it is to be used. It is possible to include the subflow without modification but this will result in potential problems:
Although the key parameters which may need to be changed have been identified above it is suggested that you review all parameter settings on nodes within the subflow to ensure that they are compatible with your requirements.
There are a number of ways in which you could modify the subflow to use an alternative storage facility for the data. One alternative might to be use a database for example. Instead of using the MQGet node to read a WebSphere MQ message the subflow could read data from a database.
You should be aware that changing the storage facility will change the performance characteristics of the subflow. It is important to ensure that the characteristics of the implementation you choose are consistent with the performance requirements for the message flow. Use of a database to hold the information could add different overheads depending on the implementation. If data is retrieved using a read, and is not updated or deleted, the overhead is at its lowest for a database implementation. However if data is not deleted from the database the database will continue to grow in size and become progressively slower to use unless some housekeeping is put in place. If the retrieval process involves updating a row to indicate that the data had been retrieved, or the deleting of a row, this would involve a write to the database manager log, resulting in a significantly larger processing overhead than for the read-only case.
Use of an alternative storage facility can also change the transactional properties of the subflow. When data is stored using a WebSphere MQ message this uses the same resource manager as the WebSphere MQ messages that are read elsewhere in the message flow. If there is only processing of WebSphere MQ messages in the message flow, only a single resource manager is involved. Use of a database or other recoverable resource manager would necessitate the use of a two-phase-commit recovery protocol between the Message Broker queue manager and the database manager of the database in which data is stored in order to ensure data integrity.
When making changes it is suggested that you review all parameter settings on nodes within the subflow to ensure that they are compatible with your requirements.