Tester les API personnalisées

Dans Oracle Mobile Hub, vous pouvez tester vos API personnalisées avant leur déploiement à l'aide de données fictives. Vous pouvez également tester vos connecteurs REST à l'aide de la page de test qui prend en charge deux modes : Test standard et Test avancé.

Test d'une API personnalisée Oracle Mobile Hub

Pour tester votre API personnalisée directement à partir d'Oracle Mobile Hub, procédez comme suit :

  1. Connectez-vous à Oracle Mobile Hub.
  2. Cliquez sur l'icône de menu, puis développez Développement et cliquez sur Back-ends.
  3. Sélectionnez le back-end mobile et cliquez sur Ouvrir.
  4. Cliquez sur Paramètres dans la barre de navigation de gauche.
  5. Copiez l'URL à partir de l'adresse de jeton SSO située sous URL d'environnement.
  6. Collez l'URL copiée dans une fenêtre de navigateur Web, mais n'appuyez pas sur la touche Entrée.
  7. Copiez l'ID client situé sous la section Consommateur OAuth.
  8. Ajoutez un paramètre de chaîne de requête à l'URL endpoint du jeton SSO collée dans votre navigateur Web au format ?clientID=[YourClientID], puis appuyez sur la touche Entrée. Exemple d'URL :
    https://<YourSSOTokenEndpointURL>?clientID=<yourClientID>
    Le navigateur affiche un jeton OAuth d'accès avec connexion unique.
  9. Dans la fenêtre de back-end mobile, cliquez sur la page des API située dans la navigation de gauche. Le navigateur passe de la page Paramètres à la page API.
  10. Cliquez sur Sélectionner des API.
  11. Cliquez sur le nom de l'API à tester. Une nouvelle page s'ouvre. Elle affiche les adresses d'API dans la navigation de gauche, ainsi que les onglets Demande et Réponse.
  12. Cliquez sur l'adresse à tester.
  13. Dans la section Authentification, sélectionnez Jeton d'authentification unique dans la méthode d'authentification.
  14. Copiez le jeton OAuth SSO et collez-le dans le champ Jeton d'accès avec connexion unique.
  15. Cliquez sur Adresse de test. Si tout est correct, le serveur répond avec le statut 200 et vous devez voir les données JSON dans la réponse.

Tester les adresses d'API à l'aide de données de simulation

Vous pouvez fournir des données de simulation dans vos corps de message de demande et de réponse pendant la phase de conception de votre configuration d'API. Cela vous permet d'examiner le contexte de chaque appel sans avoir à utiliser des données en temps réel ou à interagir avec un service en temps réel. Par exemple, pour vérifier si votre code gère correctement un ID non valide, vous pouvez ajouter un exemple dans le corps de votre demande avec des données de simulation contenant un ID non valide. Lorsque vous avez terminé le test, vous pouvez remplacer l'exemple par un autre code pour tester un autre aspect de la méthode.

Dans l'exemple FixItFast, les données de simulation dans le corps de la réponse vous permettent de vérifier si les informations client correctes sont renvoyées. Voici un exemple de données de simulation que le développeur de service pourrait créer pour le corps de réponse de l'opération POST de la ressource contact dans l'exemple FixItFast :
{
 "id": 20934,
 "title": "Lynn's Leaking Water Heater",
       "contact": {
       "name": "Lynn Adams",
       "street": "45 O'Connor Street",
       "city": "Ottawa",
       "postalcode": "ala1a1"
       "username":"johneta"
       }
 "status": "new",
 "driveTime": 30,
 "priority": "high",
 "createdon": "2015-04-23 18:12:03 EDT"
}

Lorsque vous créez une API personnalisée, une implémentation de simulation est créée automatiquement. L'implémentation de simulation vous permet d'appeler l'API à partir de votre application mobile avant d'implémenter le code personnalisé. Vous pouvez ainsi développer et tester simultanément les applications mobiles et le code personnalisé. Si vous êtes satisfait de la configuration, vous pouvez ajouter une implémentation réelle.

Jusqu'à ce que vous créiez votre première implémentation, l'implémentation par défaut est l'implémentation factice. Une fois que vous avez créé une implémentation réelle, elle devient l'implémentation par défaut de l'API.

Cliquez sur le lien de navigation Implémentations pour télécharger une implémentation ou voir les implémentations existantes. Vous pouvez modifier l'implémentation par défaut sur la page Implémentations. Une fois que vous avez téléchargé une implémentation, vous voyez la liste des implémentations existantes, qui inclut l'implémentation de simulation.

Tester l'API de connecteur REST

Maintenant que vous avez défini votre API de connecteur REST et enregistré la configuration, vous devez vérifier que vous êtes en mesure d'envoyer une demande et de recevoir les résultats attendus du service Web. Le test d'une connexion est une étape facultative, mais vous pouvez gagner du temps en identifiant et en résolvant les problèmes dès maintenant avant de finaliser l'API de connecteur. La page Test vous permet de tester une adresse à la fois.

Si vous avez fourni un descripteur, vous avez le choix entre deux modes de test :

  • Test standard

    Si vous avez fourni des métadonnées de descripteur, le mode de test standard est affiché dans lequel les corps de demande et de réponse sont générés à partir des métadonnées descriptives et affichés dans les onglets Demande et Réponse. Il vous suffit de sélectionner les paramètres à tester pour les méthodes GET et d'inclure les en-têtes HTTP avec lesquels vous souhaitez effectuer le test.

  • Tests avancés

    Vous pouvez affiner vos tests en sélectionnant Test en mode avancé (mode de test que vous entrez si vous avez fourni une URL de service distant). Sans métadonnées descriptives, vous sélectionnez la méthode et la ressource à tester, vous incluez les en-têtes HTTP à inclure et vous créez manuellement le corps JSON.

Tester en mode avancé

La page de test avancé vous permet de définir manuellement les paramètres de chemin, d'ajouter des en-têtes, ainsi que les charges utiles de demande et de réponse.

Pour configurer manuellement un test de connecteur, procédez comme suit :

  1. Cliquez sur le lien de navigation Tester.
  2. Si vous avez fourni un descripteur, sélectionnez Tester en mode avancé sur On.

    La page de test avancé s'affiche automatiquement si vous avez fourni une URL de service distant.

  3. Sélectionnez la méthode HTTP à tester dans la liste déroulante.
  4. Indiquez les paramètres de chemin de ressource dans le champ URI local si nécessaire à des fins de test. Par exemple :
    directions/json?origin=los+angeles&destination=seattle

    Le champ est automatiquement précédé de l'URI local que vous avez défini lorsque vous avez entré un nom d'API. Dans notre exemple, le contenu complet du champ se présente comme suit :

    myMapAPI /directions/json?origin=los+angeles&destination=seattle

    Notez que si vous avez défini des règles, le champ Règles appliquées (sous le champ Corps) affiche les numéros correspondant aux règles applicables à l'opération sélectionnée. Le champ URL distante affiche la chaîne exacte qui sera transmise au service pour le test.

  5. Ajoutez des en-têtes HTTP de demande ou de réponse si nécessaire.

    Ces en-têtes sont à des fins de test uniquement et ne seront pas ajoutés à votre configuration d'API de connecteur REST.

  6. Cliquez dans le champ Corps HTTP pour créer le corps du message (la charge utile) dans l'éditeur source.
    Exemple :
    {
      "status":"ZERO_RESULTS",
      "routes":[ ]
    }

    Gardez le contenu du corps du message pertinent pour l'objectif du connecteur, c'est-à-dire ne gonflez pas le message en ajoutant des données inutiles. L'inclusion de données pertinentes uniquement dans le corps du message facilite la transmission rapide de la demande ou de la réponse.

  7. Si le service auquel vous êtes connecté nécessite une authentification, ouvrez la section Authentification et entrez vos informations d'identification utilisateur mobile pour chaque méthode testée. Si vous utilisez des informations d'identification de test par défaut, vous pouvez ignorer cette étape.

    Avec les stratégies de sécurité basées sur SAML, l'identité de l'utilisateur qui effectue l'appel est propagée vers le service externe. Pour les autres stratégies de sécurité telles que l'authentification de base HTTP et le jeton de nom utilisateur, les informations d'identification utilisées pour l'authentification auprès du service externe sont fournies dans les remplacements de stratégie en tant que clés CSF. Selon l'opération que vous avez définie, vous devrez peut-être saisir des informations d'identification spécifiques pour chaque opération ou vous pourrez utiliser un ensemble d'informations d'identification pour toutes les méthodes d'authentification de votre connecteur auprès du service.

  8. Cliquez sur Enregistrer en tant qu'informations d'identification par défaut du back-end mobile en cours pour enregistrer le nom utilisateur et le mot de passe que vous indiquez comme valeur par défaut.
  9. Si vous êtes en phase de conception de la création du connecteur et que vous voulez simplement voir si vos adresses sont valides, cliquez sur Informations d'identification de test du concepteur d'API par défaut et sélectionnez un back-end mobile avec lequel vous êtes inscrit, ainsi que son numéro de version.
    Vous pouvez éventuellement saisir vos informations d'identification utilisateur mobile (nom utilisateur et mot de passe).

    Ces informations d'identification de test par défaut sont conservées dans toutes les méthodes que vous testez. Elles restent valides pendant la session Mobile Hub en cours.

  10. Cliquez sur Adresse de test.

    L'adresse de test bascule sur Annuler le test lorsque vous cliquez dessus. Si vous souhaitez arrêter le test pour une raison quelconque, cliquez sur Annuler le test.

    Cliquez sur Réinitialiser pour effacer les champs et modifier les paramètres de test.

  11. Cliquez sur Terminé lorsque vous avez terminé de tester vos adresses.