I need to implement a SOAP server that will respond to a third-party application that behaves as a SOAP client.
The server should be in PHP, so I started using nusoap and http://www.wsdltophp.com/ to generate the skeleton.
Here's the wsdl file they gave me:
http://pastebin.com/YXBbszqE
The guy from support said I should start with the Ping request, because it's the most simple and straightforward to implement.
I'm new to this and will really appreciate some help.
Here's what I have so far for the server:
http://pastebin.com/vARst5t0
and to simulate the client:
http://pastebin.com/seG7EmM6
and it gives me an error:
http://pastebin.com/Say6FmF6
Thanks a lot, guys.
EDIT:
I found that on the server, after disabled the error_reporting, I don't receive the previous error.
I forgot to mention that I use the nusoap feature of loading the wsdl file and not defining each complexType manually, but it's still not working, now I get the following error:
Operation 'Ping' is not defined in the WSDL for this service.
And I'm sure it is there.
Maybe it comes from the options you chose when generating the package. Indeed, when calling the MySoapServicePing::Ping() method, parameters are maybe not sent properly : contained by an array or not. So try modifying the generation behaviour and send the request again.
You may also look to the XML request sent to the SOAP server in order to ensure that it does not come from the request. To get the XML request, you can call the MySoapWsdlClass::getSoapClient()->__getLastRequest() method or the $mySoapServicePing->getLastRequest() method (depends on the version of the generator) after sending the request.
Let me know if it changes anything or not.
Thank you guys, I ended up using the php native functions and it was much easier to configure.
Related
I would like to ask you if there is any component that I can use to connect laravel and prolog
Thanks
You haven't said which prolog supplier you wish to connect to, but swi-prolog comes with an http server package, which handles regular http GET and POST requests from any http client.
It is possible to call swi prolog from the console from php, but http is much, much faster, as you're not shelling out to a console each time.
I don't know anything about Laravel, but a quick search shows it natively supports http via 'routes', so it should be possible in theory.
I have also successfully called swi prolog server from a php curl client. Laravel seems to have support for curl, so that be another way to initiate the http client GET/POST request.
There is the abandoned https://packagist.org/packages/prologue/phpconsole for Laravel 4, or it's replacement https://packagist.org/packages/phpconsole/phpconsole that you might consider.
I was landed a project to debug a PHP SOAP server (SoapServer) written by an unknown party. It is being used by a c# SOAP client, which I don't have access to the source code to (in other words, I cannot use __getLastResponse to see what it gets). I am trying to capture XML output of the server's responses. Traffic sniffing (wireshark, etc) doesn't work because of the SSL layer being used to encrypt XML messages. Any help in figuring out how to see the XML messages sent out by the server would be greatly appreciated.
There's an excellent example for extending the SoapServer class and grabbing the Soap XML request and responses here: http://blog.mayflower.de/archives/179-Extending-class-SoapServer-PHP5-for-debugging.html
Does the SoapServer look like this one, or like this one? If it's the former, you're up a tree and every ladder within a year's distance has been violently destroyed by wolverines. Rather, it's a binary blob of compiled code from which there is no escape.
If it's the latter, you may have some hope -- the service method's third parameter can be set to true to get the response data rather than blindly sending it out.
There's also a rumor that the ancient "nuSOAP" library has a server mode, but that project seems to have imploded in upon itself, and took the documentation with it.
Long-term, you may be better served by using a web service layer that isn't pathologically backwards, though that might not be an option for you.
I've got a nice question here :)
I need to debug my web service written in PHP. Its client is written in C#.
After a couple of days of searching I realized this is not an easy task. At least it seems nobody knows the right solution.
What is the problem in, actually?
We have 2 popular PHP debugging libraries : PHP Debugger from NuSphere and XDebug extension.
The problem is they both are controlled from URL query string or with the help of cookies. For example, to enable debugging with PHP Debugger you need to add ?DBGSESSID=xxx parameter to your URL or to have DBGSESSID cookie.
But when your web service is called from the external client, the client doesn't have a cookie and doesn't add DBGSESSID url parameter. So how can we debug in this situation?
PS. I don't want to write to log files, see request and response headers/data or something like this. I want normal step-by-step debugging and breakpoints.
Anyone?
Well, I am answering to myself.
If we use PHPEd & DBG, then we can use the magic function DebugBreak().
Make sure PHPEd & PHP DBG Listenere are running, write
DebugBreak('1#127.0.0.1');
anywhere in your werbservice's code, make a call from the client, and voila! - you are in PHPEd on that line in debugging mode!
you could set xdebug.remote_autostart to 1 to always debug (no request parameter needed). this could be limited to some url with the <Location> or <Files> directive.
Or just log some debug information (using Zend_Log or Pear Log if you want a generic library) using var_export.
quick and dirty way is:
file_put_contents('/tmp/log1.txt',
var_export(array($_REQUEST, $something), true));
You could write data to a log file (meh).
Or output debugging information in response headers (if the client can view them). But as far as using breakpoints, you may be out of luck.
You could also look into connection hijacking on your local computer (something similar to the Firefox AddOn Tamper Data) where you can interrupt the request and add the url parameter.
Try SoapUI to issue requests manually and get the detailed responses. Not sure if you can fake the cookie, but you can control the endpoints, and therefore the URL to an extent.
I seem to remember that you can configure NuSphere's product to automatically attempt to connect to the debug listener with or without the DBGSESSID parameter (in query string or cookie). I'm not positive if that's the case, though. However, you can get the effect you're looking for by doing the following. It may be a little more manually intensive than you're hoping for.
Setup some sort of HTTP query/response listener.
Perform desired access against web service from client.
Manually re-issue those requests, appending the appropriate DBGSESSID
For a little more initial setup, but lower friction debugging later:
Configure your client to access an alternate URL.
Setup a proxy to listen on that URL (for debugging, I've seen Privoxy recommended, though I have no experience with it personally).
Configure the proxy to forward all requests to the real web service, appending an appropriate DBGSESSID parameter or including the cookie
I use the plugin Poster to help debug my php Webservice
Edit :
Found a better tool to debug web service : Advanced REST client Application
It's a Chrome Plugin, works great to test all kind of web services that use REST
I have a problem using a distributed WSDL File (scheme / other definitions are declared outside the actual WSDL) with PHP's SoapClient.
This is the fault message I got:
SOAP-ERROR: Parsing WSDL: 'getSomeInfo' already defined.
After some googling, it seems to be a bug inside PHP as someone else discovered exactly the same problem: http://bugs.php.net/bug.php?id=45282
Has there been any bug fix(es)? Any solution to work around this bug?
I think posting a code snippet is senseless, since the invocation of the SoapClient ctor using just the WSDL is the only that fails.
I had same issue. The problem was in wsdl and imports, I saved wsdl from site and pointed soapclient to use local file, but all references were original. Soap client each time gets file from remote host, went to parts, and from them back to same file but on remote drive. That caused same file to be loaded twice.
Solution is to use only remote files or to rewrite paths to local (all). SoapUI does that when you hit "export definitions" on project wsdl. Hope that will help others.
Download a local copy of the WSDL file. Remove duplicate method names. Update your soap client to use the local WSDL file. This has worked well for me in the past.
I had the same issue while accessing a WCF service providing multiple endpoints through PHP. In my case, it turned out that the main WSDL imports sub-WSDLs for each endpoint, while the sub-WSDLs do include the main-WSDL in turn. This is apparently the reason why PHP reads the main-WSDL twice and comes up with the "already defined"-error. I could avoid this behavior by creating the client with the sub-WSDL URL of the desired endpoint instead of the main WSDL URL.
The PHP source code (svn) which takes care of the import nodes contains the comment /* TODO: namespace ??? */. Namespaces are ignored which enables the method collisions to occur.
Three solutions are proposed:
Fix the source code to cater for namespaces (which would be very welcome)
Manipulate the WSDL files to prevent such method overlaps (this is likely not an option at all)
Instead of using the original WSDL file, call the imported ones individually (or group ones which do not have method name collisions) with separate SoapClient instances.
Sorry that I can't be of more help.
I want to have a PHP script send a XML formatted string to another PHP script that resides on a different server in a different part of town.
Is there any nice, clean way of doing this?
(PHP5 and all the latest software available)
check out cURL for posting data between pages.
If it were me, I would just POST the xml data to the other script. You could use a socket from PHP, or use CURL. I think that's the cleanest solution, although SOAP is also viable if you don't mind the overhead of the SOAP request, as well as using a library.
I strongly suggest rolling your own RESTful API and avoiding the complexity of SOAP altogether. All you need is the curl extension to handle the HTTP request/response, and simple_xml to build/process the XML. If your data is in a reasonable format, it should be easy for you to push it into an XML string and submit it as a POST to the other server. That server will respond to the request by reading the XML string from the POST var back into an object, and voila! It shouldn't take you all day to whip this out.
XML-RPC or SOAP or just a RESTful API
You can use cURL (complex API), the http extension (cleaner), or if you need to do more complex stuff you can even use the Scriptable Browser from simpletest.