Service Virtualization

Expand all | Collapse all

Namespace issue in .vsi request

  • 1.  Namespace issue in .vsi request

    Posted 08-02-2018 07:14 PM

    Hi,

     

    I’m developing virtual services using request & response pairs. Here marked namespaces are changing when I integrate virtual service in my API. (API internally talks with virtual service and request sent to virtual service. Mainly namespaces are changed here).  So my API is receiving default META response from virtual service.

     

    Is there a way to avoid/omit namespaces in .vsi request? I’ve chosen Match style as “Exact” because response will vary from id. Please provide your suggestions here?

    Request used for implementing virtual service :
    <soap:Envelope
    xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Header>
    <ns2:WFContext
    xmlns:ns6="http://xxxx/address/2003/"
    xmlns:ns5="http://xxxx/communication/email/2003/"
    xmlns:ns4="http://xxxx/communication/2003/"
    xmlns:ns3="http://xxxx/communication/phone/2003/"
    xmlns:ns2="http://***/entity/message/2003/">
    <ns2:messageId>xxxx</ns2:messageId>
    <ns2:sessionId>***</ns2:sessionId>
    <ns2:creationTimestamp>xxxx</ns2:creationTimestamp>
    </ns2:WFContext>
    <ns3:hulaContext
    xmlns:ns3="http://***/provider/HCFG/entity/envelope/2004/"
    xmlns:ns2="http://***/entity/message/2003/">
    <ns2:version>0</ns2:version>
    </ns3:hulaContext>
    </soap:Header>
    <soap:Body>
    <ns8:process
    xmlns:ns2="http://***/entity/message/2003/"
    xmlns:ns3="http://***/HCFG/entity/envelope/2004/"
    xmlns:ns4="http://xxxx/communication/phone/2003/"
    xmlns:ns5="http://xxxx/communication/2003/"
    xmlns:ns6="http://xxxx/communication/email/2003/"
    xmlns:ns7="http://***/communication/address/2003/"
    xmlns:ns8="http://xxxdata/***/2016/" contentType="application/json" encoding="charset=utf-8">&lt;![CDATA[{"request":{"id":"1000"}}]]&gt;
    </ns8:process>
    </soap:Body>
    </soap:Envelope>


    Request from API to virtual service:
    <soap:Envelope
    xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Header>
    <ns2:WFContext
    xmlns:ns6="http://***/communication/address/2003/"
    xmlns:ns5="http://***/communication/email/2003/"
    xmlns:ns4="http://***/communication/2003/"
    xmlns:ns3="http://***/communication/phone/2003/"
    xmlns:ns2="http://***/message/2003/">
    <ns2:type>***</ns2:type>
    </ns2:WFContext>
    <ns3:hulaContext
    xmlns:ns3="http://***/provider/HCFG/entity/envelope/2004/"
    xmlns:ns2="http://***/entity/message/2003/">
    <ns2:version>0</ns2:version>
    </ns3:hulaContext>
    </soap:Header>
    <soap:Body>
    <ns8:process
    xmlns:ns2="http://***/message/2003/"
    xmlns:ns3="http://***/communication/phone/2003/"
    xmlns:ns4="http://***/communication/2003/"
    xmlns:ns5="http://***/communication/email/2003/"
    xmlns:ns6="http://***/communication/address/2003/"
    xmlns:ns7="http://***/provider/x/entity/envelope/2004/"
    xmlns:ns8="http://***/provider/x/data/***/2016/" contentType="application/json" encoding="charset=utf-8">&lt;![CDATA[{"request":{"id":"1000"}}]]&gt;
    </ns8:process>
    </soap:Body>
    </soap:Envelope>

     



  • 2.  Re: Namespace issue in .vsi request

    Posted 08-03-2018 03:01 AM

    Hi,

     

    Is it possible to attach your VSM/VSI files which generated from request/response pair in this question?
    If yes, could you please attach your VSM/VSI files in this question?
    If no because of a security reason, then it is better to create a support case for your issue.
    Please refer to Tech Tips: Opening a DevTest Support Case to open a case.

     

    Thank you,



  • 3.  Re: Namespace issue in .vsi request

    Posted 08-03-2018 12:38 PM

    Hi,

     

    Here I’m providing my VSM/VSI files. Please check it and let me know your update soon.

     

    I was trying to attach VSM/VSI files in community forum but looks like we can attach image & video files?

     

    Thanks

    Swathi.

    Attachment(s)

    zip
    TestService.vsi.zip   2K 1 version
    zip
    TestService.vsm.zip   1K 1 version


  • 4.  Re: Namespace issue in .vsi request

    Posted 08-03-2018 12:44 PM

    I was not sure how to attach my VSM/VSI files here. Responded to email please check



  • 5.  Re: Namespace issue in .vsi request

    Posted 08-06-2018 05:07 PM

    I do not believe we have all of the requirements to understand exactly what the response is supposed to be.

     

    - There may be an issue with the VSI having a different number of XML arguments than the request sent by the application.  For example, the post above has two different XMLs each containing a different number of XML elements.  For example, Header_WFContext_messageId, Header_hulaContextType. And the VSI expects a different set of XML elements in the signature.

     

    - The VSM also contains a SOAP and XML DPH. You can probably get away with using only the XML DPH as these two DPHs provide similar, yet different results (Soap only processes the Soap Body).

     

    - The VSI's specific transaction only selects the specific response if all elements exactly match the value column (presumably what the service was built from).

     

    If it is possible for the application to optionally send XML header and/or body elements, the VSI signatures or match styles must reflect these variations. The RDM DPH could potentially help weed out arguments the VSI does not need. 

     

     



  • 6.  Re: Namespace issue in .vsi request

    Posted 08-08-2018 02:09 AM

    I've removed some attributes in my XML's. Since i'm not considering the value of that arguments. 

     

    In the above request, I've to consider &lt;![CDATA[{"request":{"id":"1000"}}]]&gt; only from soap:Body remaining xml schema not required to validate.

    To extract id value from CDATA, I used SOAP -> XML -> RDM -> Scriptable -> JSON data protocols. Here I moved soap:Body process tag 

    to requestBody and deleted namespaces too. Still issue is persisting. 

    I'm looking for a way to see only id:1000 in vsi requestData? So that my issue would be resolved.



  • 7.  Re: Namespace issue in .vsi request

    Posted 08-08-2018 12:40 PM

    Let's take a look at what each of the DPHs is doing.  Without any modifications, let's send the first request (Request used for implementing the virtual service).

    After the SOAP DPH executes, the incoming request looks like this:

    Operation = "process"    - taken from the Soap Body

    Arguments = ""  - the Soap DPH does not parse the header and there are not body elements except for the [CDATA] to the argument list is empty

    Conversely, if you were to use the SOAP Headers DPH, the headers would be extracted and you could skip the XML DPH moving straight to the Scriptable which sets up for the JSON parsing.

    After the XML DPH executes, the incoming request looks like this:

    Operation = "Envelope" - XML takes the root element and makes it the operation

    Arguments =

    Header_WFContext_messageId=XXXX

    Header_WFContext_sessionId=***

    Header_WFContext_creationTimestamp=xxxx

    Header_hulaContext_version=0

    Body_process=<![CDATA[{"request":{"id":"1000"}}]]>

    After the RDM DPH executes, the incoming request looks like this:

    Operation = null  - because Header_hulaContext_action is not included in the XML sample

    Arguments = 

    Header_WFContext_messageId=xxxx
    Header_WFContext_sessionId=***
    Header_WFContext_creationTimestamp=xxxx
    Header_hulaContext_version=0

    There is no Body_process=...[CDATA] because the RDM "moved" this argument to the request body.

    After the Scriptable DPH executes there is no net change in the argument list or in the Operation name.  The Scriptable is setting up the Body for the JSON DPH.

    After the JSON DPH executes, the incoming request looks like this:

    Operation = null

    Arguments =

    Header_WFContext_messageId=xxxx
    Header_WFContext_sessionId=***
    Header_WFContext_creationTimestamp=xxxx
    Header_hulaContext_version=0
    request_id=1000

    Therefore, the VSI needs to contain an Operation of NULL and the above argument list in order to complete the exact matching logic.

     

    Now, let's repeat the same steps and look at the XML sent during the API call from the consumer.

     

    Soap DPH results:

    Operation = process

    Arguments = ""

    XML DPH results:

    Operation = "Envelope" - XML takes the root element and makes it the operation

    Arguments =

    Header_WFContext_type=***

    Header_hulaContext_version=0

    Body_process=<![CDATA[{"request":{"id":"1000"}}]]>

    RDM DPH results:

    Operation = "null"

    Arguments =

    Header_WFContext_type=***

    Header_hulaContext_version=0

    Scriptable causes no change, just set up for JSON

    JSON DPH executes:

    Operation = "null" 

    Arguments =

    Header_WFContext_type=***

    Header_hulaContext_version=0

    request_id = 1000

     

    Let's compare the argument list in the VSI to the two incoming requests. 

    The sample VSI is performing Signature matching, therefore, the signature of the incoming request must match the VSI.

    Given the operation is null, the VSI should be throwing the Service Image Not Found Response - but let's assume the sample XML is missing some XML elements.

     

    Request 1 Arg ListRequest 2 Arg ListVSI Expected Signature (i.e., Arguments)

    Operation = null

    Args:

    Header_WFContext_messageId=xxxx
    Header_WFContext_sessionId=***
    Header_WFContext_creationTimestamp=xxxx

     

     

     

     

     

     

     

     

     

     

     

     

     


    Header_hulaContext_version=0
    request_id=1000

    Operation = null 

    Args:

     

     

     

     

     

     

     

     

     

     

     

    Header_WFContext_type=***

     

     

     

     

     

    Header_hulaContext_version=0

    request_id = 1000

    Operation = customerRequest

    Args:

    Header_WFContext_messageId

    Header_WFContext_sessionId

    Header_WFContext_creationTimestamp

    Header_WFContext_activitySourceId

    Header_WFContext_hostName

    Header_WFContext_originatorId

    Header_WFContext_originatorIdType

    Header_WFContext_initiatorId

    Header_WFContext_initiatorIdType

    Header_WFContext_service

    Header_WFContext_processingMode

    Header_WFContext_contextType

    Header_hulaContext_service

    Header_hulaContext_password

    Header_hulaContext_keyword

    Header_hulaContext_behaviorVersion

    customerRequest_id



  • 8.  Re: Namespace issue in .vsi request

    Posted 08-08-2018 01:20 PM

    Hi Joel, Thank you for your response.

     

    Could you please share VSI & VSM files?



  • 9.  Re: Namespace issue in .vsi request

    Posted 08-08-2018 02:08 PM
      |   view attached

    The example I used was based on the TestService.VSM and VSI that you uploaded in the earlier post.

    I created the information by adding a DPH to dump the lisa_vse_request after each DPH fires. The attached log is edited and some formatting done on the lines so you can see the content of the Arguments and Operation after each DPH executes.

    Attachment(s)



  • 10.  Re: Namespace issue in .vsi request

    Posted 08-06-2018 05:52 PM

    If you want to return a specific response (an exact match), and not the META response, then you need to ensure the values in the request match what you have in the VSI. A potential problem that I see with providing a specific response is that you're trying to match on fields that appear to be dynamic and unique in nature. For example, you have the following fields on exact match:

    Header_WFContext_messageId

    Header_WFContext_sessionId

    Header_WFContext_creationTimeStamp

     

    The above fields look like they would be unique each time your API consumes the virtual service, so you will never get an exact match. So if your API is sending dynamic and unique values then you may want to change the Comparison Operator from "=" to "Anything" so that the virtual service ignores those particular fields as they will never match what you have in the VSI.



  • 11.  Re: Namespace issue in .vsi request

    Posted 08-08-2018 02:10 AM

    Yes correct. I'm making all my request arguements to anything except id value. id would be request to virtual service.