Création d’une fonction externe sur AWS Utilisation de l’interface Web

Ce document montre une façon de créer une fonction externe sur la plate-forme Cloud Amazon Web Services (AWS), notamment :

  • Création d’un service distant (fonction Lambda sur AWS).

  • Création d’un service proxy (sur Amazon API Gateway).

  • Création d’une intégration API dans Snowflake.

  • Création d’une fonction externe dans Snowflake.

  • Appel de la fonction externe.

Ces instructions supposent que vous connaissez déjà l’administration d’AWS. Ces instructions spécifient les étapes générales que vous devez exécuter, mais ne vous guident pas dans les détails de la console de gestion AWS car les détails pourraient changer.

Dans ce chapitre :

Planification de votre fonction externe sur AWS

Planification de la création d’une fonction externe sur AWS

Vous avez besoin des éléments suivants :

  • Un compte avec AWS, y compris des privilèges pour :

    • Créer des rôles AWS via IAM (gestion des identités et des accès).

    • Créer des fonctions Lambda AWS.

    • Créer un point de terminaison API Gateway.

  • Un compte Snowflake dans lequel vous disposez des privilèges ACCOUNTADMIN ou un rôle avec le privilège CREATE INTEGRATION.

Ce document suppose que vous êtes un administrateur AWS expérimenté.

Feuille de calcul

Lorsque vous créez votre fonction externe, vous devez enregistrer des informations spécifiques (par exemple, l’URL d’API Gateway) que vous saisissez afin de pouvoir utiliser ces informations dans les étapes suivantes. La feuille de calcul ci-dessous vous aide à suivre ces informations.

==============================================================================================
=========================================== Worksheet ========================================
==============================================================================================

------------------ Information about the Lambda Function (remote service) --------------------

AWS Account ID.............: _____________________________________________

Lambda Function Name.......: _____________________________________________


---------------------- Information about the API Gateway (proxy Service) ---------------------

New IAM Role Name..........: _____________________________________________

New IAM Role ARN...........: _____________________________________________

Snowflake VPC ID (optional): _____________________________________________

New API Name...............: _____________________________________________

API Gateway Resource Name..: _____________________________________________

Resource Invocation URL....: _____________________________________________

Method Request ARN.........: _____________________________________________


------------ Information about the API Integration and External Function ---------------------

API Integration Name.......: _____________________________________________

API_AWS_IAM_USER_ARN.......: _____________________________________________

API_AWS_EXTERNAL_ID........: _____________________________________________

External Function Name.....: _____________________________________________

Ressources supplémentaires pour la mise en place de fonctions externes sur AWS (lecture facultative)

Lorsque vous serez prêt à créer votre propre service à distance pour votre propre fonction externe, vous voudrez peut-être consulter les exemples de services à distance basés sur les fonctions Lambda qui sont disponibles à l’adresse :

Étape 1 : Créer le service distant (fonction Lambda sur AWS)

Il existe plusieurs façons de créer un service distant. Cette section montre comment créer un service distant implémenté en tant que fonction Python s’exécutant dans AWS Lambda.

Cette fonction externe est synchrone. Pour des informations sur la création d’une fonction externe asynchrone, voir Création d’une fonction asynchrone sur AWS.

Cet exemple de fonction en langage Python renvoie simplement son ou ses entrée(s). Les entrées sont renvoyées sous la forme d’une valeur SQL VARIANT, qui peut contenir une ou plusieurs valeurs.

Cette fonction accepte et renvoie les données au même format (JSON) que celui envoyé et lu par Snowflake. (Pour plus d’informations sur les formats de données, voir Formats des données d’entrée et de sortie des services à distance .)

Cette fonction Python reçoit deux paramètres, event et context. Le paramètre event comprend de nombreux sous-champs, dont l’un est body. Le corps est un dictionnaire qui comprend une clé nommée data ; la valeur correspondante pour data est une chaîne contenant les données envoyées par Snowflake au format JSON. Etant donné que AWS Lambda traite commodément la requête HTTP POST envoyée par Snowflake, extrait le corps et transmet le corps à l’intérieur du paramètre d’événement, cet exemple de fonction n’a pas besoin d’analyser l’intégralité de la requête HTTP POST.

Après que cette fonction Python a extrait le corps sous forme de chaîne, la fonction appelle une fonction de bibliothèque JSON pour convertir la chaîne en une structure de données Python. La fonction extrait ensuite des lignes individuelles de cette structure de données, les traite et renvoie une valeur pour chacune d’entre elles.

Le JSON pour une valeur de retour typique d’une fonction AWS Lambda ressemble à ceci :

{
"statusCode": <http_status_code>,
"body":
        {
            "data":
                  [
                      [ 0, <value> ],
                      [ 1, <value> ]
                      ...
                  ]
        }
}

Les données de la valeur de retour correspondent au format décrit précédemment pour les données d’entrée. Sur AWS, la convention pour un service compatible HTTP est de renvoyer le corps à l’intérieur d’un objet JSON qui inclut également le code de statut HTTP.

Pour créer cette fonction Lambda AWS, procédez comme suit :

  1. Connectez-vous à la console de gestion AWS, si ce n’est pas déjà fait.

  2. Enregistrez votre ID de compte AWS dans le champ « ID du compte AWS » de la feuille de calcul.

    Si vous devez consulter votre ID de compte AWS, suivez les instructions AWS.

  3. Sélectionnez Lambda.

  4. Sélectionnez Create function.

  5. Saisissez un nom de fonction.

    Enregistrez ce nom dans le champ « Nom de la fonction Lambda » de la feuille de calcul.

  6. Sélectionnez le langage à utiliser. Pour cet exemple, choisissez Python Python 3.7.

  7. Choisissez ou créez un rôle d’exécution pour cette fonction.

    Sélectionnez la ou les options appropriées, généralement Create a new role with basic Lambda permissions.

    (Ce rôle est distinct de votre rôle de compte Cloud et distinct de vos rôles Snowflake.)

  8. Cliquez sur le bouton Create Function.

  9. Dans l’onglet lambda_function , entrez le code de la fonction. Si vous n’avez pas encore écrit votre propre fonction, vous pouvez remplacer le code de fonction par défaut par le code ci-dessous, qui fera écho à son entrée. Vous pouvez remplacer ou mettre à jour ce code ultérieurement lorsque vous serez prêt à créer une fonction personnalisée.

    Cet exemple de code suppose que vous utilisez l’intégration du proxy Lambda, comme le recommande Snowflake dans les instructions de création du point de terminaison API Gateway.

    Si vous ne pouvez pas coller dans la fenêtre d’édition, essayez de double-cliquer sur le nom du fichier de la fonction pour activer l’édition.

    import json
    
    def lambda_handler(event, context):
    
        # 200 is the HTTP status code for "ok".
        status_code = 200
    
        # The return value will contain an array of arrays (one inner array per input row).
        array_of_rows_to_return = [ ]
    
        try:
            # From the input parameter named "event", get the body, which contains
            # the input rows.
            event_body = event["body"]
    
            # Convert the input from a JSON string into a JSON object.
            payload = json.loads(event_body)
            # This is basically an array of arrays. The inner array contains the
            # row number, and a value for each parameter passed to the function.
            rows = payload["data"]
    
            # For each input row in the JSON object...
            for row in rows:
                # Read the input row number (the output row number will be the same).
                row_number = row[0]
    
                # Read the first input parameter's value. For example, this can be a
                # numeric value or a string, or it can be a compound value such as
                # a JSON structure.
                input_value_1 = row[1]
    
                # Read the second input parameter's value.
                input_value_2 = row[2]
    
                # Compose the output based on the input. This simple example
                # merely echoes the input by collecting the values into an array that
                # will be treated as a single VARIANT value.
                output_value = ["Echoing inputs:", input_value_1, input_value_2]
    
                # Put the returned row number and the returned value into an array.
                row_to_return = [row_number, output_value]
    
                # ... and add that array to the main array.
                array_of_rows_to_return.append(row_to_return)
    
            json_compatible_string_to_return = json.dumps({"data" : array_of_rows_to_return})
    
        except Exception as err:
            # 400 implies some type of error.
            status_code = 400
            # Tell caller what this function could not handle.
            json_compatible_string_to_return = event_body
    
        # Return the return value and HTTP status code.
        return {
            'statusCode': status_code,
            'body': json_compatible_string_to_return
        }
    
  10. Cliquez sur le bouton Deploy pour déployer la fonction.

  11. Facultatif, mais fortement recommandé : testez votre fonction.

    Pour l’exemple de fonction Python fournie par Snowflake, utilisez les données de test suivantes (remplacez toutes les données par défaut par les données ci-dessous) :

    {
      "body":
        "{ \"data\": [ [ 0, 43, \"page\" ], [ 1, 42, \"life, the universe, and everything\" ] ] }"
    }
    

    Les résultats d’exécution doivent être similaires à ceci :

    {
      "statusCode": 200,
      "body": "{\"data\": [[0, [\"Echoing inputs:\", 43, \"page\"]], [1, [\"Echoing inputs:\", 42, \"life, the universe, and everything\"]]]}"
    }
    

Si le précédent a fonctionné correctement, vous disposez maintenant d’une fonction AWS Lambda que vous pouvez utiliser comme service distant pour votre fonction externe.

Étape 2 : Configurer le service proxy (Amazon API Gateway) et créer l’intégration API (dans Snowflake)

Configurer Amazon API Gateway en tant que service proxy nécessite plusieurs étapes, notamment :

  • Création d’un nouveau rôle IAM dans votre compte AWS.

  • Création et configuration d’un point de terminaison Amazon API Gateway.

  • Sécurisation de votre point de terminaison Amazon API Gateway.

  • Création d’un objet d’intégration API dans Snowflake.

  • Configuration d’une relation de confiance entre Snowflake et le nouveau rôle IAM.

Les étapes pour les créer sont entrelacées, car l’intégration API a besoin d’informations de l’API Gateway (l’ARN (Amazon Resource Name) du rôle), et l’API Gateway a besoin d’informations de l’intégration API (le API_AWS_EXTERNAL_ID et le API_AWS_IAM_USER_ARN).

Créer un nouveau rôle IAM dans votre compte AWS

Pour que Snowflake s’authentifie auprès de votre compte AWS, un utilisateur IAM appartenant à Snowflake (gestion des identités et des accès) doit être autorisé à assumer un rôle IAM dans votre compte AWS. Pour ce faire, une relation de confiance doit être établie. Pour établir la relation de confiance, vous devez créer un rôle IAM sur votre compte AWS et le configurer avec l’ARN de l’utilisateur IAM appartenant à Snowflake, et vous devez créer un objet d’intégration API dans Snowflake et configurer l’objet d’intégration API avec les informations sur le rôle IAM à assumer.

  1. Créez un nouveau rôle IAM.

  2. Lorsque vous devez sélectionner le type d’entité de confiance, choisissez Another AWS account.

  3. Lorsqu’on vous demande de Specify accounts that can use this role, collez la valeur du champ « ID du compte AWS » de la feuille de calcul.

  4. Cliquez sur Next: Permissions.

  5. Définissez les autorisations (Attach permissions policies) si nécessaire.

  6. Entrez un nom de rôle.

    • Enregistrez le nom du rôle dans le champ « Nom du nouveau rôle IAM » de la feuille de calcul.

  7. Cliquez sur le bouton Create role. Après avoir créé le rôle :

    • Enregistrez le Role ARN dans le champ « ARN du nouveau rôle IAM » de la feuille de travail.

Créer et configurer une API dans Amazon API Gateway

Choisissez votre type de point de terminaison : point de terminaison régional vs. point de terminaison privé

Vous accédez à un service proxy (tel que Amazon API Gateway) via une URI, souvent appelé point de terminaison. Pour votre Amazon API Gateway, vous pouvez créer, au choix :

  • Un point de terminaison régional.

  • Un point de terminaison privé.

Un point de terminaison régional peut être accessible à travers les régions ou même les Clouds. Votre instance Snowflake, votre service proxy et votre service à distance peuvent tous se trouver dans des régions différentes ou même sur des plateformes Cloud différentes. Par exemple, une instance de Snowflake fonctionnant sur Azure pourrait envoyer des requêtes à un point de terminaison régional Amazon API Gateway, qui à son tour pourrait transmettre des données à un service distant fonctionnant sur GCP.

Un point de terminaison privé peut être configuré pour permettre l’accès uniquement à partir d’un VPC (Cloud privé virtuel) Snowflake dans la même région AWS via PrivateLink.

Pour plus de détails sur les types de points de terminaison sur AWS, voir :

Si vous souhaitez utiliser un point de terminaison privé et que vous n’êtes pas sûr de la région que vous utilisez, vous pouvez rechercher votre région en procédant de l’une des manières suivantes :

  • Appelez la fonction SQL CURRENT_REGION() (par exemple SELECT CURRENT_REGION()).

  • Vérifiez le nom d’hôte de votre compte Snowflake, qui indique normalement le fournisseur de services Cloud et la région. Pour plus d’informations sur les noms d’hôtes, les régions et les fournisseurs de services Cloud relatifs aux comptes, voir Régions Cloud prises en charge.

Pour utiliser un point de terminaison privé, votre compte doit remplir les conditions suivantes :

  • Édition Business Critical (ou supérieure) de Snowflake.

Sur AWS, Snowflake prend en charge la connexion des comptes Snowflake aux VPCs AWS. Les points de terminaison privés permettent la communication entre VPCs (Clouds privés virtuels) via PrivateLink. Pour plus d’informations sur Snowflake et AWS PrivateLink, voir :

Créer le point de terminaison API Gateway

Avant de créer et de configurer votre API Gateway, choisissez si vous voulez utiliser un point de terminaison régional ou privé. Pour plus d’informations, voir Choisissez votre type de point de terminaison : point de terminaison régional vs. point de terminaison privé.

Note

Vous pouvez créer une fonction externe sur des instances de Snowflake non hébergées par AWS. Si votre entrepôt virtuel se trouve sur Azure ou GCP (Google Cloud Platform), vous pouvez créer une fonction externe qui accède à un service distant via une Amazon API Gateway.

Les étapes pour créer un point de terminaison API Gateway sont les suivantes :

  1. Si vous prévoyez d’utiliser un point de terminaison privé, obtenez l’ID du VPC (Cloud privé virtuel) en exécutant la commande suivante dans l’interface Web Snowflake :

    select system$get_snowflake_platform_info();
    

    La sortie devrait ressembler à ce qui suit :

    {"snowflake-vpc-id":["vpc-12345699"]}
    

    Enregistrez l’ID du VPC (par exemple « vpc-12345699 ») dans le champ « ID du VPC Snowflake » de la feuille de calcul.

    (Remarque : vous devez utiliser un ID de VPC et non un ID de point de terminaison VPC. Les IDs de points de terminaison VPC peuvent changer au fil du temps).

  2. Dans la console de gestion AWS, sélectionnez API Gateway.

  3. Sélectionnez Create API.

  4. Sélectionnez le type de point de terminaison (régional ou privé).

    • Si vous voulez un point de terminaison régional , alors :

      • Trouvez REST API et cliquez sur son bouton Build .

    • Si vous voulez un point de terminaison privé, alors :

      • Trouvez REST API private et cliquez sur son bouton Build .

    Important

    Veillez à choisir REST API ou REST API private . Ne sélectionnez pas HTTP API ou une autre option.

  5. Sélectionnez l’option New API .

  6. Saisissez un nom pour la nouvelle API.

    Enregistrez ce nom dans le champ « Nom de la nouvelle API » de la feuille de calcul.

  7. Si on vous demande de sélectionner un Endpoint Type, sélectionnez Regional ou Private.

  8. Si vous créez un point de terminaison privé, entrez l’ID du VPC Snowflake enregistré dans le champ « ID du VPC Snowflake » dans la feuille de calcul.

    (Si vous ne créez pas de point de terminaison privé, vous n’avez pas besoin d’entrer un ID de VPC.)

  9. Cliquez sur le bouton Create API.

    Cela devrait vous amener à un nouvel écran qui vous permet de créer des ressources.

  10. Créez une ressource.

    (Vous devrez peut-être cliquer sur le bouton Actions pour voir l’option Create Resource.)

    Enregistrez le nom de la ressource dans le champ « Nom de la ressource API Gateway » de la feuille de calcul.

    Après avoir cliqué sur le bouton Create Resource l’écran devrait afficher No methods defined for the resource.

  11. Créez une nouvelle méthode. Cliquez sur Actions et sélectionnez Create Method pour cette ressource.

    Spécifiez l’option POST. (Si vous ne voyez pas l’option POST cliquez sur la petite boîte de menu déroulant sous le nom de la ressource).

    Une nouvelle fenêtre devrait alors s’ouvrir et afficher Integration type ainsi que d’autres options.

  12. Integration type devrait être Lambda Function. Si ce n’est pas déjà sélectionné, sélectionnez-le.

  13. Cliquez sur la case à cocher Use Lambda Proxy integration.

    Il est important de sélectionner une intégration de proxy Lambda, car le JSON sans intégration du proxy Lambda serait différent du JSON avec intégration du proxy Lambda. Pour plus d’informations sur l’intégration du proxy Lambda, voir la documentation AWS pour :

  14. Dans le champ Lambda Function , collez le nom de la fonction Lambda que vous avez enregistré dans la feuille de calcul.

  15. Enregistrez.

  16. Cliquez sur le bouton Actions , et sélectionnez l’action Deploy API .

  17. Sélectionnez ou créez une zone de préparation pour cette fonction.

  18. Sous le nom de la ressource, vous devriez voir POST.

    Si ce n’est pas le cas, vous devrez peut-être développer l’arbre des ressources en cliquant sur le triangle qui se trouve à gauche du nom de la ressource.

  19. Cliquez sur POST, puis enregistrez Invoke URL de la demande POST dans le champ « Resource Invocation URL » de la feuille de calcul.

    Assurez-vous que l’URL d’appel inclut le nom de la ressource que vous avez créée ; si ce n’est pas le cas, vous avez peut-être cliqué sur l’URL d’appel pour la zone de préparation plutôt que pour la ressource.

  20. Cliquez sur Save Changes.

Protégez votre point de terminaison Amazon API Gateway

Pour un aperçu de la sécurisation des points de terminaison du service proxy, comme les point de terminaison Amazon API Gateway, voir Sécuriser le service proxy.

Pour sécuriser un point de terminaison Amazon API Gateway :

  1. À ce stade, vous devriez être sur l’écran qui affiche vos informations sur API Gateway, et vous devriez voir votre ressource et la méthode POST.

    Si vous n’y êtes pas déjà, faites ce qui suit :

    1. Dans la console de gestion AWS, allez à la page API Gateway.

    2. Sélectionnez votre API Gateway si vous ne l’avez pas encore fait.

    3. Dans le volet de gauche, cliquez sur Resources .

    4. Cliquez sur la méthode POST . (Si vous ne voyez pas cela, développez l’arbre des ressources en cliquant sur le triangle à gauche de la ressource dans le panneau Resources , qui est généralement le deuxième panneau à partir de la gauche).

  2. Copiez l”Method Request ARN de la case Method Request vers le champ « ARN de la requête de méthode » de la feuille de calcul.

  3. Cliquez sur le titre Method Request.

  4. Précisez que le Method Request nécessite l’autorisation du AWS_IAM.

    Notez qu’après avoir sélectionné l’autorisation AWS_IAM dans le menu déroulant, vous devez cliquer sur la petite coche à côté du menu pour confirmer votre choix.

  5. Définissez la politique de ressource pour API Gateway afin de spécifier qui est autorisé à appeler le point de terminaison de la passerelle.

    Pour accéder à la fenêtre d’édition qui vous permet de saisir une politique de ressources, vous devrez peut-être cliquer sur Resource Policy dans la colonne de gauche de la fenêtre pour l” API.

    • Point de terminaison régional :

      Collez le modèle de politique de ressources ci-dessous dans l’éditeur de politique de ressources au format JSON, puis remplacez les caractères de remplissage par les valeurs appropriées de la feuille de calcul, comme décrit ci-dessous.

      {
          "Version": "2012-10-17",
          "Statement":
          [
              {
              "Effect": "Allow",
              "Principal":
                  {
                  "AWS": "arn:aws:sts::<12-digit-number>:assumed-role/<external_function_role>/snowflake"
                  },
              "Action": "execute-api:Invoke",
              "Resource": "<method_request_ARN>"
              }
          ]
      }
      

      Remplacez les parties suivantes de la politique de ressource :

      • Remplacez le <numéro à 12chiffres> par l’ID de compte AWS, que vous avez enregistré dans la feuille de calcul.

      • Remplacez <rôle_fonction_externe> par le nom de rôle du champ « Nom du nouveau rôle IAM » de la feuille de calcul.

        Par exemple, si votre nom de rôle AWS est :

        arn:aws:iam::987654321098:role/MyNewIAMRole
        

        alors le résultat devrait être :

        "AWS": "arn:aws:sts::987654321098:assumed-role/MyNewIAMRole/snowflake"
        
      • Remplacez <ARN_demande_méthode> par la valeur du champ « ARN de la demande de méthode » de la feuille de calcul. Il s’agit de l’ARN de la méthode POST de la ressource.

        Note

        La définition de la ressource sur l’ARN de la demande de méthode spécifie que l’API Gateway doit autoriser les appels uniquement vers la ressource spécifiée. Il est possible de spécifier un sous-ensemble de l’ARN de la demande de méthode comme préfixe, ce qui permet d’appeler plusieurs ressources à partir de la même API Gateway.

        Par exemple, si l’ARN de la demande de méthode est :

        arn:aws:execute-api:us-west-1:123456789012:a1b2c3d4e5/*/POST/MyResource
        

        alors vous pouvez spécifier simplement le préfixe suivant :

        arn:aws:execute-api:us-west-1:123456789012:a1b2c3d4e5/*/
        
    • Point de terminaison privé :

      Collez le modèle de politique de ressources ci-dessous dans l’éditeur de politique de ressources, puis remplacez les caractères de remplissage par les valeurs appropriées de la feuille de calcul, comme décrit ci-dessous.

      {
          "Version": "2012-10-17",
          "Statement": [
              {
                  "Effect": "Allow",
                  "Principal": {
                      "AWS": "arn:aws:sts::<12-digit-number>:assumed-role/<external_function_role>/snowflake"
                  },
                  "Action": "execute-api:Invoke",
                  "Resource": "<method_request_ARN>",
                  "Condition": {
                      "StringEquals": {
                          "aws:sourceVpc": "<VPC_ID>"
                      }
                  }
              }
          ]
      }
      

      Remplacez les parties suivantes de la politique de ressource :

      • Remplacez les valeurs de <12-digit-number>, <external_function_role> et <method_request_ARN> comme décrit ci-dessus pour un point de terminaison régional.

      • Remplacez la valeur de <VPC_ID> par l’ID du VPC Snowflake de votre région, qui doit être enregistré dans le champ « ID du VPC Snowflake » de la feuille de calcul.

  6. Si vous n’avez pas encore cliqué sur Save pour enregistrer la politique des ressources, faites-le maintenant.

  7. Déployez l’API mise à jour.

Dans les étapes suivantes, vous créez un objet d’intégration API Snowflake. Ne fermez pas votre fenêtre d’administration AWS maintenant ; vous devrez y revenir plus tard.

Créer un objet d’intégration API dans Snowflake

  1. Ouvrez (si vous ne l’avez pas déjà fait) une session Snowflake, généralement une session d’interface Web Snowflake.

  2. Utilisez un rôle Snowflake avec des privilèges ACCOUNTADMIN ou le privilège CREATE INTEGRATION, par exemple :

    use role has_accountadmin_privileges;
    
  3. Tapez la commande CREATE API INTEGRATION pour créer une intégration API. La commande doit ressembler à ce qui suit :

    CREATE OR REPLACE API INTEGRATION my_api_integration_01
      api_provider = aws_api_gateway
      api_aws_role_arn = '<new_IAM_role_ARN>'
      api_allowed_prefixes = ('https://')
      enabled = true;
    

    Personnalisez la commande :

    • Si vous utilisez un point de terminaison privé, la clause api_provider doit être définie sur aws_private_api_gateway. Sinon, la clause api_provider doit être définie sur aws_api_gateway.

    • Le <nouveau_ARN_de_rôle_IAM> doit être la valeur du champ « Nouveau ARN de rôle IAM » dans la feuille de calcul.

    • Le champ api_allowed_prefixes doit contenir l’URL de l’appel de ressource que vous avez enregistrée précédemment.

    • Vous pouvez également souhaiter personnaliser le nom de l’intégration API, plutôt que d’utiliser la valeur dans l’exemple.

    Voici un exemple d’une instruction CREATE API INTEGRATION complète :

    create or replace api integration demonstration_external_api_integration_01
        api_provider=aws_api_gateway
        api_aws_role_arn='arn:aws:iam::123456789012:role/my_cloud_account_role'
        api_allowed_prefixes=('https://xyz.execute-api.us-west-2.amazonaws.com/production/')
        enabled=true;
    
  4. Dans le champ de la feuille de travail intitulé « Nom de l’intégration API », enregistrez le nom de l’intégration API que vous avez créée. Vous aurez besoin du nom de l’intégration API lorsque vous exécuterez la commande CREATE EXTERNAL FUNCTION ultérieurement.

  5. Exécutez la commande CREATE API INTEGRATION que vous avez tapée ci-dessus.

  6. Exécutez la commande DESCRIBE INTEGRATION.

    DESCRIBE INTEGRATION <my_integration_name>;
    

    Par exemple :

    DESCRIBE INTEGRATION my_api_integration_01;
    
  7. Recherchez la propriété nommée API_AWS_IAM_USER_ARN puis enregistrez la property_value de cette propriété dans la feuille de calcul.

  8. Trouvez la propriété nommée API_AWS_EXTERNAL_ID puis enregistrez la property_value de cette propriété dans la feuille de calcul.

    Notez que la property_value de API_AWS_EXTERNAL_ID se termine souvent par un signe égal (« = »). Ce signe égal fait partie de la valeur ; assurez-vous de le couper et de le coller avec le reste de la valeur_propriété.

Pour les étapes suivantes, vous retournez à votre fenêtre d’administration AWS. Ne fermez pas votre fenêtre d’administration Snowflake maintenant ; vous devez y revenir plus tard.

Configurer la relation de confiance entre Snowflake et le nouveau rôle IAM

Dans la console de gestion AWS :

  1. Sélectionnez IAM.

  2. Sélectionnez Roles.

  3. Dans la feuille de travail, recherchez la valeur dans le champ « Nom du nouveau rôle IAM », puis recherchez la même valeur (nom du rôle) dans la console de gestion AWS.

  4. Cliquez sur l’onglet Trust relationships puis cliquez sur le bouton Edit trust relationship.

    Cela devrait ouvrir le Policy Document dans lequel vous pouvez ajouter des informations d’authentification.

  5. Dans le Policy Document trouvez le champ Statement.Principal.AWS et remplacez la valeur (pas la clé) par la valeur du champ « API_AWS_IAM_USER_ARN » de la feuille de calcul.

  6. Trouvez le champ Statement.Condition. Initialement, cela ne devrait contenir que des accolades (« {} »).

  7. Collez ce qui suit entre les accolades : "StringEquals": { "sts:ExternalId": "xxx" }.

  8. Remplacez le xxx par la valeur du champ « API_AWS_EXTERNAL_ID » de la feuille de calcul.

  9. Une fois que vous avez terminé de modifier le Policy Document pour la relation de confiance, cela devrait ressembler à ce qui suit :

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Principal": {
            "AWS": "arn:aws:iam::1234567898012:user/development/development_user"
          },
          "Action": "sts:AssumeRole",
          "Condition": {"StringEquals": { "sts:ExternalId": "EXTERNAL_FUNCTIONS_SFCRole=3_8Hcmbi9halFOkt+MdilPi7rdgOv=" }}
        }
      ]
    }
    
  10. Cliquez sur Update Trust Policy.

Etape 3 : Créer la fonction externe

Retournez maintenant à l’interface Web de Snowflake (où vous avez précédemment tapé la commande CREATE API INTEGRATION).

  1. Tapez la commande CREATE EXTERNAL FUNCTION. Cela devrait ressembler à ce qui suit :

    CREATE EXTERNAL FUNCTION my_external_function(n INTEGER, v VARCHAR)
        RETURNS VARIANT
        API_INTEGRATION = <api_integration_name>
        AS '<resource_invocation_url>';
    

    Personnalisez la commande :

    • La valeur <api_integration_name> doit contenir le nom de l’intégration API que vous avez créée précédemment.

    • La valeur <resource_invocation_url> doit être l’URL d’appel de ressource que vous avez enregistrée dans la feuille de calcul. Assurez-vous que cette URL inclut le nom de la ressource API Gateway, pas seulement le nom de la zone de préparation.

    • Vous pouvez également personnaliser le nom de la fonction.

    Cet exemple transmet deux arguments (un INTEGER et un VARCHAR), car ce sont les arguments que la fonction Lambda attend. Lorsque vous créerez votre propre fonction Lambda, vous devez transmettre les arguments appropriés pour votre fonction Lambda.

  2. Dans la feuille de calcul, enregistrez le nom de la fonction externe que vous avez créée dans le champ intitulé « Nom de la fonction externe ».

  3. Si vous n’avez pas encore exécuté la commande CREATE EXTERNAL FUNCTION que vous avez tapée ci-dessus, exécutez-la maintenant.

Etape 4 : Appeler la fonction externe

  1. Le cas échéant, accordez le privilège USAGE sur la fonction externe à un ou plusieurs rôles Snowflake afin que ces rôles puissent appeler la fonction externe. (Un rôle doit avoir des privilèges USAGE ou OWNERSHIP sur cette fonction externe.)

  2. Exécutez votre fonction en appelant :

    SELECT my_external_function(42, 'Adams');
    

    Si vous avez personnalisé le nom de la fonction dans la commande CREATE EXTERNAL FUNCTION , alors remplacez « ma_fonction_externe » par le nom personnalisé.

    La valeur renvoyée doit être similaire à :

    [0, 42, "Adams"]
    

    42, "Adams" est la valeur renvoyée et 0 est le numéro de ligne de la valeur renvoyée.

Création d’une fonction asynchrone sur AWS (lecture facultative)

Pour que le tutoriel reste simple, il crée un exemple de fonction externe synchrone. Des fonctions externes plus sophistiquées peuvent bénéficier du fait d’être asynchrones.

Cette section de la documentation fournit des informations sur la création d’une fonction externe asynchrone sur AWS. (Avant de mettre en œuvre votre première fonction externe asynchrone, vous pouvez lire l” aperçu conceptuel des fonctions externes asynchrones).

Sur AWS, les services à distance asynchrones doivent surmonter les restrictions suivantes :

  • Comme les requêtes HTTP POST et GET sont des requêtes distinctes, le service distant doit conserver des informations sur le workflow lancé par la requête POST afin que l’état puisse être interrogé ultérieurement par la requête GET.

    En général, chaque requête HTTP POST et HTTP GET appelle une instance distincte de la ou des fonctions de gestionnaire dans un processus ou un chemin distinct. Les différentes instances ne partagent pas leur mémoire. Pour que le gestionnaire GET puisse lire le statut ou les données traitées, le gestionnaire GET doit accéder à une ressource de stockage partagée qui est disponible sur AWS.

  • La seule façon pour le gestionnaire POST d’envoyer le code de réponse initial HTTP 202 est d’utiliser une instruction return (ou un équivalent), qui met fin à l’exécution du gestionnaire. Par conséquent, avant de renvoyer HTTP 202, le gestionnaire POST doit lancer un processus indépendant (ou thread) pour effectuer le travail de traitement des données du service à distance. Ce processus indépendant nécessite généralement un accès au stockage qui est visible pour le gestionnaire GET.

Un moyen pour un service distant asynchrone de surmonter ces restrictions est d’utiliser 3 processus (ou chemins) et un stockage partagé :

Illustration of processes for an Asynchronous Remote Service

Dans ce modèle, les processus ont les responsabilités suivantes :

  • Le gestionnaire HTTP POST :

    • Lit les données d’entrée. Dans une fonction Lambda, elle est lue à partir du corps du paramètre d’entrée event de la fonction de gestionnaire.

    • Lit l’ID de lot. Dans une fonction Lambda, ceci est lu à partir de l’en-tête du paramètre d’entrée event .

    • Lance le processus de traitement des données, et lui transmet les données et l’ID de lot. Les données sont généralement transmises pendant l’appel, mais elles peuvent être transmises en les écrivant sur un stockage externe.

    • Enregistre l’ID de lot dans un stockage partagé auquel peuvent accéder à la fois le processus de traitement des données et le processus du gestionnaire HTTP GET.

    • Si nécessaire, enregistre que le traitement de ce lot n’est pas encore terminé.

    • Retourne HTTP 202 si aucune erreur n’a été détectée.

  • Le code de traitement des données :

    • Lit les données d’entrée.

    • Traite les données.

    • Met le résultat à la disposition du gestionnaire GET (soit en écrivant les données de résultat sur un stockage partagé, soit en fournissant une API permettant d’interroger les résultats).

    • Généralement, il met à jour le statut de ce lot (par exemple de IN_PROGRESS à SUCCESS) pour indiquer que les résultats sont prêts à être lus.

    • Quitte. En option, ce processus peut renvoyer un indicateur d’erreur. Snowflake ne le voit pas directement (Snowflake ne voit que les codes de retour HTTP du gestionnaire POST et du gestionnaire GET), mais le renvoi d’un indicateur d’erreur du processus de traitement des données pourrait aider au débogage.

  • Le gestionnaire GET :

    • Lit l’ID de lot. Dans une fonction Lambda, ceci est lu à partir de l’en-tête du paramètre d’entrée event .

    • Lit le stockage pour obtenir le statut actuel de ce lot (par exemple IN_PROGRESS ou SUCCESS).

    • Si le traitement est toujours en cours, alors retournez 202.

    • Si le traitement s’est terminé avec succès, alors :

      • Lisez les résultats.

      • Nettoyez le stockage.

      • Renvoyez les résultats avec le code HTTP 200.

    • Si le statut stocké indique une erreur, alors :

      • Nettoyez le stockage.

      • Renvoyez un code d’erreur.

    Notez que le gestionnaire GET peut être appelé plusieurs fois pour un lot si le traitement prend suffisamment de temps pour que plusieurs requêtes HTTP GET soient envoyées.

Il existe de nombreuses variations possibles sur ce modèle. Par exemple :

  • L’ID de lot et le statut pourraient être écrits au début du processus de traitement des données plutôt qu’à la fin du processus POST.

  • Le traitement des données pourrait être effectué dans une fonction distincte (par exemple, une fonction Lambda distincte) ou même comme un service complètement distinct.

  • Le code de traitement des données ne doit pas nécessairement être écrit sur un stockage partagé. Au lieu de cela, les données traitées pourraient être mises à disposition d’une autre manière. Par exemple, une API pourrait accepter l’ID de lot comme paramètre et renvoyer les données.

Le code de mise en œuvre doit tenir compte de la possibilité que le traitement prenne trop de temps ou échoue, et tout résultat partiel doit donc être nettoyé pour éviter de gaspiller de l’espace de stockage.

Le mécanisme de stockage doit pouvoir être partagé entre plusieurs processus (ou chemins). Parmi les mécanismes de stockage possibles, on peut citer :

Le code de chacun des 3 processus ci-dessus peut être écrit comme 3 fonctions Lambda séparées (une pour le gestionnaire POST, une pour la fonction de traitement des données et une pour le gestionnaire GET), ou comme une fonction unique qui peut être appelée de différentes manières.

L’exemple de code Python ci-dessous est une fonction Lambda unique qui peut être appelée séparément pour les processus POST, le traitement des données et GET.

Ce code montre un exemple de requête avec sortie. Dans cet exemple, l’accent est mis sur les trois processus et leur interaction, et non sur le mécanisme de stockage partagé (DynamoDB) ou la transformation des données (analyse des sentiments). Le code est structuré de manière à faciliter le remplacement du mécanisme de stockage et de transformation des données par d’autres.

Par souci de simplicité, voici un exemple :

  • Code en dur certaines valeurs importantes (par exemple, la région AWS).

  • Suppose l’existence de certaines ressources (par exemple, la table Jobs dans Dynamo).

import json
import time
import boto3

HTTP_METHOD_STRING = "httpMethod"
HEADERS_STRING = "headers"
BATCH_ID_STRING = "sf-external-function-query-batch-id"
DATA_STRING = "data"
REGION_NAME = "us-east-2"

TABLE_NAME = "Jobs"
IN_PROGRESS_STATUS = "IN_PROGRESS"
SUCCESS_STATUS = "SUCCESS"

def lambda_handler(event, context):
    # this is called from either the GET or POST
    if (HTTP_METHOD_STRING in event):
        method = event[HTTP_METHOD_STRING]
        if method == "POST":
            return initiate(event, context)
        elif method == "GET":
            return poll(event, context)
        else:
            return create_response(400, "Function called from invalid method")

    # if not called from GET or POST, then this lambda was called to
    # process data
    else:
        return process_data(event, context)


# Reads batch_ID and data from the request, marks the batch_ID as being processed, and
# starts the processing service.
def initiate(event, context):
    batch_id = event[HEADERS_STRING][BATCH_ID_STRING]
    data = json.loads(event["body"])[DATA_STRING]

    lambda_name = context.function_name

    write_to_storage(batch_id, IN_PROGRESS_STATUS, "NULL")
    lambda_response = invoke_process_lambda(batch_id, data, lambda_name)

    # lambda response returns 202, because we are invoking it with
    # InvocationType = 'Event'
    if lambda_response["StatusCode"] != 202:
        response = create_response(400, "Error in inititate: processing lambda not started")
    else:
        response = {
            'statusCode': lambda_response["StatusCode"]
        }

    return response


# Processes the data passed to it from the POST handler. In this example,
# the processing is to perform sentiment analysis on text.
def process_data(event, context):
    data = event[DATA_STRING]
    batch_id = event[BATCH_ID_STRING]

    def process_data_impl(data):
        comprehend = boto3.client(service_name='comprehend', region_name=REGION_NAME)
        # create return rows
        ret = []
        for i in range(len(data)):
            text = data[i][1]
            sentiment_response = comprehend.detect_sentiment(Text=text, LanguageCode='en')
            sentiment_score = json.dumps(sentiment_response['SentimentScore'])
            ret.append([i, sentiment_score])
        return ret

    processed_data = process_data_impl(data)
    write_to_storage(batch_id, SUCCESS_STATUS, processed_data)

    return create_response(200, "No errors in process")


# Repeatedly checks on the status of the batch_ID, and returns the result after the
# processing has been completed.
def poll(event, context):
    batch_id = event[HEADERS_STRING][BATCH_ID_STRING]
    processed_data = read_data_from_storage(batch_id)

    def parse_processed_data(response):
        # in this case, the response is the response from DynamoDB
        response_metadata = response['ResponseMetadata']
        status_code = response_metadata['HTTPStatusCode']

        # Take action depending on item status
        item = response['Item']
        job_status = item['status']
        if job_status == SUCCESS_STATUS:
            # the row number is stored at index 0 as a Decimal object,
            # we need to convert it into a normal int to be serialized to JSON
            data = [[int(row[0]), row[1]] for row in item['data']]
            return {
                'statusCode': 200,
                'body': json.dumps({
                    'data': data
                })
            }
        elif job_status == IN_PROGRESS_STATUS:
            return {
                'statusCode': 202,
                "body": "{}"
            }
        else:
            return create_response(500, "Error in poll: Unknown item status.")

    return parse_processed_data(processed_data)


def create_response(code, msg):
    return {
        'statusCode': code,
        'body': msg
    }


def invoke_process_lambda(batch_id, data, lambda_name):
    # Create payload to be sent to processing lambda
    invoke_payload = json.dumps({
        BATCH_ID_STRING: batch_id,
        DATA_STRING: data
    })

    # Invoke processing lambda asynchronously by using InvocationType='Event'.
    # This allows the processing to continue while the POST handler returns HTTP 202.
    lambda_client = boto3.client('lambda', region_name=REGION_NAME,)
    lambda_response = lambda_client.invoke(
        FunctionName=lambda_name,
        InvocationType='Event',
        Payload=invoke_payload
    )
    # returns 202 on success if InvocationType = 'Event'
    return lambda_response


def write_to_storage(batch_id, status, data):
    # we assume that the table has already been created
    client = boto3.resource('dynamodb')
    table = client.Table(TABLE_NAME)

    # Put in progress item in table
    item_to_store = {
        'batch_id': batch_id,
        'status': status,
        'data': data,
        'timestamp': "{}".format(time.time())
    }
    db_response = table.put_item(
        Item=item_to_store
    )


def read_data_from_storage(batch_id):
    # we assume that the table has already been created
    client = boto3.resource('dynamodb')
    table = client.Table(TABLE_NAME)

    response = table.get_item(Key={'batch_id': batch_id},
                          ConsistentRead=True)
    return response

Voici un exemple d’appel à la fonction externe asynchrone, ainsi qu’un exemple de sortie, y compris les résultats de l’analyse des sentiments :

create table test_tb(a string);
insert into test_tb values
    ('hello world'),
    ('I am happy');
select ext_func_async(a) from test_tb;

Row | EXT_FUNC_ASYNC(A)
0   | {"Positive": 0.47589144110679626, "Negative": 0.07314028590917587, "Neutral": 0.4493273198604584, "Mixed": 0.0016409909585490823}
1   | {"Positive": 0.9954453706741333, "Negative": 0.00039307220140472054, "Neutral": 0.002452891319990158, "Mixed": 0.0017087293090298772}

Notes sur l’exemple de code :

  • La fonction de traitement des données est appelée par un appel :

    lambda_response = lambda_client.invoke(
        ...
        InvocationType='Event',
        ...
    )
    

    Le InvocationType doit être un « événement », comme indiqué ci-dessus, car le 2e processus (ou chemin) doit être asynchrone et Event est le seul type d’appel non bloquant disponible par la méthode invoke() .

  • La fonction de traitement des données renvoie un code HTTP 200. Toutefois, ce code HTTP 200 n’est pas renvoyé directement à Snowflake. Snowflake ne voit aucun HTTP 200 jusqu’à ce qu’un GET interroge le statut et constate que la fonction de traitement des données a terminé le traitement de ce lot avec succès.

Dépannage des fonctions externes sur AWS

Symptômes indépendants de la plate-forme

Les valeurs de retour réelles pour un type de données ne correspondent pas aux valeurs de retour attendues

Lorsque vous transmettez des arguments vers ou depuis une fonction externe, assurez-vous que les types de données sont appropriés. Si la valeur envoyée ne peut pas correspondre au type de données reçues, la valeur peut être tronquée ou corrompue d’une autre manière.

Pour plus de détails, voir Assurez-vous que les arguments de la fonction externe correspondent aux arguments analysés par le service distant.

Lorsque vous appelez votre fonction à partir de SQL, vous obtenez un message indiquant que les numéros de ligne ne sont pas en ordre

Cause(s) possible(s)

N’oubliez pas que les numéros de ligne que vous renvoyez dans chaque lot doivent être des entiers ascendants monotones à partir de 0. Les numéros de ligne d’entrée doivent également suivre cette règle, et chaque ligne sortie doit correspondre à la ligne d’entrée correspondante (par exemple, la sortie dans la ligne de sortie 0 doit correspondre à l’entrée dans la ligne d’entrée 0).

Solution(s) possible(s)
  1. Assurez-vous que les numéros de ligne que vous renvoyez sont identiques à ceux que vous avez reçus et que chaque valeur de sortie utilise le numéro de ligne de l’entrée correspondante. Cela devrait fonctionner. Si ce n’est pas le cas, il est possible que les numéros de ligne en entrée ne soient pas corrects ou que vous n’ayez pas renvoyé les lignes dans le bon ordre. Passez donc à l’étape 2 ci-dessous.

  2. Assurez-vous que les numéros de ligne de sortie commencent par 0, augmentent de 1 et sont en ordre.

Pour plus d’informations sur les formats d’entrée et de sortie des données, voir Formats des données d’entrée et de sortie des services à distance.

Lorsque vous essayez d’appeler la fonction externe, vous obtenez le message « Erreur d’analyse JSON : réponse non valide »

Cause(s) possible(s)

La cause la plus probable est que le JSON renvoyé par le service distant (par exemple fonction AWS Lambda) n’est pas construit correctement.

Solution(s) possible(s)

Assurez-vous de renvoyer un tableau de tableaux, avec un tableau interne renvoyé pour chaque ligne d’entrée reçue. Consultez la description du format de sortie sur Format de données reçu par Snowflake.

Un message d’erreur indiquant que la valeur renvoyée n’est pas au format JSON

Cause(s) possible(s)

Une cause possible de ceci est que votre valeur de retour inclut des guillemets doubles à l’intérieur de la valeur.

Solution(s) possible(s)

Bien que les chaînes JSON soient délimitées par des guillemets doubles, la chaîne elle-même ne doit pas commencer et se terminer par un guillemet dans la plupart des cas. Si les guillemets doubles intégrés sont incorrects, supprimez-les.

Un message d’erreur indiquant que la fonction a reçu le mauvais nombre de lignes

Cause(s) possible(s)

Le service distant a probablement tenté de renvoyer plus ou moins de lignes qu’il en a reçues. (N’oubliez pas, même si la fonction est nominalement scalaire, elle peut recevoir plusieurs lignes dans le champ « body » du paramètre « event » et doit renvoyer exactement autant de lignes qu’elle a reçues.)

Solution(s) possible(s)

Assurez-vous que le service distant renvoie une ligne pour chaque ligne qu’il reçoit.

Symptômes spécifiques à la plate-forme

Une API Gateway renvoie une erreur 502 lorsque le point de terminaison utilise l’intégration du proxy Lambda

Cause(s) possible(s)

La fonction Lambda peut avoir :

  • Expiré.

  • Renvoyé une exception.

  • Echoué d’une autre manière.

Solution(s) possible(s)

Si les journaux Lambda ou API Gateway sont à votre disposition, examinez-les.

Si le code source de la fonction Lambda est à votre disposition, analysez et déboguez le code dans la fonction Lambda. Dans certains cas, vous pourrez peut-être exécuter une copie de ce code dans un contexte plus simple (en dehors de AWS) pour faciliter le débogage.

Vérifiez que les données envoyées à la fonction Lambda sont au format attendu par la fonction Lambda. Vous voudrez peut-être essayer d’envoyer un ensemble de données plus petit et plus simple pour voir si cela réussit.

Vérifiez que vous n’envoyez pas trop de données à la fois.

Dans certains cas, l’augmentation du délai d’attente peut résoudre le problème, en particulier si la fonction Lambda nécessite beaucoup de ressources CPU, ou si la fonction Lambda elle-même appelle d’autres services distants et nécessite donc plus de temps.

Impossible de lire le corps des requêtes au sein de la méthode HTTP POST dans la fonction Amazon AWS Lambda

Cause(s) possible(s)

Vous n’avez peut-être pas activé l’intégration du proxy Lambda.

Solution(s) possible(s)

Activation de l’intégration des proxy Lambda.

Pour plus de détails, voir les étapes correspondantes dans Créer et configurer une API dans Amazon API Gateway.

Erreur : Error assuming AWS_ROLE

Le texte intégral du message est le suivant :

SQL execution error: Error assuming AWS_ROLE. Please verify the role and externalId are configured correctly in your AWS policy.

Cause(s) possible(s)
  • Dans la stratégie de relation de confiance AWS pour votre rôle, l’ARN AWS est incorrect. Les causes possibles de cela comprennent :

    • Vous ne l’avez pas défini.

    • Vous l’avez défini, mais vous avez utilisé l’ARN du rôle AWS (incorrect) au lieu de l’ARN utilisateur, que vous pouvez voir à partir de la commande DESCRIBE INTEGRATION dans Snowflake. Veillez à utiliser la valeur du champ « API_AWS_IAM_USER_ARN » de la feuille de calcul plutôt que la valeur du champ « API_AWS_ROLE_ARN ».

  • Dans votre stratégie de relation de confiance AWS, le std:ExternalId est incorrect. Les causes possibles de cela comprennent :

    • Vous ne l’avez pas défini.

    • Vous avez recréé l’objet d’intégration API. La recréation de l’objet API modifie son ID externe.

Erreur : 403 '{"Message":"User: <ARN> is not authorized to perform: execute-api:Invoke"}'

Le texte intégral du message est le suivant :

Request failed for external function <nom_fonction>. Error: 403 '{"Message":"User: <ARN> is not authorized to perform: execute-api:Invoke on resource: <MethodRequestARN>"}'

Cause(s) possible(s)
  • La politique des ressources API Gateway a :

    • Le mauvais ARN de rôle IAM.

    • Le mauvais rôle assumé.

    • Le mauvais ARN de requête de méthode.

  • Le rôle IAM n’est pas assorti de la bonne politique.

Solution(s) possible(s)
  • Assurez-vous que vous avez bien suivi le modèle de politique des ressources figurant dans Protégez votre point de terminaison Amazon API Gateway. Plus précisément, vérifiez que votre politique en matière de ressources :

    • A remplacé le <12-digit number> par la valeur du champ « ID du compte AWS » de la feuille de calcul.

    • A remplacé le <external_function_role> par la valeur du champ « Nom du nouveau rôle IAM » de la feuille de travail.

    • A remplacé le method_request_ARN dans le champ Resource avec la valeur dans le champ « ARN de requête de méthode » de la feuille de calcul.

  • Si vous devez vous assurer que le rôle IAM a la bonne politique de permissions attachée, vous pouvez trouver la liste de la politique de permissions du rôle en suivant les étapes ci-dessous :

    1. Dans AWS, sélectionnez le rôle.

    2. Affichez le Summary pour le rôle.

    3. Cliquez sur l’onglet Permissions .

    4. Vérifiez que la politique requise figure dans la liste Permissions policies.

Erreur : 403 '{"Message":"User: anonymous is not authorized to perform: execute-api:Invoke"}'

Le texte intégral du message est le suivant :

Request failed for external function <nom_fonction>. Error: 403 '{"Message":"User: anonymous is not authorized to perform: execute-api:Invoke on resource: <MethodRequestARN>"}'

Cause(s) possible(s)

Une cause possible est que lorsque vous configuriez l’autorisation pour l’API Gateway, vous n’avez peut-être pas précisé que Method Request nécessite l’autorisation AWS_IAM pour la ressource.

Solution(s) possible(s)

Si vous n’avez pas suivi les instructions de sécurité Amazon API Gateway, alors veuillez les suivre dès à présent pour spécifier l’autorisation AWS_IAM.

Erreur : Error parsing JSON response ... Error: top-level JSON object must contain "data" JSON array element

Le texte intégral du message est le suivant :

Error parsing JSON response for external function ... Error: top-level JSON object must contain "data" JSON array element

Cause(s) possible(s)
  • Vous n’avez peut-être pas spécifié l’intégration par proxy Lambda pour la commande API dans votre ressource POST Gateway.

Solution(s) possible(s)

La demande a échoué pour la fonction externe EXT_FUNC avec une erreur de service à distance : 403 “{« message »: »Forbidden »}”;

Cause(s) possible(s)

Le service proxy a besoin d’une clé API, généralement pour l’authentification ou la facturation. La clé API est manquante ou incorrecte.

Solution(s) possible(s)

Utilisez la commande ALTER API INTEGRATION pour spécifier la bonne clé API.