Service Virtualization

  • Private Community

  • 1.  Request Side DataProtocol

    Posted Jan 15, 2018 09:09 AM

    Hi Everyone,

     

    I have a SOAP Request and Response pair with me and i am trying to visualize. When I am giving the the Request Side data protocol as Webservices (SOAP), i am getting the proper response. But when I add two protocols, that is Webservices (SOAP) and XML Data Protocol i am getting a default error response saying - The LISA VSE server could not match request to a recorded request. Consider expanding your service image. 

     

    My question is when I add these 2 protocols why am I getting the error. Even a SOAP message is having XML data right. 
    so what is wrong if I add XML Protocol.

     

    Thanks

    Nikhil



  • 2.  Re: Request Side DataProtocol

    Posted Jan 15, 2018 09:44 AM

    The 'LISA VSE server could not match request to a recorded request' indicates that the VSI did not locate a transaction that matched the incoming request. This may be related to one or more of the following:

    - The operation name does not match (perhaps, the XML DPH overlayed the SOAP DPH's operation name)

    - Maybe the argument list created by the two DPHs does not match the arg list in VSI

    - Or, the transaction match style (Exact, Signature, Operation) is causing a no-match

     

    If you deployed the service to VSE, look in the lisatmp_xx.xx.x (where xx.xx.x is your DevTest version) directory. 

    Locate the file having the name VS_xxxx.log (where 'xxxx' is the name of your virtual service).

    This log contains the inbound request and arguments.

    Open this file and look for the lines that contain something like the following:

    2018-01-12 13:08:02,732Z (07:08)[XXXX [VS_XXXX_Run]/1] INFO - Inbound Request {"id":0,"operation":"GET /some/URI","arguments":{"Arg1":"Arg1Val"}}
    2018-01-12 13:08:02,732Z (07:08)[XXXX [VS_XXXX_Run]/1] INFO - No Session ID No session identified
    2018-01-12 13:08:02,732Z (07:08)[XXXX [VS_XXXX_Run]/1] INFO - No Stateless Match Could not match a stateless transaction
    2018-01-12 13:08:02,732Z (07:08)[XXXXX [VS_XXXXX_Run]/1] WARN -     No Match Request <?xml version="1.0" ?>

    <request operation="GET /some/URI" matchTolerance="EXACT">
      <arguments>
        <parameter name="Arg1">Arg1Val</parameter>
      </arguments>
      <attributes>
        <parameter name="HTTP-Segment-Attr-0">some</parameter>
        <parameter name="HTTP-Segment-Attr-1">URI</parameter>

           :
      </attributes>
      <metaData>
        <parameter name="HTTP-Method">GET</parameter>
        <parameter name="HTTP-URI">/some/URI?Arg1=Arg1Val</parameter>
        :
      </metaData>
    </request>

    Compare the parameter names in the operation, <arguments> list with the argument list(s) in the VSI, and match style to determine the cause of the no-match response. 



  • 3.  Re: Request Side DataProtocol

    Posted Jan 16, 2018 12:38 AM

    Thanks for the reply J_NeSmith. 

    However, when i trigger the request from the application, the incoming request is same as the recorded request. Even then i could see this issue. 

    I have did the virtualization once again and only by adding the request side data protocol as Webservices(SOAP) and i could get the proper response. 

    My doubt is when we are trying to virtualize the SOAP request, can't we add XML Data protocol ? 



  • 4.  Re: Request Side DataProtocol

    Posted Jan 16, 2018 06:18 AM

    PanditiAvinashUlrich_Vogtmonika_mehtaJaved_Ali



  • 5.  Re: Request Side DataProtocol

    Posted Jan 16, 2018 08:53 AM

    If the incoming request is an exact match to the recorded request as expressed by the VSI, then there should not be a mismatch.

    Did you record and create the VSI using both Soap and XML DPHs?

    What do you hope to gain by adding both WS Soap and XML DPHs?  

     

     

    Let's look at an abbreviated sample Soap XML:

    <?xml version="1.0" encoding="UTF-8"?>
    <SOAP-ENV:Envelope xmlns:....>
    <SOAP-ENV:Header xmlns:....></SOAP-ENV:Header>

    <SOAP-ENV:Body>
    <CreateOrUpdateActivity xmlns....>
      <crmactivity>
         <Subject>Quality Assurance</Subject>
         <Owner></Owner>
         <Body>Feature Manager</Body>
        <ActivityType>Quality Assurance</ActivityType>
        :
      </crmactivity>
    </CreateOrUpdateActivity>
    </SOAP-ENV:Body>
    </SOAP-ENV:Envelope>

     

    The VSI generated by the Soap DPH contains the Operation name pulled out of the envelope (CreateOrUpdateActivity). XML Elements also parsed:

     

    Now, take a look at what happens in the VSI when I chain the WS Soap DPH and the XML DPH together on the request side.  Can you spot any differences?

     

    WS Soap DPH ONLY:

    WS Soap DPH chained with XML DPH.

    The XML DPH overlaid the operation name. Additionally, as the XML DPH parsed the incoming request arguments, a duplicate set of arguments having a different set of element names were created.

     

    Both of the above VSIs used identical input requests. The recorded raw request in both VSIs is also identical. The difference is that at runtime the manner in which the input request is parsed altered what the VSI needs to provide a proper matching.

     

    If you will provide an output dump from the log files showing the incoming request and the VSI you are using, we can try to explain why the service treats a request as No Match.