Appels SOAP Apex
Objectifs de formation
Après avoir terminé ce module, vous pourrez :
- Générer des classes Apex en utilisant WSDL2Apex.
- Émettre un appel pour envoyer des données à un service externe en utilisant le SOAP.
- Tester les appels à l’aide d’appels fictifs.
Vidéo de démonstration Trail Together
Vous souhaitez être guidé pas à pas par un expert pendant que vous travaillez sur cette étape ? Regardez cette vidéo qui fait partie de la série Trail Together sur Trailhead Live.
(Ce clip commence à 45 min 49 s, au cas où vous voudriez revenir en arrière et regarder à nouveau le début de l’étape.)
Utiliser WSDL2Apex pour générer du code Apex
En plus des appels REST, l’Apex permet aussi d’émettre des appels vers des services Web en utilisant du XML. Travailler avec le SOAP peut être une expérience douloureuse (mais nécessaire). Heureusement, nous avons des outils pour nous simplifier la tâche.
WSDL2Apex génère automatiquement des classes Apex à partir d’un document WSDL. Vous téléchargez le fichier WSDL du service Web. Ensuite, vous le transférez et WSDL2Apex génère les classes Apex pour vous. Les classes Apex constituent le XML SOAP, transmettent les données et analysent le XML de réponse des objets Apex. Au lieu de développer la logique de construction et d’analyse du XML des messages du service Web, laissez les classes Apex générées en interne par WSDL2Apex gérer tout ce travail supplémentaire. Si vous êtes déjà familiarisé avec WSDL2Java ou avec l’importation d’une ressource WSDL en tant que référence Web dans .NET, cette fonctionnalité est similaire à WSDL2Apex. De rien.
Dans cet exemple, nous utilisons un simple service Web de calcul pour ajouter deux nombres. Un service révolutionnaire qui fera fureur ! La première chose qu’il nous faut faire, c’est télécharger le fichier WSDL pour générer les classes Apex. Cliquez sur ce lien et téléchargez le fichier calculator.wsdl sur votre ordinateur. N’oubliez pas l’emplacement où vous enregistrez ce fichier, car vous en aurez besoin à l’étape suivante.
Générer une classe Apex à partir du WSDL
- Dans Setup (Configuration), saisissez
Apex Classes
(Classes Apex) dans la zone Quick Find (Recherche rapide), puis cliquez sur Apex Classes (Classes Apex).
- Cliquez sur Générer à partir du WSDL.
- Cliquez sur Choisir un fichier et sélectionnez le fichier calculator.wsdl téléchargé.
- Cliquez sur Parse WSDL (Analyser WSDL).
L’application génère un nom de classe par défaut pour chaque espace de noms figurant dans le document WSDL et signale toute erreur.
Pour cet exemple, utilisez le nom de classe par défaut. Cependant, dans la vie réelle, nous vous recommandons vivement de changer les noms par défaut pour qu’ils fonctionnent plus facilement avec votre code et le rendent plus intuitif.
Il est temps de vous parler franchement de l’analyseur WSDL. L’analyse WSDL2Apex est connue pour être capricieuse. Le processus d’analyse peut échouer pour plusieurs raisons, par exemple, en cas de type non pris en charge, de liaisons multiples ou d’éléments inconnus. Malheureusement, il est possible que vous soyez contraint de coder manuellement les classes Apex appelant le service Web ou utilisant le HTTP.
- Cliquez sur Generate Apex code (Générer le code Apex).
La dernière page de l’assistant montre les classes générées ainsi que les éventuelles erreurs. Cette page fournit également un lien permettant d’afficher le code généré avec succès.
Les classes Apex générées incluent des classes stub et type permettant d’appeler le service Web tiers représenté par le document WSDL. Ces classes vous offrent la possibilité d’appeler le service Web externe en Apex. Pour chaque classe générée, une deuxième classe est créée. Elle porte le même nom, auquel le préfixe Async
est ajouté. La classe calculatorServices
est destinée aux appels synchrones. La classe AsyncCalculatorServices
est destinée aux appels asynchrones.
Exécuter l’appel
Prérequis
Avant d’exécuter cet exemple, autorisez l’URL du point de terminaison de l’appel de service Web, https://th-apex-soap-service.herokuapp.com, en suivant les étapes de la section Autoriser les adresses de points de terminaison.
Vous pouvez maintenant exécuter l’appel pour voir s’il ajoute correctement les deux nombres. Gardez une calculatrice à portée de main pour vérifier les résultats.
- Ouvrez la Developer Console depuis Setup (Configuration) ().
- Dans la Developer Console, sélectionnez Débogage | Ouvrir la fenêtre d’exécution anonyme.
- Supprimez tout le code existant et insérez l’extrait suivant :Vous remarquerez l’implémentation de la classe calculatorServices avec
calculatorServices.CalculatorImplPort calculator = new calculatorServices.CalculatorImplPort(); Double x = 1.0; Double y = 2.0; Double result = calculator.doAdd(x,y); System.debug(result);
calculatorServices.CalculatorImplPort
. Les classes créées via Generate from WSDL (Générer à partir du WSDL) ont toujours une méthode comportant le suffixeImplPort
.
- Sélectionnez Ouvrir le journal, puis cliquez sur Exécuter.
- Une fois le journal de débogage ouvert, cliquez sur Debug Only (Débogage uniquement) pour afficher la sortie des instructions
System.debug
. Le journal devrait afficher3.0
.
Tester les appels de service Web
Tous les développeurs Apex expérimentés savent déployer ou emballer le code Apex, au moins 75 % de ce code devant être couvert par un test. Cette couverture inclut les classes que nous avons générées avec WSDL2Apex. Vous le savez peut-être déjà, mais les méthodes de test ne prennent pas en charge les appels de service Web, et les tests exécutant des appels de service Web échouent.
Nous avons donc un petit travail à faire. Pour empêcher l’échec des tests et accroître le code couvert, l’Apex offre une interface WebServiceMock
intégrée ainsi que la méthode Test.setMock
. Vous pouvez utiliser cette interface pour recevoir des réponses fictives d’une méthode test, et ainsi couvrir le code nécessaire dans le test.
Spécifier une réponse fictive pour les appels
Lorsque vous créez une classe Apex à partir d’une WSDL, les méthodes de la classe générée automatiquement invoquent WebServiceCallout.invoke
, qui émet l’appel vers le service externe. Lorsque vous testez ces méthodes, vous pouvez demander au runtime Apex de générer une réponse fictive dès que WebServiceCallout.invoke
est invoqué. Pour ce faire, implémentez l’interface WebServiceMock
et spécifiez une réponse fictive que le runtime de test doit envoyer.
Demandez au runtime Apex d’envoyer cette réponse fictive en appelant Test.setMock
dans votre méthode test. Pour le premier argument, transmettez WebServiceMock.class
. Pour le deuxième argument, transmettez une nouvelle instance de votre implémentation d’interface WebServiceMock
.
Test.setMock(WebServiceMock.class, new MyWebServiceMockImpl());
Il y a beaucoup à faire, alors étudions un peu de code pour observer un exemple complet. Dans cet exemple, vous créez la classe qui génère l’appel, une implémentation fictive pour le test et la classe de test en elle-même.
- Dans Developer Console, sélectionnez File (Fichier) | New (Nouveau) | Apex Class (Classe Apex).
- Pour Class Name (Nom de classe), saisissez
AwesomeCalculator
, puis cliquez sur OK.
- Remplacez le code généré automatiquement par la définition de classe suivante :
public class AwesomeCalculator { public static Double add(Double x, Double y) { calculatorServices.CalculatorImplPort calculator = new calculatorServices.CalculatorImplPort(); return calculator.doAdd(x,y); } }
- Appuyez sur CTRL+S pour enregistrer.
Créez votre implémentation fictive qui générera l’appel fictif durant le test. Votre implémentation de WebServiceMock
appelle la méthode doInvoke
qui retourne la réponse que vous avez spécifiée pour les tests. La plupart de ce code est standard. La partie la plus difficile de cet exercice consiste à imaginer la manière dont le service Web retourne la réponse afin que vous puissiez créer une valeur fictive.
- Dans Developer Console, sélectionnez File (Fichier) | New (Nouveau) | Apex Class (Classe Apex).
- Pour Class Name (Nom de classe), saisissez
CalculatorCalloutMock
, puis cliquez sur OK.
- Remplacez le code généré automatiquement par la définition de classe suivante :
@isTest global class CalculatorCalloutMock implements WebServiceMock { global void doInvoke( Object stub, Object request, Map<String, Object> response, String endpoint, String soapAction, String requestName, String responseNS, String responseName, String responseType) { // start - specify the response you want to send calculatorServices.doAddResponse response_x = new calculatorServices.doAddResponse(); response_x.return_x = 3.0; // end response.put('response_x', response_x); } }
- Appuyez sur CTRL+S pour enregistrer.
Pour terminer, votre méthode test doit demander au runtime Apex d’envoyer la réponse fictive en appelant Test.setMock
avant d’émettre l’appel de la classe AwesomeCalculator
. Tout comme avec l’autre méthode, nous nous assurons que le bon résultat a été reçu par le biais de notre réponse fictive.
- Dans Developer Console, sélectionnez File (Fichier) | New (Nouveau) | Apex Class (Classe Apex).
- Pour Class Name (Nom de classe), saisissez
AwesomeCalculatorTest
, puis cliquez sur OK.
- Remplacez le code généré automatiquement par la définition de classe suivante :
@isTest private class AwesomeCalculatorTest { @isTest static void testCallout() { // This causes a fake response to be generated Test.setMock(WebServiceMock.class, new CalculatorCalloutMock()); // Call the method that invokes a callout Double x = 1.0; Double y = 2.0; Double result = AwesomeCalculator.add(x, y); // Verify that a fake result is returned Assert.areEqual(3.0, result); } }
- Appuyez sur CTRL+S pour enregistrer.
- Pour exécuter le test, sélectionnez Test | Tout exécuter.
La classe AwesomeCalculator
devrait maintenant couvrir 100 % du code !
Ressources
-
Apex Developer Guide: SOAP Services: Defining a Class from a WSDL Document
-
Apex Developer Guide: Tester les appels de service Web
-
Blog des développeurs Salesforce : Announcing the Open-Source WSDL2Apex Generator