Sonic Connect Web Service Endpoint bound to localhost - Forum - Technology Partner - Progress Community

Sonic Connect Web Service Endpoint bound to localhost


Sonic Connect Web Service Endpoint bound to localhost

  • When Sonic Connect publishes a Web Service the endpoint defaults to: http://localhost:2580/process/<ESB_Process_Name>

    This is stored in the <project>.properties file in the "lib" folder and published in the spring.xml file (config folder) by the cxfEndpoint address property referring to the properties file.

    Example: <cxf:cxfEndpoint id="rMessagePortEndpoint" address="${rMessageV4rDMSService.rMessagePort.address}" ...

    The problem is that this binds the endpoint to localhost. If I try to deliver a message to http://<ip_address>:2580/process/<ESB_Process_Name> I get the error:

    <soapenv:Envelope xmlns:soapenv="" xmlns:xsd="" xmlns:xsi="">
                    <faultstring>Failed to locate WSDL for Sonic service or process: rm4ReceiveWebService</faultstring>

    This can be fixed by changing the project prooperties file to bind to the IP address or by overriding the value in the Export and Deploy process but:

    - We have to deploy this application to a many servers. Does that mean we have to create a specific deployment for each server?

    - This would be really hard to diagnose and we'd have to create a new deployment if a customer changes the server IP address (as happens occasionally)

    - What if the server has multiple IP interfaces.

    Is there any way to set this configuration to bind to all IP interfaces by default?



  • Hello Stephen,

    I have tried it using intsead of localhost and it seems to work!

    I don't know if you are using sdm but you can manage different IP adress for deployement with it.


    Chan Jeremy

  • By setting the host address, it will bind to all IP address.  The WorkBench wizard in 8.5 has been updated to set default as instead of localhost.


  • Thanks William

    That solution works well.

    We're just in the process of upgrading our development environment to 8.5 and it will be good to see the little annoyances that have been addressed :-)

    We figured out how to use HTTPS and SSL Certificates. The documentation wasn't easy

    A follow on question ... for bonus points ....

    Is it possible to bind both HTTP and HTTPS to the same Sonic Connect (CXF) endpoint?



  • Hi Steve,

    It is not possible to bind both HTTP and HTTPS to the same Sonic Connect/CXF endpoint.



  • Hi William

    Binding the address works as you described for Sonic Connect projects. We have been able to connect from several clients.

    However, when the Client is an OpenEdge program we are unable to connect to the web service. If we change the IP address in the Sonic Connect configuration from to the IP of the host then OpenEdge is then able to connect.

    The OpenEdge program we are using is attached (I am not an OpenEdge programmer).



  • That is strange.   Do you see any error messages in the logs on both (Sonic and OpenEdge) sides?
  • Hi William

    I figured out what causes this.

    The OpenEdge web service client does a WSDL request to open the session: http://TheHost/TheEndpoint?WSDL

    When we do this on our .NET/IIS Web service the enquiry puts the URL we sent into the Service address:

    <soap12:address location=http://TheHost/TheEndpoint />

    When we do this against the Sonic Server it sends back whatever in the the WSDL

    <soap12:address location= />

    And OpenEdge spits it's dummy because the IP address is invalid.

    1) Is this a bug in Sonic?

    2) Is there a way to use the OpenEdge Web Service client so that it does not to a WSDL enquiry first?



  • Thanks Steve. I logged a defect in Sonic (SNC00082827 "?wsdl can return as web service address"). I defer the second question to OpenEdge experts.

  • Can you get a local copy of the WSDL?

    OpenEdge can support using a local copy of the WSDL in the first instance, then making the call to the operation on the host. Any credentials for accessing the actual service need to still be included , ie SOAPEndpoint* etc

    as an example


    open http://TheHost/TheEndPoint?wsdl' in  a browser and save  to say c:\openedge\wrk\WSDL.wsdl

    ensure the WSDL references the right host.


    /* Access WSDL,  */
    hWebService:CONNECT("-WSDL 'c:\openedge\wrk\WSDL.wsdl'
                         -Service SErviceName

                         -Port PortName

                         -SOAPEndpointUserid xxxxx                  

                         -SOAPEndpointPassword xxxxxxx                     ").

    or from your code ensure  vp_wsdl references a local file version of the WSDL.


  • Hi Noel

    I canvassed this with our OpenEdge developers and, while it is possible, it is just as undesireable as the solution in Sonic.

    Going back to the original problem in Sonic ...

    Sonic Connect uses the "..address" Property to publish the cxfEndpoint via Spring. eg:

    This meant that Sonic would only listen on one interface and only for that IP address.

    The reason that was a problem is because we deploy to a lot of sites and it would have meant a unique deployment at each site. The solution was to use IP address

    I haven't figured out whether the WSDL Sonic is sending is directoy from the WSDL of the ..address" Property. I suspect the latter.

    If we locally deploy the WSDL in OpenEdge then we'd be in the same boat. The WSDL at each site would need to be unique.



  • Hi Steve,

    True you could deploy a WSDL to each site but with a simple awk, sed or even openedge program you could automate the creation of the wsdl. Not knowing where the webservice is called (server or client side), DB connected or not, however, you could deploy a common wsdl in the database with a flag to indicate new. If the code goes to call the webservice, determines a new wsdl exists, it then extracts the wsdl from the DB, substitutes the with the correct value, also DB stored, writes WSDL to disk and then use it. A little bit of work....

    As an aside, on the sonic front, have you tried putting in the hosts file and mapping it to the server in question. No idea if that works but could be worth a try...


    Senior Solution Consultant

    Progress Software Corporation

    GPO Box 2731  |  Brisbane, QLD 4001  |  Australia


    MOBILE  +61 409-940-918 TOLL FREE  1800 767 774

      Follow us on Twitter

      Like us on Facebook

      Join us on LinkedIn