Transmettre un proxy à un service SOAP

Vous consultez la documentation d'Apigee Edge.
Consultez la documentation Apigee X.
en savoir plus

Points abordés

Dans ce tutoriel, vous allez apprendre à effectuer les opérations suivantes :

  • Générez un proxy d'API Edge à partir d'un fichier WSDL.
  • Vous devez faire la différence entre un type de proxy SOAP RESTful et un proxy SOAP direct.

Dans ce tutoriel, vous allez apprendre à placer un proxy d'API Edge devant un service Web basé sur le protocole SAML.

Ce tutoriel explique comment générer une nouvelle API RESTful devant votre service basé sur le protocole SOAP. Bien qu'il ne soit pas décrit en détail ici, vous pouvez également générer un proxy de type passthrough qui accepte une charge utile SOAP et la transmet au service de backend.

Ce dont vous avez besoin

  • Un compte Apigee Edge. Si vous n'en avez pas encore, vous pouvez vous inscrire à l'aide des instructions de la section Créer un compte Apigee Edge.

Créer le proxy

Ici, vous demanderez à Edge de générer le proxy qui se placera devant un service SAML. Il existe deux types de proxys d'API SAML:

  • Le type de proxy REST-SOAP-REST génère une nouvelle API RESTful avec une couche de traduction vers le protocole SOAP. Les clients l'appellent comme d'autres services RESTful, en transmettant les paramètres de requête nécessaires au service de backend. Edge traduit cela en la charge utile SOAP attendue par le service.
  • Le type de proxy proxy passthrough permet aux clients de transmettre simplement une charge utile SAML. De cette manière, les appels de service SOAP bénéficient des fonctionnalités de gestion en périphérie.

Périphérie

Pour transmettre par proxy un service SAML à l'aide de l'interface utilisateur Edge:

  1. Connectez-vous à apigee.com/edge.
  2. Sélectionnez Développer > Proxys API dans la barre de navigation de gauche.
  3. Cliquez sur +Proxy.
  4. Cliquez sur ServiceSOAP.
  5. Sur la page "Détails du proxy", saisissez les informations suivantes:

    Champ Description
    Source WSDL

    Sélectionnez: URL

    Copiez et collez l'URL WSLD suivante dans le champ Saisissez une URL:

    https://ws.cdyne.com/delayedstockquote/delayedstockquote.asmx?wsdl

    Clic: Valider

    Apigee Edge récupère le fichier WSDL et le lit pour découvrir la liste des opérations prises en charge par le service SAML.

    Nom

    Ne pas modifier: delayedstockquote

    Il s'agit du nom du proxy d'API que vous créez.

    Chemin de base Ne pas modifier: /delayedstockquote
    Description Ajoutez éventuellement une description, telle que: Code d'API WSDL des cotations boursières
  6. Cliquez sur Suivant.
  7. Sur la page Règles communes, sous Sécurité: Autorisation, sélectionnez Passthrough (aucune autorisation).
  8. Cliquez sur Suivant.
  9. Sur la page Opérations WSDL, sélectionnez REST to SOAP to REST.

    Une fois que vous avez sélectionné le type de proxy, Edge affiche la liste des opérations pour lesquelles il va générer des chemins d'accès à l'API REST. Cette liste vous permet de choisir parmi les opérations trouvées dans le WSDL (si vous recherchez un ensemble spécifique). Notez que le tableau affiche également les ressources qu'un client REST peut utiliser pour appeler le service SAML de backend.

    Conservez toutes les autres sélections sur la page.

  10. Cliquez sur Suivant.
  11. Acceptez les valeurs par défaut de l'hôte virtuel en cliquant sur Next (Suivant).
  12. Sur la page Summary (Résumé), sous "Optional Deployment" (Déploiement facultatif), cliquez sur Test, puis sur Create and deploy (Créer et déployer).

    Edge génère un proxy d'API RESTful et le déploie dans l'environnement test. À partir du WSDL, il détermine les opérations prises en charge par le service, les paramètres d'entrée, etc. Edge suggère la méthode HTTP à utiliser pour chaque opération. En règle générale, Edge traduit les opérations en requêtes GET, qui ont l'avantage de pouvoir être mises en cache. Edge configure également le point de terminaison cible du backend, qui peut varier selon l'opération SAML.

    À moins que vous ne personnalisiez le nouveau proxy d'API (et que vous n'êtes pas dans ce tutoriel), c'est tout ce que vous avez à faire. Vous pouvez passer au test du nouveau proxy d'API.

Classic Edge (cloud privé)

Pour envoyer un proxy à un service SOAP à l'aide de l'interface utilisateur Classic Edge:

  1. Connectez-vous à http://ms-ip:9000, où ms-ip correspond à l'adresse IP ou au nom DNS du nœud du serveur de gestion.
  2. Sélectionnez API > Proxies d'API dans la barre de navigation supérieure.
  3. Cliquez sur + Proxy d'API.
  4. Cliquez sur ServiceSOAP.
  5. Sur la page "Détails du proxy", saisissez les informations suivantes:

    Champ Description
    WSDL

    Sélectionner: Exemple d'URL

    Ensuite, sélectionnez:
    ...delayedstockquote.asmx?WSDL

    Clic: Valider

    Apigee Edge récupère le fichier WSDL et le lit pour découvrir la liste des opérations prises en charge par le service SAML.

    Proxy Name (Nom du proxy)

    Saisissez : delayedstockquote

    Il s'agit du nom du proxy que vous créez.

    Chemin de base du proxy et description Ne modifiez aucune valeur.
  6. Cliquez sur Suivant.
  7. Sur la page WSDL, effectuez les sélections suivantes:
    Dans ce champ procédez comme suit
    Type de proxy d'API

    Sélectionnez: REST to SOAP to REST.

    Une fois que vous avez sélectionné le type de proxy, Edge affiche la liste des opérations pour lesquelles il va générer des chemins d'accès à l'API REST, comme indiqué ici. Cette liste vous permet de choisir parmi les opérations trouvées dans le WSDL (si vous recherchez un ensemble spécifique). Notez que le tableau affiche également les ressources qu'un client REST peut utiliser pour appeler le service SAML de backend.

    Pour l'instant, laissez simplement le premier ensemble d'opérations sélectionné.

    Type de port: DelayedStockCitationsavon Sélectionnez les trois opérations WSDL. Ne modifiez pas les autres paramètres.

  8. Cliquez sur Suivant.
  9. Sur la page "Sécurité", sélectionnez Passthrough (none).
  10. Cliquez sur Suivant.
  11. Acceptez les valeurs par défaut de l'hôte virtuel, puis cliquez sur Next (Suivant).
  12. Sur la page "Build", acceptez les valeurs par défaut et cliquez sur Build and Deploy (Compiler et déployer) pour que Edge commence à générer le proxy.

    Edge génère un proxy d'API RESTful. À partir du WSDL, il détermine les opérations prises en charge par le service, les paramètres d'entrée, etc. Edge suggère la méthode HTTP à utiliser pour chaque opération. En règle générale, Edge traduit les opérations en requêtes GET, qui ont l'avantage de pouvoir être mises en cache. Edge configure également le point de terminaison cible du backend, qui peut varier selon l'opération SAML.

    À moins que vous ne personnalisiez le nouveau proxy (et que vous n'êtes pas dans ce tutoriel), il n'y a rien d'autre à faire. Vous pouvez passer au test du nouveau proxy.

Tester le proxy

Pour tester le proxy que vous avez créé, ouvrez une invite de commande et utilisez cURL. Saisissez la commande ci-dessous, où:

  • ORG est le nom de l'organisation Edge dans laquelle vous avez créé le proxy.
  • "ENV" est l'environnement dans lequel le proxy est déployé.
  • DOMAIN correspond à l'instance Edge que vous utilisez.
curl "https://{ORG}-{ENV}.{DOMAIN}/delayedstockquote/quote?StockSymbol=GOOG&LicenseKey=0"

Par exemple, si votre organisation est docfood, son environnement test et que vous utilisez le cloud d'entreprise Edge, vous devez exécuter une commande semblable à celle-ci:

curl "https://docfood-test.apigee.net/delayedstockquote/quote?StockSymbol=GOOG&LicenseKey=0"

Si vous avez saisi GOOG pour le paramètre de requête StockSymbol, vous devriez obtenir le prix actuel de l'action Alphabet Inc. de classe C. Exemple :

{  
   "GetQuoteResponse":{  
      "GetQuoteResult":{  
         "StockSymbol":"GOOG",
         "LastTradeAmount":819.55,
         "LastTradeDateTime":"2017-02-13T14:33:00",
         "StockChange":5.88,
         "OpenAmount":816.0,
         "DayHigh":820.96,
         "DayLow":815.49,
         "StockVolume":785064,
         "PrevCls":813.67,
         "ChangePercent":"+0.72%",
         "FiftyTwoWeekRange":"663.28 - 841.95",
         "EarnPerShare":27.88,
         "PE":29.4,
         "CompanyName":"Alphabet Inc.",
         "QuoteError":false
      }
   }
}

Obtenir la spécification OpenAPI générée automatiquement

Lorsque vous faites passer un service via un proxy à l'aide de « REST to SOAP to REST », Edge génère automatiquement une spécification OpenAPI. Vous pouvez utiliser la spécification OpenAPI afin de générer la documentation de l'API.

Pour obtenir la spécification OpenAPI, il vous suffit d'accéder à cette URL:

curl https://{ORG}-{ENV}.{DOMAIN}/delayedstockquote/openapi.json

Crédit supplémentaire: comment savoir quels paramètres de ressource, de verbe et de requête utiliser ?

Dans l'appel d'API de test, vous avez utilisé une ressource et des paramètres de requête spécifiques dans votre appel cURL au service SOAP de backend. Mais comment le découvririez-vous par vous-même ?

Ressource et verbe

Dans l'assistant de proxy d'API, lors de la création du proxy, vous avez vu comment les opérations SOAP étaient mappées avec les verbes et les ressources de l'API. Toutefois, si vous ne les avez pas notifiés, voici comment vous en informeriez une fois le proxy créé.

Dans l'onglet Develop (Développer) du proxy d'API, le volet de navigation de gauche contient une liste de flux sous les points de terminaison du proxy. Cliquez sur le flux qui vous intéresse. Par exemple, le flux GetQuote est un bon candidat. Ensuite, affichez le code XML dans le volet "Code", qui indique le chemin d'accès à la ressource et le verbe du flux dans l'élément <Condition> : /quote et GET.

Paramètres de requête

Après avoir sélectionné le flux GetQuote, cliquez sur la première règle de la vue de flux graphique. Il doit s'agir d'une règle d'extraction de variables qui capture les paramètres de requête devant être transmis: StockSymbol et LicenseKey. Si vous recherchez le service SOAP sur le Web, vous y trouverez les éléments à transmettre pour la clé de licence.

Les paramètres de requête capturés sont enregistrés en tant que variables et utilisés par la règle suivante pour créer le message SOAP.