SV for TCP with HEX Message

[venukg]

one of my client have requirement have service virtualization for ISO 8583 messages.  I wanted to do SV using LISA. transport protocol is TCP and it has HEX data into it. can Some one guide me how to proceed?

 

how to test once we developed the VS?

[Legacy User]

ISO 8583 transactions are not directly supported out-of-box.

There have been some customer-specific implementations created by CA Services personnel; however, those DPHs cannot be shared here because they are customer-specific and may contain proprietary implementations.

Generally speaking, one would use the DevTest TCP step as the listener / responder.

A custom Data Protocol Handler (DPH) would take in the request or response and perhaps call 3rd party JARs to convert the message from HEX to ASCII or vice versa. Once converted, the data can be edited within the VSI.

If for some reason, the HEX data is outside the ASCII character set range, additional considerations may apply for dealing with these elements. 

[venukg]

Hi Joel,

Thanks for the information..

 

I am using Devtest 10.1 and need your help to develop virtuval service using messages(HEX or ASCII) for ISO 8583. As I do not work on ISO messages. Please let me know if you need any information from my side.

 

Thanks,

Venu

[Legacy User]

In this scenario, we need to engage with you and your customer to discuss in detail the available options.

I sent a private message asking for some information in order to figure out how to proceed.

[venukg]

Hi Joel,

 

can you please share JAR files to covert HEX to ASCII and vise versa?

 

Thanks,

Venu

[Legacy User]

I don't think it is as simple as just converting Hex to ASCII -- especially, if the input contains non-ASCII Hex data such as (0x00, 0x0B, 0x0C, etc.)

 

There is some third party work worth researching at: chochos / j8583 — Bitbucket 

These are the types of JARs consumed by the DPH during request / response processing.

The DPH processes the request / response as it is presented with DevTest. The DPH then invokes these types of classes to perform the conversion work to and from a format compatible with DevTest. From this message, the DevTest attributes are generated. Since this is TCP, there might also be a need for a TCP delimiter so request / response data can be correctly set. I do not know what the value of those delimiters would be for your implementation.

[venukg]

Joel Nesmith's Blog - thanks for your inputs.

let me check with my client and will get back to you or will submit support ticket.

 

Thank you,

Venu

[venukg]

Hi Joel,

 

I had discussion with my client and as per discussion, based on MTI code they should receive response.

I have followed below process.

Steps:

1. created VSM and VSI by selecting TCP as transport protocol and without selecting any DPH using RR pairs which are in HEX format.

2.  Edited VSM by adding Scriptable data Protocol and added below script to convert the HEX to String.

import com.itko.util.ParameterList;
import com.itko.util.Parameter;

// Manipulate request body text
String theBody = lisa_vse_request.getBodyText();
 theBody = theBody.replaceAll("[^a-zA-Z0-9 ]","").replaceAll("\\s","");
            StringBuilder output = new StringBuilder();
            for (int i = 0; i < theBody.length(); i+=2) {
                String str = theBody.substring(i, i+2);
                // Remove spl char and space
                output.append((char)Integer.parseInt(str, 16));
                output.tostring().replaceAll("[^a-zA-Z0-9 ]","").replaceAll("\\s","");
            }
            String hex2 = output.toString().replaceAll("[^a-zA-Z0-9 ]","").replaceAll("\\s","").substring(00, 04);
            hex2.addParameter(new Parameter("MTI_Code", MTI));
            lisa_vse_request.setArguments(hex2);

 

3. added Argument key value pair in VSI. Argument name as "MTI" and value "0200"

4. deployed on port#.

 

I have below Questions:

1. Is it correct approach?

2. How to test TCP calls.

 

could you please guide me to complete this project?

 

Also I have tried to hit the service by using java code.

public static void TCPclientcall(String outputString) throws IOException,ClassNotFoundException, InterruptedException {
  // System.out.println(outputString);
  try {
   //InetAddress host = InetAddress.getLocalHost();
   Socket socket = null;
   socket = new Socket("localhost", 9876);
   ObjectOutputStream oos = new ObjectOutputStream(socket.getOutputStream());
   ObjectInputStream ois = new ObjectInputStream(socket.getInputStream());    
   if(outputString!=""|outputString!=null){
    oos.writeObject(outputString);
   }
   String message = (String) ois.readObject();
   System.out.println("TCP Response Message:" + message);
   ois.close();
   oos.close();
   socket.close();
   Thread.sleep(100);
  } catch (IOException e) {
   e.printStackTrace();
  }

 

 

Thanks,

Venu

[Legacy User]

What was the result of calling your the service from the test harness?  Were you able to receive a response message?

 

On to your questions:

1. Is it correct approach?

If you answer that the test harness is able to receive a response message from the service, then I would say your approach worked, at least, to the point where the service was able to send a response. The answer to your question of whether or not the approach is correct is something that you and your business partner have to answer. Having an agreement that the service meets the requirement(s) is the final way of making a determination.

 

From a CA Services point of view, it would be more efficient to create a custom DPH (compiled Java code) rather than use a Scriptable DPH for several reasons.

• Performance - a custom DPH is compiled Java code
• Framework - custom DPHs can take advantage of logic that might not be easily implemented in a Scriptable DPH (utility methods, morphing, subclassing, inheritance, etc)
• Parsing - Normally, a DPH parses all the elements inside the request payload into an input argument list.

Potential Issue: Your DPH only parses the MTI code. The VSI response selection can base decisions on the MTI code value. If other elements within a given MTI code are used as a decision point, the Scriptable needs to locate and parse those field(s) as well.   

• Response / Maintainability - Your display did not include the response side for the example MTI code. Is the response stored as binary or ASCII text? My guess is that the response is a long string or binary object. A custom DPH provides facilities (during recording and playback) for parsing the response data into a JSON or XML format such that the response in the VSI is readable to the user, more easily accepts {{magic string}} response notations, and can apply {{doDateDelta}} logic on dates in the response output. NOTE: {{magic strings}} are largely based on parsing the incoming request. At best, your response can only echo the MTI code from the incoming request. I cannot echo other elements that may be on the request since those elements are never parsed and added as arguments by the Scriptable.

 

2. How to test TCP calls.

Your approach is correct for the most part. Some sort of test harness needs to act as the client and send a request to the endpoint virtual service over a TCP connection. Or, debug by using the actual client application. If using a harness, the request needs to be in the exact format that the real consumer application would send. The caveat to this form of testing is that debugging Scriptable DPHs often involves using _logger.info to display output and Scriptables can also encounter exceptions, typos, etc.

  

When using a custom DPH, a test harness can bypass the TCP server layer (i.e., transport), create a Request or Response object, store the binary data in the request or response body, and call the updateRequest or updateResponse methods. This allows debugging within the IDE. 

[venukg]

Hi Joel,

 

Thanks for your explanation.

we will submit the support ticket for this and will share the details once I have support ticket number.

 

Thank you,

Venu

[venukg]

Hi Joel,

 

we have submitted support ticket on 20th July  and CA Support Case #01146894.

I have a webex with "Marcy Nunns" and explained what I have did till now.

below is the next actions description from CA support team:

I will reach out to our professional Services organization and ask them for help.

 

Thanks,

Venu