By default, assets deployed with an IBM MQ configuration will copy the MQMD characterSet
, messageId
, and correlationId
from the incoming request MQ Message to the outgoing response MQ message. This is the default correlation mechanism.
If a different correlation mechanism is required, such as making the virtual asset copy the incoming request messageId
into the outgoing response correlationId
, then you can configure this at the Message Responder level. To do this:
messageId
(or the desired MQMD field) value (see Header Data Bank).messageId
(or the desired MQMD field name) and parameterize its value with the request messageId
or field provided by the Data Bank. This approach can be used for MQMD MQMessage fields as desired.Note that Virtualize will display a hex-encoded representation of the byte array fields in order to allow their values to be readable in the data bank and traffic views. However, the exact byte content will be transferred gracefully from the request to the response messages, preserving the original byte contents.
For MQ messages that use a custom message format, the RFH2 headers are not accessible in the XML Message for the purpose of responder correlation if they are not explicitly retained in the custom message converter. If RFH2 headers are needed for responder correlation, they can be accessed through the custom scripting context as part of the message string in XML format.
The following Jython script provides an example of how to accomplish this. It tests the request to see if the message domain is set to sampleDomain
and the application-defined property for sampleKey
is set to sampleValue
.
from com.parasoft.api import CorrelationScriptingHookConstants from com.parasoft.xml import XMLUtil from org.w3c.dom import * from javax.xml.xpath import * from java.lang import * def match(context): msg = context.get(CorrelationScriptingHookConstants.MESSAGE_STR) if msg != None: xmlDocument = XMLUtil.buildDocumentFromString(msg) cond1 = matchRFH2Header(xmlDocument, "mcd/Msd", "sampleDomain") cond2 = matchRFH2Header(xmlDocument, "usr/sampleKey", "sampleValue") return cond1 and cond2 return false def matchRFH2Header(xmlDocument, path, val): xPathFactory = XPathFactory.newInstance(); xpath = xPathFactory.newXPath() expression = xpath.compile("/RFH2Message/RFH2Headers/" + path + "/text()") elementValue = expression.evaluate(xmlDocument) return String(elementValue).equals(val) |
The following paths can be used to access the values in various RFH2 areas:
Message Content Descriptor
Publish/subscribe Command
Application-Defined Properties
Java Messaging Service
For details on using scripted correlations, seeĀ Custom Correlation.
If messages are not correlating properly, producing error message, or not responding to messages, check for a mismatch between the encoding indicated in the header vs. the encoding that is actually being used in the message body. If this occurs, you need to override the expected message format using JRE system properties.
For example, if your message headers indicate characterSet=37 but the actual messages were encoded in UTF-8, you would use the following JRE system property:
mq.force.utf8.encoding=true
by starting Virtualize with -J-D
followed by the property name. For example:
virtualize.exe -J-Dmq.force.utf8.encoding=true
A related property, mq.force.custom.encoding=UTF-8
, applies to the MQ recording wizard when viewing or using a custom message format (when converting between the native MQ message content and XML).