|
|
TUTORIEL PHP |
|
|
|
Créer des services Web avec SOAP et PHP |
Dans cet article, nous allons écrire notre propre service Web avec les outils de base de PHP, et en faire un autre à l'aide de NuSOAP.
(13/05/2004) |
|
(fourni
par )
Utiliser NuSOAP
Lors de l'écriture de la seconde application, nous allons tirer
parti de la bibliothèque NuSOAP : c'est un groupe de classe
conçues pour gérer des services Web en SOAP, qui vont accélérer
votre programmation. Comme j'ai déjà utilisé ces classes dans
mes deux articles précédents, parus en janvier et mars, je vais
passer rapidement sur les généralités de NuSOAP. La bibliothèque
est distribuée sous licence LGPL et vous pouvez la télécharger
sur le site de Dietrich.
Pour inclure les classes NuSOAP, il suffit d'ajouter la ligne
require('nusoap.php') dans le
script PHP.
Notre application
est présentée dans le Listing 2. Comme vous pouvez le voir,
après avoir inclus NuSOAP, nous créons une instance de soap_server,
qui est stockée dans la variable $s.
Puis, nous utilisons la fonction register()
pour informer l'instance du nom de la méthode que nous voulons
permettre à l'utilisateur. Dans le précédent exemple, nous avons
ignoré cette étape. En fait, nous n'avons même pas défini de
nom de méthode, car notre script a été conçu pour ne faire qu'une
seule opération : l'insertion.
La bibliothèque NuSOAP, d'un autre coté, est conçue pour supporter
plusieurs méthodes, et donc, nous devons commencer par enregistrer
la méthode auprès du serveur, puis déclarer une fonction PHP
du même nom. Cette fonction, à son tour, va accueillir les instructions
que nous voulons exécuter lorsque l'appel distant sera fait.
En fait, dans cette seconde application, la fonction elle-même
contient tout ce qui était hors de notre classe dans le premier
exemple.
D'un point de vue fonctionnel, l'application est très similaire
à sa version sans NuSOAP : d'abord, nous validons les données
d'entrées ; si une erreur survient, nous émettons une erreur
: dans ce cas, c'est une erreur NuSOAP, émise via soap_fault(),
mais, comme vous pouvez le voir, cette méthode n'est pas très
différente de notre SOAP::fault().
Notez que vous n'avez pas à vous tracasser avec la méthode de
communication utilisée par le client : NuSOAP va s'occuper de
cela pour vous.
Après cela, nous construisons la requête, et nous la stockons
dans la variable $query. Une
fois qu'elle y est, nous enchaînons les opérations dans la base
de données (connexion, sélection de la base, exécution de la
requête, et déconnexion). Nous nous assurons aussi qu'aucune
erreur ne survient. Cette fois, nous allons aussi nous assurer
qu'une ligne a été trouvée, et si ce n'est pas le cas, nous
allons retourner une erreur. Finalement, nous stockons le résultat
de la lecture dans la variable $resp,
et nous retournons le tableau.
La dernière ligne de code à utiliser pour compléter le script
est celle qui appelle la Remote Procedure Call via NuSOAP :
en utilisant la méthode $s->service(),
nous envoyons toutes les données issues de l'utilisateur via
la méthode POST, à l'analyseur NuSOAP. Ce dernier va analyser
la requête, rechercher la méthode a exécuter parmis celles qui
sont enregistrées, c'est à dire people_select()
dans notre cas. S'il en trouve une, NuSOAP l'exécute et assure
l'affichage du résultat en XML.
Comme c'est le cas dans nos précédents articles, NuSOAP assure
un masquage efficace de l'analyse et la génération XML pour
l'application. Il nous suffit de nous concentrer sur les fonctionnalités.
D'un autre coté, comme toujours avec les bibliothèques externes,
NuSOAP introduit un surcoût que vous devez prendre en compte.
Tests et déboguage de l'application
Pour tester notre application, nous devons écrire deux clients
SOAP. Comme nous l'avons faire par le passé, nous pouvons utiliser
la bibliothèque NuSOAP, pour gagner du temps. Le code est présenté
dans le Listing
3.
Créer un client SOAP avec NuSOAP, comme vous pouvez vous en
souvenir de notre dernier article, est très facile. Nous commençons
évidemment par inclure le fichier nusoap.php,
puis nous créons une instance de soapclient,
plaçée dans $ins, avec l'URI
d'action comme argument. Le tableau associatif $param
contient des paramètres qui doivent être passé à la procédure
distante. Finalement, nous invoquons la procédure avec la méthode
$ins->call(), qui requiert deux
arguments.
- Le nom de la méthode distante : dans notre exemple, nous avons
utilisée le nom people_insert
comme nom de méthode, mais tout autre chaîne fonctionnerait
aussi : nous ne nous sommes pas préoccupé du nom de la méthode
dans insert.php. En fait, nous
pouvons ignorer ce paramètre, car notre serveur ne supporte
qu'une méthode.
- Le tableau associatif qui contient les paramètres.
Le résultat de la RPC est stocké dans la variable $results,
qui est un tableau associatif : comme ce n'est rien d'autre
qu'un script de tests, nous nous contentons d'afficher le résultat
avec la fonction print_r().
Dans la seconde partie du Listing 3, ces opérations sont répétées
pour le second serveur SOAP 'select.php' en utilisant une instance
$sel de soapclient.
Nous pouvons maintenant tester nos applications : un appel correct
à insert.php devrait nous retourner quelque chose comme ceci
:
Array(
[status] => OK
[time] => 1079265466
)
Si une erreur survient, par exemple si l'identification n'est
pas correcte, la réponse sera un message d'erreur, sous cette
forme :
Array(
[faultcode] => Client
[faultactor] => Login incorrect
[faultstring] => Bad value of params 'user' or 'pwd'
[detail] => Array(
[soapVal] =>
)
)
Ceci est un message d'erreur SOAP. Comme nous l'avons vu, faultcode
peut être soit 'Client' ou 'Server', suivant le type d'erreur
: 'faultactor' représente la cause de l'erreur, et 'faultstring'
contient le message d'erreur. Comme vous pouvez le voir, il
y a une quatrième entrée, 'detail' qui peut contenir d'autre
informations sur l'erreur, mais nous ne l'avons pas utilisé
dans notre message, et donc, elle est vide.
Puis, nous passons à select.php.
La réponse du serveur à une requête valide est :
Array(
[name] => Robert White
[age] => 28
[city] => Boston
[time] => 1079271398
)
Cette réponse contient la ligne demandée dans la table, et la
date de lecture. Voyons maintenant un cas d'erreur : par exemple,
le message suivant contient une erreur liée à MySQL : dans ce
cas particulier, l'erreur est émise par la fonction mysql_select_db()
(Ligne 20 du Listing 2) :
Array(
[faultcode] => Server
[faultactor] => MySQL
[faultstring] => Unknown database 'xyz'
[detail] => Array(
[soapVal] =>
)
)
C'est une erreur côté serveur, "Server", causée par MySQL. Afin
d'obtenir cette erreur, j'ai dû modifier l'argument de la fonction
mysql_select_db(), pour lui
donner un nom de base de données inexistant, pour simuler une
véritable situation. Comme dans l'exemple précédent, il n'y
a pas de détail de précisé.
|
Forum |
|
Réagissez
dans les forums
de JDN Développeurs
|
C'est une méthode très simple pour nous assurer que nos serveurs
fonctionnent comme ils devraient le faire. Si vous vous apercevez
que print_r() génère un message
d'erreur trop compliqué, vous pouvez intercepter les erreurs
et faire un affichage plus approprié. Par exemple, nous pouvons
ajouter cette ligne avant l'appel à print_r(),
dans le listing 3 :
if($client->fault)
die("<h1>FAULT:</h1>Code: {$ins->faultcode}<br
/>"
. "Actor: {$ins->faultactor}<br />"
. "String: {$ins->faultstring}");
Ce code va arrêter l'exécution du script, et afficher un rapport
d'erreur.
|
|
|