Cette petite bête s’appelle Web Service ou API et derrière ce nom d’insecte se cache l’une des fonctionnalités les plus importantes de Magento dans le cadre de l’intégration d’une boutique Magento à un système d’information.

C’est quoi un Web Service ?

Si je devais illustrer ce qu’est un Web Service je dirais que c’est à Magento ce que le langage des signes est aux sourds. C’est un moyen de communication.

Un moyen de communication mais pour qui ?

Pour tous les logiciels qui auraient besoin de dialoguer avec Magento. Votre logiciel de gestion comptable, de gestion commerciale ou autre.

Pour quoi faire ?

A travers le Web Service un logiciel tiers pourra par exemple récupérer la liste des commandes, ajouter des produits, ajouter des catégories, …
Je parlais au début d’intégration dans le système d’information, vous devez commencer à voir le potentiel de l’API, un logiciel de comptabilité pourra récupérer les commandes et mettre à jour automatiquement votre compta, votre logiciel de suivit des stocks ou de production pourra prendre en compte les volumes de produits commandé et les mettre à jour.

Oui mais ça on le faisait déjà avant

Probablement tant ce genre de fonctionnalité est importante, toutefois les plateformes e-commerce gratuite disposent rarement d’un Web Service natif en fait je n’en connais pas à part Magento. Donc si vous l’aviez fait auparavant vous aviez probablement du faire faire un développement spécifique (mise en place d’un Web Service, envoi de fichier, ou autre).

Donc

L’intérêt premier de ce Web Service est :

• Sa disponibilité assure d’une part l’homogénéité d’une plateforme Magento à l’autre (le Web Service est le même sur toutes les boutiques Magento)
• Accélère l’intégration puisqu’il n’y plus besoin de le développer (réduisant les coûts de développement)
• L’aspect Web Service assure que la communication sera bien assurée sans devoir personnaliser la sécurité du site puis qu’un appel standard au Web Service se fait avec le protocole http sur le port 80, il est possible si besoin de passer par du https si on veut sécuriser les données transitant sur le web.
• Et enfin on bénéficie de la sécurité intégrée à Magento et du framework Zend.

Comment ça marche ?

Sans rentrer dans les détails un Web Service communique avec un langage standardisé que n’importe quel programme est capable de générer : des flux XML.
Magento supporte 2 protocoles de Web Service nativement, vous pouvez utiliser au choix SOAP ou XML-RPC, pour ceux qui ne savent pas les 2 sont du XML, mais la manière de formater les 2 n’est pas la même, l’utilisation de l’un ou l’autre dépendra principalement de l’environnement technique.
Sachez cependant qu’un Web Service ne sait pas parler, il ne sait que répondre il doit donc être sollicité à chaque fois qu’on a besoin d’une information.
Exemple :  Le Web Service ne pourra pas de lui-même envoyer les commandes à votre comptabilité, c’est la comptabilité qui devra solliciter le Web Service et lui demander la liste des commandes.
Et la sécurité ?

Je n’ai pas personnellement fait de test de sécurité mais je pense que cette partie est robuste en voiçi les raisons :

Le Web Service n’expose que 8 méthodes publiquement et aucune de ses méthodes ne permet d’accéder aux données :

• startSession()
• login(apiUser, apiKey)
• endSession(sessionId)
• call(sessionId, resourcePath,array arguments)
• multiCall(sessionId, array calls,array options)
• resources(sessionId)
• globalFaults(sessionId)
• resourceFaults(sessionId, resourceName)

Pour accéder aux données il faut utiliser call ou multiCall, Magento vérifie alors que l’utilisateur a le droit d’utiliser la méthode appelée grâce au système ACL de Zend.
A partir de là j’imagine que ces méthodes publique ont été correctement protégé et qu’en conséquence la sécurité du site n’est pas compromise.
Toutefois il y a un point qui me chiffonne c’est que les requêtes http et les flux XML sont tout de même facile à intercepter pour qui le veut, or un appel à la méthode login envoie le login et mot de passe en clair, c’est pourquoi je pense qu’il faut privilégier les appels en https.

Et les performances ?

Soyons franc la communication passant par Web Service c’est lent et ça consomme, par exemple voici le flux XML envoyé pour l’authentification, on envoie que 3 paramètres :
<?xml version= »1.0″?>
<methodCall>
<methodName>login</methodName>
<params>
<param>
<value>
<string>Fabrice</string>
</value>
</param>
<param>
<value>
<string>123456</string>
</value>
</param>
</params>
</methodCall>
Pour 20 caractères pertinents on en envoie 10x plus à côté, et encore ici c’est de l’XML-RPC, SOAP est encore plus consommateur. De plus les temps de réponses sont longs (on compte en secondes) entre le moment ou on envoie la requête et le moment ou on reçoit la réponse. Et je ne parle pas de la consommation de ressources serveurs liée à l’exécution des requêtes en elle-même, mais à mon avis récupérer la liste des produits d’une boutique en ayant 5000+ pendant les soldes est selon moi une mauvaise idée (qui tente l’expérience ?). Ces aspects ne gâchent en rien l’utilité du Web Service mais il important d’en connaître les défauts si on veut l’exploiter de manière optimale.

Concrètement comment je peux faire appel à l’API ?

La première chose à connaitre est l’adresse du Web Service, elle dépend surtout du type de Web Service que vous souhaitez utiliser :
SOAP : http://www.monsite.com/api/?wsdl
XML-RPC : http://www.monsite.com/api/xmlrpc/

Ensuite cela dépend du langage que vous allez utiliser, commençons par PHP car c’est facile :

1. $client = new SoapClient(‘http://www.monsite.com/api/?wsdl’);
2. // Vous pouvez aussi utiliser
3. // http://www.monsite.com/api/soap/?wsdl
4. // Si on a besoin de s’authentifier,
5. // on récupère le jeton de session
6. $session = $client->login(‘apiUser’, ‘apiKey’);
7. $result = $client->call($session, ‘module.methode’);
8. $result = $client->call($session, ‘module.methode’, ‘arg1′);
9. $result = $client->call($session, ‘module.methode’, array(‘arg1′, ‘arg2′, ‘arg3′));
10. // Si on a fini on termine la session
11. $client->endSession($session);

Faisons un peu de .Net

En .Net c’est un peu plus compliqué, bien que le framework .Net supporte le SOAP, il y a visiblement un problème de norme entre SOAP Magento et SOAP .Net ce qui rend cette librairie inutilisable.

Il va donc falloir passer par XML-RPC. Malheureusement ce type n’est pas supporté nativement par .Net, toutefois il existe une très bonne librairie gratuite créé par Cook Computing.

Pour l’utiliser il va falloir créer l’interface des méthodes publique du WebService Magento, voici la mienne :

using System;
using System.Text;
using CookComputing.XmlRpc;
public interface XmlRpcInterfaces : IXmlRpcProxy
{
  [XmlRpcMethod("login")]
  string login(string apiUser, string apiKey);

  [XmlRpcMethod("endSession")]
  bool endSession(string sessionID);

  [XmlRpcMethod("call")]
  XmlRpcStruct[] call(string sessionID, string resourcePath, object[] data);

  [XmlRpcBegin]
  IAsyncResult Begincall(string sessionID, string resourcePath, object[] data);

  [XmlRpcBegin]
  IAsyncResult Begincall(string sessionID, string resourcePath, object[] data, AsyncCallback acb);

  [XmlRpcBegin]
  IAsyncResult Begincall(string sessionID, string resourcePath, object[] data, AsyncCallback acb, object state);

  [XmlRpcEnd]
  XmlRpcStruct[] Endcall(IAsyncResult iasr);
}

Notez que je n’ai implémenté que 3 des 8 méthodes publiques et que j’ai implémenté la méthode call pour pouvoir faire des appels asynchrone (avec du polymorphisme en prime).

Pour l’utiliser c’est relativement simple, si je devais reprendre l’exemple PHP ça nous donnerai en C# :

1. XmlRpcInterfaces proxy = XmlRpcProxyGen.Create<XmlRpcInterfaces>();
2. XmlRpcStruct[] result;
3. proxy.Url = @ »http://www.monsite.com/api/xmlrpc/ »;
4. string session = proxy.login(« apiUser », « apiKey »);
5. result = proxy.call(session, « module.methode », new object[] { });
6. result = proxy.call(session, « module.methode », new object[] { « arg1″ });
7. result = proxy.call(session, « module.methode », new object[] { « arg1″, « arg2″, « arg3″ });
8. proxy.endSession(session);

Les appels asynchrone

Ce qu’il y a de bien avec des langages comme .Net ou Java c’est la possibilité de faire des appels Asynchrone, plutôt que d’attendre la réponse du serveur on envoie la requête et on déclenche un évènement dès que l’on réceptionne la réponse.

C’est possible à faire avec le WebService de Magento à 2 conditions :
Tout d’abord il faut implémenter la gestion de l’appel Asynchrone (déjà fait dans mon exemple pour call) de la méthode.
Ensuite il faut absolument que le serveur Apache soit configuré de manière à pouvoir garder en vie la session, sans ça vous avez toutes les chances que la session expire entre 2 requêtes ou même entre la requête et la réponse.

Dans la plupart des cas les appels asynchrone ne sont pas possible car Apache n’est pas configuré pour cela par défaut, un moyen de contourner cela est de faire des appels synchrone dans des threads séparés.

Etendre le Web Service

Utiliser le Web Service est ce dont vous avez besoin mais les traitements proposés ne vous conviennent pas ?
Qu’a cela ne tienne, il est parfaitement possible de créer de nouvelles méthodes dans l’API en les implémentant dans un module Magento. Je ne ferai pas de cours sur ce point maintenant car j’ai l’intention d’écrire un article dédié aux modules ultérieurement. Sachez juste que c’est facile à faire.

Conclusion

Le Web Service c’est le bien.

Son utilisation est un vrai bonheur pour relier des applications à Magento avec les exemples que j’ai donné vous devriez pouvoir l’utiliser vous même assez facilement. Pour les marchands ou futur marchands vous connaissez désormais un des potentiels de Magento.