Service Virtualization

I'm attempting to setup a data driven Virtual Serivce (SOAP) The request parameters contain 2 values (RqUID & AccountNo).   the account no is used for the lookup (ex: RqAccount=001), and the RqUID is generated by the calling app for tracking (ex: RqUID=23984923899), and is a random number..

The XLSX file contains the Request Data Augument AcctId, but no RqUID, as it can never be matched.

The challenge I face is that it seems the Request Data Arguement must have matching entries in the mapping xlsx file.  If include the RqUID, the virtualization will never work, and I cannot set the mapping to ignore the request data.  Need an option to ignore some parameters when mapping the SOAP request parms.  Suggestions are welcomed.

Also potentially needed would be to mark the RqUID as a magic value to be returned the response.  is there a way that could be done, in a data driven scenario?

This is BTW version 9.1..  Maybe available in 10.x?   If could confirm?

Regards,

Rob.

At present data-driven virtual services done support comparison operator, the default comparison operator will "=.", even in DevTest 10 version does't support.  

But however, you can solve your problem by adding Request Data Manager Data protocol handler and Move the RqUID argument as an attribute. 

Follow the below steps to solve your problem.

1.  Keeps the transaction signature with only one argument. i.e. AccountNumber

2. From the workstation add the Request Data Manager to the virtual services and move the RqUID argument as an attribute. 

3. To update the response with dynamic RqUID user the attribute as the magic string. 

I have tested it and it is working, I got the UID what I send in the request argument. 

Hope this helps, 

Thanks,

Vamsi Kurukuri  | Services Architect | CA Technologies

I'll give it a try next week sometime...  In the meantime, I did stumble upon a behaviour that seemed to solve my difficulty.. Basically, I set the request to map on the same field numerous times, but I found the system only attempts to match on the last mapping entry. The remaining fields seemed to be ignored (yea!).  Requested CA to confirm behaviour as correct or just a bug that is a useful feature.  see screen shot below.   Go figger...

Strange, are you sure it is not matching the meta-transaction ? 

I'm not sure, as I'm going on behavour of the tools, nothing concrete.  I can see (through experimentation) that the order makes a difference, with the last entry being the match mapping. Beyond that CA will need to clarify the behaviour...

But it seems to work...

It is most likely to be a bug that happens to be a useful feature.

I agree with you, we do NEED the option to set the arguments required for mapping and ignore the rest... Imagine the incoming request has 50 arguments and 10 different scenarios, and I have to create an excel file with 500 argument values, a nightmare to maintain the data.

I don't think so if you are matching only with one or two arguments out of 50 arguments, you can create only those one or two columns in the excel at MAX you will create 50 columns in the excel.  

You can create multiple signatures if the incoming request varies on number of arguments.