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="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<soapenv:Fault>
<faultcode>soapenv:Server.Exception</faultcode>
<faultstring>Failed to locate WSDL for Sonic service or process: rm4ReceiveWebService</faultstring>
<faultactor/>
<detail/>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>
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?
Thanks
Steve
Hello Stephen,
I have tried it using 127.0.0.1 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.
Regards
Chan Jeremy
By setting the host address 0.0.0.0, it will bind to all IP address. The WorkBench wizard in 8.5 has been updated to set default as 0.0.0.0 instead of localhost.
Thanks.
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?
Regards
Steve
Hi Steve,
It is not possible to bind both HTTP and HTTPS to the same Sonic Connect/CXF endpoint.
Thanks,
William
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 0.0.0.0 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).
Regards
Steve
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=http://0.0.0.0/TheEndpoint />
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
Thanks Steve. I logged a defect in Sonic (SNC00082827 "?wsdl can return http://0.0.0.0/... 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
locally
open http://TheHost/TheEndPoint?wsdl' in a browser and save to say c:\openedge\wrk\WSDL.wsdl
ensure the WSDL references the right host.
then
/* 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.
regards
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: http://192.168.255.3/TheEndpoint
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 0.0.0.0.
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.
Regards
Steve
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 0.0.0.0 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 0.0.0.0 in the hosts file and mapping it to the server in question. No idea if that works but could be worth a try...
NOEL SHANNON
Senior Solution Consultant
Progress Software Corporation
GPO Box 2731 | Brisbane, QLD 4001 | Australia
MOBILE +61 409-940-918 TOLL FREE 1800 767 774
www.progress.com
Follow us on Twitter
Like us on Facebook
Join us on LinkedIn