Submit and vote on feature ideas.

Welcome to the new Parasoft forums! We hope you will enjoy the site and try out some of the new features, like sharing an idea you may have for one of our products or following a category.

Traffic Viewer does not show the SOAP Response

After successful execution, I see the SOAP Request in the Traffic Viewer but I don't see the corresponding SOAP Response. (SOAtest 9.9 version). For the same SOAP Request, I get the SOAP Response in SOAPSonar tool (We are trying to migrate from SOAPSonar to Parasoft). Can you help me figure out why I don’t see the SOAP Response in Parasoft SOAtest?

Comments

  • [Deleted User]
    [Deleted User] Posts: 0 admin
    edited December 2016

    Hi Sunkarabhanu,

    That behavior is unfortunate. I am wondering ifyou can try something for me. In your SOAP Client, can you Right Click > add Output > Traffic Stream > WriteFile

    Configure the Write File to write to the Workspace in append mode

    Append allows you to see the entire stream. It is possible that there are multiple steps to the response message and the final response is not something that could be shown in the editor

    Let me know what you find.

    Also, Is it possible for you to let me know what Sonar is showing for the response? Is it XML? anything funny about it

  • Hi Chris Colosimo

    First of all - Thank you for your quick response.

    I followed your steps about the FILE OUTPUT. The file is created – however it is an empty file.

    I also want to bring this to your attention, just in case they are related:
    Within the test, Transport tab - when I attempt to give Transport: “HTTP 1.1”, the test fails.
    The test passes only when Transport: “None”.
    (under Parasoft > Preferences > SOAP - the Default transport: “HTTP 1.1”)

    In SOAP SONAR tool response looks like this.
    <?xml version="1.0" encoding="utf-8"?>




    .........



  • [Deleted User]
    [Deleted User] Posts: 0 admin

    It looks like Sonars Response is empty (Just a prolog, which I think is there by default and might not be coming back from the target API). Are there any response Headers?

    Setting the transport to NONE means you are not actually sending a request.

    When setting the SOAtest transport to HTTP 1.1 or 1.0, you indicated that the test fails is there any information? Can you please let me know what it displays in quality tasks

  • When I change SOAtest transport to HTTP 1.1 or 1.0, in Quality tasks I get this error message:
    Connection refused: connect
    Additional Details:
    A connection error has been detected. This may occur if a test has timed out while the client was still attempting to send or receive data.

    In SOAP SONAR, I do get the full response. I intentionally removed the content since it is my work place sensitive information.

  • OmarR
    OmarR Posts: 233 admin

    Hi Sunkarabhanu!!!

    Did you create your SOAP client from a WSDL?
    If so, could you try disabling the option below and running your test? Is there any change in behavior after doing this?

    Also, aside from the Quality Tasks view, a Screenshot of the Console would be very helpful :smiley:

  • Hi OmarR,
    I have created the SOAP client from a WSDL.
    I tried disabling the ‘Constrain request to WSDL’ option but still see the same behavior.
    I have attached screen shots of the below 2 issues (Not sure if they are related)
    Issue 1) When I set the TRANSPORT = “None” – the test passes however I see no response
    Issue 2) When I set the TRANSPORT = “HTTP 1.1” – the test fails

  • OmarR
    OmarR Posts: 233 admin

    Thank you for the screenshots!

    As @Chris Colosimo had said in his earlier post, when a user selects Transport=NONE and runs their test, any tools (Databank, Assertor, Transformer, etc) associated with the test will execute, but your request will NOT be sent anywhere. By selecting NONE for your transport, you are essentially saying "Do-not-send-to-an-Endpoint". Therefore, it is no surprise that you do not receive a response back. This is expected behavior; The behavior you are seeing is not an issue.

    On-to-the-real-issue!
    We may need some more details on why this error is happening. Would you kindly generate a Technical Support Archive (TSA) and send it our way? Please follow the steps on how to generate a TSA in the link below!

    http://forums.parasoft.com/discussion/2748/generating-a-log-technical-support-archive-to-troubleshoot-errors-failures/p1?new=1

  • sunkarabhanu
    sunkarabhanu Posts: 8

    Hi OmarR,

    Please find the attached Technical Support Archive (TSA) log that you requested.

  • OmarR
    OmarR Posts: 233 admin

    Heyhey Sunkarabhanu,

    The logs show the following:
    [WARN ] [13:00:57,543] Thread-101 com.parasoft.webtool.messaging.Logger: Connection refused: connect java.net.ConnectException: Connection refused: connect at java.net.DualStackPlainSocketImpl.connect0(Native Method) at java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:79) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at java.net.Socket.connect(Socket.java:579) at java.net.Socket.connect(Socket.java:528) at java.net.Socket.<init>(Socket.java:425) at java.net.Socket.<init>(Socket.java:208) at webtool.net.LoggingSocket.<init>(LoggingSocket.java:38) at webtool.net.LoggingSocket.createLoggingSocket(LoggingSocket.java:91) at webtool.messaging.SoapLogConfiguration.addLogs(SoapLogConfiguration.java:90) at webtool.messaging.HTTPTransportSocketUtil.getHTTPSocket(HTTPTransportSocketUtil.java:185) at webtool.messaging.HTTPTransport.sendRequest(HTTPTransport.java:409) at webtool.messaging.HTTPTransport.invokeInternal(HTTPTransport.java:266) at webtool.messaging.HTTPTransport.invokeInternal(HTTPTransport.java:249) at webtool.messaging.HTTPTransport.invoke(HTTPTransport.java:286) at webtool.messaging.MessagingClientConfig.invokeOverHTTP(MessagingClientConfig.java:144) at webtool.messaging.MessagingClientConfig.invoke(MessagingClientConfig.java:100) at webtool.messaging.MessageRunner.run(MessageRunner.java:49) at com.parasoft.util.thread.timeout.TimeoutThread.run(TimeoutThread.java:101)

    The exception above can be due to any of the following:

    1) Server is not running

    2) The server is running, but You are trying to connect to the wrong port number.

    3) Host-Port combination is incorrect

    4) Incorrect protocol in Connection String

    5) A Firewall is blocking the connection

    Please verify your test configurations and ensure that your environment is properly set up to communicate with your server. It may also help to compare the Request headers between SoapSonar and SOAtest to see what the differences are!

  • sunkarabhanu
    sunkarabhanu Posts: 8

    SOAP Client > HTTP Transport > ENDPOINT.
    SOAtest is not accepting the actual ENDPOINT.
    Workaround: Use the HIGH level WSDL in the ENDPOINT field as well.

  • sunkarabhanu
    sunkarabhanu Posts: 8

    ENDPOINT mentioned above is broken, hence this confusion.
    Works fine with just the HIGH level WSDL

  • OmarR
    OmarR Posts: 233 admin

    To clarify, the unexpected behavior was due to the customer's WSDL containing an invalid Endpoint location. The customer should consult with his developers to update the ENDPOINT location in the WSDL. SoapSonar failed to detect the invalid endpoint and simply used the "..?wsdl" endpoint.