//English version at the end.
Bonjour,
Ce message s'adresse aux manageurs du plugin Webservices!
Je vous écrit à la suite d'une mésaventure au cours du développement de
nouveaux services web, se basant sur le plugin Webservices.
Mon plugin devait fournir un fichier WSDL. Et après l'avoir construit,
je me suis rendu compte que le plugin Webservices ne semblait pas prêt à
répondre à un client que se connecterait via WSDL.
Je faisais inévitablement face au message "Function $mamethode doesn't
exist". :'(
Voici ma proposition (déjà codé) :
*Problème : *
Coté Client:
En utilisant PHP, je créé une instance de SOAPClient en lui fournissant
en paramètre, mon fichier WSDL.
Ici, le comportement de php est le suivant : si le fichier wsdl est
construit proprement, PHP va ajouter des fonctions à l'objet qui auront
le même nom que leur méthode web service associé.
Autrement dit, si le WSDL prevoit la méthode "createTicket". Je dois
pouvoir faire : $soap->createTicket();
Coté Serveur:
Le plugin webservice instancie le serveur en assignant la classe :
PluginWebserviceSoap. Cette classe ne contient qu'une méthode en réalité
: genericExecute.
Malheureusement, par le biais d'un WSDL, cette fonction n'est pas
exécutée pour rediriger vers la bonne classe et la bonne fonction. On se
retrouve face à un script qui tente de faire :
PluginWebserviceSoap::createTicket(); Or createTicket n'existe pas...
d'où l'erreur précédemment décrite : "Function createTicket doesn't exist".
Solution proposée :
Ajouter une fonction magique __call() :
En ajoutant une fonction magique __call(), appeler une fonction qui
n'existe pas ne renverra plus d'erreur, et nous sommes ici en mesure de
savoir quel méthode est en réalité appelée.
En couplant cette fonction avec ce que contient $WEBSERVICES_METHOD,
nous sommes capable de limiter l'utilisation de cette fonction aux
méthodes réellement disponibles.
Limitation à cette fonctionnalité :
La limitation de cette fonctionnalité est minime : si l'on passe par un
fichier WSDL, nous perdons les clés des paramètres envoyés à la méthodes.
Autrement dit, en appelant une méthode de connexion qui attendrait trois
paramètres : $param['login'], $param['pass'] et $param['help'], nous
aurions en réalité : $param[0], $param[1], $param[2].
Là ou cette limitation est minime, c'est qu'un fichier WSDL est
suffisamment stricte pour nativement imposer un ordre dans le passage
des paramètres. Si le fichier décrit ces trois paramètres dans un ordre
précis, le client ne pourra faire autrement.
Note : si jamais il est prévu qu'un jour, le plugin intègre un
générateur de WSDL, ou simplement un WSDL recensant les méthodes
initialement disponibles, il faudrait songer à supprimer le "glpi."
devant les méthodes. En effet, cette syntaxe est impossible à appeler
dans une fonction : $soap->glpi.login() n'est pas une syntaxe de
fonction correcte. Toutefois, en trichant légèrement avec le fichier
WSDL, on peut fournir la fonction "login", et renvoyer en réalité :
glpi.login.
Note 2 : j'ai déjà le profil développeur sur la forge du plugin. Il ne
me manque qu'une validation de votre part!
Amicalement,
Anthony "SphynXz" Hébert.
//English version
Good morning,
My message is actually for the Webservice plugin managers.
Im writing you this email after experiencing some issues when developing
new webservice methods, based on this plugin.
My personal plugin is expected to provide a WSDL file, which I did.
However, when using this file from the client side, I figured out that
the Webservices plugin was not yet able to respond the proper way when a
script was connecting using a WSDL.
I keep facing the error : "Function $myMethod doesn't exist".
Here's my proposal (already developed) :
*Problem : *
Client side:
When using PHP, I create a SOAPClient instance, by using my WSDL file.
The default behavior of PHP is the following : If the WSDL is ok, PHP
will create new functions on the instance for each webservice methods
describe in the WSDL.
This way, for the method "CreateTicket", Im expected to write :
$soap->createTicket();
Server side:
The Webservices plugin initiate the SOAPServer by using the class
PluginWebserviceSoap. This class actually only contains one method :
genericExecute.
Unfortunately, when using a WSDL, this function is not executed. We are
facing a script that tries to reach
PluginWebserviceSoap::createTicket(); But createTicket does not exist...
That's why I got the Soap error : Function createTicket doesn't exist.
Proposal :
Add the magical function __call() :
When adding the __cal() function, calling an undefined function will be
catched. This way, we would be able to know which method is originally
requested.
By checking the $WEBSERVICES_METHOD content, we are even able to limit
the use of this function to the available methods.
Limite to this feature :
The limite of this feature is acceptable (IMO) : if the client connects
via WSDL, we lose the key of each parameter we send to the method. In
other words, If we call a "login" method which expects three parameteres
: $param['login'],$param['pass'], $param['help'], we would actually have
: $param[0],$param[1], $param[2].
When I say the limite is acceptable, I mean that a WSDL is strict enough
to force the client to pass the parameters in a specific order.
Otherwise, the SOAPClient is locally able to refuse the call thanks to
the WSDL definition.
Today, there is no WSDL at all included in the plugin, so there is
nothing to reflect on each php methods to cover this feature.
Cheers,
Anthony.
_______________________________________________
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev
