By default, assets deployed with a WebSphere 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:

1. Chain a Header Data Bank tool to the incoming header request of that responder and extract the messageId (or the desired MQMD field) value (see Header Data Bank).
2. In the Message Responder Transport Header Options, MQ (see Transport Header Tab) add 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.
   • For the list of MQ Message MQMD field names recognized and handled by Virtualize, see the MQMD documentation.

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.

Using RFH2 Headers in Correlations for MQ Messages with a Custom Message Format

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 follwing paths can be used to access the values in various RFH2 areas:

Message Content Descriptor

• "mcd/Msd" - Message Domain
• "mcd/Set" - Message Set
• "mcd/Type" - Message Type
• "mcd/Fmt" - Output Format

Publish/subscribe Command

• "psc/Command"
• "psc/Topic"
• "psc/SubIdentity"
• "psc/QName"
• "psc/QMgrName"
• "psc/SubPoint"
• "psc/Filter"
• "psc/SubName"
• "psc/SubUserData"
• "psc/RegOpt"

Application-Defined Properties

• "usr/*"

Java Messaging Service

• "jms/Dst" - Destination
• "jms/Rto" - Reply To
• "jms/Tms" - Timestamp
• "jms/Exp" - Expiration
• "jms/Cid" - Correlation Id
• "jms/Pri" - Priority
• "jms/Dlv" - Delivery Mode

For details on using scripted correlations, see Custom Correlation.

Troubleshooting

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).