Service Virtualization

Hello,

I am trying to create a soap virtual service using RR pairs but whenever I create transactions operation name in body tag is not displayed , instead Envelope is recorded as transaction name. Any ideas on this ? 

1. I have only configured only Request side protocols - a) Generic XML payload parser b) XML data protocol c) Web-services SOAP d) Web service SOAP Header.

2. I selected Operation name in body tag and mark the current xpath as Operation , in Conversation list window .

When I create virtual serice , in VSI I see transaction named as Envelope (guess which is taken from SOAP request xml)  instead of operation name, let me know if I am missing any step or any wrong step ?

What does the operation name in the VSI look like if you run your RR pairs using only the Soap Headers DPH and Soap DPH? Does the operation name in the VSI show up correctly? 

If so, perhaps one of the other DPHs is overlaying the operation name.

If the two Soap DPHs work, then  rerun your pairs after adding the next DPH. If the results look OK, add the next DPH and check it out. This will help you diagnose which DPH is causing the issue. My guess is the XML DPH is the culprit.

Refer here: Using Data Protocols - DevTest Solutions - 10.0 - CA Technologies Documentation  

Thanks Joel, it worked

I have one more query on returning META responses from this virtual service . I can achieve it by using Specific txn as EXACT and META as Signature , but how can I return META response if my specific txn match style is set as Operation . I tried by using different combinations , but it didn't worked .. It will be helpful if you can share some knowledge , it was not clear from documentation.

You need to consider the sequence within which DevTest operates when making its selections from a VSI.

Signature Analysis: DevTest tries to match the incoming request's Operation Name and Argument Names (not values) to find a list of candidate transactions to match on. Refer to this link for a better description: Stateless Transactions View - DevTest Solutions - 10.0 - CA Technologies Documentation   

Match Tolerance: Defines how the VSE selects a given response from the list of transactions that pass the signature analysis. Refer to this link for a better description: Match Tolerance - DevTest Solutions - 10.0 - CA Technologies Documentation  

• Operation The loosest match tolerance. The operation name of the incoming transaction must match the name of the recorded transaction.
• Signature  The operation name must match and the names of the arguments must match exactly, with no additions or deletions. The order of arguments does not have to be the same.
• Exact         In addition to the signature match, the values for each argument must match the values that were recorded, as defined by the argument match operators.

One way to think about the VSI (graphic below) is that the upper left hand portion of the Service Image Editor is more focused on signature analysis while the the lower left hand portion of the Service Image Editor is focused on Match Tolerance. The right hand side of the SI Editor is focused on specific values to match, and response data.

Therefore, I would generally consider a specific transaction (circled in Red) as an Exact Match and a META transaction as a Signature Match within their respective signature sets (i.e., the first signature which is highlighted in Blue in the top pane).

I typically use the Operation Match to represent a 'catch all' transaction that returns a response when neither the Exact nor Signature match selects a response. I consider an Operation Match as only having a META response. And, I place Exact and Signature matches before Operation matches. The idea here is that the VSI needs to start with a narrow selection and widen to a loose selection. It does not work the other way around. 

Best practice is to set META transaction match style to one level higher than a Specific transaction. For example,

. META=Operation then Specific=Signature or Exact

. META=Signature then Specific=Exact

If META match style is same or lower to what Specific has then META response is not returned at all. For example;

. META=Signature and Specific=Operation then META will not be returned at all as the Specific match will occur first.

. META=Operation and Specific=Operation then META will not be returned at all as the Specific match will occur first.