In Delphi 11 Alexandria, I created a simple SOAP webservice using File->New->Soap Server. I asked to create the demo interfaces, I have built the project, corrected Apache conf, and I have copied the DLL inside Apache's module directory.
So, if I request:
http://127.0.0.1:81/xyz/mod_webbroker.dll
I get into the page where I see the interfaces, and I can view the WSDL.
Now, I would like to try to call the demo function (echoDouble) from PHP using curl.
How do I know what address I should use?
I tried:
http://127.0.0.1:81/xyz/wsdl/IMyService/echoDouble/
But it's not working.
Any help?
I understand my doubts now. I have always used "Datasnap rest application" but now I am trying "SOAP server application", that is why I cannot find the correct URL, because they work different. When using "Datasnap rest application" you need to go to a specific URL to get the function but SOAP works different, the base URL is always this (in my case):
http://127.0.0.1:81/xyz/wsdl/IMyService/
Sorry for that, I will switch back to "Datasnap rest application"
Related
I´m currently evaluating Web Dav Product for .NET and I´m really impressed. I only noticed that when I´m integrating the sample code (Asp.NetFileSystem) into my existing ASP.NET Web API 2 Project, it doesn´t work with Office Word directly as a save target.
We have Web API 2 with Windows Authentication and CORS Headers on.
Windows Explorer can open and Navigate the WebDAV Folder and I can create new files there. But when I´m saving from word directly, I get errors in Word that the network path does not work / exist. I tried to debug it but it happens
I separated the WebDAV part in it´s own project for test purposes and it works without the problems.
Am I using it wrong in the context of Web API 2, or is this an unsupported usecase?
I´ll try to get fiddler logs to.
Thanks a lot!
Thanks to the IT Hit WebDav we were able to trace the problem down. To work correctly, OPTION requests have to be processed by the WebDAVHandler. We have a custom module which intercepts OPTION requests to handle CORS. Because of our Module, the WebDAVHandler was not able to add the necessary headers, and Office opened the files readonly.
I read somewhere here on stackoverflow that using NuSoap is not a good idea and its dead. If it is, what is the best possible solution to create WSDL files. I was just nusoap just for creating wsdl files and I never got the webservice to work
NuSOAP isn't being developed any more and hasn't been for a while.
I have looked at most of the current PHP Soap options, and settled for Zend_Soap_Server, specifically because of its AutoDiscovery component.
The main point about AutoDiscovery is that the WSDL is generated from the docblocks within your code. So as long as you follow the correct conventions, the component will build a well-formed WSDL for you.
If you don't want to use a framework, you can just include the files Server.php, AutoDiscover.php and Wsdl.php. I do it like this;
require_once 'Zend/Loader.php';
require_once "Zend/Loader/Autoloader.php";
$autoloader = Zend_Loader_Autoloader::getInstance();
Zend_Loader::loadClass('Zend_Soap_Server');
Zend_Loader::loadClass('Zend_Soap_AutoDiscover');
Zend_Loader::loadClass('Zend_Soap_Wsdl');
It's also worth remembering that AutoDiscovery alone IS NOT a SOAP server, it just generates your WSDL. So in theory, you could probably use it to create a WSDL, but use a different SOAP server if you wanted to i.e. the native PHP one (which does not generate WSDL). However, as you will have loaded up the Zend Soap Server it would seem a bit wasteful not to use it IMO.
If you're working with PHP4, it might be your only alternative.
With PHP5, you can use Zend Soap. http://framework.zend.com/manual/en/
I'm using Nusoap with php 5.2.5. Working great for me. But I never tested it with higher veersion.
Same as MacMan, I am using with php 5.2.17 and it is working great, easy that native PHP SOAP, I guess.
i use WCF with ios application, and when request for some method, IIS returns me 415 error, Not Supported Media Type.
Proxy class are generated through wsdl2objc, the same call from windows application works fine
The problem is probably in your WCF service configuration, specifically the binding you're using. I suppose you have configured it to use either custom binding or WSHttpBinding, but in either way the service expects application/soap+msbin1 mime type, but the requests made by the generated classes from wsdl2objc are with text/xml. I'm not quite sure how to fix it, but start by configuring your service for the standard BasicHttpBinding and give it a try. Also revert all changes you've made on the generated code from wsdl2objc.
Btw WSHttpBinding uses SOAP 1.2 and I'm not sure if wsdl2objc can work with it (i have tested it only with BasicHttpBinding).
I'm signed up, I've downloaded sample code, I've got a WSDL...and yet I have no idea how to get this stuff into my existing .Net application. The WSDL was in a zip file, not a URL so I can't just "Add Web Reference." I've run the wsdl tool from the .Net command prompt, and it made a nice class for me...yet dropping that into my web_reference folder doesn't give me any kind of instantiatable class.
I know I'm missing something stupid. Can someone point me in the right direction please?
The proper way to load the FedEx API WSDL file in Visual Studio 2010:
Open the Solution Explorer
Right click your project
Click 'Add Service Reference'
Click the 'Advanced...' button
Click the 'Add Web Reference...' button
Enter the exact path to the WSDL file for the specific FedEx web reference you're using. For example, I extracted mine to the root of my C:\ drive, so all I entered into the URL field was "C:\ShipService.wsdl" without quotes. If you leave quotes, it won't work.
When you hit go, Visual Studio should consume the wsdl into workable classes for you. Click Add Reference and enjoy!
Note: Make sure you read the FedEx documentation well - a lot of their services have gotchyas and implementation can be a nightmare. For example, their address validation service is consumed incorrectly and creates two-dimensional arrays in Reference.cs where they shouldn't exist - this is detailed in the documentation. Worse yet, the fact that they don't allow address validation on their dev environment isn't documented anywhere! Good luck!
Actually, you can just "Add Web Reference". Give the path to the URL.
OTOH, you should be doing all new web service development (even client development) using WCF. Microsoft now considers ASMX web services to be "legacy technology".
BTW, I just tried using their address validation service, and it won't work with .NET. Both ASMX and WCF clients will attempt to use the XML serializer to consume this service, and there is a bug there that prevents that service from being used.
Matt, the WSDL zip file has the WSDL and its associated transactions for that service. Unzip the file and then "Add the reference" to the WSDL in your code.
Try changing the namespace of the proxy class to that of your application. I currently use the proxy class with C# and it works in spite of FedEx's limited documentation and samples.
My problem is closely related to this one: How can I use .NET web services from non-standard ports?. My web service runs behind a port-forwarding firewall, so the port numbers reported in the WSDL document contain the internal high-numbered port. I wrote a SoapExtensionReflector class which is able to rewrite the WSDL document. So a request like example.com/path/loginservice?wsdl is handled correctly.
However, this doesn't handle the "disco" request: example.com/path/loginservice?disco. This returns an XML document like this:
<discovery>
<contractRef ref="http://example.com:10092/loginservice.asmx?wsdl" docRef="http://example.com:10092/loginservice.asmx"/>
<soap address="http://example.com/path/loginservice.asmx" binding="q1:LoginServiceSoap"/>
<soap address="http://example.com/path/loginservice.asmx" binding="q2:LoginServiceSoap12"/>
</discovery>
While the soap bindings have been properly re-written by the SoapExtensionReflector, the contractRef and docRef URLs have the high-numbered port. How can I rewrite them as well?
Finally figured something out. Created proxy classes manually using svcutil after migrating everything to WCF. I figure you could probably do the same thing using the wsdl tool that came with the old asp.net web services, but I haven't tried that.