Service Virtualization

In our regression we are getting into issue when request got changed with one new element [or]  remove one element and our virtualization service deployed with match style "Exact" mode. In this situation we are getting META response. Is there any way we can suggest in VSE log matches one request in VSI matches x% and new element got added incoming request.So that end user will know why it is failed in run time.

If you have created a VS with specific number of arguments (for example 5) and if you send a request with 4 or 6 then you should get a "No Match" but not a META match. You will get META match only if the signature of the transaction is matched, which means the number of arguments and names should match.

If you request has any optional arguments, then you can use Request Data Manager DPH while creating the VS and configure the Arguments. For example, if your request has 6 arguments then using Request Data Manager DPH you can create with only 4, 3, etc but your request can still have 6, 7, 8, etc. To match the request it will look for what you have it in the VSI and ignore the rest.

Hope the information helps, if need more help with specific example then please open a support ticket.

In my case we are using Stateless transaction has "Operation" and each scenario transaction has "Signature". So if message name match and no individual transaction matched we will META response. My question here it is our stubbing working fine for release1 and when release2 comes there is one new element added and we are getting meta response. Is there anyway we can get "release1" matched transaction and explain in DevTest log only one element not matched and may be code changed. This helps end user why test case failing in "release2" and passed in "release1".

If you look the vse_matches.log and/or VS_XXXX.log (XXXX refers to the name of the VS) that should give the information about the request arguments. For example:

vse_matches.log:

2017-03-02 23:22:26,053Z (17:22)[ucs [VS_ucs11_Run]/1] INFO  - Transaction Navigator Respond from: {"id":3,"request":{"id":24,"matchTolerance":"EXACT","operation":"deleteUser","arguments":{"user":"vfbC60"}}}

VS_XXXX.log:

INFO  - Stateless Match Transaction: {"id":4,"navigationTolerance":"<stateless>","request":{"id":5,"matchTolerance":"SIGNATURE","operation":"addUser","arguments":{"username":"webapp-1809697075554","password":"example-pwd"}}}

You can also see the arguments in the VSE Inspection view.

depending how the log level is set you can get the matching information in the inspection view as the image http://ecm.ca.com/KB/KB%20Asset%20Library/TEC1179674_Embeded/InspectionView_Matching.png 

How do you use the Inspection View and options to help debugging VSE transactions. 

As deoma03 and gadpr08 both state, there is not an out-of-box way to display only the new or missing arguments that did not match. DevTest prints all of the arguments on the input request into the logs.

From a product perspective, the following scenario complicates the idea of printing only the elements that do not match even further. Assume that the same operation in a VSI has a varying number of args:

OpA   - 4 VSI arguments for input request

OpA   - 5 VSI arguments for input request

OpA   - 10 VSI arguments for input request

OpA   - setup for operation match only (no specific txns only META response)

If a request comes in having 8 arguments, which of the above operations does the product use to base its print out of the arguments that mismatched?  The logic that might work for one scenario fails for another.

Maybe, you could get fancy and code a matches script that compares the incoming request operation name, arg list count, and arg list names against the VSI's arg list count and names and then print input argument mismatches.This approach, assuming it is doable, creates additional CPU overhead for the service. I would definitely not recommend this for a performance test scenario.  

Thanks for you reply , This logic I am only going to apply when META response match and this saves lot of time in debug why pour request not matched from UI generated request. This will helps end user to triage the issue what was missing from Stubbed and incoming request. my goal is match the best match from VSI and show the different to end user only when meta matched.

Hi,

Just a suggestion

If you are sending response from EXACT, i am sure you must be using some attribute to identify uniquely all matches uniquely.

Solution:

For EX: If there is 1 Meta (Signature), 1 Operation and 15 EXACT.  I am using <empId>1</empId> to identify all matches in EXACT uniquely.

So coming back to query, if Myrequest is getting change irrespective of <empId>1</empId>, then i can simply add match script for <empId>1</empId> in all EXACT.

Now, When ever any request come to Lisa, it will match the operation name and Match Script. That's it. It will not check your other attributes(Whether any tag is added or deleted) and it will send the response accordingly.

I am sure it will resolve your issue

Regards,

Sumeet

Can you help me understand what you need here?

If the service was able to still find and send a reply, would the consumer of the service be OK?

If so, then if the element is NOT used in the response (e.g. a magic string) then you can use the Request Data Manager to strip out the unnecessary request arguments so you'll match more often.

Or do you just need better information on why the request didn't match?

I am looking for print meaningful information with best match from VSI and different from Best match vs invcoming request. Because user looking for valid resposne and they are getting meta. We want to communicate to  end user when they seeing in VSE dashbaord they got the META response however there is one best match found in VSI with [One Element added/One Element missing/Element value different].  This helps our debug process faster when requets changed from stubbed one.

What kind of changes do you usually encounter?  Is it just a minor change in the request, or is there a corresponding change in the response?

Or to ask it a different way - if you were able to still match even when the request changed (e.g. by using a match script), would that take care of the problem?  Or do you need to know when the requests have changed so that you can also change the virtual response?