Virtualize - MQ Setup using Different Queue Managers for Request and Reply

satishms10

Hi Team,

I'm new to Parasoft and trying to create a virtual service using MQ.

My requirement is that Message Broker writes the request to queue (it is defined on Mainframe MQ)

Details are:

Host: <hostname>
Port: <port
Channel: AXP.CHANNEL.02
Queue Manager: MQN3
Queue: AXP.BRKR01.SYDID.Q00459.03

Request MQ Header contains below ReplyToQueue and QueueManager details. This Queue and QMGR is present on Distributed MQ (Not on Mainframe MQ)

replyToQueueManagerName: LLXXXD11 
replyToQueueName: OT_AXPP_PROCESS_GET_QUEUE7.NT

These two queues are local queues on the respective QMGRs. They don't have any Alias or Remote

I have created the MQ Manager connection on server..

Also configured the Queue details at Virtual Service level..

Request is reaching the virtual service and response is not going back. No error is happening but response is not reaching to client.

My expectation/assumption is that Parasoft Virtual service will use replyToQueueManagerName ** and **replyToQueueName to sent the reply.

Please help me in this regard.

Thanks,
Sati

satishms10

Hi Benken and William,

Sorry for the late reply. Here is the solution to my original discussion point.

We no need to create separate connection if the reply Queue and Queue Manager are on a separate server. MQ will take care of it.

I have selected the same connection for "Get queue" and "Put queue" under MQ, Virtual Asset Deployment Settings

• Using the "Header Data Bank", captured messageID, correlationID and expiry values from the request header

• Used above messageID, correlationID and expiry values for RESPONSE in Response Transport Header under MQ Transport. Hardcoded the messageType, format values.

Key point is, messageID and correlationID values from request header needs to be interchanged in the response header.

This resolved the issue. Thought of sharing this for the benefit of the forum.

Thanks,
Sati

benken_parasoft

From docs: Configuring Virtual Assets Deployed to Virtualize Server > Use replyToQueueName for Response

If Use replyToQueueName for Response is enabled and values for both MQMD.replyToQueueManagerName and MQMD.replyToQueueName have been specified, those values will determine both the queue manager and the queue name to send the response to.

satishms10

Dear Benken,

Thanks for your reply. Below replyToQueueManager and replyToQueue are defined in different MQ Unix server whereas Request QMGR and Queue is defined on Mainframe MQ.

replyToQueueManagerName: LLXXXD11 
replyToQueueName: OT_AXPP_PROCESS_GET_QUEUE7.NT

Do we need to create the MQ Manager connection on Parasoft Local Machine and select that under "Put Queue Settings" or Parasoft will use replyToQueueManager and replyToQueue setup from request connection.

Thanks,
Sati

williammccusker

Hi,

Since the reply queues are on a separate server, yes you will need the connection settings in the Server Connections (on the Local Machine) and then in the Virtual Asset for the Put Queue use that connection. You don't have to specify the specific reply queues as the "use replyToQueue" option will take the queue names from the request.

satishms10

Hi William,

Thank you so much for your reply.

I have configured the connection in the Server Connections (on the Local Machine) for the Put Queue to use that connection. Now the response is reaching the Broker Queue but MQ team is saying Parasoft is sending DATAGRAM rather than RESPONSE type.

I am struggling to find the option to configure the Message Type as RESPONSE in Parasoft Virtual service.

Could you please help me in this regard.

Thanks,
Sati

williammccusker

Hi,

I am not sure how to change the MQ Message Type, could you contact Parasoft Support?

benken_parasoft

Now the response is reaching the Broker Queue but MQ team is saying Parasoft is sending DATAGRAM rather than RESPONSE type.

DATAGRAM is IBM's default value. To use a different message type you have to change it explicitly.
To do this, open your Message Responder, click "Transport Header" then select "MQ" in the "Transport" box. In the MQ Headers table, click Add. Name the header "messageType" with value "2".

Explanation:
Each message has a MQMD (message descriptor) which is a binary data structure, acting as a header. The MQMD includes various "fields" that both Virtualize and SOAtest identify with contrived, friendly names like "messageType". You will see names of MQMD fields in various places, like when configuring named "headers" in a Message Responder and when viewing traffic like in the Event Details perspective. In this case, the message type field is of type MQLONG which is a 32-bit signed integer.

Below, I list the MQMT (message type) constants that I pulled from com.ibm.mq.constants.CMQC:

MQMT_SYSTEM_FIRST = 1;
MQMT_REQUEST = 1;
MQMT_REPLY = 2;
MQMT_DATAGRAM = 8;
MQMT_REPORT = 4;
MQMT_MQE_FIELDS_FROM_MQE = 112;
MQMT_MQE_FIELDS = 113;
MQMT_SYSTEM_LAST = 65535;
MQMT_APPL_FIRST = 65536;
MQMT_APPL_LAST = 999999999;

Instead of typing a fixed value like "2" you can also script the value and return com.ibm.mq.constants.CMQC.MQMT_REPLY, for example.

benken_parasoft

On this topic, another common MQMD field to always change from the default is the message format field. IBM's default for message format is MQFMT_NONE which is (eight spaces) which says the message payload is binary (non-text) or is empty. In most cases, the payload is text (like XML or JSON) in which case you almost always want MQFMT_STRING which is MQSTR (MQSTR followed by three trailing spaces). In the MQ Headers table, use "format" for the header name.

For reference, I'm listing all of the MQFMT (message format) constants here, pulled from com.ibm.mq.constants.CMQC:

MQFMT_NONE = "        ";
MQFMT_ADMIN = "MQADMIN ";
MQFMT_AMQP = "MQAMQP  ";
MQFMT_CHANNEL_COMPLETED = "MQCHCOM ";
MQFMT_CICS = "MQCICS  ";
MQFMT_COMMAND_1 = "MQCMD1  ";
MQFMT_COMMAND_2 = "MQCMD2  ";
MQFMT_DEAD_LETTER_HEADER = "MQDEAD  ";
MQFMT_DIST_HEADER = "MQHDIST ";
MQFMT_EMBEDDED_PCF = "MQHEPCF ";
MQFMT_EVENT = "MQEVENT ";
MQFMT_IMS = "MQIMS   ";
MQFMT_IMS_VAR_STRING = "MQIMSVS ";
MQFMT_MD_EXTENSION = "MQHMDE  ";
MQFMT_PCF = "MQPCF   ";
MQFMT_REF_MSG_HEADER = "MQHREF  ";
MQFMT_RF_HEADER = "MQHRF   ";
MQFMT_RF_HEADER_1 = "MQHRF   ";
MQFMT_RF_HEADER_2 = "MQHRF2  ";
MQFMT_STRING = "MQSTR   ";
MQFMT_TRIGGER = "MQTRIG  ";
MQFMT_WORK_INFO_HEADER = "MQHWIH  ";
MQFMT_XMIT_Q_HEADER = "MQXMIT  ";

In the MQ Headers table you can type the value directly or script the value and return the named constant like com.ibm.mq.constants.CMQC.MQFMT_STRING.

williammccusker

Thanks for sharing your solution!

benken_parasoft

Hardcoded the messageType, format values.

Just to share, IBM MQMD constants can be tricky.

format:
https://www.ibm.com/docs/en/ibm-mq/9.2?topic=descriptor-format-mqchar8
https://www.ibm.com/docs/en/ibm-mq/9.2?topic=constants-mqfmt-formats

messageType:
https://www.ibm.com/docs/en/ibm-mq/9.2?topic=descriptor-msgtype-mqlong
https://www.ibm.com/docs/en/ibm-mq/9.2?topic=constants-mqmt-message-types

Notice how format is an eight byte 8-byte alphanumeric field (MQCHAR8). The value is padded at the end with space characters to make it 8 bytes in length. In particular, "MQSTR " actually has three trailing spaces. IBM's default value for this header is " " (8 spaces) for binary content or no data.

The message type is a 32-bit signed integer (MQLONG). In particular, "1" is for request and "2" is for reply. IBM's default is "8" for sending a "datagram" where no reply is expected.