What tools do you use when creating virtual services to confirm it's working properly.
Like for instance I would use SOAP UI to test an actual SOAP Web Service.
Any comments will be of great help!!
The answer depends on the how the virtual service is set up. If you open the service and double click the LISTEN step, the editor opens up the LISTENER properties. In this section is a Base Path: property. This property determines the minimum amount of information the caller must provide for this VSM to accept the request. If the base path = "/myservice", the request must at least contain http://<server>:<port>/myservice".
Here are some valid paths for a LISTEN step base path of "/" -- which will accept ALL HTTP requests on the endpoint: (Assume http:// or https:// are in front of the endpoints listed here)
If the base path were to be coded with "/myservice", only endpoints starting with "/myservice" are acceptable:
If your base path is "/myservice", these paths would NOT be accepted by the LISTEN step:
Lastly, base paths are Case Sensitive. So, if the application sends different endpoints constructs, (i.e., /myservice, /MyService, or /myService), you would need three VSMs where the LISTEN step in each one caters for the case differences.
Hope this helps, Joel
Hi Patricio, the DevTest Recorder is the most efficient way to create a virtual service, but there are other alternatives such as R/R pairs, WSDL, PCAP, etc.
Once the service has been recorded, it boils down to personal preference as to which tools you might use for service testing and validation.
Option 1) Use Soap UI / PostMan / other 3rd Party tools. Since you have Soap UI, you might start your Virtual Service in DevTest Workstation ITR mode, send your request from Soap UI to your service endpoint running on localhost, step through the VSM using the ITR debugger and watch the response go back to Soap UI. ITR provides the added benefits of being able to view various properties that are set during execution as well as to see how the VSM branches to different steps.
Option 2) Use the DevTest Test Automation (i.e., Test Case) suite that is available to you OOTB. Deploy your service to the VSE. Create a Test Case, for example using an Webservice Execution (XML) step, and send different requests from the Webservice Execution step to your virtual service. The response is displayed in the Test Case. I will often add a dataset or some other mechanism for sending a variety of requests to ensure the responses meet the Use Case behaviors.
Option 3) As always, plug in the real system-under-test and send requests from the application to your service.
I typically perform all three options during the creation and validation of a service. My personal preference is to start by testing my service locally using ITR prior to deploying to VSE. This approach is really helpful when your VSM contains custom behavior such as scripting or new steps.
Thanks Joel! I'll try your suggestions.
Does an endpoint of a Virtualized SOAP Webservice look like this: http://<devtestserver>:<portnumber>?
Or do I need to add the Service name too?
You were of great help Joel!
I'm finally moving forward with this
Thank you so much!
Retrieving data ...