Tester les API personnalisées

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

Tester 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 système 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 du 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 votre ID client dans la section OAuth Consumer.
  8. Ajoutez un paramètre de chaîne de requête à l'URL endpoint de jeton SSO que vous avez collée dans votre navigateur Web au format?clientID=[YourClientID], puis appuyez sur la touche Entrée. Voici un exemple d'URL :
    https://<YourSSOTokenEndpointURL>?clientID=<yourClientID>
    Le navigateur affiche un jeton OAuth d'accès avec connexion unique (SSO).
  9. Dans la fenêtre back-end mobile, cliquez sur la page API, située dans la navigation de gauche. Le navigateur Web passe de la page Paramètres à la page API.
  10. Cliquez sur Sélectionner des API.
  11. Cliquez sur le nom d'API à tester. Une nouvelle page apparaît ; elle contient les adresses d'API dans la navigation à gauche, ainsi que les onglets Demande et Réponse.
  12. Cliquez sur l'adresse que vous voulez tester.
  13. Sous la section Authentification, sélectionnez Jeton d'accès avec connexion unique (SSO) 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 (SSO).
  15. Cliquez sur Adresse de test. Si tout est correct, le serveur répond avec le statut 200 et les données JSON sont affichées dans la réponse.

Test des adresses d'API à l'aide des données de simulation

Vous pouvez fournir des données de simulation dans les corps de message de demande et de réponse lors de la phase de conception de la configuration de votre API. Vous pouvez ainsi examiner le contexte de chaque appel sans avoir à utiliser des données en temps réel ni à 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 la 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 certains autres aspects de la méthode.

Dans l'exemple FixItFast, les données de simulation du corps de la réponse 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 services peut créer pour le corps de la 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 la simulation vous permet d'appeler l'API à partir de votre application mobile avant d'implémenter le code personnalisé. Cela vous permet de développer et tester simultanément les applications mobiles et le code personnalisé. Si la configuration vous convient, vous pouvez ajouter une implémentation réelle.

Tant que vous n'avez pas créé votre première implémentation, l'implémentation par défaut est l'implémentation de simulation. Une fois une implémentation réelle créée, elle devient l'implémentation par défaut de l'API.

Cliquez sur le lien de navigation Implémentations afin de télécharger une implémentation ou de visualiser les implémentations existantes. Vous pouvez modifier l'implémentation par défaut dans la page Implémentations. Après avoir 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 l'API de connecteur REST et enregistré la configuration, vous voudrez vérifier que vous êtes en mesure d'envoyer une demande et de recevoir les résultats attendus à partir du service Web. Le test d'une connexion est une étape facultative mais vous pouvez gagner du temps en identifiant et en corrigeant les problèmes maintenant avant de finaliser l'API de connecteur. La page Test 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 indiqué des métadonnées de descripteur, le mode de test standard apparaît. Il permet de générer les corps de demande et de réponse à partir des métadonnées descriptives, et de les afficher dans les onglets Demande et Réponse. Il suffit de sélectionner les paramètres à tester pour les méthodes GET et d'inclure tous les en-têtes HTTP avec lesquels effectuer le test.

  • Test avancé

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

Tester en mode avancé

La page de test avancé vous permet de définir manuellement des paramètres de chemin, d'ajouter des en-têtes et les données traitées 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 indiqué un descripteur, sélectionnez Tester en mode avancé sur On.

    La page de test avancé s'affiche automatiquement si vous avez indiqué 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éfixé par l'URI local que vous avez défini lorsque vous avez entré un nom d'API. Voici un exemple du contenu complet du champ :

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

    Si vous avez défini des règles, le champ Règles appliquées (sous le champ Corps) affiche les nombres 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 au moins un en-tête HTTP de demande ou de réponse selon vos besoins.

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

  6. Cliquez dans le champ Corps HTTP pour créer le corps de message (données traitées) dans l'éditeur source.
    Par exemple :
    {
      "status":"ZERO_RESULTS",
      "routes":[ ]
    }

    Conservez le contenu du corps du message pertinent pour l'objectif du connecteur, c'est-à-dire ne pas lier le message en ajoutant des données supplémentaires. L'intégration 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 vous connectez nécessite une authentification, ouvrez la section Authentification et entrez vos informations d'identification d'utilisateur mobile pour chaque méthode que vous testez. Si vous utilisez les informations d'identification de test par défaut, vous pouvez ignorer cette étape.

    Grâce aux stratégies de sécurité SAML, l'identité de l'utilisateur effectuant l'appel est propagée au 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 devez peut-être entrer des informations d'identification spécifiques pour chaque opération, ou vous pouvez utiliser un ensemble d'informations d'identification pour toutes les méthodes afin d'authentifier votre connecteur auprès du service.

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

    Ces informations d'identification de test par défaut sont persistantes pour toutes les méthodes que vous testez. Ils restent valides pendant la session Mobile Cloud en cours.

  10. Cliquez sur Adresse de test.

    L'adresse de test bascule sur Annuler le test lorsque vous cliquez dessus. Si vous voulez 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 fini de tester vos adresses.