Forum Discussion

SaraCavelind's avatar
SaraCavelind
Contributor
12 years ago

[Resolved] Namespace and changed endpoint

Hi!
I have a situation where we have a new version of a webservice that I would like to use in all out tests.
I have defined a new endpoint (the new correct), and changes (in a copy) the endpoint to this.
When I try to execute I get the following error:
<faultcode>S:Client</faultcode>
<faultstring>Cannot find dispatch method for {http: ------

I notice that the namespace in my updated tests isn't the same as if I create the request from scratch:
Only updated with new endpoint:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ref="http://tbd.se/y35/refundpayment-ws1"> <soapenv:Header/>
<soapenv:Body>
<ref:withdrawRefund>
<!--Zero or more repetitions:-->
<withdrawRequest>
<!--Optional:-->
<amount>100</amount>
<!--Optional:-->
<customerId>unknown</customerId>
</withdrawRequest>
</ref:withdrawRefund>
</soapenv:Body>
</soapenv:Envelope>

Request created from scrath (Insert Test Step ect)
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ref="http://tbd.se/y35/refundpayment-ws2">
<soapenv:Header/>
<soapenv:Body>
<ref:withdrawRefund><withdrawRequest><amount>100</amount><customerId>unknown</customerId></withdrawRequest></ref:withdrawRefund>
</soapenv:Body>
</soapenv:Envelope>

1. Any idea of the error (my guess is the namespace)
2. Is there some easy way to get the new namespace also?
  • SoapUI Pro 4.5.1

    I've got exactly the same problem - I need to basically clone my workspace and point at a new version of the webservices.
    If I do an update to the definitions, the namespace does not change, either in the PortBindings nor in the test steps and the assertions and property transfers in the test suites. Although the 'Definition Parts' in the port binding overview pane do change correctly.
    The url and the version are defined in project level properties, so for example the service endpoint entry looks like:
    http://${#Project#ServiceEndpoint}/${#Project#IntegrateVersion}/services/CardService

    If I try the refactor definition, I get a dialog saying 'Missing matching binding [{http://blahblahmyUrl/v2_1}CardServicePortBinding] in definition, select new binding to map to and there is a selection box with the {theNewNamespace}CardServicePortBinding

    If I select that, soapUI gives me the hourglass, starts consuming hundreds of megabytes of memory ... I let that run for at least 10 minutes and finally decided to kill it. I don't know whether it would ever succeed, but that is ridiculously slow considering I have 18 services in 7 projects that need to be updated.

    I can't figure out where the namespace is coming from. I can't find it in any wsdl files.
    Obviously it is in the project files I copied, but it seems like there must be someplace where it was originally generated ... be nice to find that point and fix it there.

    I don't really want to edit the project file outside soapUI, but its beginning to look like I'll have to
  • Hmmm ... so I went and tried one more time to use the Refactor Definition, and it ran reasonably quickly.
    No idea what changed.
    Still not useful, though - every test step and assertion and property transfer has the original namespace, so while the port binding information is updateable, every test step has to be modified by hand. That obviously wont work.

    Something else that is interesting - the PortBinding namespace after the Refactor does not show as having been changed unless I close the project and then reload it.

    Memory consumption just keeps climbing still. Started out at 780Mb, now up to 1.8G after refactoring 5 PortBindings, and saving and reloading the project a few times.
    Executing GC in the memory log window has no apparent effect.
  • I will try the WSDL refactor functionality at some time.
    I ended with rewriting the calls manually...
  • SmartBear_Suppo's avatar
    SmartBear_Suppo
    SmartBear Alumni (Retired)
    Ok.

    Are you considering this issue to be closed?

    --
    Regards

    Erik
    SmartBear Sweden