Suivez votre progression
Accueil Trailhead
Accueil Trailhead

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.

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. Vous êtes les bienvenus.

Remarque

Remarque

Si possible, utilisez des messages sortants pour gérer les solutions d’intégration. N’utilisez des appels de service Web tiers que si cela est vraiment nécessaire.

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.xml 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

  1. Dans Configuration, entrez Classes Apex dans la zone Recherche rapide puis cliquez sur Classes Apex.
  2. Cliquez sur Générer à partir du WSDL.
  3. Cliquez sur Choisir un fichier et sélectionnez le fichier calculator.xml téléchargé.
  4. Cliquez sur Analyser le WSDL. L’application génère un nom de classe par défaut pour chaque espace de noms du 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.

  5. Cliquez sur 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.

  1. Ouvrez la Developer Console depuis l’icône Configuration (Icône d’engrenage Configuration).
  2. Dans la Developer Console, sélectionnez Débogage | Ouvrir la fenêtre d’exécution anonyme.
  3. Supprimez tout le code existant et insérez l’extrait suivant :
    calculatorServices.CalculatorImplPort calculator = new  calculatorServices.CalculatorImplPort();
    Double x = 1.0;
    Double y = 2.0;
    Double result = calculator.doAdd(x,y);
    System.debug(result);
  4. Sélectionnez Ouvrir le journal, puis cliquez sur Exécuter.
  5. Une fois le journal de débogage ouvert, cliquez sur Débogage uniquement pour afficher la sortie des instructions System.debug. Le journal devrait afficher 3.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 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.

  1. Dans la Developer Console, sélectionnez Fichier | Nouveau | Classe Apex.
  2. Entrez AwesomeCalculator comme nom de classe puis cliquez sur OK.
  3. 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);
        }
    }
  4. 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.

  5. Dans la Developer Console, sélectionnez Fichier | Nouveau | Classe Apex.
  6. Entrez CalculatorCalloutMock comme nom de classe puis cliquez sur OK.
  7. 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); 
       }
    }
  8. 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.

  9. Dans la Developer Console, sélectionnez Fichier | Nouveau | Classe Apex.
  10. Entrez AwesomeCalculatorTest comme nom de classe puis cliquez sur OK.
  11. 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
            System.assertEquals(3.0, result); 
        }
    }
  12. Appuyez sur CTRL+S pour enregistrer.
  13. Pour exécuter le test, sélectionnez Test | Tout exécuter.

La classe AwesomeCalculator devrait maintenant couvrir 100 % du code !

Ressources

Remarque

Remarque

N’oubliez pas que ce module est conçu pour Salesforce Classic. Lorsque vous lancez votre organisation d’exercice, basculez vers Salesforce Classic pour relever ce défi.