GSP842

Présentation

La plate-forme d'API Apigee de Google Cloud peut être utilisée pour moderniser des applications existantes grâce à l'ajout de de nouvelles fonctionnalités à vos API actuelles.

Dans cet atelier, vous allez déployer un service de backend sur Cloud Run. Le service de backend implémente une API REST qui stocke des données bancaires (clients, comptes, distributeurs automatiques et transactions) dans une base de données Firestore et les en extrait. Vous allez créer un proxy d'API Apigee qui sert de relais au service de backend. Vous allez également créer un flux partagé qui récupère et met en cache le contenu d'un service externe. Vous appellerez ensuite ce flux partagé à partir de votre proxy d'API et vous utiliserez du code JavaScript pour modifier une réponse de l'API.

Objectifs

Dans cet atelier, vous allez apprendre à effectuer les tâches suivantes :

• Déployer un service de backend sur Cloud Run
• Utiliser un proxy Apigee X pour relayer un service de backend
• Créer un flux partagé pour une fonctionnalité utilisable par plusieurs proxys
• Stocker les données de configuration dans un ensemble de propriétés
• Utiliser une règle d'appel de service pour récupérer du contenu à partir d'un service
• Utiliser des règles de cache pour mettre en cache les informations réutilisables
• Utiliser du code JavaScript pour modifier la charge utile d'une réponse

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

Remarque : Ouvrez une fenêtre de navigateur en mode incognito (recommandé) ou de navigation privée pour effectuer cet atelier. Vous éviterez ainsi les conflits entre votre compte personnel et le compte temporaire de participant, qui pourraient entraîner des frais supplémentaires facturés sur votre compte personnel.

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

Remarque : Utilisez uniquement le compte de participant pour cet atelier. Si vous utilisez un autre compte Google Cloud, des frais peuvent être facturés à ce compte.

Démarrer l'atelier et se connecter à la console Google Cloud

1. Cliquez sur le bouton Démarrer l'atelier. Si l'atelier est payant, une boîte de dialogue s'affiche pour vous permettre de sélectionner un mode de paiement. Sur la gauche, vous trouverez le panneau "Détails concernant l'atelier", qui contient les éléments suivants :

   • Le bouton "Ouvrir la console Google Cloud"
   • Le temps restant
   • Les identifiants temporaires que vous devez utiliser pour cet atelier
   • Des informations complémentaires vous permettant d'effectuer l'atelier

2. Cliquez sur Ouvrir la console Google Cloud (ou effectuez un clic droit et sélectionnez Ouvrir le lien dans la fenêtre de navigation privée si vous utilisez le navigateur Chrome).

   L'atelier lance les ressources, puis ouvre la page "Se connecter" dans un nouvel onglet.

   Conseil : Réorganisez les onglets dans des fenêtres distinctes, placées côte à côte.

   Remarque : Si la boîte de dialogue Sélectionner un compte s'affiche, cliquez sur Utiliser un autre compte.

3. Si nécessaire, copiez le nom d'utilisateur ci-dessous et collez-le dans la boîte de dialogue Se connecter.

   {{{user_0.username | "Username"}}}

   Vous trouverez également le nom d'utilisateur dans le panneau "Détails concernant l'atelier".

4. Cliquez sur Suivant.

5. Copiez le mot de passe ci-dessous et collez-le dans la boîte de dialogue Bienvenue.

   {{{user_0.password | "Password"}}}

   Vous trouverez également le mot de passe dans le panneau "Détails concernant l'atelier".

6. Cliquez sur Suivant.

   Important : Vous devez utiliser les identifiants fournis pour l'atelier. Ne saisissez pas ceux de votre compte Google Cloud. Remarque : Si vous utilisez votre propre compte Google Cloud pour cet atelier, des frais supplémentaires peuvent vous être facturés.

7. Accédez aux pages suivantes :

   • Acceptez les conditions d'utilisation.
   • N'ajoutez pas d'options de récupération ni d'authentification à deux facteurs (ce compte est temporaire).
   • Ne vous inscrivez pas à des essais sans frais.

Après quelques instants, la console Cloud s'ouvre dans cet onglet.

Remarque : Pour accéder aux produits et services Google Cloud, cliquez sur le menu de navigation ou saisissez le nom du service ou du produit dans le champ Recherche.

Activer Cloud Shell

Cloud Shell est une machine virtuelle qui contient de nombreux outils pour les développeurs. Elle comprend un répertoire d'accueil persistant de 5 Go et s'exécute sur Google Cloud. Cloud Shell vous permet d'accéder via une ligne de commande à vos ressources Google Cloud.

1. Cliquez sur Activer Cloud Shell  en haut de la console Google Cloud.

2. Passez les fenêtres suivantes :

   • Accédez à la fenêtre d'informations de Cloud Shell.
   • Autorisez Cloud Shell à utiliser vos identifiants pour effectuer des appels d'API Google Cloud.

Une fois connecté, vous êtes en principe authentifié et le projet est défini sur votre ID_PROJET : . Le résultat contient une ligne qui déclare l'ID_PROJET pour cette session :

Your Cloud Platform project in this session is set to {{{project_0.project_id | "PROJECT_ID"}}}

gcloud est l'outil de ligne de commande pour Google Cloud. Il est préinstallé sur Cloud Shell et permet la complétion par tabulation.

3. (Facultatif) Vous pouvez lister les noms des comptes actifs à l'aide de cette commande :

gcloud auth list

4. Cliquez sur Autoriser.

Résultat :

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} To set the active account, run: $ gcloud config set account `ACCOUNT`

5. (Facultatif) Vous pouvez lister les ID de projet à l'aide de cette commande :

gcloud config list project

Résultat :

[core] project = {{{project_0.project_id | "PROJECT_ID"}}} Remarque : Pour consulter la documentation complète sur gcloud, dans Google Cloud, accédez au guide de présentation de la gcloud CLI.

Tâche 1 : Déployer un service de backend sur Cloud Run

Dans cette tâche, vous allez déployer un service de backend sur Cloud Run.

Le service implémente une API pour SimpleBank. Cette API fournit une représentation élémentaire d'une banque, avec des clients, des comptes, des transactions et des distributeurs automatiques. Le service SimpleBank est conçu à l'aide de Node.js avec des données stockées dans Firestore. Le code est empaqueté dans un conteneur Docker qui est lui-même déployé sur Cloud Run.

Cloner le dépôt de code

1. Pour cloner le dépôt hébergeant le code du service SimpleBank, exécutez la commande suivante dans Cloud Shell :

   git clone --depth 1 https://github.com/GoogleCloudPlatform/training-data-analyst

2. Créez un lien symbolique vers le répertoire de travail :

   ln -s ~/training-data-analyst/quests/develop-apis-apigee ~/develop-apis-apigee

3. Pour accéder au répertoire contenant le backend REST, exécutez la commande suivante :

   cd ~/develop-apis-apigee/rest-backend

4. Pour mettre à jour la région dans le fichier de configuration, exécutez la commande suivante :

   sed -i "s/us-west1/{{{ project_0.default_region | "REGION" }}}/g" config.sh

Initialiser le projet

Le script d'initialisation du projet, init-project.sh, active les API dans le projet. Ces API seront nécessaires pour déployer des services Cloud Run.

La base de données du service sera hébergée dans Firestore en mode natif. Un projet ne peut héberger qu'une seule base de données Firestore, soit en mode natif, soit en mode Datastore. Ce script va créer la base de données Firestore en mode natif.

1. Pour afficher les instructions exécutées par le script init-project.sh, saisissez la commande suivante :

   cat init-project.sh

   Le script active les API et crée la base de données Firestore en mode natif.

2. Pour exécuter le script, saisissez la commande suivante :

   ./init-project.sh

Cliquez sur Vérifier ma progression pour valider l'objectif. Activer l'API Cloud Run et créer la base de données Firestore

Initialiser le service

Le script d'initialisation du service, init-service.sh, crée un compte de service nommé simplebank-rest. Ce compte de service est utilisé comme identité de ce service Cloud Run. Le compte de service reçoit le rôle roles/datastore.user, qui autorise le service à lire et à modifier les données dans Firestore.

Lorsque vous créez un service, il est recommandé de créer un compte de service associé et d'accorder des autorisations à ce compte en appliquant le principe du moindre privilège. Ce principe stipule qu'un compte ne doit disposer que des droits essentiels à l'exécution de sa fonction unique.

1. Pour afficher les instructions exécutées par le script init-service.sh, saisissez la commande suivante :

   cat init-service.sh

   Le script crée le compte de service utilisé par le service et lui ajoute des rôles.

2. Pour exécuter le script, saisissez la commande suivante :

   ./init-service.sh

Déployer le service de backend

Le script de déploiement deploy.sh crée l'application du service simplebank à partir du code contenu dans le répertoire actuel et déploie le service sur Cloud Run à l'aide du compte de service simplebank-rest. Le script de déploiement est exécuté chaque fois que vous mettez à jour le code de votre application.

Le service est déployé de façon à exiger un accès authentifié. Vous ne pouvez donc pas l'appeler sans jeton d'identité OpenID Connect valide.

1. Pour afficher les instructions exécutées par le script deploy.sh, saisissez la commande suivante dans Cloud Shell :

   cat deploy.sh

   Le script crée et déploie le service simplebank-grpc sur Cloud Run.

Remarque : Le script de déploiement utilise le paramètre "max-instances" pour limiter à 1 le nombre d'instances dans le cluster Cloud Run. Pour un service réel en production, une limite aussi basse n'est pas appropriée.

2. Pour déployer le script sur Cloud Run, saisissez la commande suivante :

   ./deploy.sh

Cliquez sur Vérifier ma progression pour valider l'objectif. Déployer le service de backend

Tester le service

1. Pour vérifier que le service est en cours d'exécution, envoyez une requête curl qui l'appelle :

   export RESTHOST=$(gcloud run services describe simplebank-rest --platform managed --region {{{project_0.default_region |REGION}}} --format 'value(status.url)') echo "export RESTHOST=${RESTHOST}" >> ~/.bashrc curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" -X GET "${RESTHOST}/_status"

   La commande qui définit la variable RESTHOST utilise gcloud pour récupérer le nom d'hôte du service Cloud Run simplebank-rest. La variable est ensuite ajoutée au fichier .bashrc, ce qui entraîne le rechargement de la variable RESTHOST si Cloud Shell redémarre.

   La commande GET /_status renvoie simplement une réponse JSON indiquant que l'API est opérationnelle. Dans cet appel, vous avez utilisé gcloud auth print-identity-token afin d'obtenir un jeton d'identité OpenID Connect pour l'utilisateur connecté à Cloud Shell. Vous êtes connecté avec le rôle de propriétaire du projet, qui dispose d'autorisations très étendues.

2. Pour vérifier que le service peut écrire dans Firestore, envoyez une requête curl qui crée un client :

   curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" -H "Content-Type: application/json" -X POST "${RESTHOST}/customers" -d '{"lastName": "Diallo", "firstName": "Temeka", "email": "temeka@example.com"}'

   La commande POST /customers crée un client. Les paramètres lastName, firstName et email sont tous obligatoires. L'adresse e-mail doit être unique et est utilisée comme identifiant du client. L'enregistrement client est stocké dans Firestore.

   Remarque : Si vous obtenez un message d'erreur "AlreadyExist" (Existe déjà), cela peut indiquer que vous n'avez pas réussi à créer la base de données Firestore. La base de données est créée quand le script init-project.sh est exécuté.

3. Pour vérifier que le service peut lire les données de Firestore, envoyez une requête curl qui récupère le client que vous venez de créer :

   curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" -X GET "${RESTHOST}/customers/temeka@example.com"

   La commande GET /customers/ récupère un enregistrement client dans Firestore.

4. Pour charger d'autres exemples de données dans Firestore, saisissez la commande suivante :

   gcloud firestore import gs://spls/shared/firestore-simplebank-data/firestore/example-data

   Cette commande gcloud utilise la fonctionnalité d'importation/exportation de Firestore pour importer dans la base de données des clients, des comptes et des distributeurs automatiques.

5. Pour récupérer la liste des distributeurs automatiques, exécutez la commande curl suivante :

   curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" -X GET "${RESTHOST}/atms"

6. Pour récupérer un seul distributeur, exécutez la commande curl suivante :

   curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" -X GET "${RESTHOST}/atms/spruce-goose"

   La requête récupère un distributeur automatique à partir de son nom, et la réponse contient la latitude et la longitude du distributeur, mais pas son adresse :

   {"name":"spruce-goose","longitude":-118.408207,"description":"","latitude":33.977601}

   Dans une tâche ultérieure, vous utiliserez Apigee et l'API Geocoding afin de compléter avec une adresse la réponse renvoyée pour une requête de récupération d'un distributeur spécifique.

Tâche 2 : Mettre en place un proxy pour le service de backend à l'aide d'un proxy d'API Apigee

Dans cette tâche, vous allez créer un proxy d'API Apigee qui fait office de façade pour le service de backend. Ce proxy d'API utilisera un compte de service pour présenter des jetons d'identité OpenID Connect au service Cloud Run.

Créer un compte de service pour le proxy d'API Apigee

1. Pour créer un compte de service utilisable par le proxy d'API Apigee, saisissez la commande suivante :

   gcloud iam service-accounts create apigee-internal-access \ --display-name="Service account for internal access by Apigee proxies" \ --project=${GOOGLE_CLOUD_PROJECT}

   La commande gcloud crée un compte de service nommé apigee-internal-access, qui sera utilisé par votre proxy Apigee lors des appels au service de backend.

2. Pour accorder le rôle autorisant l'accès au service, saisissez la commande suivante :

   gcloud run services add-iam-policy-binding simplebank-rest \ --member="serviceAccount:apigee-internal-access@${GOOGLE_CLOUD_PROJECT}.iam.gserviceaccount.com" \ --role=roles/run.invoker --region={{{project_0.default_region |REGION}}} \ --project=${GOOGLE_CLOUD_PROJECT}

   Cette commande gcloud attribue au compte de service le rôle roles/run.invoker pour le service Cloud Run simplebank-rest, ce qui autorise le compte à appeler le service.

3. Pour récupérer l'URL du service de backend, utilisez la commande suivante :

   gcloud run services describe simplebank-rest --platform managed --region {{{project_0.default_region |REGION}}} --format 'value(status.url)'

   Enregistrez cette URL : vous l'utiliserez lors de la création du proxy d'API.

Cliquez sur Vérifier ma progression pour valider l'objectif. Il peut y avoir un léger délai avant que le rôle accordé ne soit détecté. Créer un compte de service pour le proxy d'API Apigee

Ouvrir la console Apigee

Pour ouvrir la console Apigee :

• Dans la console Google Cloud, dans le champ Rechercher, saisissez Apigee, puis cliquez sur Apigee API Management dans les résultats de recherche.

La console Apigee s'ouvre. La page de destination propose des liens rapides vers des emplacements couramment utilisés.

• Dans le menu de navigation (), à côté de Apigee, cliquez sur Épingler ().

Apigee est désormais épinglé au menu de navigation.

Créer le proxy Apigee

1. Dans le menu de navigation, sélectionnez Proxy development > API Proxies (Développement de proxys > Proxys d'API).

2. Pour créer un proxy à l'aide de l'assistant de proxy, cliquez sur +Create (+ Créer).

   Vous allez créer un proxy inverse pour votre service de backend.

3. Pour le modèle de proxy, sélectionnez General template > Reverse proxy (Most common) (Modèle général > Proxy inverse (le plus courant)).

   Remarque : N'utilisez pas l'option Reverse proxy (Most common) (Proxy inverse (le plus courant)) dans la section OpenAPI spec template (Modèle de spécification OpenAPI).

4. Saisissez les informations suivantes pour les détails du proxy :

   Propriété	Valeur
   Proxy name (Nom du proxy)	bank-v1
   Base path (Chemin de base)	/bank/v1
   Target (Existing API) (Cible (API existante))	URL du backend

   Remarque : Vérifiez que vous utilisez bien "/bank/v1" comme chemin de base, et non "/bank-v1".

   La cible doit être l'URL du backend que vous avez récupérée précédemment au cours de cette tâche. Elle doit ressembler à ceci :

   https://simplebank-rest-mtdtzt7yzq-ue.a.run.app

5. Cliquez sur Next (Suivant).

6. Conservez les paramètres par défaut de la section Deploy (optional) (Déployer (facultatif)), puis cliquez sur Create (Créer).

Vérifier que l'instance d'exécution est disponible

1. Dans Cloud Shell, collez et exécutez l'ensemble de commandes suivant :

   export INSTANCE_NAME=eval-instance; export ENV_NAME=eval; export PREV_INSTANCE_STATE=; echo "waiting for runtime instance ${INSTANCE_NAME} to be active"; while : ; do export INSTANCE_STATE=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${GOOGLE_CLOUD_PROJECT}/instances/${INSTANCE_NAME}" | jq "select(.state != null) | .state" --raw-output); [[ "${INSTANCE_STATE}" == "${PREV_INSTANCE_STATE}" ]] || (echo; echo "INSTANCE_STATE=${INSTANCE_STATE}"); export PREV_INSTANCE_STATE=${INSTANCE_STATE}; [[ "${INSTANCE_STATE}" != "ACTIVE" ]] || break; echo -n "."; sleep 5; done; echo; echo "instance created, waiting for environment ${ENV_NAME} to be attached to instance"; while : ; do export ATTACHMENT_DONE=$(curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" -X GET "https://apigee.googleapis.com/v1/organizations/${GOOGLE_CLOUD_PROJECT}/instances/${INSTANCE_NAME}/attachments" | jq "select(.attachments != null) | .attachments[] | select(.environment == \"${ENV_NAME}\") | .environment" --join-output); [[ "${ATTACHMENT_DONE}" != "${ENV_NAME}" ]] || break; echo -n "."; sleep 5; done; echo "***ORG IS READY TO USE***";

   Cette série de commandes utilise l'API Apigee pour déterminer quand l'instance d'exécution a été créée et l'environnement d'évaluation associé.

2. Attendez que l'instance soit prête.

   Lorsque le texte ***ORG IS READY TO USE*** s'affiche, l'instance est prête. Il se peut que l'organisation Apigee ait été créée avant le début de l'atelier. Dans ce cas, vous n'aurez pas à attendre la création de l'instance.

   Pendant que vous patientez, vous pouvez en apprendre davantage sur Apigee, explorer l'architecture Apigee X ou découvrir les API et proxys d'API.

Déployer le proxy d'API

1. Dans le menu de navigation, sélectionnez Proxy development > API Proxies (Développement de proxys > Proxys d'API), puis cliquez sur bank-v1.

2. Cliquez sur Deploy (Déployer).

3. Pour Environnement (Environnement), sélectionnez eval.

4. Pour Service account (Compte de service), spécifiez l'adresse e-mail du compte de service :

   apigee-internal-access@{{{ project_0.project_id | PROJECT }}}.iam.gserviceaccount.com

5. Cliquez sur Deploy (Déployer), puis sur Confirm (Confirmer).

6. Attendez que l'état du déploiement eval indique que le proxy a été déployé.

Tester le proxy d'API

L'environnement d'évaluation de l'organisation Apigee peut être appelé à l'aide du nom d'hôte eval.example.com. L'entrée DNS pour ce nom d'hôte a été créée dans votre projet et elle renvoie vers l'adresse IP de l'instance d'exécution Apigee. Cette entrée DNS a été créée dans une zone privée, ce qui signifie qu'elle n'est visible que sur le réseau interne.

Cloud Shell ne réside pas sur le réseau interne. Par conséquent, les commandes Cloud Shell ne peuvent pas résoudre cette entrée DNS. Une machine virtuelle (VM) de votre projet peut accéder au DNS de la zone privée. Une VM nommée apigeex-test-vm a été créée automatiquement : vous pouvez l'utiliser pour appeler le proxy d'API.

1. Dans Cloud Shell, ouvrez une connexion SSH vers votre VM de test :

   TEST_VM_ZONE=$(gcloud compute instances list --filter="name=('apigeex-test-vm')" --format "value(zone)") gcloud compute ssh apigeex-test-vm --zone=${TEST_VM_ZONE} --force-key-file-overwrite

   La première commande gcloud récupère la zone de la VM de test, tandis que la seconde ouvre la connexion SSH vers la VM.

2. Si vous êtes invité à donner votre autorisation, cliquez sur Autoriser.

   Pour chaque question posée dans Cloud Shell, cliquez sur Entrée ou Retour pour spécifier la valeur par défaut.

   L'identité avec laquelle vous êtes connecté est propriétaire du projet. La connexion SSH à cette machine est donc autorisée.

   Votre session Cloud Shell s'exécute désormais dans la VM.

3. Appelez le proxy d'API bank-v1 déployé dans l'environnement eval :

   curl -i -k "https://eval.example.com/bank/v1/_status"

   L'option -k indique à curl d'ignorer la vérification du certificat TLS. L'environnement d'exécution Apigee de cet atelier utilise un certificat autosigné au lieu d'un certificat créé par une autorité de certification (CA) de confiance.

   Remarque : Vous ne devez pas utiliser l'option -k pour contourner la vérification des certificats dans les cas d'utilisation en production.

   L'opération renvoie un code d'état 403 "Forbidden" (Accès interdit), avec un message d'erreur indiquant que votre client n'est pas autorisé à obtenir l'URL. La requête adressée au service de backend a été refusée, car le client n'a pas fourni le jeton requis avec la requête. Le proxy d'API s'exécute avec la bonne identité, mais vous devez quand même forcer l'envoi du jeton d'identité OpenID Connect avec la requête.

4. Revenez au proxy bank-v1, puis cliquez sur l'onglet Développer.

5. Dans le menu de gauche du proxy, dans la section Target Endpoints > default (Points de terminaison cibles > Par défaut), cliquez sur PreFlow.

6. Recherchez le code suivant (votre URL sera différente) :

   <HTTPTargetConnection> <Properties/> <URL>https://simplebank-rest-zce6j3rjwq-uw.a.run.app</URL> </HTTPTargetConnection> Remarque : Si la section "HTTPTargetConnection" n'apparaît pas, assurez-vous d'avoir cliqué sur "PreFlow" dans la section Target Endpoints (Points de terminaison cibles) et non dans la section Proxy Endpoints (Points de terminaison du proxy).

7. Dans la section HTTPTargetConnection, sous l'URL, ajoutez une section Authentication qui ressemble à ceci :

   <Authentication> <GoogleIDToken> <Audience>AUDIENCE</Audience> </GoogleIDToken> </Authentication>

8. Remplacez AUDIENCE par la valeur d'URL déjà présente dans la section HTTPTargetConnection. Votre code doit maintenant ressembler à ceci, excepté que votre URL spécifique apparaît dans les éléments "URL" et "Audience" :

   <TargetEndpoint name="default"> <PreFlow name="PreFlow"> <Request/> <Response/> </PreFlow> <Flows/> <PostFlow name="PostFlow"> <Request/> <Response/> </PostFlow> <HTTPTargetConnection> <Properties/> <URL>https://simplebank-rest-zce6j3rjwq-uw.a.run.app</URL> <Authentication> <GoogleIDToken> <Audience>https://simplebank-rest-zce6j3rjwq-uw.a.run.app</Audience> </GoogleIDToken> </Authentication> </HTTPTargetConnection> </TargetEndpoint>

9. Cliquez sur Save (Enregistrer), puis sur Save As New Revision (Enregistrer en tant que nouvelle révision).

10. Cliquez sur Deploy (Déployer).

11. Pour Environment (Environnement), utilisez eval.

12. Pour Service account (Compte de service), spécifiez l'adresse e-mail du compte de service :

    apigee-internal-access@{{{ project_0.project_id | PROJECT }}}.iam.gserviceaccount.com

13. Cliquez sur Deploy (Déployer), puis sur Confirm (Confirmer).

14. Cliquez sur l'onglet Overview (Vue d'ensemble) et attendez que l'état du déploiement eval indique que la nouvelle révision a été déployée.

Cliquez sur Vérifier ma progression pour valider l'objectif. Créer le proxy Apigee

14. Si votre connexion SSH a expiré, exécutez la commande suivante dans Cloud Shell pour rétablir la connexion :

    TEST_VM_ZONE=$(gcloud compute instances list --filter="name=('apigeex-test-vm')" --format "value(zone)") gcloud compute ssh apigeex-test-vm --zone=${TEST_VM_ZONE} --force-key-file-overwrite

15. Réexécutez la commande d'état dans la VM :

    curl -i -k "https://eval.example.com/bank/v1/_status"

    Vous devriez cette fois obtenir une réponse positive (200) semblable à celle-ci :

    HTTP/2 200 x-powered-by: Express content-type: application/json; charset=utf-8 etag: W/"41-x4uozCo6q/yN+kzizriXxryNZvc" x-cloud-trace-context: 5c810a7faa3353bcc085473fd58805b7 date: Thu, 11 Nov 2021 22:54:35 GMT server: Google Frontend content-length: 65 x-request-id: cf109193-6d6f-49a1-b323-7f66f63c5e28 via: 1.1 google {"serviceName":"simplebank-rest","status":"API up","ver":"1.0.0"}

    Cette réponse indique que le proxy d'API appelle correctement le service de backend.

16. Saisissez la commande exit pour quitter la session SSH et revenir à Cloud Shell.

Tâche 3 : Autoriser l'utilisation de l'API Google Cloud Geocoding

Dans cette tâche, vous allez activer l'API Geocoding, qui sera utilisée dans votre proxy d'API pour ajouter des informations d'adresse à la réponse générée par le service SimpleBank pour une requête de récupération d'un distributeur automatique.

1. Dans Cloud Shell, exécutez la commande suivante pour activer l'API Geocoding :

   gcloud services enable geocoding-backend.googleapis.com

   Vous allez maintenant créer une clé API permettant d'accéder à l'API Geocoding.

2. Pour créer la clé API, exécutez la commande suivante :

   API_KEY=$(gcloud alpha services api-keys create --project=${GOOGLE_CLOUD_PROJECT} --display-name="Geocoding API key for Apigee" --api-target=service=geocoding_backend --format "value(response.keyString)") echo "export API_KEY=${API_KEY}" >> ~/.bashrc echo "API_KEY=${API_KEY}" Remarque : Si vous recevez un message d'erreur indiquant que la propriété du projet est définie sur la chaîne vide, vérifiez que vous avez bien quitté la session SSH de la VM et que vous êtes revenu dans Cloud Shell.

   La commande gcloud crée la clé API permettant d'envoyer des requêtes à l'API Geocoding. Fournir le paramètre --format vous permet de sélectionner le champ "keyString" dans la réponse pour en stocker la valeur dans la variable shell API_KEY. La variable API_KEY est ensuite stockée dans le fichier .bashrc dans Cloud Shell.

Cliquez sur Vérifier ma progression pour valider l'objectif. Autoriser l'utilisation de l'API Google Cloud Geocoding

3. Pour récupérer les informations de géocodage correspondant à une latitude et une longitude données, exécutez la commande curl suivante :

   curl "https://maps.googleapis.com/maps/api/geocode/json?key=${API_KEY}&latlng=37.404934,-122.021411"

   Cette commande appelle l'API Geocoding en fournissant la clé API ainsi que la latitude et la longitude souhaitées. La réponse contient un tableau de résultats, chacun comportant une adresse mise en forme. Dans votre proxy d'API, vous utiliserez le premier résultat d'adresse mise en forme afin de l'ajouter à la réponse fournie par l'API pour une requête de récupération des détails concernant un distributeur automatique donné.

Tâche 4 : Créer un flux partagé pour appeler l'API Geocoding

Dans cette tâche, vous allez créer un flux partagé pour appeler l'API Geocoding de Google. Les flux partagés vous permettent de combiner des règles et des ressources dans un même flux afin que celui-ci puisse être consommé par plusieurs proxys d'API ou par d'autres flux partagés.

Le flux partagé utilisera le modèle suivant :

Le nombre de distributeurs automatiques figurant dans notre base de données est limité, et leurs coordonnées géographiques (latitude et longitude) ne changent pas. Pour éviter de multiplier les appels à l'API Geocoding, l'adresse récupérée sera mise en cache, en utilisant comme clé de cache la latitude et la longitude. Si l'adresse ne figure pas dans le cache pour une latitude et une longitude données, l'API Geocoding est appelée et l'adresse renvoyée est alors stockée dans le cache.

Créer le flux partagé

1. Dans le menu de navigation, sélectionnez Apigee > Proxy development > Shared flows (Apigee > Développement de proxys > Flux partagés).
2. Click +Create (+ Créer).
3. Définissez le nom sur get-address-for-location, puis cliquez sur Create (Créer).
4. Cliquez sur l'onglet Develop (Développer) :

Ajouter une règle LookupCache

La règle LookupCache récupère une adresse si celle-ci a déjà été mise en cache.

1. Dans le menu de gauche du flux partagé, dans la section Shared Flows (Flux partagés), cliquez sur default (par défaut).

2. Dans le volet sharedflows/default.xml, cliquez sur Add policy step  (Ajouter une étape de règle).

3. Sélectionnez Create new policy (Créer une règle).

4. Dans Select policy (Sélectionner une règle), choisissez Traffic Management > Lookup Cache (Gestion du trafic > Recherche dans le cache).

5. Dans la section Details (Détails), spécifiez les informations suivantes :

   Propriété	Valeur
   Name (Nom)	LC-LookupAddress
   Display Name (Nom à afficher)	LC-LookupAddress

6. Cliquez sur Add (Ajouter), puis sur LC-LookupAddress.

   La règle est ajoutée au flux, et le fichier XML de configuration de la règle s'affiche dans le volet situé sous le flux.

7. Vérifiez que la configuration LookupCache figure bien dans le volet, puis remplacez-la par les éléments suivants :

   <LookupCache continueOnError="false" enabled="true" name="LC-LookupAddress"> <CacheResource>AddressesCache</CacheResource> <Scope>Exclusive</Scope> <CacheKey> <KeyFragment ref="geocoding.latitude"/> <KeyFragment ref="geocoding.longitude"/> </CacheKey> <AssignTo>geocoding.address</AssignTo> </LookupCache>

   La règle recherche dans AddressesCache une entrée correspondant à la latitude et à la longitude spécifiées. Si elle en trouve une, elle attribue la valeur trouvée à la variable d'adresse.

Ajouter une règle d'appel de service

La règle Service Callout (règle d'appel de service) appellera l'API Geocoding de Google.

1. Dans le menu de gauche du flux partagé, dans la section Shared Flows (Flux partagés), cliquez sur default (par défaut).

2. Dans le volet sharedflows/default.xml, cliquez sur Add policy step  (Ajouter une étape de règle).

3. Sélectionnez Create new policy (Créer une règle).

4. Dans Select policy (Sélectionner une règle), choisissez Extension > Service Callout (Extension > Appel de service).

5. Dans la section Details (Détails), spécifiez les informations suivantes :

   Propriété	Valeur
   Name (Nom)	SC-GoogleGeocode
   Display Name (Nom à afficher)	SC-GoogleGeocode

6. Laissez le champ "HTTP Target" (Cible HTTP) inchangé, cliquez sur Add (Ajouter), puis sur SC-GoogleGeocode.

7. Vérifiez que la configuration ServiceCallout figure bien dans le volet, puis remplacez-la par les éléments suivants :

   <ServiceCallout continueOnError="false" enabled="true" name="SC-GoogleGeocode"> <Request> <Set> <QueryParams> <QueryParam name="latlng">{geocoding.latitude},{geocoding.longitude}</QueryParam> <QueryParam name="key">{geocoding.apikey}</QueryParam> </QueryParams> <Verb>GET</Verb> </Set> </Request> <Response>calloutResponse</Response> <HTTPTargetConnection> <URL>https://maps.googleapis.com/maps/api/geocode/json</URL> </HTTPTargetConnection> </ServiceCallout>

   Cette règle appelle l'API Geocoding avec les variables geocoding.latitude, geocoding.longitude et geocoding.apikey. La réponse à l'appel d'API est stockée dans la variable calloutResponse.

Ajouter une règle ExtractVariables

La règle ExtractVariables extrait l'adresse mise en forme de la réponse de l'API Geocoding de Google.

1. Dans le menu de gauche du flux partagé, dans la section Shared Flows (Flux partagés), cliquez sur default (par défaut).

2. Dans le volet sharedflows/default.xml, cliquez sur Add policy step  (Ajouter une étape de règle).

3. Sélectionnez Create new policy (Créer une règle).

4. Dans Select policy (Sélectionner une règle), choisissez Mediation > Extract Variables (Médiation > Extraire les variables).

5. Dans la section Details (Détails), spécifiez les informations suivantes :

   Propriété	Valeur
   Name (Nom)	EV-ExtractAddress
   Display Name (Nom à afficher)	EV-ExtractAddress

6. Cliquez sur Add (Ajouter), puis sur EV-ExtractAddress.

7. Vérifiez que la configuration ExtractVariables figure bien dans le volet, puis remplacez-la par les éléments suivants :

   <ExtractVariables continueOnError="false" enabled="true" name="EV-ExtractAddress"> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> <JSONPayload> <Variable name="address"> <JSONPath>$.results[0].formatted_address</JSONPath> </Variable> </JSONPayload> <Source clearPayload="false">calloutResponse.content</Source> <VariablePrefix>geocoding</VariablePrefix> </ExtractVariables>

   Cette règle utilise JSONPath pour extraire l'élément formatted_address du premier résultat de la charge utile JSON du message calloutResponse. L'adresse est stockée dans la variable geocoding.address.

Ajouter une règle PopulateCache

La règle PopulateCache stocke l'adresse dans le cache.

1. Dans le menu de gauche du flux partagé, dans la section Shared Flows (Flux partagés), cliquez sur default (par défaut).

2. Dans le volet sharedflows/default.xml, cliquez sur Add policy step  (Ajouter une étape de règle).

3. Sélectionnez Create new policy (Créer une règle).

4. Dans Select policy (Sélectionner une règle), choisissez Traffic Management > PopulateCache (Gestion du trafic > PopulateCache).

5. Dans la section Details (Détails), spécifiez les informations suivantes :

   Propriété	Valeur
   Name (Nom)	PC-StoreAddress
   Display Name (Nom à afficher)	PC-StoreAddress

6. Cliquez sur Add (Ajouter), puis sur PC-StoreAddress.

7. Vérifiez que la configuration PopulateCache figure bien dans le volet, puis remplacez-la par les éléments suivants :

   <PopulateCache continueOnError="false" enabled="true" name="PC-StoreAddress"> <CacheResource>AddressesCache</CacheResource> <Scope>Exclusive</Scope> <Source>geocoding.address</Source> <CacheKey> <KeyFragment ref="geocoding.latitude"/> <KeyFragment ref="geocoding.longitude"/> </CacheKey> <ExpirySettings> <TimeoutInSec>3600</TimeoutInSec> </ExpirySettings> </PopulateCache>

   La règle stocke la valeur de la variable address dans AddressesCache en utilisant les mêmes fragments de clé de latitude et de longitude que la règle LookupCache, dans le même ordre. Le paramètre ExpirySettings/TimeoutInSec indique que les données stockées sont mises en cache pour une durée de 3 600 secondes, soit une heure.

Ignorer des règles de manière conditionnelle

Lorsque l'adresse correspondant à une latitude et une longitude spécifiques est trouvée dans le cache (succès de cache), les règles ServiceCallout, ExtractVariables et PopulateCache ne sont pas nécessaires et doivent donc être ignorées.

1. Dans le menu de gauche du flux partagé, dans la section Shared Flows (Flux partagés), cliquez sur default (par défaut).

   Le volet "Code" contient le flux par défaut, qui liste les quatre règles qui ont été associées :

   <SharedFlow name="default"> <Step> <Name>LC-LookupAddress</Name> </Step> <Step> <Name>SC-GoogleGeocode</Name> </Step> <Step> <Name>EV-ExtractAddress</Name> </Step> <Step> <Name>PC-StoreAddress</Name> </Step> </SharedFlow>

   Chaque étape (Step) spécifie une règle qui a été associée. L'élément Name spécifie le nom de la règle associée. Un élément Condition peut également être ajouté pour spécifier une condition booléenne qui détermine si la règle doit être exécutée.

   Examinez à nouveau le modèle de flux partagé présenté au début de la tâche. Lorsque la recherche d'adresse réussit, il n'est pas nécessaire d'appeler le service ni de stocker les données dans le cache. Dans ce cas, les deuxième, troisième et quatrième étapes de règles doivent être ignorées.

   La règle LookupCache définit une variable qui indique si l'élément a été trouvé dans le cache. Si la variable lookupcache.{policyName}.cachehit est définie sur "false", cela signifie que l'élément n'a pas été trouvé. Les règles des étapes 2 à 4 ne doivent s'exécuter que lorsqu'il n'y a pas eu de succès de cache.

2. Pour chacune de ces étapes, ajoutez la condition suivante à l'intérieur de l'élément "Step" :

   <Condition>lookupcache.LC-LookupAddress.cachehit == false</Condition>

   Après tous ces ajouts, le flux partagé devrait se présenter comme suit :

   <SharedFlow name="default"> <Step> <Name>LC-LookupAddress</Name> </Step> <Step> <Condition>lookupcache.LC-LookupAddress.cachehit == false</Condition> <Name>SC-GoogleGeocode</Name> </Step> <Step> <Condition>lookupcache.LC-LookupAddress.cachehit == false</Condition> <Name>EV-ExtractAddress</Name> </Step> <Step> <Condition>lookupcache.LC-LookupAddress.cachehit == false</Condition> <Name>PC-StoreAddress</Name> </Step> </SharedFlow>

3. Cliquez sur Save (Enregistrer).

4. Cliquez sur Deploy (Déployer).

5. Pour Environment (Environnement), utilisez eval.

6. Laissez le champ Service Account (Compte de service) vide, puis cliquez sur Deploy (Déployer) et sur Confirm (Confirm).

   Le flux partagé utilise une clé API pour appeler l'API Geocoding. Un compte de service n'est donc pas nécessaire.

   Un flux partagé ne peut être testé qu'en l'appelant à partir d'un proxy d'API.

Cliquez sur Vérifier ma progression pour valider l'objectif. Créer un flux partagé pour appeler l'API Geocoding

Tâche 5 : Ajouter l'adresse du distributeur dans la réponse à une requête de récupération d'un distributeur automatique donné

Dans cette tâche, vous allez ajouter au proxy d'API une règle FlowCallout pour appeler le flux partagé que vous venez de créer. Lorsque vous récupérez un distributeur automatique spécifique, votre proxy d'API doit extraire la latitude et la longitude de la réponse obtenue du service Cloud Run, puis appeler le flux partagé pour récupérer l'adresse correspondante. Une règle JavaScript ajoutera ensuite l'adresse à la réponse de l'API.

Ajouter un ensemble de propriétés pour la clé API

Un ensemble de propriétés peut être utilisé pour stocker des données qui n'expirent pas et qui sont facilement accessibles depuis le proxy d'API. Une valeur de l'ensemble de propriétés contiendra la clé API.

1. Dans le menu de navigation de gauche, sélectionnez Proxy development > API Proxies (Développement de proxys > Proxys d'API).

2. Cliquez sur bank-v1, puis sélectionnez l'onglet Develop (Développer).

3. Dans le menu de gauche du proxy, dans la section Resources (Ressources), cliquez sur Add resource  (Ajouter une ressource).

4. Dans le menu déroulant Resource type (Type de ressource), sélectionnez Property Set (Ensemble de propriétés).

5. Comme Resource name (Nom de la ressource), spécifiez geocoding.properties, puis cliquez sur Add (Ajouter).

6. Dans le volet geocoding.properties, ajoutez la propriété suivante :

   apikey=<APIKEY>

7. Remplacez <APIKEY> par la valeur de l'API_KEY que vous avez créée dans la tâche 3.

8. Vous pouvez récupérer la valeur d'API_KEY en exécutant la commande suivante dans Cloud Shell :

   echo ${API_KEY}

   Votre fichier geocoding.properties devrait ressembler à ceci :

   apikey=AIzaSyC8-B6nt7M240wwZtsxR2O5sb0xznuhQWc

Créer un flux conditionnel

1. Dans le menu de gauche du proxy, dans la section Proxy Endpoints (Points de terminaison du proxy), cliquez sur default (par défaut).

2. Dans le volet proxy-endpoints/default.xml, à côté de Proxy endpoint: default (Point de terminaison du proxy : par défaut), cliquez sur Add conditional flow  (Ajouter un flux conditionnel).

3. Dans la boîte de dialogue Add Conditional Flow (Ajouter un flux conditionnel), saisissez les valeurs suivantes :

   Propriété	Valeur
   Flow name (Nom du flux)	GetATM
   Description	récupérer un distributeur automatique donné
   Condition type (Type de condition)	sélectionnez Path and Verb (Chemin et verbe).
   Path (Chemin)	/atms/{name}
   Verb (Verbe)	sélectionnez GET

   Laissez le champ Target URL (URL cible) vide.

4. Cliquez sur Add (Ajouter).

   Un proxy d'API est composé de nombreux flux. Chaque flux fournit un emplacement permettant d'associer des règles en tant qu'étapes. Voici le schéma d'un proxy d'API :

   

   Une configuration de flux conditionnel ne s'exécute que lorsque la condition vaut "true". Pour ce flux conditionnel, la variable proxy.pathsuffix doit correspondre au format /atms/{name} et la variable request.verb doit avoir pour valeur GET.

   Vous allez associer des règles au flux conditionnel GetATM afin qu'elles s'exécutent uniquement pour une requête GET /atms/{name}. Les règles doivent s'exécuter après l'appel du service de backend. Elles doivent donc être associées à un flux conditionnel de réponse du point de terminaison du proxy.

Extraire la latitude et la longitude

1. Dans le flux Proxy endpoint: default (Point de terminaison du proxy : par défaut), dans la section Response (Réponse), à droite de GetATM, cliquez sur Add Policy Step  (Ajouter une étape de règle).

   Remarque : Veillez à ajouter l'étape du côté Response (Réponse), et non du côté "Request" (Requête).

2. Sélectionnez Create new policy (Créer une règle).

3. Dans Select policy (Sélectionner une règle), choisissez Mediation > Extract Variables (Médiation > Extraire les variables).

4. Dans la section Details (Détails), spécifiez les informations suivantes :

   Propriété	Valeur
   Name (Nom)	EV-ExtractLatLng
   Display name (Nom à afficher)	EV-ExtractLatLng

5. Cliquez sur Add (Ajouter), puis sur EV-ExtractLatLng.

6. Vérifiez que la configuration ExtractVariables figure bien dans le volet, puis remplacez-la par les éléments suivants :

   <ExtractVariables name="EV-ExtractLatLng"> <Source>response</Source> <JSONPayload> <Variable name="latitude"> <JSONPath>$.latitude</JSONPath> </Variable> <Variable name="longitude"> <JSONPath>$.longitude</JSONPath> </Variable> </JSONPayload> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> </ExtractVariables>

   Cette stratégie extrait la latitude et la longitude de la réponse JSON GET /atms/{name} fournie par le service de backend. L'élément IgnoreUnresolvedVariables est défini sur "true", ce qui permet au traitement de se poursuivre même si la latitude et la longitude ne sont pas trouvées dans la réponse.

Appeler le flux partagé

1. Dans le flux Proxy endpoint: default (Point de terminaison du proxy : par défaut), dans la section Response (Réponse), à droite de GetATM, cliquez sur Add Policy Step  (Ajouter une étape de règle).

2. Sélectionnez Create new policy (Créer une règle).

3. Dans Select policy (Sélectionner une règle), choisissez Extension > Flow Callout (Extension > Appel de flux).

4. Dans la section Details (Détails), spécifiez les informations suivantes :

   Propriété	Valeur
   Name (Nom)	FC-GetAddress
   Display name (Nom à afficher)	FC-GetAddress
   Flux partagé	sélectionnez get-address-for-location.
   Condition	latitude != null AND longitude != null

   Si l'une des deux valeurs de latitude ou de longitude d'un distributeur automatique n'a pas été récupérée, l'adresse ne peut pas être déterminée et l'étape de règle est donc ignorée.

5. Cliquez sur Add (Ajouter), puis sur FC-GetAddress.

6. Vérifiez que la configuration FlowCallout figure bien dans le volet, puis remplacez-la par les éléments suivants :

   <FlowCallout continueOnError="false" enabled="true" name="FC-GetAddress"> <Parameters> <Parameter name="geocoding.latitude">{latitude}</Parameter> <Parameter name="geocoding.longitude">{longitude}</Parameter> <Parameter name="geocoding.apikey">{propertyset.geocoding.apikey}</Parameter> </Parameters> <SharedFlowBundle>get-address-for-location</SharedFlowBundle> </FlowCallout>

   Cette règle définit les variables "latitude", "longitude" et "apikey" en tant que paramètres du flux partagé, puis appelle le flux partagé. Le flux partagé définit la variable geocoding.address.

Ajouter l'adresse

1. Dans le flux Proxy endpoint: default (Point de terminaison du proxy : par défaut), dans la section Response (Réponse), à droite de GetATM, cliquez sur Add Policy Step  (Ajouter une étape de règle).

2. Sélectionnez Create new policy (Créer une règle).

3. Pour Select policy (Sélectionner une règle), sélectionnez Extension > JavaScript.

4. Dans la section Details (Détails), spécifiez les informations suivantes :

   Propriété	Valeur
   Name (Nom)	JS-AddAddress
   Display name (Nom à afficher)	JS-AddAddress
   Fichier JavaScript	sélectionnez Create New Resource (Créer une ressource)

5. Dans la section Add resource (Ajouter une ressource), spécifiez les éléments suivants :

   Propriété	Value (Valeur)
   Source	sélectionnez Create new file (Créer un fichier)
   Resource name (Nom de la ressource)	addAddress.js

6. Cliquez sur Add (Ajouter), puis sélectionnez addAddress.js.

7. Pour Condition, spécifiez latitude != null AND longitude != null.

8. Cliquez sur Add (Ajouter), puis sur JS-AddAddress.

9. Dans le menu de gauche du proxy, dans la section Resources > jsc (Ressources > jsc), cliquez sur addAddress.js.

   Le volet de code est vide pour addAddress.js.

10. Ajoutez le code JavaScript ci-dessous pour ajouter l'adresse à la réponse :

    // get the flow variable 'geocoding.address' var address = context.getVariable('geocoding.address'); // parse the response payload into the responsePayload object var responsePayload = JSON.parse(context.getVariable('response.content')); try { // add address to the response responsePayload.address = address; // convert the response object back into JSON context.setVariable('response.content', JSON.stringify(responsePayload)); } catch(e) { // catch any exception print('Error occurred when trying to add the address to the response.'); }

    Ce code analyse la charge utile de la réponse JSON et la transforme en objet auquel il ajoute un champ d'adresse, avant de reconvertir l'objet en chaîne JSON pour le stocker dans la réponse.

    Un bloc try/catch est utilisé pour éviter que la règle JavaScript ne génère des exceptions. Une erreur est générée si une exception n'est pas interceptée, ce qui entraînerait l'abandon du traitement par le proxy d'API.

Vérifier que les règles sont ignorées de manière conditionnelle

1. Dans le menu de gauche du proxy, dans la section Proxy endpoints > default (Points de terminaison du proxy > par défaut), cliquez sur GetATM.

   Le volet "Code" contient le flux GetATM qui liste les trois règles précédemment associées, avec des conditions sur les deuxième et troisième règles :

   <Flow name="GetATM"> <Description>retrieve a single ATM</Description> <Request/> <Response> <Step> <Name>EV-ExtractLatLng</Name> </Step> <Step> <Condition>latitude != null AND longitude != null</Condition> <Name>FC-GetAddress</Name> </Step> <Step> <Condition>latitude != null AND longitude != null</Condition> <Name>JS-AddAddress</Name> </Step> </Response> <Condition>(proxy.pathsuffix MatchesPath "/atms/{name}") and (request.verb = "GET")</Condition> </Flow>

2. Cliquez sur Save (Enregistrer), puis sur Save As New Revision (Enregistrer en tant que nouvelle révision).

3. Cliquez sur Deploy (Déployer).

4. Pour Environment (Environnement), utilisez eval.

5. Pour Service account (Compte de service), spécifiez l'adresse e-mail du compte de service :

   apigee-internal-access@{{{ project_0.project_id | PROJECT }}}.iam.gserviceaccount.com

6. Cliquez sur Deploy (Déployer), puis sur Confirm (Confirmer).

7. Cliquez sur l'onglet Overview (Vue d'ensemble) et attendez que l'état du déploiement eval indique que la nouvelle révision a été déployée.

Cliquez sur Vérifier ma progression pour valider l'objectif. Ajouter l'adresse du distributeur dans la réponse à une requête de récupération d'un distributeur automatique donné

Tester le proxy d'API mis à jour

1. Dans Cloud Shell, ouvrez une connexion SSH vers votre VM de test :

   TEST_VM_ZONE=$(gcloud compute instances list --filter="name=('apigeex-test-vm')" --format "value(zone)") gcloud compute ssh apigeex-test-vm --zone=${TEST_VM_ZONE} --force-key-file-overwrite

2. Utilisez la commande suivante pour appeler le proxy bank-v1 et récupérer tous les distributeurs automatiques :

   curl -i -k "https://eval.example.com/bank/v1/atms"

   La réponse ne contient pas d'adresses, car la requête n'utilise pas le flux GET /atms/{name}.

3. Récupérer un seul distributeur automatique :

   curl -i -k "https://eval.example.com/bank/v1/atms/spruce-goose"

   Cette réponse contient maintenant l'adresse qui a été ajoutée dans le proxy d'API :

   {"longitude":-118.408207,"latitude":33.977601,"description":"","name":"spruce-goose","address":"5865 S Campus Center Dr, Los Angeles, CA 90094, USA"}

Félicitations !

Dans cet atelier, vous avez déployé un service de backend sur Cloud Run. Vous avez créé un proxy d'API Apigee qui sert de relais pour le service de backend. Vous avez créé un flux partagé qui récupère et met en cache du contenu provenant d'un service externe. Vous avez appelé ce flux partagé à partir de votre proxy d'API et vous avez utilisé du code JavaScript pour modifier une réponse de l'API.

Étapes suivantes et informations supplémentaires

• Qu'est-ce qu'Apigee ?
• Architecture Apigee X
• API et proxys d'API

Dernière modification du manuel : 16 juillet 2024

Dernier test de l'atelier : 16 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.