When the ReplyToQ and ReplyToQmgr values of the original request message are saved in a WebSphere MQ message for later retrieval, the whole of the MQMD of the request message is saved, rather than just the ReplyToQ and ReplyToQMgr details. The whole MQMD is saved because there is a requirement to store and retrieve three values (ReplyToQ, ReplyToQmgr, and CorrelID), and the MQGet node can store or retrieve only a single value. Therefore, you must save the structure containing the values that are required instead of saving the individual values. When you change the sample to store different values, you must consider the behavior of the MQGet node.
You can use your own implementations of the subflows that are used in the Request and Reply flows to replace those provided in the sample. For example, you might want to use a database to store the ReplyToQ and ReplyToQmgr details from the initial request message. Alternatively, you might want to use the subflows that are used to store and retrieve the ReplyToQ, ReplyToQmgr, and CorrelID in a WebSphere MQ message in other message flows.
You can use the StoreOriginalMQMD_Sub subflow in your message flows; this subflow acts in the same way as saving the MQMD in a WebSphere MQ message. To save the MQMD of the request message, you must include the subflow at the appropriate point in the message flow in which it is to be used. You can include the subflow without modification but you must take into account the following considerations:
Although the key parameters that you can change have been identified in the preceding text, you must review all of the parameter settings on the nodes within the subflow to ensure that they are compatible with your requirements.
You can modify the subflow to use an alternative storage facility for the data; for example, if you choose to use a database, instead of writing a WebSphere MQ message the subflow must insert data into a database.
Changing the storage facility changes the performance characteristics of the subflow. It is important to ensure that the characteristics of the implementation that you choose are consistent with the performance requirements for the message flow. Using a database to hold the information makes the message flow more likely to be I/O-bound because each insert to the database requires a write to the database manager log.
Using an alternative storage facility can also change the transactional properties of the subflow. When data is stored by using a WebSphere MQ message, it uses the same resource manager as the WebSphere MQ messages that are read elsewhere in the message flow. If the WebSphere MQ messages are processed only in the message flow, a single resource manager is involved. Using a database, or other recoverable resource manager, requires a two-phase-commit recovery protocol between the WebSphere Message Broker queue manager and the database manager of the database in which data is stored in order to ensure data integrity.
When you are making changes, you must review all of the parameter settings on the nodes within the subflow to ensure that they are compatible with your requirements.
You can use the RestoreOriginalMQMD_Sub subflow in other message flows to retrieve the MQMD of the initial request message from a WebSphere MQ message. To retrieve the MQMD, you must include the subflow at the appropriate point in the message flow in which it is to be used. You can include the subflow without modification but you must take into account the following considerations:
Although the key parameters that you might want to change have been identified in the preceding text, you must review all of the parameter settings on the nodes within the subflow to ensure that they are compatible with your requirements.
You can modify the subflow to use an alternative storage facility for the data; for example, you might want to use a database, so that instead of using the MQGet node to read a WebSphere MQ message the subflow can read data from a database.
Changing the storage facility changes 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. The use of a database to hold the information might add different overheads depending on the implementation. If data is retrieved by 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 continues 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 has been retrieved, or the deleting of a row, this action involves 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 by using a WebSphere MQ message, it uses the same resource manager as the WebSphere MQ messages that are read elsewhere in the message flow. If WebSphere MQ messages are processed only in the message flow, only a single resource manager is involved. Using a database or other recoverable resource manager requires the use of a two-phase-commit recovery protocol between the WebSphere Message Broker queue manager and the database manager of the database in which data is stored to ensure data integrity.
You must review all of the parameter settings on the nodes within the subflow to ensure that they are compatible with your requirements.