Retrieval of reports

 

If you ask for COA or COD reports, we can ask for them to be reassembled for you with MQGMO_COMPLETE_MSG. An MQGET with MQGMO_COMPLETE_MSG is satisfied when enough report messages (of a single type, for example COA, and with the same GroupId) are present on the queue to represent one complete original message. This is true even if the report messages themselves do not contain the complete original data; the OriginalLength field in each report message gives the length of original data represented by that report message, even if the data itself is not present.

We can use this technique even if there are several different report types present on the queue (for example, both COA and COD), because an MQGET with MQGMO_COMPLETE_MSG reassembles report messages only if they have the same Feedback code. However, we cannot usually use this technique for exception reports, because, in general, these have different Feedback codes.

We can use this technique to get a positive indication that the entire message has arrived. However, in most circumstances we need to cater for the possibility that some segments arrive while others might generate an exception (or expiry, if you have allowed this). We cannot use MQGMO_COMPLETE_MSG in this case, because, in general, you might get different Feedback codes for different segments and, as noted above, you might get more than one report for a given segment. We can, however, use MQGMO_ALL_SEGMENTS_AVAILABLE.

To allow for this you might need to retrieve reports as they arrive, and build up a picture in your application of what happened to the original message. We can use the GroupId field in the report message to correlate reports with the GroupId of the original message, and the Feedback field to identify the type of each report message. The way in which you do this depends on your application requirements.

One approach is as follows:

• Ask for COD reports and exception reports.

• After a specific time, check whether a complete set of COD reports has been received using MQGMO_COMPLETE_MSG. If so, your application knows that the entire message has been processed.

• If not, and exception reports relating to this message are present, handle the problem as for unsegmented messages, but ensure that you clean up orphan segments at some point.

• If there are segments for which there are no reports of any kind, the original segments (or the reports) might be waiting for a channel to be reconnected, or the network might be overloaded at some point. If no exception reports at all have been received (or if you think that the ones you have might be temporary only), you might decide to let your application wait a little longer.

  As before, this is similar to the considerations you have when dealing with unsegmented messages, except that also consider the possibility of cleaning up orphan segments.

If the original message is not critical (for example, if it is a query, or a message that can be repeated later), set an expiry time to ensure that orphan segments are removed.

 

Parent topic:

Reports and segmented messages

fg10680_