Skip to main content
Build the future with Agentforce at TDX in San Francisco or on Salesforce+ on March 5–6. Register now.

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

Remarque

Vous souhaitez apprendre en français ? Commencez le défi dans un Trailhead Playground en français et utilisez les traductions fournies entre crochets pour naviguer. Copiez et collez uniquement les valeurs en anglais, car les validations de défi reposent sur les données en anglais. Si vous ne réussissez pas le défi dans votre organisation en français, nous vous recommandons (1) de définir le paramètre régional sur les États-Unis, (2) de définir la langue sur l’anglais en suivant les instructions ici, puis (3) de cliquer à nouveau sur le bouton « Vérifier le défi ».

Consultez le badge Trailhead dans votre langue pour découvrir comment profiter de l’expérience Trailhead traduite.

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.

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

  1. Dans Setup (Configuration), saisissez Apex Classes (Classes Apex) dans la zone Quick Find (Recherche rapide), puis cliquez sur Apex Classes (Classes Apex).
  2. Cliquez sur Générer à partir du WSDL.
  3. Cliquez sur Choisir un fichier et sélectionnez le fichier calculator.wsdl téléchargé.
  4. 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.
  5. 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.

  1. Ouvrez la Developer Console depuis Setup (Configuration) (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);
    Vous remarquerez l’implémentation de la classe calculatorServices avec calculatorServices.CalculatorImplPort. Les classes créées via Generate from WSDL (Générer à partir du WSDL) ont toujours une méthode comportant le suffixe ImplPort.
  4. Sélectionnez Ouvrir le journal, puis cliquez sur Exécuter.
  5. 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 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 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.

  1. Dans Developer Console, sélectionnez File (Fichier) | New (Nouveau) | Apex Class (Classe Apex).
  2. Pour Class Name (Nom de classe), saisissez AwesomeCalculator, 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.

  1. Dans Developer Console, sélectionnez File (Fichier) | New (Nouveau) | Apex Class (Classe Apex).
  2. Pour Class Name (Nom de classe), saisissez CalculatorCalloutMock, puis cliquez sur OK.
  3. 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);
   }
}
  4. 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.

  1. Dans Developer Console, sélectionnez File (Fichier) | New (Nouveau) | Apex Class (Classe Apex).
  2. Pour Class Name (Nom de classe), saisissez AwesomeCalculatorTest, puis cliquez sur OK.
  3. 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);
    }
}
  4. Appuyez sur CTRL+S pour enregistrer.
  5. Pour exécuter le test, sélectionnez Test | Tout exécuter.

La classe AwesomeCalculator devrait maintenant couvrir 100 % du code !

Ressources

Partagez vos commentaires sur Trailhead dans l'aide Salesforce.

Nous aimerions connaître votre expérience avec Trailhead. Vous pouvez désormais accéder au nouveau formulaire de commentaires à tout moment depuis le site d'aide Salesforce.

En savoir plus Continuer à partager vos commentaires