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

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.