Service Virtualization

  • 1.  The response body after creating a VSI is displayed only in black colour and this may be the reason after stubbing , I am not able to hit the service from SOAP UI

    Posted Sep 06, 2017 07:30 AM

    The response body after creating a VSI is displayed only in black colour and this may be the reason after stubbing , I am not able to hit the service from SOAP UI.

     

    My service is SOAP with a wsdl. I used Request data manager to create my vsi. I opened the vsi but the response is displayed like plain text without colours. I thought there is no issue in this and stubbed the response and deployed in dev test portal. but I dont get any response when invoking this stubbed service from SOAP ui. Please help me with this.I created this project in F folder since I dont have access inside CA/Devtest which is in C Drive.

    Attachment(s)

    zip
    mashery_project.zip   754 KB 1 version


  • 2.  Re: The response body after creating a VSI is displayed only in black colour and this may be the reason after stubbing , I am not able to hit the service from SOAP UI

    Broadcom Employee
    Posted Sep 06, 2017 10:59 AM

    Could you please upload your VSM/SI?  We can take a look at it.  



  • 3.  Re: The response body after creating a VSI is displayed only in black colour and this may be the reason after stubbing , I am not able to hit the service from SOAP UI

    Posted Sep 06, 2017 01:02 PM

    In most cases you should only need to use the Web service SOAP request data handler for a SOAP over HTTP. There shouldn't be a need for Request Data Manager.

     

    Other things to look for is to make sure you're using the right base path URL and port number in your soapUI test case.



  • 4.  Re: The response body after creating a VSI is displayed only in black colour and this may be the reason after stubbing , I am not able to hit the service from SOAP UI

    Posted Sep 06, 2017 03:04 PM

    To add to what Will_Truong said.  

    Rather than simply swapping DPHs in your VSM, it is a good idea to rebuild your service using the Soap DPH. The RDM may not have mapped the operation and arguments the same way the Soap DPH does. 

    Also, many of your XML elements are declared optional. After rebuilding, send a transaction and check the Portal -> Monitor -> VSE. Check transaction counts, use Inspection View, and try to decipher what the service did. If the transaction count does not go up, the request never made it to the service so check endpoint, port, and base path. If the count goes up, inspection view will help identify operation and arguments and What Happened so you can debug what the service did. If you can provide a screenshot of this information, we might be able to spot an issue for you.



  • 5.  Re: The response body after creating a VSI is displayed only in black colour and this may be the reason after stubbing , I am not able to hit the service from SOAP UI

    Posted Sep 07, 2017 02:31 AM

    Hi All,

     

    The txn count is displayed as 1 in my Portal. I have uploaded my VSI and VSM here. When I tried the same steps in another one VM from my team, it was working. Does this mean any issue with config or properties file?I even compared my dev test properties with my friends' and found both are same. Is there any other configuration that needs to done?And I need Request data manager so that I can alter some of the request values.



  • 6.  Re: The response body after creating a VSI is displayed only in black colour and this may be the reason after stubbing , I am not able to hit the service from SOAP UI

    Posted Sep 07, 2017 10:26 AM
      |   view attached

    The Responder step is churning away but never sends a response before an HTTP Timeout occurs.  

    The logic that is killing your performance is located in the VSI response.  

     

    Here's a trick to help you see what is occurring:

    1.  Stop Workstation
    2.  Access your c:\users\<yourId>\lisatmp_10.1.0 directory
    3.  Delete workstation.log then start your Workstation
    4.  Start your VSM in ITR Mode (Single Step Mode) on your Workstation
    5.  Send your request from SoapUI to your Workstation
    6.  Allow Listen & VSI Selection Steps to fire (2 CLICKs) 
    7.  Access LISA_HOME\logging.properties and set the logger to DEBUG mode
    8.  Go back to Workstation and CLICK next to cause Responder Step to execute

     

    The Responder Step should start clocking.  Let this step run for a couple of minutes and return to LH\logging.properties and set the logger back to INFO mode -- this will stop spewing out detailed log entries into Workstation.log.

     

    You will notice that each of the elements in the response has displays in the log.  DevTest does not start magic string {{ }} logic until data is about to 'go on the wire'.

     

    The log displays will look something like this (abbreviated here for clarity):

    2017-09-07 13:55:53,020Z (08:55) [thread] DEBUG com.itko.lisa.history.NodeExecHistory - notifyPropUsed: lisa.scripting.default.language value null
    2017-09-07 13:55:53,026Z (08:55) [thread] DEBUG com.ca.sv.devtest.util.GenerateString - forRegex: regex=[A-Za-z0-9]{5,15} --generated random string=i7652VC

     

    The generated string for the first element in my response started at:

    2017-09-07 13:46:42,156Z (08:46)

    I waited for a while and the response on the wire occurred at:

    2017-09-07 13:56:58,507Z (08:56)

     

    This tells me the beanshell logic and the forRegex method took approximately 10+ minutes to complete.

     

    Looking back at the VSI, you will see that each of the elements contains beanshell with a call to GenerateString forRegex. Each of these {{ }} fragments is compiled and processed one at a time.

    {{=%beanshell% com.ca.sv.devtest.util.GenerateString.forRegex("[A-Za-z {{=request_updateBillingAccountConfigurationInput_Payload_Customer_CustomerDetails_Party_Individual_IndividualIdentification_BirthCertificateIdentification_PartyIdentification_issuer_isLegalEntity;/*0*/}}-9]{5,{{=request_updateBillingAccountConfigurationInput_Payload_Customer_customerRank;/*1*/}}5}");}}

     

    Was this code generated by DevTest when the service was created from WSDL?

    Does the random data have to be based off a different field in the XML? 

     

    EDIT:

    Normally, the regex that is generated for WSDL (using the vinlink-decoder.wsdl in the 10_1 examples folder, generates a regex that looks like this:

    {{=%beanshell% com.ca.sv.devtest.util.GenerateString.forRegex("[A-Za-z0-9]{5,15}");}}

    What had me concerned is the injection of the {{=request_<inputArgVal>}} into the regex which seems to be a double whammy.

     

    EDIT, EDIT:  (sorry, still looking at the response XML)

    I see this sort of stuff in the response XML and it does not make sense to me. Assuming DevTest did a substitution, it appears that an invalid XML would be generated.

    <ValidFor>
    {{=request_updateBillingAccountConfigurationInput_Payload_CustomerAccountPartyRole_Party_Individual_IndividualIdentification_PartyIdentification_issuer_OrganizationIdentification;/*
    */}}<!--startDate is nillable and optional-->
    {{=request_updateBillingAccountConfigurationInput_Payload_CustomerAccountPartyRole_Party_Individual_IndividualIdentification_PartyIdentification_issuer_OrganizationIdentification;/*
    */}}<startDate>{{=[:startDate:2000-01-01T00\:00\:00]}}</startDate>
    {{=request_updateBillingAccountConfigurationInput_Payload_CustomerAccountPartyRole_Party_Individual_IndividualIdentification_PartyIdentification_issuer_OrganizationIdentification;/*
    */}}<!--endDate is nillable and optional-->
    {{=request_updateBillingAccountConfigurationInput_Payload_CustomerAccountPartyRole_Party_Individual_IndividualIdentification_PartyIdentification_issuer_OrganizationIdentification;/*
    */}}<endDate>{{=[:endDate:2000-01-01T00\:00\:00]}}</endDate>
    </ValidFor>

    If we substitute a pretend value of "ABCD", the resulting XML would look like this:

      <ValidFor>ABCD

       <!--startDate is nillable and optional-->
       ABCD

       <startDate>{{=[:startDate:2000-01-01T00\:00\:00]}}</startDate>
       ABCD

       <!--endDate is nillable and optional-->
       ABCD

       <endDate>{{=[:endDate:2000-01-01T00\:00\:00]}}</endDate>
    </ValidFor>
     Perhaps the incoming request arg value is <blanks> which would not negate XML, but it is still very strange.

    I removed all of the extraneous substitution and the response took about 14+ seconds to complete.

    Attached is the VSI I used after replacing some of the magic string logic -- which may foul up the XML as I was going for a response not valid XML.

    Attachment(s)

    zip
    UBAC.vsi.zip   366 KB 1 version


  • 7.  Re: The response body after creating a VSI is displayed only in black colour and this may be the reason after stubbing , I am not able to hit the service from SOAP UI

    Posted Sep 13, 2017 08:12 AM

    Hi Joel,

     

    Yes, the attached vsi is the correct one which all of my team mates getting. I dont know how these extraneous substitution are added.Do you know how these extraneous substitution are added and how to erradicate while creating a vsi?Is is any issue in my configuration. Is it anything regarding that I dont have access to {{LISA HOME}} directory but they have? (My project is in someother drive other than LISA HOME). Does this need to do anything with this issue? 



  • 8.  Re: The response body after creating a VSI is displayed only in black colour and this may be the reason after stubbing , I am not able to hit the service from SOAP UI
    Best Answer

    Posted Sep 13, 2017 08:35 AM

    If the substitutions were added when the service was created, please open a ticket so CA Support can review this with you. It is possible that you have uncovered a never-before-seen problem or there is an issue with your DevTest setup.

     

    Perhaps, the magic string processor saw <blanks> between element tag names and located a matching input element containing the same number of blanks so it created a magic string substitution. I have never seen this happen, but it is the only explanation I have at this time.



  • 9.  Re: The response body after creating a VSI is displayed only in black colour and this may be the reason after stubbing , I am not able to hit the service from SOAP UI

    Posted Sep 13, 2017 10:03 AM

    Hi,

     

    Thanks,

     

    I dont know what was the actual issue. But now I got access to {{LISA HOME}} in C folder and the project I created now is working. Now the response of the vsi doesn't come with any extraneous substitution. The issue which I guessed is correct but dont know the exact issue.