fév 26

Le but de cet article est de vous faire découvrir un aspect très important de Magento et pourtant  peu sexy car il s’adresse plus aux développeurs qu’aux marchands.

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.

écrit par Fabrice Beck \\ tags: , , , , , , , , ,


12 commentaires sur “Magento le Web Service”

  1. 1. Philippe Humeau Dit :

    Bravo ! C’est clair, net et précis.Il va falloir qu’on rebondisse sur ton article avec des propositions d’optimisation coté « poids » / performance du Webservice. Mais c’est clairement en vogue puisque j’ai un client qui pense sortir le frontend de Magento, le refaire intégralement avec du Flash qui travaillerait avec le Webservice.

  2. 2. Romain Carrere Dit :

    Tres bonne présentation générale des possiblitées offertes par l’API magento. Effectivement le concept est simple mais la mise en oeuvre l’est peut etre moins selon le language utilisé pour dialoguer avec Magento.
    Je suis justement en train de faire des tests pour utiliser cette API via Javascript dans une application Adobe AIR…
    Il me semble qu’e termes de nombreuses extensions intéréssantes pour les marchands pourrait être crées sous forme d’applis AIR.

  3. 3. Nicolas | Boutik-Circus Dit :

    Très bon article!
    Reste une question qui me taraude, c’est la création de commande via l’API.. si qq’un a travaillé un peu sur le sujet, ca m’intéresse fortement!

  4. 4. Fabrice Beck Dit :

    Pour savoir ce qui est disponible avec l’API il faut dle cas des commande regarder dans /app/code/core/sales/etc/api.xml

    On peut déjà y voir un certains nombre de méthodes (changement de statut de commande, gestion des factures, …)

    Tu peux voir aussi cette ligne : sales/order_api
    Qui indique que les méthodes sont définies dans dans /app/code/core/sales/model/order/api.php

    Ouvre ce fichier et tu aura accès au methodes et aux arguements qu’elle prennent

    Et il n’existe rien sur la création de commande via l’API, il faudrait donc le créer avec un module.

    Un prochain article peut être ?

  5. 5. jsperri Dit :

    … ou dans une prochaine release de Magento.
    Varien avait annoncé à l’Openday un enrichissement des APIs sur la prochaine release 1.3 de Magento en mars 2009, espérerons que la création des commandes via l’API soit dans cette mise à jour.

  6. 6. mgf Dit :

    @ Philippe Humeau : Honnetement, faire un frontend basé sur les API Magento me parait complêtement irréaliste à l’heure actuelle : Les accès à l’API sont beaucoup trop lents !

  7. 7. Philippe Humeau Dit :

    Je dois avouer que je n’ai pas bencher ce point précisément. Mais prochainement, on va ouvrir une partie de notre infrastructure aux tests :) Vous pourrez y réaliser des tests tordues sur Magento dans un environnement optimisés, on pourra à ce moment tester les perfs des API pourquoi pas. Kallister a peut être plus de données que moi sur les perfs des API ?

  8. 8. Thierry Dit :

    Voici l’adresse du webservice si la réécriture d’url n’est pas active :

    SOAP : http://www.monsite.com/index.php/api/soap/?wsdl

    Thierry

  9. 9. Matthieu Dit :

    Très intéressant!

    Quels sont les avantages/inconvénients entre développer un nouveau module sur magento et l’utilisation du Web Service, pour le développement d’une fonction spécifique?

  10. 10. Philippe Humeau Dit :

    ah ca, je vous invite à le demander à [email protected]

  11. 11. Jean Dit :

    Cette API a l »air plus aboutie que celle que j’ai pu tester avec Sage, je tairais son nom mais elle est bien connue des initiés. Je vais de ce pas mettre à profit votre billet et me créer un petit module maison qui j’espère sera beaucoup plus efficace que celui que j’utilise actuellement pour mes échanges comptables.

  12. 12. Intégration de Magento et Symfony2 | Blog Symfony - Lexik Montpellier Dit :

    [...] A distance, le seul moyen d’échanger des données entre la boutique et un autre site est de passer par le web service. Son activation et ses possibilités sont très bien décrites dans la documentation officielle et sur Wikigento. [...]

Poster une réponse