Forum Discussion

roberticogonzal's avatar
roberticogonzal
Occasional Contributor
14 years ago

Asynchronouns web service testing with soapUI

Hi,

I am currently evaluating soapUI (http:/www.soapui.org). I was wondering if someone can provide some guidance since I don’t know how to proceed with this issue.

I would like to test an asynchronous web service using soapUI. I couldn’t find documentation on how to do this in soapUI.org.

The WSDL is defined in a URL. I have also attached the contents of the WSDL:
https://soap-100:8443/platform-services ... rvice?wsdl


The steps are (see PowerPoint presentation attached):

1. The client (soapUI sends a request which is a SOAP Service message such as “APIVersionService” and in particular it invokes the method “getAPIVersion” to the server (Cisco Unified Communications Manager). This request includes the WS-Addressing parameters, which include the ‘ReplyTo” URL and the “MessageID”. The client is running on “bldr-vcm184.cisco.com” and the server is running on “soap-100.cisco.com”.
2. The service responds immediately with a 202 Accepted. This part appears to be working as expected.
3. Then, after some time, which may be up to 3 hours or so, the service running on the server creates a new request and it sends to the call back URL sent in the initial request in the ReplyTo header.
4. Finally, soapUI should reply with a 202 Accepted when it gets the response in the MockService.

I have been trying to set up a Mockup service that would be running on port 8088 to capture the asynchronous response sent on step 3 above. But so far, I have been unable to do this.

Here are the steps I followed to try to capture the async request coming from the server.

1. First, right click on the “SecondTrialMock” project and then select “Add WSDL”
2. In the Add WSDL screen, enter the WSDL URL: https://soap-100:8443/platform-services ... rvice?wsdl
3. Check the 3 boxes in this screen: a) Create sample requests for all operations; b) Creates a TestSuite for the imported WSDL and c) Creates a Web Service Simulation of the imported WSDL
4. Next, in the Generate MockService screen, make the path "/", use the 8088 port (you can use another port if desired) and check the boxes: a) Adds the MockServices endpoint to the mocked Interface and b) Starts the MockService immediately.
5. In the next screen, use the default name for the mock service or change to a desired name
6. After this step, you should see a newly added mock service
7. Double click on the mock service if it is not already in the right side window
8. Then, stop the mock service if it is running.
9. Click on the property icon for the mock service
10. In the MockService options window, check the "only binds to specified host"
11. You can use hostname or you can put in the ip address in the "Host" section
12. Finally, click "Browse" and select a doc root. This can be any directory, it does not matter.
13. Now, start the mock service and you should see a "running on port 8088" in the top right corner

Entering Service Endpoint URL

1. Right Mouse Click on the Interface (APIVersionServiceSoap11Binding) and select "Show Interface Viewer".
2. Click on the "Service Endpoint" tab.
3. In the "Endpoint" field, enter the URL for the service. Use the "F2" key to edit the field and the arrow keys to move across the field contents.

https://soap-100.cisco.com:8443/platfor ... ionService

SOAP Authentication
If you know that many SOAP test requests will need to share the same HTTP Basic Authentication credentials, you'll want to just set them one time. You can do this through a soapUI tool called the Interface Viewer. To open the Interface Viewer, right-click on a WSDL operation in the project explorer tree on the left-hand side of the soapUI interface and choose "Show Interface Viewer". This will open a screen with four tabs: Overview, Service Endpoints, WSDL Content, and WS-I Compliance. The HTTP Basic Authentication credentials are set through the "Service Endpoints" tab. For each endpoint in the list you can specify what username and password to use. Once specified, all of the test requests on the WSDL operation (the one you selected to open the Interface Viewer) using the specific endpoint will automatically use the username and password you entered.

WS-A Addressing

1. Define the "WS-A version" as "NONE" and "WS-A anonymous" as "optional" parameters at the interface level.
2. Select a request and right mouse click and select "Show Request Editor". In the XML tab, select the WS-Addressing element at the bottom of the page. Enable WS-A addressing by clicking on the checkbox at the top of the form. After doing this, the "WS-Addressing" property on the left panel changes its value to "True". Our SOAP services require the ReplyTo and MessageID headers to be populated. For the ReplyTo parameter use the following URL:

http://bldr-vcm184.cisco.com:8088

This is the MockService running that should capture the async message.

For the MessageID, check the checkbox to generate a random string.

Note: the Action parameter is filled with a specific urn such as: "urn:getAPIVersion"

Then, we are ready to run our test. Right mouse click on the “Request 1” under the Interface folder (APIVersionServiceSoap11Binding > GetAPIVersion > Request 1) and click on the green arrow. After doing this, I get the following error message in the Error Log:

Thu Sep 01 15:02:51 MDT 2011:ERROR:com.eviware.soapui.impl.wsdl.mock.DispatchException: Missing operation for soapAction [urn:getAPIVersionResponse] and body element [{http://services.api.platform.vos.cisco.com}getAPIVersionResponse] with SOAP Version [SOAP 1.1]
com.eviware.soapui.impl.wsdl.mock.DispatchException: Missing operation for soapAction [urn:getAPIVersionResponse] and body element [{http://services.api.platform.vos.cisco.com}getAPIVersionResponse] with SOAP Version [SOAP 1.1]
at com.eviware.soapui.impl.wsdl.support.soap.SoapUtils.findOperationForRequest(SoapUtils.java:359)
at com.eviware.soapui.impl.wsdl.mock.WsdlMockRunner.dispatchPostRequest(WsdlMockRunner.java:250)
at com.eviware.soapui.impl.wsdl.mock.WsdlMockRunner.dispatchRequest(WsdlMockRunner.java:375)
at com.eviware.soapui.monitor.JettyMockEngine$ServerHandler.handle(JettyMockEngine.java:714)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:945)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:843)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)


I don’t know where is it getting the following string “urn:getAPIVersionResponse”. The Response part is not defined anywhere as far as I can tell.

Here is a sample request from the API documentation. It is similar to what soapUI is sending but there are some differences.

APIVersionService Request
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SOAP-ENV:Header>
<wsa:Action
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">urn:getAPIVersion</wsa:Action>
<wsa:MessageID
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">uuid:63e5d8ca-dcac-40af-916b-d32ec3382d0f</wsa:MessageID>
<wsa:ReplyTo
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
<wsa:Address>http://se032c-94-154.cisco.com:9080/servlet/WSACallBackHandler</wsa:Address>
<wsa:PortType
xmlns:ns1="http://example.org">ns1:LocalPart</wsa:PortType>
</wsa:ReplyTo>
<wsa:To xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">https://10.94.171.238/platform-services/services/APIVersionService.APIVersionServiceHttpSoap11Endpoint</wsa:To>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<getAPIVersion xmlns="http://services.api.platform.vos.cisco.com"/>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

---------------

I have tried to run my scenario with my PC with Cisco Security Agent disabled and I still have the same problem.

I also tried with a machine in the virtual lab and had the same problem.

I actually was able to capture the async response using Wireshark. However, I don’t think soapUI realizes that it received an async response

If I add this to the path of the Mock response
/getAPIVersionResponse

I get a 200 OK for the async response (see attachment).

If the path is / I get a 500 Internal Server Error with the following message:

<faultstring>Missing operation for soapAction [urn:getAPIVersionResponse] and body element [{http://services.api.platform.vos.cisco.com}getAPIVersionResponse] with SOAP Version [SOAP 1.1]</faultstring>\n

I am attaching a screen capture of my screen.

Regards,
RG
  • roberticogonzal's avatar
    roberticogonzal
    Occasional Contributor
    Testing Asynchronous web services with soapUI

    In an asynchronous web service the client sends a request to the server on an initial connection and the server replies with 202 Accepted. Then, after some point later in time (could be several hours), the server initiates a request on a new connection and the client replies with a 200 Ok.

    0. Follow the steps to test a synchronous web service.

    1. Define the "WS-A version" as "NONE" and "WS-A anomymous" as "optional" parameters at the interface level.

    2. In order to capture the async message in soapUI, you need to use MockResponse TestStep . You can add it from the list of TestSteps available on a TestCase (right click on the TestCase/Add TestStep/MockResponse).

    3. Be sure to set "Start Step" for it , under TestProperties in the lower left part of soapUI when MockResponse selected, so it knows when to start listening.

    4. Check other TestProperties like port, path and timeout. The port must be unique and the path should match the operation response defined in the WSDL. The timeout could be set toi 30,000 ms

    5. Set "Handle Response" to true.

    6. The host should be set to the global variable containing the host name for the test server.