Virtualization TCP traffic

[Ritu Arora]

Hi All- I have a requirement to virtualize TCP transactions. I received attached RR pairs and have host and port details of the target system.
When I navigate to create the service, there are multiple fields which need to fill in like-
"Treat request as text", if yes then need to answer about encoding
same for response
"Request Delimiter"
"Response Delimiter"

I am not sure which and how this information needs to be asked from the requester team.

Please suggest me how to proceed. If RR can be a right approach or recording can help us here and which all info I need to gather before start of recording.

Appreciate your guidance.

Regards,
Ritu

Attachment(s)

Elavon-req.txt   395 B 1 version

Elavon-rsp.txt   395 B 1 version

[Danny Saro]

Hi,

 

This seems to be XML over TCP.

 

You are sure that it is plain TCP and that it is not XML over HTTP?

 

The XML file is the whole datapackage, so you can define: Request Delimiter = Records are equal to whole Data Package.

Same for Response Delimiter.

 

Then next you will need to process the XML, the data is in attributes, if you know which field will be used for your matching criteria then you can use a Generic XML Parser DPH to movethe attribute value of that field to an argument.

 

Cheers,

Danny

::DISCLAIMER::

---

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.

---

[Ritu Arora]

Thanks Danny. I double checked and it seems its XML over TCP only. Lets see how it goes. I got another information that  request encoding is in ISO-8583 standards. Does it mean that we have to treat request as text? I don't see any option for ISO-8583 standards.

Can I test this service? I didn't find any step to send traffic over TCP. Please advise.

Regards,
Ritu

[Vaibhav Jain]

Hi Ritu,

ISO8583 messages can be in different formats like Hex, XML etc. Looking at the XML, i think you don't have to change any encoding format and can use the request as text.

As per my understanding, there is no TCP step within workstation to test. I use an OpenSource utility PackerSender (https://packetsender.com/) to test/trigger the transactions. Also, there was a custom step created long back for TCP trigger, not sure if it will compatible with the latest versions of CA DevTest.

Thanks.

------------------------------
Regards,
Vaibhav Jain
Capgemini
------------------------------

[Vaibhav Jain]

Hi Ritu,

PFA the TCP step jar. Copy the same in lib folder under LISA_Home.

I tested it and this is compatible with 10.5 version.

Thanks

------------------------------
Regards,
Vaibhav Jain
Capgemini
------------------------------

Attachment(s)

vaib.zip   31 KB 1 version

[Ritu Arora]

Thanks Vaibhav. It helps.

Regards,
Ritu

[Ritu Arora]

I'm back with change in requirement. After doing more analysis we found that data is not exchanged in xml over TCP but its a binary form
Request-ABgYBCAwAQAAAAAAAAAARhZwGRAxETIRCDE=
Response-ABQYFAAAAGVEkBkQKAkYKQ==

If I can send the same response back to client, that will suffice the need for now.

I'm not sure how to make RR pairs for that but tried in a very normal way and put the same data in to RR pair. tried creating service, treated req and rsp as text, all default settings and created services. No data protocol selected (not sure what to select). Service got created with unknown operating and not receiving any transaction on that, its timing out from client.
Can I create the service with this data, defined some generic way where all the requests will be responded with given response without checking any operation or any thing.

Please advise and help.

Regards,
Ritu

[Ritu Arora]

Please check if someone can help me here.

Thanks much!

[Vaibhav Jain]

​Hi Ritu,

One easy option is to have a TCP VS deployed and invoke it from application(although it will be timed out, but you will be able to see the operation name in portal coming from application call). Once, the operation name is identified you can update the same in vsi.

Thanks

------------------------------
Regards,
Vaibhav Jain
Capgemini
------------------------------

[Danny Saro]

Hi Ritu,

For your very immediate need - ie. sending back the same response to whatever incoming request - you can set the operatio name yourself:
Add a scriptable DPH to your Listen step, inside one statement: lisa_vse_request.setOperation("xyz");
Then in your vsi, set the operation name to "xyz" and set Match Style to "Operation"

For your future versions, you do need access to application design information regarding this communication, otherwise it will be a lot of trial and error.
The request string you are showing is a Base64 encoded string. I decoded it which then gives you a binary datablock. Very often what you then get on the next level is a zipped payload. In your case it is not gzip, I tried it, not the correct format. It could be a normal zip (windows-like), because it can be processed as such BUT in this case it processes as an empty zip file, ie. no file inside the zip-file. Which is not surprising because the binary block is ony 26 bytes long. For one file zipped, the zip file itself will likely have an overhead of more then 150 bytes. So, if it is a zip file then it is empty (no ZipEntry inside).

If you can get hold of a bigger request payload, you can post it, we can have a go trying to unzip it. Once you know how to treat it to get readable text than we put those statements in a scriptable DPH, and then subsequently let another DPH process the XML (or whatever).
BUT it would be more efficient if you get hold of the documentation which describes what exactly goes over the wire instead of the above trial and error method.





------------------------------
Cheers,
Danny
------------------------------