GSP363

Présentation

Dans un atelier challenge, vous devez suivre un scénario et effectuer une série de tâches. Aucune instruction détaillée n'est fournie : vous devez utiliser les compétences acquises au cours des ateliers du cours correspondant pour déterminer comment procéder par vous-même. Vous saurez si vous avez exécuté correctement les différentes tâches grâce au score calculé automatiquement (affiché sur cette page).

Lorsque vous participez à un atelier challenge, vous n'étudiez pas de nouveaux concepts Google Cloud. Vous allez approfondir les compétences précédemment acquises. Par exemple, vous devrez modifier les valeurs par défaut ou encore examiner des messages d'erreur pour corriger vous-même les problèmes.

Pour atteindre le score de 100 %, vous devez mener à bien l'ensemble des tâches dans le délai imparti.

Cet atelier est recommandé aux participants ayant terminé les ateliers du cours Développer et sécuriser des API avec Apigee X. Êtes-vous prêt pour le challenge ?

Préparation

Avant de cliquer sur le bouton "Démarrer l'atelier"

Lisez ces instructions. Les ateliers sont minutés, et vous ne pouvez pas les mettre en pause. Le minuteur, qui démarre lorsque vous cliquez sur Démarrer l'atelier, indique combien de temps les ressources Google Cloud resteront accessibles.

Cet atelier pratique vous permet de suivre les activités dans un véritable environnement cloud, et non dans un environnement de simulation ou de démonstration. Des identifiants temporaires vous sont fournis pour vous permettre de vous connecter à Google Cloud le temps de l'atelier.

Pour réaliser cet atelier :

• Vous devez avoir accès à un navigateur Internet standard (nous vous recommandons d'utiliser Chrome).

• Vous disposez d'un temps limité. N'oubliez pas qu'une fois l'atelier commencé, vous ne pouvez pas le mettre en pause.

Scénario du challenge

Vous êtes ingénieur cloud chez Cymbal Shops, une enseigne nationale. Cymbal Shops se concentre sur les ventes à l'international, et les services de traduction ont été identifiés comme un outil clé pour développer l'activité à l'échelle mondiale. On vous demande dans ce contexte de créer la première version d'une API de traduction.

Vous êtes censé avoir les compétences et les connaissances requises pour ces tâches. Par conséquent, aucune instruction détaillée ne vous est fournie.

Votre challenge

Vous allez créer un proxy d'API Apigee et d'autres ressources dans l'organisation Apigee du projet. Lisez attentivement la description de chaque tâche, puis créez la fonctionnalité requise.

Erreurs d'enregistrement

Lorsque vous enregistrez des modifications apportées à votre proxy d'API, l'erreur Could not save new revision (Impossible d'enregistrer la nouvelle révision) peut s'afficher. Si vous utilisez le bouton de menu déroulant "Enregistrer" (), puis sélectionnez Enregistrer en tant que nouvelle révision, un message d'erreur devrait s'afficher pour vous indiquer ce qui n'est pas valide.

Tâche 1 : Créer le proxy d'API Cloud Translation

Cymbal Shops a décidé d'utiliser l'API Translation de Google Cloud comme service de backend pour le proxy d'API.

Exigences :

1. Dans la console Google Cloud, vérifiez que l'API Cloud Translation est activée dans la Bibliothèque d'API.
2. Créez un compte de service pour le proxy d'API nommé apigee-proxy et attribuez-lui le rôle Journalisation > Rédacteur de journaux.
3. Dans la console Google Cloud, sélectionnez Apigee dans le menu de navigation pour ouvrir l'UI Apigee et créer votre proxy d'API.
4. Le proxy d'API doit être un proxy inverse nommé translate-v1, avec un chemin de base /translate/v1.
5. La cible du proxy d'API est l'URL HTTP de la version de base de l'API Cloud Translation (https://translation.googleapis.com/language/translate/v2).
6. N'ajoutez pas d'autorisation, de CORS ni de quota à l'aide de la page "Règles courantes" de l'assistant de création de proxy.
7. Sur la page récapitulative, créez le proxy d'API en conservant les paramètres par défaut.
8. Ajoutez une section "Authentication" au TargetEndpoint par défaut, ce qui entraîne l'envoi d'un jeton d'accès avec chaque requête de backend. Utilisez un élément GoogleAccessToken avec un niveau d'accès de https://www.googleapis.com/auth/cloud-translation.

9. Utilisez le script Cloud Shell suivant pour vérifier que l'environnement d'exécution Apigee est complètement installé :

Lorsque le script renvoie ORG IS READY TO USE, vous pouvez passer aux étapes suivantes.

10. Enregistrez et déployez le proxy translate-v1 dans l'environnement eval à l'aide du compte de service suivant :

11. Testez le proxy d'API.

L'environnement "eval" de l'organisation Apigee peut être appelé à l'aide du nom d'hôte eval.example.com. Cette entrée DNS n'est disponible que sur le réseau interne. Vous devez donc utiliser une VM qui a été créée pour vous.

12. Dans Cloud Shell, ouvrez une connexion SSH vers apigeex-test-vm :

13. Si vous êtes invité à donner votre autorisation, cliquez sur Autoriser. Pour chaque question posée dans la commande gcloud, appuyez sur Entrée ou sur Retour pour spécifier la valeur par défaut.

14. Une fois la tâche 1 terminée, la commande curl suivante devrait traduire le texte :

La réponse doit ressembler à ceci :

Cliquez sur Vérifier ma progression pour valider l'objectif. Créer un proxy pour l'API Cloud Translation

Tâche 2 : Modifier la requête API et sa réponse

Cymbal Shops souhaite créer une API avec une interface différente de celle fournie par l'API Translation. À cet effet, deux appels de l'API Translation doivent être modifiés.

Le premier appel récupère la liste des langues valides.

Requête API Cloud Translation :

Réponse de l'API Cloud Translation :

Requête translate-v1 :

Réponse de translate-v1 :

Le proxy d'API doit remplacer GET par POST, supprimer les champs de réponse data et languages, et obtenir le code de la langue cible à partir d'un ensemble de propriétés. Le jeton d'accès a été ajouté automatiquement par la section Authentication de la tâche 1.

Le deuxième appel traduit le texte dans une langue spécifiée.

Requête API Cloud Translate :

Réponse de l'API Cloud Translate :

Requête translate-v1 :

Réponse de translate-v1 :

Le proxy d'API doit extraire la langue cible du paramètre de requête lang et modifier les noms de champs pour le texte entrant et le texte traduit. Le paramètre de requête lang peut être omis de la requête translate-v1. Dans ce cas, la langue cible sera extraite d'une propriété de l'ensemble de propriétés.

Exigences :

1. Dans le proxy d'API, créez un ensemble de propriétés nommé language.properties. Celui-ci doit comporter deux propriétés : output avec la valeur es et caller avec la valeur en. La propriété caller est utilisée pour spécifier la langue cible lorsque les langues sont listées (la langue utilisée pour le champ name). Quant à la propriété output, elle spécifie la langue cible par défaut à utiliser si le paramètre de requête lang n'est pas fourni.

2. Dans le point de terminaison du proxy, créez un flux conditionnel de chemin d'accès et de verbe pour la ressource POST /. Nommez-le translate.

3. Dans le point de terminaison du proxy, créez un flux conditionnel de chemin d'accès (sans verbe) pour la ressource /languages. Nommez-le getLanguages. [N'incluez pas de verbe. Vous allez modifier le verbe de la requête, qui passera de GET (pour l'entrée du proxy) à POST (requis par le backend). Si vous incluez un verbe dans la condition, les règles de réponse du flux ne s'exécutent pas, car request.verb n'est plus égal à GET.]

4. Créez une règle AssignMessage nommée AM-BuildTranslateRequest pour créer la requête de backend utilisée dans le flux conditionnel translate.

Contenu et caractéristiques de la règle :

• Une section AssignVariable avec un modèle permettant de créer des variables qui seront utilisées ultérieurement dans un message journalisé. La variable text doit utiliser la fonction de modèle de message jsonPath pour extraire le champ text de la requête.

• La variable language doit être créée à l'aide de la fonction de modèle de message firstnonnull. Cette variable doit contenir la valeur de paramètre de requête lang, le cas échéant, et la propriété output de l'ensemble de propriétés linguistiques pour la langue cible si le paramètre de requête lang n'a pas été spécifié.

• Une section Set doit être utilisée pour définir la charge utile JSON requise par le service de backend. Les deux variables que vous avez créées seront utilisées dans la charge utile.

• L'élément [AssignTo] doit utiliser le message de requête existant.

  Les sections AssignVariable de la règle AssignMessage doivent ressembler à ceci :

  <AssignVariable> <Name>...</Name> <Template>...</Template> <AssignVariable>

5. Créez une règle AssignMessage nommée AM-BuildTranslateResponse sous le flux conditionnel translate afin de créer la réponse pour l'appelant en utilisant la réponse de l'API Translation.

Contenu et caractéristiques de la règle :

• Une section AssignVariable avec un modèle jsonPath pour créer une variable nommée translated, qui extrait le champ translatedText de la réponse de l'API Translation. Conseil : l'expression JSONPath permettant d'extraire ce champ est $.data.translations[0].translatedText.

• Définissez createNew sur "true".

• La nouvelle charge utile JSON utilisera la variable translated.

  Les sections AssignVariable de la règle AssignMessage doivent ressembler à ceci :

  <AssignVariable> <Name>...</Name> <Template>...</Template> <AssignVariable>

6. Créez une règle AssignMessage nommée AM-BuildLanguagesRequest pour créer la requête de backend utilisée dans le flux conditionnel getLanguages.

Contenu et caractéristiques de la règle :

• Utilisez Set pour définir le verbe et la charge utile appropriés pour la requête de backend.

• La propriété caller de l'ensemble de propriétés language doit être utilisée pour le champ target dans la charge utile du backend.

• Définissez createNew sur "true".

• Définissez la charge utile de la requête de backend sur un type de contenu application/json.

  Les sections AssignVariable de la règle AssignMessage doivent ressembler à ceci :

  <AssignVariable> <Name>...</Name> <Set> ... </Set> </AssignVariable>

7. Créez une règle JavaScript nommée JS-BuildLanguagesResponse sous le flux conditionnel getLanguages pour créer la réponse pour l'appelant. Suivez ces étapes pour écrire le code JavaScript :

• Utilisez context.getVariable pour récupérer la variable response.content.
• Utilisez JSON.parse pour convertir le JSON response.content en objet.
• Utilisez JSON.stringify pour convertir le champ data.languages de l'objet en JSON.
• Utilisez context.setVariable pour remplacer response.content par le JSON de l'étape 3.

Votre code JavaScript doit ressembler à ceci :

8. Testez l'API. À partir de la machine virtuelle apigeex-test-vm, utilisez les commandes curl suivantes pour tester les exemples ci-dessus :

• Liste des langues :

  curl -i -k -X GET "https://eval.example.com/translate/v1/languages"

• Traduire dans la langue spécifiée (allemand) :

  curl -i -k -X POST "https://eval.example.com/translate/v1?lang=de" -H "Content-Type:application/json" -d '{ "text": "Hello world!" }'

• Traduire dans la langue par défaut (espagnol) :

  curl -i -k -X POST "https://eval.example.com/translate/v1" -H "Content-Type:application/json" -d '{ "text": "Hello world!" }'

Cliquez sur Vérifier ma progression pour valider l'objectif. Modifier la requête API et sa réponse

Tâche 3 : Ajouter la vérification des clés API et l'application de quotas

L'accès à cette API doit être limité aux applications approuvées. Vous allez donc ajouter une règle de vérification de la clé API, ainsi qu'une règle de quotas pour limiter le nombre de requêtes.

Exigences :

1. Créez un produit d'API avec le nom et le nom à afficher translate-product. Ce produit d'API doit être publiquement accessible, approuver automatiquement les demandes d'accès et être disponible dans l'environnement "eval".

2. Ajoutez une opération au produit d'API translate-product. Cette opération doit autoriser l'accès au proxy translate-v1 et utiliser un chemin d'accès /, qui autorise l'accès à toute requête, y compris /. Les méthodes autorisées sont GET et POST. Ajoutez un paramètre de quota d'opération de 10 requêtes par minute.

3. Créez un développeur avec l'adresse e-mail joe@example.com. Choisissez votre propre prénom, nom et nom d'utilisateur.

4. Créez une application nommée translate-app et activez le produit d'API translate-product pour celle-ci. Vous devrez l'associer à votre développeur joe@example.com.

5. Ajoutez une règle VerifyAPIKey nommée VA-VerifyKey au PreFlow du point de terminaison du proxy. La clé API doit être requise pour chaque requête et doit être envoyée à l'aide de l'en-tête Key.

6. Ajoutez une règle de quotas nommée Q-EnforceQuota au PreFlow du point de terminaison du proxy.

Voici les étapes à inclure pour cette règle :

• Utilisez un type calendar. Le type calendar nécessite un élément StartTime.
• Spécifiez UseQuotaConfigInAPIProduct pour utiliser le quota du produit d'API, avec un quota par défaut de cinq requêtes par heure si le produit d'API ne spécifie pas de paramètres de quota.
• Définissez Distributed et Synchronous sur "true", puis supprimez l'élément AsynchronousConfiguration.

Une fois ces modifications apportées, la requête doit renvoyer une erreur si aucune clé API valide n'est spécifiée dans l'en-tête "Key".

7. À partir de la machine virtuelle apigeex-test-vm, utilisez les commandes curl suivantes pour tester la fonctionnalité de la clé API :

• Échec (aucune clé API) :

  curl -i -k -X POST "https://eval.example.com/translate/v1?lang=de" -H "Content-Type:application/json" -d '{ "text": "Hello world!" }'

• Échec (clé API non valide) :

  curl -i -k -X POST "https://eval.example.com/translate/v1?lang=de" -H "Content-Type:application/json" -H "Key: ABC123" -d '{ "text": "Hello world!" }'

• Succès (lorsque la variable KEY est définie sur une clé API valide KEY=<valeur obtenue à l'étape précédente lors de la configuration d'une application de développeur>) :

  curl -i -k -X POST "https://eval.example.com/translate/v1?lang=de" -H "Content-Type:application/json" -H "Key: $KEY" -d '{ "text": "Hello world!" }'

Cliquez sur Vérifier ma progression pour valider l'objectif. Ajouter la vérification des clés API et l'application de quotas

Tâche 4 : Ajouter la journalisation des messages

Pour comprendre l'utilisation du service de traduction, une règle de journalisation des messages enregistrera chaque message traduit.

Exigences :

1. Ajoutez une règle de journalisation des messages nommée ML-LogTranslation au flux conditionnel translate. La règle doit s'exécuter après l'étape AM-BuildTranslateResponse.

2. La règle doit consigner les journaux dans Cloud Logging. Consultez la documentation sur les règles.

• La valeur LogName doit être :

  projects/{organization.name}/logs/translate

• Le message consigné doit avoir un contentType de text/plain et le contenu du message doit être le suivant :

  {language}|{text}|{translated}

Ce message nécessite les variables language, text et translated créées dans les règles AM-BuildTranslateRequest et AM-BuildTranslateResponse.

3. Validez les messages consignés sur la page Journalisation de la console Google Cloud. Utilisez la requête logName : "translate" pour n'afficher que les journaux traduits.

4. Une fois la règle de journalisation des messages ajoutée, utilisez cette commande curl :

• Elle devrait créer un message de journal contenant :

  de|Hello world!|Hallo Welt!

Cliquez sur Vérifier ma progression pour valider l'objectif. Ajouter la journalisation des messages

Tâche 5 : Réécrire un message d'erreur de backend

Lorsque le paramètre target envoyé à l'API Translation n'est pas valide, un message d'erreur 400 (requête incorrecte) est renvoyé :

Ce message d'erreur serait déroutant pour l'appelant. Vous allez donc le réécrire.

Exigences :

1. Ajoutez une section FaultRules au point de terminaison cible par défaut. Lorsque le backend renvoie une réponse 400, il évalue automatiquement toutes les règles d'erreur correspondantes dans le point de terminaison cible.

2. Ajoutez une règle FaultRule à la section FaultRules. La condition de cette règle FaultRule doit être définie de sorte qu'elle s'exécute si fault.name est ErrorResponseCode.

3. Créez une règle AssignMessage nommée AM-BuildErrorResponse et associez-la à la règle FaultRule. Utilisez cette configuration de règle :

Une fois la règle associée, votre section FaultRules dans le point de terminaison cible doit se présenter comme suit :

4. Testez l'API.

• Une requête valide comme celle-ci devrait toujours fonctionner :

  curl -i -k -X POST "https://eval.example.com/translate/v1?lang=de" -H "Content-Type:application/json" -H "Key: $KEY" -d '{ "text": "Hello world!" }'

• Un paramètre de requête de langue non valide comme celui-ci devrait renvoyer le message d'erreur réécrit :

  curl -i -k -X POST "https://eval.example.com/translate/v1?lang=invalid" -H "Content-Type:application/json" -H "Key: $KEY" -d '{ "text": "Hello world!" }'

Cliquez sur Vérifier ma progression pour valider l'objectif. Réécrire un message d'erreur de backend

Félicitations !

Au cours de cet atelier challenge, vous avez démontré vos connaissances sur le développement et la sécurité des API Apigee X.

Gagnez un badge de compétence

Cet atelier d'auto-formation fait partie de la quête Développer et sécuriser des API avec Apigee X. Si vous terminez cette quête, vous obtiendrez le badge de compétence ci-dessus attestant de votre réussite. Ajoutez votre badge à votre CV et partagez-le sur les réseaux sociaux en utilisant le hashtag #GoogleCloudBadge.

Cette quête, qui ouvre droit à un badge de compétence, fait partie du parcours de formation Développeur d'API de Google Cloud. Poursuivez votre apprentissage en vous inscrivant à la quête Déployer et gérer Apigee X.

Formations et certifications Google Cloud

Les formations et certifications Google Cloud vous aident à tirer pleinement parti des technologies Google Cloud. Nos cours portent sur les compétences techniques et les bonnes pratiques à suivre pour être rapidement opérationnel et poursuivre votre apprentissage. Nous proposons des formations pour tous les niveaux, à la demande, en salle et à distance, pour nous adapter aux emplois du temps de chacun. Les certifications vous permettent de valider et de démontrer vos compétences et votre expérience en matière de technologies Google Cloud.

Dernière mise à jour du manuel : 10 juillet 2024

Dernier test de l'atelier : 10 juillet 2024

Copyright 2025 Google LLC. Tous droits réservés. Google et le logo Google sont des marques de Google LLC. Tous les autres noms d'entreprises et de produits peuvent être des marques des entreprises auxquelles ils sont associés.