Service Virtualization

 View Only
  • 1.  CA SV Match Script

    Posted Jan 09, 2018 08:56 AM

    We need to generate dynamic XML response based on the input request in CA SV.


    1) If Request has one field then response has one field. If it is two field, then response should be two and so on.

    2) How to use Match script for validating the input request by using Javascript and where can we refer what are all the functions available for this one. We need a sample script for this.


    Please help on this.

  • 2.  Re: CA SV Match Script

    Posted Jan 09, 2018 12:39 PM

    Prior to determining if Match Scripting is the most appropriate solution, can you provide some additional background?

    For example,

    - Are you using any DPHs to add or remove arguments from the input request?

    (i.e., what is the argument signature when the request passes to the VSI)


    - What data protocol does the consumer pass (XML, JSON, copybook, proprietary)?


    - Are there more arguments on the input request than the number of "repeating" arguments you mention in your post?

    (i.e., are there request arguments that do not repeat when dynamically creating the response)


    - How are the responses (signatures) set up in the VSI?

    One and only one signature or multiple signatures (one for each number of input request arguments)?


    - Does the VSI/VSM dynamically insert data into the response payload?

    How does this happen? (e.g., as a custom step in the VSM or as part of the VSI Matches Script execution)



    - What high level test case (user story) requirements govern the data scenario coverage expressed by the service?

    It is difficult to determine, but feels as though the service is not implementing specific behavior, rather simply responding to any possible set of input.  And, that may be appropriate in unique situations.


    Some questions to ponder are:

    Why does the consumer of the service find it is necessary to test with every possible combination of input / output values? 

    What is the business value of a test having 1, 3, 5, 10 and 15 response elements versus a test having 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, and 15 elements?

    Does the option of having the response data in a lookup table enable service consumers to better manage their own responses? 

  • 3.  Re: CA SV Match Script

    Posted Jan 10, 2018 03:06 AM

    Please find the details below,

    1) Sample Request:


    2) XML
    3) From 1 if no of book tag is 2 then output also has same tag with same value , if no of book tag is 3 then output also has 3
    4) one signature
    5) We are creating the VSI using RR pair with MQ transport protocol. That response should be dynamically based on dynamic request which handled by match scripting
    6) Project team needs a response based on every input combinations

  • 4.  Re: CA SV Match Script
    Best Answer

    Posted Jan 10, 2018 09:13 AM
      |   view attached

    Thank you for your answers. This is helpful.

    Normally, moving repeating incoming request arguments into the response requires customization. The complexity of the response message structure rarely echoes back the exact input data. The input data is usually interspersed with other output data that is not in the incoming request. My personal opinion is to not use Matches Scripts for this purpose; however, I suppose it is plausible to do so. 


    Most developers use a Custom or Scriptable DPH to extract and store the repeating data into properties rather than using Matches Script logic. After the response selection occurs, a customization iterates the response payload and inserts the repeating data as necessary. Again, this is usually because it is not as easy as simply copying the request argument list into the response argument list.


    Your scenario, above, demonstrates a simpler version because the request list and response list are identical. Since this is the case, I would consider the following:

    - Add a Generic XML DPH on the Listen step

    - Use Xpath query to extract only the 'book' list items and store them in a property. For example:  //descendant-or-self::book

    - Store the result of the Xpath in the Argument List. For example: fl_book_array


     - (Optional) Add an RDM DPH after the Generic XML DPH

    - Use the KEEP option and only keep the fields 'to', 'from', 'heading', 'fl_book_array'

    - This will drop the remaining arguments from the list and narrow what the VSI sees


    - In the VSI,

    - Set up one transaction having only a META response

    - Change the Match Style to Operation

    - In the response body using Magic String processing to insert fl_book_array back into the <output_sample> element.


    Your example probably does not reflect the actual complexity of the replacement. My guess is that you will need to add some customization. It is likely that the customization will require more XPath processing than shown here.


    Attached is a sample project using HTTP with R/R pairs. The pairs are in the Data directory and a VRS file supporting R/R pair recording is in the VRScenarios directory. This example does not use Matches Scripts. It also does not address the complex structures that are likely in your organization. 


    zip   18 KB 1 version

  • 5.  Re: CA SV Match Script

    Posted Jan 11, 2018 06:06 AM

    Thanks a lot. This is very helpful for us.
    One more clarification is
    1) In our scenario we need to compare all the input tags available (minium 50 input tags) with valid value or regular expressions. But request will coming as dynamically (For example <book> in above xml and for some time some other tags too). For this case how to match the recorded VSI transction with dynamic request which coming from the client. [I mean Match style as Exact]

    Apart from this,
    We have another scenario where we will be using MQFTE as middleware,
    Do you have any idea how to virtualize it.

  • 6.  Re: CA SV Match Script

    Posted Jan 11, 2018 08:57 AM

    Last first:  I have no experience with MQFTE.


    I am not convinced that service virtualization should be attempted for this scenario since you added requirements to evaluate data in the list for certain conditions. Virtual Services should be able to provide responses to a specific, well-known, well-defined set of input request criterion and provide a method (META) to send a generic response for all other scenarios that do not match the specific requirements. It does not feel like this is where the requirement is heading.


    I would seek to limit as much as possible the number of valid values that you compare on in order to make a determination of what business scenario the data is responding to.


    Any scenario that supports a unknown number of completely dynamic input data tags is a recipe for failure because the service has to cater for an what amounts to an unlimited number of scenarios and permutations. 


    I assume that the next requirement will be that the recurring XML data sent by the consumer has no positional order from one service call to the next.  Let's consider an example:  


    Assume that you have 3 occurrences of <books><book>1</book><book>2</book><book>3</book>.

    And, the consumer can send these books in any sequence. This means you have to cater for a minimum of 6 different order scenarios assuming the book IDs remain as 1, 2, 3.  

    Call 1: <books><book>1</book><book>2</book><book>3</book>

    Call 2: <books><book>1</book><book>3</book><book>2</book>

    Call 3: <books><book>2</book><book>1</book><book>3</book>

    Call 4: <books><book>2</book><book>3</book><book>1</book>

    Call 5: <books><book>3</book><book>2</book><book>1</book>

    Call 6: <books><book>3</book><book>1</book><book>2</book>


    Extend the requirement to a possible range of 1 - 50 books (50 scenarios) where the books can occur in any positional order and the matching logic within the service becomes too unruly to manage.


    Add to this requirement the notion of values that might cross reference across the range (i.e.,

    if book ID 1 exists in the list and book ID 4 exists in the list, then send this response,

    if book ID 1 exists in the list and book ID 4 exists in the list AND book ID 12 is NOT in the list, send this response


    Supporting these types of scenarios will require too much time to develop for the value it delivers. 


    If the business partner can isolate some specific data scenarios, there is likely an implementation that will work. Presently, it seems that the business partner is unable to communicate this information. 


    In these situations, I try to find a value or couple of values in the request that identify the business response behavior. For example, if the email address ends with "" send answer for 1, "" send answer for 2, and so on. It is not clear that you are able to do this.

  • 7.  Re: CA SV Match Script

    Posted Jan 12, 2018 04:53 AM

    Thanks for detailed clarifications.