We may not be able to solve this challenge in this thread.
TCP is one of the lower level transports so unpacking requests / responses requires a detailed understanding of the transaction data and the expectations of the TCP client & server on each side of the interaction. Some things to understand in order to debug are:
- Is all data passed in ASCII compatible format?
It seems DevTest is trying to tell you that it may have encountered data outside the ASCII character set. When this happens, DT considers the payloads as binary. This makes the data un-editable in the VSI from a perspective of magic strings.
- Do you know if the payloads have information about the record that are part of the payload but technically not part of the data?
For example, some applications use delimiters as a technique for defining where a record begins and ends. Some applications use the concept of passing a record length. Typically, both of these constructs are part of the record, but they are not considered to be part of the request or response body. You will need to know if either of these idioms apply to your transactions.
- Are you certain the consumer application does not pass begin and ending delimiters in the request/response records?
If delimiters are used to specify the begin and/or end of records, these delimiters need to be stripped before the payload is placed in the request. There are cases where these delimiters are custom; therefore, requiring the development of a Custom Delimiter for DevTest. The Records are Equal to Whole Data Package selection used during recording basically states there are no delimiters and everything in TCP data package is considered to be request or response data. This may be causing DevTest's interpretation that there are binary characters in the data. Perhaps, these binary characters need to be stripped.
- Is it possible to use a tool to sniff the messages so you can see the content and structure?
tcpdump, Wireshark, or tcpmon can capture transactions between the consumer and provider.
These tools are helpful in determining the makeup of the transactions.
Look in LISA_HOME/bin at a utility called tcpmon.bat or tcpmon.sh.
Run TCPMon - DevTest Solutions - 10.1 - CA Technologies Documentation
Run TCPMon - DevTest Solutions - 10.3 - CA Technologies Documentation
tcpdump and Wireshark run on either the client or provider and sniff the traffic entering and exiting the NIC so you will not need a significant amount of configuration.
tcpmon acts as a man-in-the-middle so the client points to tcpmon and tcpmon points to the provider.
- Lastly, once you have configured the TCP transport related details, you need to apply the correct DPHs to create a request operation and construct input request arguments. Without these values, the VSI has no real mechanism for determining its response selection. If the payload data is XML, use one of the XML DPHs. However, since you are recording TCP, my suspicion is that the payloads utilize a more proprietary data format that will require a custom approach to parsing requests.