Service Virtualization

Hi,

I am facing an issue with native MQ virtualization, Earlier when we were using deprecated MQ, We were able to specify the Correlation ID, Message ID, Group ID, Sequence Number, and Offset details in MQ publish step advanced options but i am unable to find the same settings in Respond step. Can anyone please let me know how to add these options to response in VSM?

Thanks,

Sai

Hi,

Can anyone please help me for the above query?

Thanks,

Sai

Hi Sai,

Do you have "PRO" options enabled?  If so, you'll see a label for "Header Properties" and an "Open Editor..." button.  Click the plus sign button and you'll be able to select those header options.

--Mike

Hi Sai,

Apologies.  I was referring to the "IBM Native Send Receive" step.  I don't see how to do this on the respond step.

--Mike

With the newer IBM MQ Native protocol, those properties are set through meta-data properties in the service image responses:

msg.correlationId

msg.messageId

msg.groupId

msg.messageSequenceNumber

There doesn't appear to be one for Offset.  That's something I can make a patch for if necessary.

Hi Kevin,

We have a lot of transactions in VSI which will keep on increasing as we are virtualizing about 100+ services. As we have already created the service using deprecated method, migrating to native will need a lot of maintenance work as i need to manually add values in each response meta-data.

As mentioned could you please provide a patch for this to add these in respond step like in deprecated method, that will help us a lot as we want to use native mq method going forward

P.S. I have also heard about sidecar which adds meta data to all transactions which might solve my issue, but I haven't got a chance to work on that, Any pointers on how to use the same would be greatly appreciated.

Thanks,
Sai

No, the patch I mentioned would just be to add 'offset' to the list of available meta-data properties. 

The new MQ protocol just doesn't work like the old one.  Response data is driven entirely by the service image, more like how the HTTP and other VSE protocols work.

You can achieve the same effect with the new protocol by adding scripted data protocol on the response side which adds those properties to the response meta-data:

%beanshell%

response = lisa_vse_response.get(0);
md = response.getMetaData();

md.setParameterValue("msg.correlationId", "414D5120514D5F69746B6F5F69626D6D0CB93C58200B5F02");

md.setParameterValue("msg.messageId", "414D5120514D5F69746B6F5F69626D6D0CB93C58200B5F02");

md.setParameterValue("msg.groupId", "414D5120514D5F69746B6F5F69626D6D0CB93C58200B5F02");

md.setParameterValue("msg.messageSequenceNumber", "12");

response.setMetaData(md);

Sidecar files are described in the documentation:

Request/Response Pairs - DevTest Solutions - 10.1 - CA Technologies Documentation

Thanks Kevin,

I will try this and getback to you.

Thanks,

Sai

Hi Kevin,

I tried adding scriptable data protocol, but i am getting the below exception

Did not get a valid Request object so we ignore processing this transaction.
java.lang.ArrayIndexOutOfBoundsException

The request and response messages are fixed length messages over MQ and i am using copybook DPH in both listen and respond steps. Can you please look into this.

Thanks,

Sai

To add the scripted DPH did you do another recording or did you modify the VSM?  Is this a stock VSM except for the scripted DPH?

Can you give the full stack trace of the error? 

We're about at the limit of what I can do for you without a support case.

Hi Kevin,

I have added scripted DPH to existing VSM, It is a stock VSM with only the scripted DPH u mentioned being the only extra feature.

I am not getting any error, just a warning in ITR with the below message

Did not get a valid Request object so we ignore processing this transaction.
java.lang.ArrayIndexOutOfBoundsException

and the header value which i am getting in my test case doesn't have the IDs which i need to pass, So the filter is not getting executed.

I can raise a support ticket for the same if needed for the issue.

Thanks,

Sai

Does your VSM emit that same warning *without* the extra scripted DPH?

You should see the full stack trace of the warning in the ITR 'Long info' column.