Is there any practical scenario or use case where a service or a connection was simulated in Devtest using TCP protocol?
Is there any practical scenario or use case where a service or a connection was simulated in Devtest using TCP protocol?
Hi,
Any application using the TCP protocol will tend to be very specific - a "general" example would be difficult to find.
What are you wanting to achieve? What application are you hoping to virtualise that uses a TCP connection?
I noticed you indicate ICMP and UDP protocols in your data flow. These are not TCP protocols so you may get mixed results and need to develop a custom transport handler if your requirement is to support these protocols.
For TCP and depending on how your messages are delimited, you may need to create a Custom Delimiter to indicate where a message ends and the next message begins.
Thanks Joel!I will ask clients to explain the scenario more.And what if we get the correct details?Do we need rr pairs or would go by recording?
I don't think we would get RR pairs for the same,but I will ask them.
You should be able to record from R/R pairs. If the data contains EBCDIC characters, you might need to store the pairs in binary form though. Keep in mind, you need the R/R pairs exactly as they look "on the wire". Some folks make the mistake of inputting the data in ASCII but at runtime the codepage or format could be different.
As wooda20 pointed out, a generic, practical example is probably non-existent. At the high level, the business reason for virtualizing TCP is no different than the reason for virtualizing any other protocol.
The reason Dave answered the question the way he did is because TCP is simply the transport on which the data flows. The typical challenges when using TCP are to locate the start / end of a transaction. Sometimes, this requires a custom delimiter. Chances are the payload content will require custom data protocols (or Opaque) to get the request / response into a format that is consumable in the VSI.
One example:
I had an airline customer that had a legacy client server application circa 2000 that communicated with a mainframe application over TCP. The payloads were very specific to the mainframe application. CA was able to virtualize the TCP transactions. The technical architecture of the service supported custom delimiters, parsing of the request / response payload to get usable VSI arguments, and EBCDIC to ASCII data conversion and back. The business outcome was the opportunity for the airline to save thousands of dollars in mainframe compute costs using the virtualization. In this case, the business outcome (i.e., savings) justified the end game. As an aside, the vendor of the mainframe application reviewed the virtualization and was impressed with what CA accomplished -- considering we had minimal information about the makeup of the transactions.
I tried looking into a link i.e Virtualize TCP - DevTest Solutions - 8.0.2 - CA Technologies Documentation and then I could try recording the transactions.But,I still doubt what would be the correct way to record the traffic.Will it be using agent or proxy mode recording.I am not sure
As wooda20 pointed out, a generic, practical example is probably non-existent. At the high level, the business reason for virtualizing TCP is no different than the reason for virtualizing any other protocol.
The reason Dave answered the question the way he did is because TCP is simply the transport on which the data flows. The typical challenges when using TCP are to locate the start / end of a transaction. Sometimes, this requires a custom delimiter. Chances are the payload content will require custom data protocols (or Opaque) to get the request / response into a format that is consumable in the VSI.
One example:
I had an airline customer that had a legacy client server application circa 2000 that communicated with a mainframe application over TCP. The payloads were very specific to the mainframe application. CA was able to virtualize the TCP transactions. The technical architecture of the service supported custom delimiters, parsing of the request / response payload to get usable VSI arguments, and EBCDIC to ASCII data conversion and back. The business outcome was the opportunity for the airline to save thousands of dollars in mainframe compute costs using the virtualization. In this case, the business outcome (i.e., savings) justified the end game. As an aside, the vendor of the mainframe application reviewed the virtualization and was impressed with what CA accomplished -- considering we had minimal information about the makeup of the transactions.