Service Virtualization

Here is the fixed length request that needs to be parsed

@CPRM 0288***00000000                   0000000000000000000                                                                                                                                                 ALLCOSRH00081309XXXXXXX ******          XXXXXXX     111111111111111111111111        &RQ09 0293***00000000                   000000000000        081309CLNTNM                   00000000          00000000       BOB                                               NI                                                  N                                                          02502501&EOFR 0010

we need to parse out BOB from it and use BOB as argument to respond the message corresponding to BOB, currently DevTest is responding to any response in the Image as all the requests are of same length.

Copybook is best, but you have two other choices ...

1. If you can get the data mapping information, you can put that into a scriptable DPH. This is what I usually do, and it is how I would create an argument for "BOB".

2. Opaque Data Processing was designed for this kind of message format, where you don't know the complete structure.

Hi Rick,

Thanks for the quick response I got the point of Scriptable DPH but I didnt understand what you mean by Opaque Data processing.... didnt see any such options

I am trying the following....

1. Using the RequestDataManager to make an arg out of the request body - seems to be working as is 

2. I will also try the scriptable DPH and try to parse out BOB or any other name using regex and make it an argument and use it to do an exact match to find the response .... i would appreciate some help on scriptable DPH

I am hoping to make this VS as data driven using the second option...

Will let know how it goes

Page 46 and onwards in this document talks about scriptable DPH

DevTest 8.0 - Scripting Guide - V1.1.pdf 

What I do with this kind of message is create arrays of field_name and field_length, and then parse the request message using the field_length values as substring values, grabbing the substring data, matching them to the field_names and saving them as parameters. It's a bit of work up-front, but everything after that becomes trivial (operation name, the field_name containing BOB, correlating response values to request values, time-shifting, etc).

Opaque Data Processing is a transport protocol first introduced in DevTest v7.5.

The Magic of Opaque Data Processing, Revealed 

Its goal is to not need to do any of the understanding listed above, and work out for itself what each byte in the response should be from inspecting a reasonable number of requests & responses.

You might need to write a custom copybook fixed length message parser using java and place it in custom step to pass the message and match texts against expected values and then return true or false to the vs image response selection step to select proper response message, or you can also formulate the response message and return it as a String from the custom step and then save it as a property like {{response}} and then place it in the image. Other way of doing it could be through response lookup step, where incoming request message would be compared against a set of string variables and if proper match found, it will respond with appropriate response. In both the approaches you can keep the match criteria in project config properties file and if in future you need to match anything else other than BOB from your request, you just modify the match criteria and redeploy the service, it will work as expected. So, without changing the parser logic, you can dynamically change the match criteria according to your requirement.