Service Virtualization

Hi ,

This is related to the already answered question: https://communities.ca.com/thread/241816538-same-responses-is-being-sent-irrespective-of-the-requests-being-received-fro… 

we are using DevTest 9.5 version with  MQ-deprecated step. In the VSI, we have two responses configured which is of XML message.

the incoming request may come in either a plain request xml or in a zip file to the VS. Existing VS is now able to handle both the things and sending the two responses in xml format back to the client.

two response messages are in xml format configured in VSI.

now the requirement is :

if the request comes in a zip file to the VS, then VS should compress the response xml (2 responses) and send the compressed byte messages back to the client, also a header("Compressed = 'Y') need to be passed along with the compressed responses.

is it doable with MQ deprecated step?

solution Assumed is:

1. in the VS Image Response selection step, add a Scripted Assertion to compress the two responses:

similarly compress the second response from VSI and store the zipBytes in another property.

2. Add a publish step (deprecated) and pass the property that is holding the first  response (zipBytes):

3. Add one more publish step and pass the property that is holding the Second  response (zipBytes):

4. Pass the header information in the Base tab of two publish steps added, in publisher info ->Message Properties.

DannySaro Rick.Brown : Please suggest if this is a correct approach or not. 

Thank you

Hi,

A standard messaging VSM (as created when doing a recording) when receiving one request message has the capability to send 2 different response messages using its Responder step. There should be no need to add any additional MQ Publish steps. If the response in the .vsi is in plain XML and it needs to be somehow processed into its final payload format (compressed, …) then a response-side DPH should do this job. If there is no OOTB response-side DPH to do the job you can use a response-side scriptable DPH.

Cheers,

Danny

Hi Danny,

yes correct. the requirement here is to process the plain XML configured in VSI to  a compressed format (normal Zip). in this case how will you compress the plain xml's from VSI using Response side DPH ? and to which property you will put this compressed data into (for two compressed responses)? 

Could you please help me understand on this

this is other question :

Also i have tried adding the following code to zip the response message. it is a normal zip not gzip. getting the below error:

Target exception: java.util.zip.ZipException: no current ZIP entry

i hope i'm missing out putNextEntry(); method or something else. Please help me fix this issue. PFA the code for GZIP which is working perfect. But i need the code working for normal zip as this is my requirement.

import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.util.zip.ZipOutputStream;

String str = testExec.getStateValue("responseMessage");    //responseMessage is a plain XML
if (str == null || str.length() == 0) {
return str;
}

ByteArrayOutputStream out = new ByteArrayOutputStream();
java.util.zip.ZipOutputStream gzip = new java.util.zip.ZipOutputStream(out);

gzip.write(str.getBytes());
gzip.close();

zipString = out.toString("ISO-8859-1");
zipBytes = out.toByteArray();

testExec.setStateValue("zipString", zipString);
testExec.setStateValue("zipBytes", zipBytes);

return out;

The Responder step will process the contents of an object that exists inside the executing .vsm workflow which is called lisa.vse.response

And a response object has a certain structure and that structure is similar to the data you see for a response within the vsi editor. Meaning that a lisa.vse.response:

•   Is an array of response objects (and this is because for messaging one request can have multiple responses, in your case 2, so here there will be a response object on index 0 and one on index 1 of the array.

•   Each response object has a body, and there are operations like getBodyText() and setBodyText()

•   Each response has a metadata parameter list that reflects the key-value pairs that you have as metadata in the vsi editor

So, in your scriptable DPH:

•   You can determine if you need to compress by examining some property that was set when the incoming request was processed.

•   If you need to compress then you can loop over the entries in the array from zero to smaller than length of array

•   Get the uncompressed XML payload with getBodyText(), compress it, update the body with setBodyAsBytes()

•   Add an additional parameter to the metadata parameter list where you set “Compress=’Y’”

(something like the above, I’m not completely clear on all the requirements)

Then after that DPH the responder step will finally handle it and create an MQ message for each response, with the body as payload and the metadata key-value pairs going into the MQ headers.

Cheers,

Danny

Hi Danny,

Thanks for the detail information. 

i have tried adding the following code to zip the response message.

it is a normal zip not gzip.

getting the below error:

Target exception: java.util.zip.ZipException: no current ZIP entry

i hope i'm missing out putNextEntry(); method or something else. PFA the code for GZIP which is working perfect. But i need the code working for normal zip as this is my requirement.

import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.util.zip.ZipOutputStream;

String str = testExec.getStateValue("responseMessage");    //responseMessage is a plain XML
if (str == null || str.length() == 0) {
return str;
}

ByteArrayOutputStream out = new ByteArrayOutputStream();
java.util.zip.ZipOutputStream zos = new java.util.zip.ZipOutputStream(out);

zos.write(str.getBytes());
zos.close();

zipString = out.toString("ISO-8859-1");
zipBytes = out.toByteArray();

testExec.setStateValue("zipString", zipString);
testExec.setStateValue("zipBytes", zipBytes);

could you please help me in fixing this issue.

Thank you.

Have you tried something like below?

:

java.util.zip.ZipOutputStream zos = new java.util.zip.ZipOutputStream(out);

zos.putNextEntry(new ZipEntry("myZipEntryName"));

zos.write(str.getBytes());

zos.closeEntry();

:

Cheers,

Danny

Hi Danny,

Thank you. yes this worked after adding these lines :

import java.util.zip.ZipEntry;

zos.putNextEntry(new ZipEntry("myZipEntryName"));
zos.write(str1.getBytes());
zos.closeEntry();

one more question is :

Additionally we have to send JMS MQ header called  "Compressed = Y", then only client application can process the transaction successfully. MQ is connected at the backend. and we are not very sure about how to pass this header in MQ deprecated step. 

this is just a try-> For this i have added the following lines of code in scripted Assertion in VS Image Response Selection and deployed :

import com.itko.util.ParameterList;

ParameterList metadata=lisa_vse_response.getMetaData();
metadata.addParameter(new Parameter("Compressed","Y"));

but still at client application, this header is not seen.

this issue is related to how to extract custom JMS header property in the VS : but this issue is raised initially  on how to extract the header that comes along with the incoming request. but this is not priority as of now. so we stopped working about it.

but now the priority is : how can we send this header property along with response messages in MQ deprecated step? is it doable?

Please suggest me if you have any ideas about this

Thank you

If you look in the vsi editor then you will see that you can define multiple responses for one incoming request. This is to support messaging virtualization like MQ and JMS

So the Image Selection step does not respond just with one response, it returns an ArrayList of responses. Theoretically if the number of reponses can vary depending on the matched transaction then you need to loop over that ArrayList and “get” and process each response for that request. In the case you know how many there will always be then you can work with hardcoded indexes.

import com.itko.util.ParameterList;

import com.itko.util.Parameter;

import com.itko.vse.stateful.model.TransientResponse;

// First response is on index 0, second on index 1, etc …

TransientResponse response = lisa_vse_response.get(0);

ParameterList metadata=response.getMetaData();

metadata.addParameter(new Parameter("Compressed","Y"));

Cheers,

Danny

Hi Danny,

yes i got it and updated the scripted assertion with two array list using get method with new Parameter. (totally we have two responses configured in VSI). 

after adding this code, we see the same issue again, that the Header passed by the VS is not reaching the client application .

PFA the code snippet that i have used in scripted assertion.

Thank You

Hi,

There can be 2 reasons why you don’t see this header in the client application:

•   The scripted assertion fails to add it correctly

•   Or, it’s the additional key-value pair is in the metadata but it is not in some correct format for it to be added to the MQ headers by the respond step.

Re. first reason, have you been able to assess that Compress=”Y” was added to the metadata?

You are running this VSE in ITR correct? When you look at the event tab and you look at the event regarding the scripted assertion, does it show any errors in Launch Extended View?

If you add a line before the return true; (or false) at the end of the script

System.out.println(lisa_vse_request.get(0));

And you then look at the System messages in the workstation (or at the workstation.log) do you see the Compress printed out in the metadata?

Cheers,

Danny

Hi Danny,

oh okay.

1. Yes i'm running the VSE on ITR. i checked the Test event tab and looked for the scripted assertion event in launch extended view and didnt find any errors there.(PFA the content present in extended view of that scripted Assertion for your reference).

2. Added System.out.println(lisa_vse_response.get(0)); at the end of the script before return false; statement. and Ran the ITR. in the workstation system messages i observed Compressed=Y header getting setting up at the end as highlighted below.

System message:

metaData=dest.ccid=&dest.channel={{Channel}}&dest.destination={{BulkPayment_ResponseQueue}}&dest.host={{HostName}}&dest.queueManager={{QueueManager}}&dest.user=&dest.password=&dest.port={{Port}}&msg.applicationIdData=&msg.applicationOriginData=&msg.backoutCount=0&msg.characterSet=819&msg.encoding=273&msg.expiry=-1&msg.feedback=0&msg.format=MQSTR&msg.getVersion=2&msg.messageFlags=0&msg.messageSequenceNumber=1&msg.messageType=8&msg.offset=0&msg.originalLength=-1&msg.persistence=0&msg.priority=0&msg.putApplicationName=WebSphere MQ Client for Java&msg.putApplicationType=28&msg.replyToQueueManagerName=&msg.replyToQueueName=&msg.report=0&msg.userId=&msg.accountingToken=&msg.correlationId=&msg.groupId=&msg.messageId=&msg.putDateTime=&dest.connectionMode=Native Client&dest.destinationType=Queue - ASYNC&dest.overrideQueueManager=&dest.receiveExit=&dest.securityExit=&dest.sendExit=&dest.tempQueueModel=&dest.isTemp=false&dest.forwardType=true&dest.requestDestination=false&dest.useCorrelationID=false&mq.dest.env.Use Non-Destructive GETs=false&mq.dest.env.Local Address Property=default&mq.dest.env.connectOptions=default&mq.dest.env.ConnTag Property=default&mq.dest.env.Header Compression Property=default&mq.dest.env.Message Compression Property=default&mq.dest.env.Local Address Property=default&mq.dest.env.SSL CertStores=default&mq.dest.env.SSL Cipher Suite=default&mq.dest.env.SSL Fips Required=default&mq.dest.env.SSL Peer Name=default&mq.dest.env.SSL Socket Factory=default&msg.format=MQSTR    &Compressed=Y, transaction=null}

PFA the VSM and VSI files that we are using for your resference.

Thank You

Hi,

Ok, yes, it seems the script works ok. In what MQ Header does your client expect this property to reside? MQMD?  RFH2?

Cheers,

Danny

Hi Danny,

It is RFH2

Thanks

I suggest to open a support case. Your Compress will need a specific format “msg.abc.xyz. ... .Compress” for the metadata key name for it to end up in the MQ RFH2 header. I am not aware how that should look.

Cheers,

Danny

Hi Danny,

okay..Will open the Case.

Thank You