Moodle

I assign to nobody cause it is not an emergency yet. Any participation is welcome.

Some comments from Martin for later:

You need this for autocreate wsdl http://framework.zend.com/manual/en/zend.soap.autodiscovery.html

Hi Luis,
we already use it. However the autodiscovered WSDL is only generated from the PHPdoc. The PHPdoc doesn't contain our full description array. So JAVA/.Net have some problems with it.
Note that this comment concerned Zend 1.9 and I'm not an expert with JAVA/SOAP. It seems to me that the solution would be to use the library functions that Zend uses for their Autodiscover class, in order to generate a fully detailled WSDL.

Voted +1. WSDL will be useful for not only java but also PHP itself (PHP-SOAP supports WSDL for automatically binding functions), python, perl etc.

Makes it a lot easier to work with SOAP when there's WSDL available.

I edited the issue title and description, it was not clear that we already generate a WSDL. I just could not make it work with a Java client.

I'm trying to track down the guys from CPIT who I was talking to, hopefully they pop up here.

Otherwise, did anyone try some googling to find the solution I mentioned?

OK, it seems that the problem is something else, I had misunderstood.

The problem is that the Zend autodiscovery method, in which our PHP structure description is converted to phpdoc and then parsed by Zend, is not capable of capturing our complex structures in enough detail, and so the resulting WSDL is not enough for Java (PHP on the other hand is more lazy and works fine).

So we either need:

• some custom code to convert our structures to a more detailed WSDL that keeps Java happy, or
• some information about making Java more tolerant like PHP

Some info from Kris at CPIT:

Looking at your issue seems to be in two parts incorrect/incomplete automatic generation of WSDL and soap encoding of array elements.

The first I can't help you with too much as I mostly use Handcrafted WSDL on PHP 5 SoapServer class. The reason behind this is the ability to version the interface. Having a dynamically built WSDL would mean that when the code changes the interface changes not desirable as the WSDL is your contract to external consumers/providers and having such a dynamic interface can pose unforeseen issues especially in compiled Java/Objective-c(IPad/IPhone) clients.

The second point is easy. The PHP setting in question that will bite you is in the handling of Array Complex type either maxOccurrences="unbounded" or soapenc:ArrayType when there is only one element in the array PHP will encode it as an element rather than an array of one. To get round this construct the SoapServer like so:

$server = new SoapServer($wsdl,array('features' => SOAP_SINGLE_ELEMENT_ARRAYS) );

Bumping this for now. I think we might need a PHP+Java expert to est this in a real situation.

Please can we increase the priority of this? It is a pain in the bum for us at the OU. Our IT department likes to call SOAP from .Net, which needs proper WSDL.

setComplexTypeStrategy in lib/zend/Zend/Soap/AutoDiscover.php looks like a promising plugin point. Can we hook into that and get it to parse our arrays with detailed struct info?

Alternatively, can we parse our detailed arguments and return information, and build an accurate Zend_Soap_Wsdl ourselves?

Hi,

The last few weeks I have been working a project to get grade and log data out of Moodle using soap web services. The last few days have progressed well. I have everything using Moodle web service APIs etc and all works well using testclient in Moodle. The problem was is I needed/wanted to use a Document/literal wrapped WSDL. I have finally got it sorted I think.. code is still a little rough, will be doing some testing next week at work but at this stage looks good under testing with soapUI. I will post code up when at work next week if anyone interested?

Anyways here brief details of what I did.

My services are sitting in Moodle as local module. Copied soap/server.php and soap/locallib.php to the local folder. I have script wsdl.php that accepts wstoken and read my wsdl.xml file and sets up targetnamespace with the wstoken. I override service_class_method_body() to build methods for the virtual class. I then load soap server $this->zend_server = new $this->zend_class(htmlentities($wsdlurl)); under init_zend_server(). It seems to work.

Regards

Troy

Yay! I think I have cracked it. At least these changes are good enough for my web service that returns an object with 4 fields.

Jerome (or anyone else) please review this and see what you think.

Does it pass the web service unit tests (xmlrpc + soap enabled) in webservice/simpletest/ (you need to set to true protocols and functions in the file; only test on a dev site that you don't care much about the db) ?
When you said you cracked it, do you mean it generates a wsdl compatible with java/.net client generator? If yes that is just really cool!

I'll try when I'm back anyway, thanks.

Hi Tim,
I reviewed it:

• all current Moodle web service unit tests are still working (soap + xmlrpc)
• the patch generates classes with a full detailed phpdoc (recursive)
• I don't think it could break anything, at worst the soap server only

Thanks for the code reduction improvement too.

I need to test the recursivity, but that seems very good. From what you are saying I understand once you have the full details, Zend SOAP server do generate a JAVA compatible?

Can you give me a JAVA client if you have one simple? I'll try netbeans client generator by tomorrow anyway.

You are going to make many people happy

I don't have a good Java client available, but fortunately these people do: http://www.soapui.org/ (I know it looks commercial, but they do have a free download available.)

SOAPUI worked for me with a non-recursive function (just returning an object with 4 fields that were strings or ints.) I did not try a more complex case.

However, even after my changes, people in the other half our IT department failed to connect to the web service using .Net, however, they only tried once then went on holiday, so the will try again later.

However, I agree with your analysis, this won't break anything other than SOAP, and it will probably only make SOAP work better, not worse, so probably OK to integrate this for now, even if there is more work to do.

I'm not going to send the patch for integration, I'm not an expert of SOAP and there are two things I'm not sure about:

1- when the param type is an array, then nothing is defined in the WSDL.

We currently generate (patch or not patch, same issue):

<xsd:complexType name="webservices_struct_class_000000">
                <xsd:all>
                    <xsd:element name="parents" type="soap-enc:Array"/>
                    <xsd:element name="files" type="soap-enc:Array"/>
                </xsd:all>
            </xsd:complexType>

I guess we still need to transform the type="soap-enc:Array" in "complexType", and we need to fully describe the complexType like Tim did in his patch for single_structure (i.e. we need to do it for multiple_structure)

2- the patch is not compatible yet with the JAX-WS generator like Netbeans SOAP client generator. However it is most likely a problem related to the Zend SOAP server config. I noticed there is a related issue in the Zend Jira tracker: http://framework.zend.com/issues/browse/ZF-6077

Assigning back to Jerome. Since he spurned my efforts, he can take this forwards

Thanks Tim, I was surprised by your JAVA server patch and very happy

My concern being that the arrays are not fully detailled in the generated phpdoc (this code part is not changed in the patch) and so there are not fully detailled in the WSDL. If we end up to find out that we can not generate a fully detailled WSDL for arrays, we would need to go back into the direction to generate the WSDL from parsing the Moodle web service description. And so removing your previous code. This doesn't seem like a quick task and it is not a Blocker/Critical issue (yet).

To people who voted: is Tim's patch good enough for your Java needs or you can not create a JAVA client with the patch?

Yes, please comment people.

We're wondering if the current suggested implementation is sufficient for your needs or if we should continue developing this for a future release.

Surprised to see this re-classified as a new feature. Moodle 2.0 claimed to support SOAP, but it does not actually work. That is: it is buggy.

Also, this is a blocker for the OU, and if I recall, at least on other person in the web services forum.

Oh well. We have a work-around, which is to copy the code in my patch into a local plugin. Just a pity that others in the community cannot benefit from it.

Can this just be submitted for intergation into master? 2.2

Can't be worse than what we had.

submitted for integration in master

Once integrated we need to create a new issue about having a WSDL generating fully detailled arrays + JAVA client.

Horrible eval, nasty SOAP, but if it helps... integrated. Please check it does not break others.

Thanks and ciao

Just a note to help the testing team, I tested this: I checked that the unit tests were running fine with soap and xmlrpc, I read the entire code, and also I checked the generated phpdoc. You can pass it and blame me if it doesn't work

Jerome has tested this, and it seems it's not easy to test it. So blindly passing it.
Thanks Jerome

Such an effort has get its prize. Universal Award to the very-best Moodle developer in the family. Thanks!

Closing. Ciao

I created two new issues now that this one is closed:
MDL-28988
MDL-28989