How to handle a JSON/REST Arguments that change dynamically

[RaviMerneedi_CVS]

I'm creating a Virtual service for a JSON request that has a plain URI and an argument that changes dynamically with the following parameters

 

e.g. POST http://ip:port/serviceName/operationName?operationIdentifier/parameter1/parameter2/parameter3

and an XML Payload request.

 

I Built a VSI & VSM using REST protocol and generic XML payload parser and set up Exact Match Tolerance on the request arguments. Once the service is deployed, Live requests don't get matched as the Request arguments - parameter1, 2 & 3 change dynamically and do not match the tolerance and gets an error "LISA VSE couldn't match a request..."

 

Request1

POST http://ip:port/serviceName/operationName?operationIdentifier/5678231/98342/14876

 

Request2

POST http://ip:port/serviceName/operationName?operationIdentifier/98778231/412342/84876

 

Is there any way to set the arguments with Parameters to be ignored or Parameterized with any handler?

[Danny Saro]

If you get "LISA VSE couldn't match a request..." that means that the signature of your incoming request does not match the signature of your transactions in your .vsi, so you don't even get back the META response. You are not yet dealing with the dynamic nature of the arguments in your URI

 

We would need to see the signature of your transactions in the .vsi, and we would need to see the signature of an incoming request as it shows in the Inspection View of the Portal.

 

Theoretically, as far as I can tell, the HTTP transport protocol handler will split your URI along the question mark (?), so you will get an operation: POST /serviceName/operationName

But your request arguments??? , the string "operationIdentifier/5678231/98342/14876" is not a standard HTTP argument. In most cases it would have been something like operationIdentifier1=5678231&operationIdentifier2=98342&operationIdentifier3=14876

 

I expect that the HTTP TPH translates your inccoming request into:

Operation: POST /serviceName/operationName

Argument1:

name: operationIdentifier/5678231/98342/14876

value: blank (no value)

 

 

Printscreens of your .vsi and of the Inspection view would allow us to confirm the above an suggest a solution

 

Cheers,

Danny

[RaviMerneedi_CVS]

Danny,

You are absolutely right, It’s exactly recorded as

 

Operation: POST /serviceName/operationName

Argument1:

name: operationIdentifier/5678231/98342/14876

value: blank (no value)

 

 

Live Request is

Operation: POST /serviceName/operationName

Argument1:

name: operationIdentifier/9845231/12342/76476

Since this exact Argument is not Found, It returns that error.

Since the data in the VSI has discretionary business data, I can’t provide a screenshot of it.

 

Can you please tell me how to handle this Argument with Parameters that change dynamically at Live Invocation?

 

 

[Danny Saro]

You will have to use a Scriptable DPH to parse the name of your argument and create "real" arguments from this, and then remove the original argument.

 

Can you tell us how you would like the signature to look like? How many arguments with what name? And what part "operationIdentifier/9845231/12342/76476" goes as value into what argument?

 

Cheers,

Danny

[RaviMerneedi_CVS]

Dany, please tell me how to handle with Scriptable DPH to parse the following:

 

Argument - operationIdentifier/9845231/12342/76476

operationIdentifier - {{operationID}}

9845231 - {{TokenID}}

12342 - {{RefID}}

76476 - {{MbrID}}

 

 

[Danny Saro]

Below is a first try. Be aware this code is not tested. Be aware that to have good script quality a number of checks and tests should be added so the script doesn't fail if some request comes in with slightly different structure. E.g. you should test that there actually exists an argument before you take the value of its key and split it. You should test that after splitting you actually have an array of 4 different values before creating new parameters from them. Etc...

 

So, add a Scriptable DPH with below code to your VSE Listen step.

 

 

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

// Get the parameterlist containing the request arguments
ParameterList requestArguments = lisa_vse_request.getArguments();

// Grab the value of the key of the first (and only) argument
// and split it into an array of values
Parameter parameter = requestArguments.get(0);
String[] httpArg = parameter.getKey().split("/");

// Remove the original first (and only) parameter
requestArguments.remove(0);

//Add the correct arguments
requestArguments.addParameter(new Parameter("operationID", httpArg[0]));
requestArguments.addParameter(new Parameter("TokenID", httpArg[1]));
requestArguments.addParameter(new Parameter("RefID", httpArg[2]));
requestArguments.addParameter(new Parameter("MbrID", httpArg[3]));

[Premalatha Gadde]

You can configure Dynamic values using {URLPARAM} in REST DPH. Please look at REST Data Protocol Handler - DevTest Solutions - 10.4 - CA Technologies Documentation 

[Danny Saro]

In this use case the HTTP TPH has already parsed the Http URI argument and created a request argument from it (with only a key and no value). The request operation does not contain any dynamic data values anymore when a REST DPH is applied, so there is no {URLPARAM} to configure.

 

Cheers,

Danny

[RaviMerneedi_CVS]

Hi Danny, I tried the following  script  in the Scriptable DPH section, but getting an error: java.lang.RuntimeException: Exception evaluating script: bsh.EvalError: 

Am I doing something wrong here?

 

import com.itko.util.Parameter;

import com.itko.util.ParameterList;

// Get the parameterlist containing the request arguments
ParameterList requestArguments = lisa_vse_request.getArguments();

// Grab the value of the key of the first (and only) argument
// and split it into an array of values
Parameter parameter = requestArguments.get(0);
String[] httpArg = parameter.getKey().split("/");

// Remove the original first (and only) parameter
requestArguments.remove(0);
//{operationName}/{0}/{1}/{2}/{3}/{4}/{5}/{6}/{7}/{8}/{9}/{10}/{11}/{12}/{13}/{14}
//Add the correct arguments
requestArguments.addParameter(new Parameter("operationName", httpArg[0]));
requestArguments.addParameter(new Parameter("version", httpArg[1]));
requestArguments.addParameter(new Parameter("appName", httpArg[2]));
requestArguments.addParameter(new Parameter("appDevice", httpArg[3]));
requestArguments.addParameter(new Parameter("tokenID", httpArg[4]));
requestArguments.addParameter(new Parameter("refID", httpArg[5]));
requestArguments.addParameter(new Parameter("participantID", httpArg[6]));
requestArguments.addParameter(new Parameter("check1", httpArg[7]));
requestArguments.addParameter(new Parameter("embedURL", httpArg[8]));
requestArguments.addParameter(new Parameter("fromDate", httpArg[9]));
requestArguments.addParameter(new Parameter("toDate", httpArg[10]));
requestArguments.addParameter(new Parameter("check2", httpArg[11]));
requestArguments.addParameter(new Parameter("someID", httpArg[12]));
requestArguments.addParameter(new Parameter("clientID", httpArg[13]));
requestArguments.addParameter(new Parameter("embedOpName", httpArg[14]));
requestArguments.addParameter(new Parameter("check3", httpArg[15]));

[Danny Saro]

There should be more information after "Exception evaluating script: bsh.EvalError: ", could you post the complete error message so we can see which statement actually fails?

 

Thanks,

Danny

[Danny Saro]

I did a quick test using a VSM in ITR with the above script, copied an pasted as-is, nothing changed:

 

I fired the following url at the waiting VSM  http://localhost:8002/someContext?operationName/0/1/2/3/4/5/6/7/8/9/10/11/12/13/14 

 

And below you can see the first bold line, that is the request after the HTTP TPH with only one argument (it is a JSON representation of the request as logged in the workstation system messages)

And the second bold line is the request transformed buy the Scriptable DPH now with the original argument removed and replaced by 15 "splitted" arguments. 

 

INFO - Name: GetUrlArgument Version: -1 created with LISA 10.3.0 (10.3.0.297)
INFO - Test Case Saved to: C:\CA\CDBOK\JSON_Processing\Tests\GetUrlArgument.tst
INFO - Test Case Results Saved to: C:\CA\CDBOK\JSON_Processing\Tests\GetUrlArgument.rsp
INFO - Name: ParseUrlArgument Version: 5 created with LISA 10.3.0 (10.3.0.297)
INFO - Inbound Request {"id":0,"operation":"POST /someContext","arguments":{"operationName/0/1/2/3/4/5/6/7/8/9/10/11/12/13/14":"operationName/0/1/2/3/4/5/6/7/8/9/10/11/12/13/14"}}
INFO - Inbound Request {"id":0,"operation":"POST /someContext","arguments":{"operationName":"operationName","version":"0","appName":"1","appDevice":"2","tokenID":"3","refID":"4","participantID":"5","check1":"6","embedURL":"7","fromDate":"8","toDate":"9","check2":"10","someID":"11","clientID":"12","embedOpName":"13","check3":"14"}}
INFO - (setSelectedNode) index: 0

 

So, as thescript seems to function fine, I think the error is in the request that you fire at the virtual service, can you post the url that fails on your side? Also, please post the complete script error message.

 

Cheers,

Danny

[RaviMerneedi_CVS]

Danny,

   It worked, I figured out the issue, the argument was coming as blank during that recording and throwing that error. Once the argument was showing up in the recording, I was able to parameterize the arguments and deployed it successfully. Thanks for your help, I appreciate it.