Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Invocation d'une AWS Lambda fonction depuis une instance de base de données
AWS Lambda est un service de calcul piloté par les événements qui vous permet d'exécuter du code sans provisionner ni gérer de serveurs. Il peut être utilisé avec de nombreux AWS services, notamment RDS pour PostgreSQL. Par exemple, vous pouvez utiliser des fonctions Lambda pour traiter les notifications d’événements à partir d’une base de données ou pour charger des données à partir de fichiers chaque fois qu’un nouveau fichier est chargé sur Amazon S3. Pour en savoir plus sur Lambda, consultez [Qu'est-ce que c'est ? AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) dans le *Guide AWS Lambda du développeur.*
**Note**
L'appel d'une AWS Lambda fonction est pris en charge dans les versions RDS pour PostgreSQL suivantes :
Toutes les versions de PostgreSQL 18
Toutes les versions de PostgreSQL 17
Toutes les versions de PostgreSQL 16
Toutes les versions de PostgreSQL 15
PostgreSQL 14.1 et versions mineures ultérieures
PostgreSQL 13.2 et versions mineures ultérieures
PostgreSQL 12.6 et versions mineures ultérieures
Vous trouverez ci-après des résumés des étapes nécessaires.
Pour plus d’informations sur les fonctions Lambda, consultez [Mise en route avec Lambda](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html) et [Principes de base d’AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-foundation.html) dans le *Guide du développeur AWS Lambda *.
**Topics**
+ [Étape 1 : configurer votre instance de base de données pour les connexions sortantes vers AWS Lambda](#PostgreSQL-Lambda-network)
+ [Étape 2 : configurer IAM pour votre instance de base de données et AWS Lambda](#PostgreSQL-Lambda-access)
+ [Étape 3 : Installation de l'`aws_lambda`extension pour une instance de RDS pour PostgreSQL](#PostgreSQL-Lambda-install-extension)
+ [Étape 4 : utiliser les fonctions d’assistance Lambda avec votre instance de base de données RDS pour PostgreSQL (Facultatif)](#PostgreSQL-Lambda-specify-function)
+ [Étape 5 : appeler une fonction Lambda à partir de votre instance de base de données RDS pour PostgreSQL.](#PostgreSQL-Lambda-invoke)
+ [Étape 6 : accorder aux autres utilisateurs l’autorisation d’appeler les fonctions Lambda](#PostgreSQL-Lambda-grant-users-permissions)
+ [Exemples : appel de fonctions Lambda à partir de votre instance de base de données RDS pour PostgreSQL](PostgreSQL-Lambda-examples.md)
+ [Messages d'erreur de fonction Lambda](PostgreSQL-Lambda-errors.md)
+ [Référence des fonctions et des paramètres AWS Lambda](PostgreSQL-Lambda-functions.md)
## Étape 1 : configurer votre instance de base de données pour les connexions sortantes vers AWS Lambda
Les fonctions Lambda s'exécutent toujours au sein d'un Amazon VPC appartenant au service. AWS Lambda Lambda applique des règles d’accès réseau et de sécurité à ce VPC, le maintient et le surveille automatiquement. Votre instance de base de données RDS pour PostgreSQL envoie du trafic réseau vers le VPC du service Lambda. La façon dont vous configurez cela dépend de si votre instance de base de données est publique ou privée.
+ instance de base de données **publique RDS pour PostgreSQL — L'instance de base** de données données est publique si elle se trouve dans un sous-réseau public de votre VPC et si la propriété « » de l'instance est. PubliclyAccessible `true` Pour trouver la valeur de cette propriété, vous pouvez utiliser la [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) AWS CLI commande. Vous pouvez également utiliser la AWS Management Console afin d’ouvrir l’onglet **Connectivity & security** (Connectivité et sécurité) et vérifier que l’option **Publicly accessible** (Accessible publiquement) est définie sur **Yes** (Oui). Pour vérifier que l’instance se trouve dans le sous-réseau public de votre VPC, vous pouvez utiliser la AWS Management Console ou AWS CLI.
Pour configurer l'accès à Lambda, vous utilisez le AWS Management Console ou AWS CLI pour créer une règle sortante sur le groupe de sécurité de votre VPC. La règle de sortie indique que TCP peut utiliser le port 443 pour envoyer des paquets à n'importe quelle IPv4 adresse (0.0.0.0/0).
+ Cluster de ** RDS privé pour instance de base de données PostgreSQL** — Dans ce cas, la propriété PubliclyAccessible `false` « » de l'instance est ou se trouve dans un sous-réseau privé. Pour permettre à l’instance de fonctionner avec Lambda, vous pouvez utiliser une passerelle traduction d’adresses réseau (NAT). Pour plus d’informations, consultez [Passerelles NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html). Vous pouvez également configurer votre VPC avec un point de terminaison VPC pour Lambda. Pour plus d’informations, consultez [Points de terminaison VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints.html) dans le *Guide de l’utilisateur Amazon VPC*. Le point de terminaison répond aux appels faits par votre instance de base de données RDS pour PostgreSQL à vos fonctions Lambda. Le point de terminaison d’un VPC utilise sa propre résolution DNS privée. RDS pour PostgreSQL ne peut pas utiliser le point de terminaison d’un VPC Lambda tant que vous n’avez pas changé la valeur du paramètre `rds.custom_dns_resolution` de sa valeur par défaut de 0 (non activée) à 1. Pour ce faire :
+ Créez un groupe de paramètres DB personnalisé.
+ Change la valeur du paramètre `rds.custom_dns_resolution` de sa valeur par défaut de `0` à `1`.
+ Modifiez votre instance de base de données pour utiliser votre groupe de paramètres de base de données personnalisé.
+ Redémarrez l’instance pour que le paramètre modifié prenne effet.
Votre VPC peut désormais interagir avec le AWS Lambda VPC au niveau du réseau. Ensuite, vous configurez les autorisations à l’aide d’IAM.
## Étape 2 : configurer IAM pour votre instance de base de données et AWS Lambda
L’appel de fonctions Lambda depuis votre instance de base de données RDS pour PostgreSQL requiert certains privilèges. Pour configurer les privilèges requis, nous vous recommandons de créer une politique IAM qui permet d’appeler des fonctions Lambda, d’attribuer cette politique à un rôle, puis d’appliquer le rôle à votre instance de base de données. Cette approche accorde à l’instance de base de données des privilèges pour appeler la fonction Lambda spécifiée en votre nom. Les étapes suivantes expliquent comment procéder à l’aide de l’ AWS CLI.
**Pour configurer les autorisations IAM pour l’utilisation de votre instance Amazon RDSavec Lambda**
1. Utilisez la AWS CLI commande [create-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/create-policy.html) pour créer une politique IAM qui permet à votre instance de base de données Aurora d'appeler la fonction Lambda spécifiée. (L’ID d’instruction (Sid) est une description facultative pour votre instruction de politique et n’a aucun effet sur l’utilisation.) Cette politique accorde à votre instance de base de données les autorisations minimales requises pour appeler la fonction Lambda spécifiée.
```
aws iam create-policy --policy-name rds-lambda-policy --policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowAccessToExampleFunction",
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:aws-region:444455556666:function:my-function"
}
]
}'
```
Vous pouvez également utiliser la politique `AWSLambdaRole` prédéfinie qui vous permet d’appeler n’importe laquelle de vos fonctions Lambda. Pour plus d’informations, consultez la rubrique [Politiques IAM basées sur l’identité pour Lambda](https://docs.aws.amazon.com/lambda/latest/dg/access-control-identity-based.html#access-policy-examples-aws-managed).
1. Utilisez la AWS CLI commande [create-role](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/create-role.html) pour créer un rôle IAM que la politique peut assumer lors de l'exécution.
```
aws iam create-role --role-name rds-lambda-role --assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}'
```
1. Appliquez la politique au rôle à l'aide de la [attach-role-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/attach-role-policy.html) AWS CLI commande.
```
aws iam attach-role-policy \
--policy-arn arn:aws:iam::444455556666:policy/rds-lambda-policy \
--role-name rds-lambda-role --region aws-region
```
1. AWS CLI Cette dernière étape permet aux utilisateurs de base de données de votre instance de base de données d’appeler des fonctions Lambda.
```
aws rds add-role-to-db-instance \
--db-instance-identifier my-instance-name \
--feature-name Lambda \
--role-arn arn:aws:iam::444455556666:role/rds-lambda-role \
--region aws-region
```
Une fois le VPC et les configurations IAM terminées, vous pouvez désormais installer l’extension `aws_lambda`. (Notez que vous pouvez installer l’extension à tout moment, mais tant que vous n’avez pas configuré la prise en charge du VPC et les privilèges IAM corrects, l’extension `aws_lambda` n’ajoute rien aux fonctionnalités de votre instance de base de données RDS pour PostgreSQL.)
## Étape 3 : Installation de l'`aws_lambda`extension pour une instance de RDS pour PostgreSQL
Cette extension offre à votre instance de base de données RDS pour PostgreSQL la capacité d’appeler des fonctions Lambda depuis PostgreSQL.
**Pour installer l'`aws_lambda`extension dans votre instance de RDS pour PostgreSQL**
Utilisez la ligne de commande `psql` de PostgreSQL ou l’outil pgAdmin afin de vous connecter à votre instance de base de données RDS pour PostgreSQL.
1. Connectez-vous à votre instance de base de données RDS pour PostgreSQL en tant qu’utilisateur doté de privilèges `rds_superuser`. L’utilisateur `postgres` par défaut est illustré dans l’exemple.
```
psql -h instance.444455556666.aws-region.rds.amazonaws.com -U postgres -p 5432
```
1. Installez l’extension `aws_lambda`. L’extension `aws_commons` est également requise. Elle fournit des fonctions d’assistance pour `aws_lambda` et de nombreuses autres extensions Aurora pour PostgreSQL. Si elle n’est pas déjà sur votre instance de base de données RDS pour PostgreSQL, elle est installée avec `aws_lambda` comme illustré ci-dessous.
```
CREATE EXTENSION IF NOT EXISTS aws_lambda CASCADE;
NOTICE: installing required extension "aws_commons"
CREATE EXTENSION
```
L’extension `aws_lambda` est installée dans l’instance de base de données primaire de votre . Vous pouvez désormais créer des structures de commodité pour appeler vos fonctions Lambda.
## Étape 4 : utiliser les fonctions d’assistance Lambda avec votre instance de base de données RDS pour PostgreSQL (Facultatif)
Vous pouvez utiliser les fonctions d’assistance de l’extension `aws_commons` pour préparer les entités que vous pouvez appeler plus facilement depuis PostgreSQL. Pour ce faire, vous avez besoin des informations suivantes concernant vos fonctions Lambda :
+ **Function name** (Nom de la fonction) — Le nom, l’Amazon Resource Name (ARN), la version ou l’alias de la fonction Lambda. La politique IAM créée dans [Étape 2 : configurer IAM pour votre instance et Lambda](#PostgreSQL-Lambda-access) nécessite l’ARN, nous vous recommandons donc d’utiliser l’ARN de votre fonction.
+ **AWS Région** — (Facultatif) AWS Région dans laquelle se trouve la fonction Lambda si elle ne se trouve pas dans la même région que votre instance de base de données Aurora .
Pour conserver les informations de nom de la fonction Lambda, utilisez la fonction [aws\$1commons.create\$1lambda\$1function\$1arn](PostgreSQL-Lambda-functions.md#aws_commons.create_lambda_function_arn). Cette fonction d’assistance crée une structure composite `aws_commons._lambda_function_arn_1` avec les détails requis par la fonction d’appel. Vous trouverez ci-dessous trois autres approches pour configurer cette structure composite.
```
SELECT aws_commons.create_lambda_function_arn(
'my-function',
'aws-region'
) AS aws_lambda_arn_1 \gset
```
```
SELECT aws_commons.create_lambda_function_arn(
'111122223333:function:my-function',
'aws-region'
) AS lambda_partial_arn_1 \gset
```
```
SELECT aws_commons.create_lambda_function_arn(
'arn:aws:lambda:aws-region:111122223333:function:my-function'
) AS lambda_arn_1 \gset
```
N’importe laquelle de ces valeurs peut être utilisée dans les appels à la fonction [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke). Pour obtenir des exemples, consultez [Étape 5 : appeler une fonction Lambda à partir de votre instance de base de données RDS pour PostgreSQL.](#PostgreSQL-Lambda-invoke).
## Étape 5 : appeler une fonction Lambda à partir de votre instance de base de données RDS pour PostgreSQL.
La fonction `aws_lambda.invoke` se comporte de manière synchrone ou asynchrone, en fonction du `invocation_type`. Les deux alternatives à ce paramètre sont `RequestResponse` (valeur par défaut) et `Event`, comme suit.
+ **`RequestResponse`** — Ce type d’appel est *synchrone*. Il s’agit du comportement par défaut lorsque l’appel est effectué sans spécifier de type d’appel. La charge utile de réponse inclut les résultats de la fonction `aws_lambda.invoke`. Utilisez ce type d’appel lorsque votre flux de travail nécessite la réception des résultats de la fonction Lambda avant de continuer.
+ **`Event`** — Ce type d’appel est *asynchrone*. La réponse n’inclut pas de charge utile contenant des résultats. Utilisez ce type d’appel lorsque votre flux de travail n’a pas besoin de résultat de la fonction Lambda pour continuer le traitement.
Pour tester simplement votre configuration, vous pouvez vous connecter à votre instance de base de données en utilisant `psql` et appeler un exemple de fonction depuis la ligne de commande. Supposons que l’une des fonctions de base soit configurée sur votre service Lambda, telle que la fonction simple Python affichée dans la capture d’écran suivante.
![\[Exemple de fonction Lambda illustré dans le fichier pour AWS CLI AWS Lambda\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/images/lambda_simple_function.png)
**Pour invoquer un exemple de fonction**
1. Connectez-vous à votre instance de base de données avec `psql` ou pgAdmin.
```
psql -h instance.444455556666.aws-region.rds.amazonaws.com -U postgres -p 5432
```
1. Appelez la fonction en utilisant son ARN.
```
SELECT * from aws_lambda.invoke(aws_commons.create_lambda_function_arn('arn:aws:lambda:aws-region:444455556666:function:simple', 'us-west-1'), '{"body": "Hello from Postgres!"}'::json );
```
La réponse se présente comme suit.
```
status_code | payload | executed_version | log_result
-------------+-------------------------------------------------------+------------------+------------
200 | {"statusCode": 200, "body": "\"Hello from Lambda!\""} | $LATEST |
(1 row)
```
Si votre tentative d’appel ne réussit pas, consultez [Messages d'erreur de fonction Lambda](PostgreSQL-Lambda-errors.md).
## Étape 6 : accorder aux autres utilisateurs l’autorisation d’appeler les fonctions Lambda
À ce stade des procédures, vous êtes le seul, en tant que `rds_superuser`, à pouvoir appeler vos fonctions Lambda. Pour permettre à d’autres utilisateurs d’appeler les fonctions que vous avez créées, vous devez leur accorder des autorisations.
**Pour accorder à d’autres personnes l’autorisation d’appeler les fonctions Lambda**
1. Connectez-vous à votre instance de base de données avec `psql` ou pgAdmin.
```
psql -h instance.444455556666.aws-region.rds.amazonaws.com -U postgres -p 5432
```
1. Exécutez les commandes SQL suivantes :
```
postgres=> GRANT USAGE ON SCHEMA aws_lambda TO db_username;
GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA aws_lambda TO db_username;
```
# Exemples : appel de fonctions Lambda à partir de votre instance de base de données RDS pour PostgreSQL
Ci-dessous, vous pouvez trouver plusieurs exemples d’appel de la fonction [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke). La plupart des exemples utilisent la structure composite `aws_lambda_arn_1` que vous créez dans [Étape 4 : utiliser les fonctions d’assistance Lambda avec votre instance de base de données RDS pour PostgreSQL (Facultatif)](PostgreSQL-Lambda.md#PostgreSQL-Lambda-specify-function) pour simplifier la transmission des détails de la fonction. Pour obtenir un exemple d’appel asynchrone, reportez-vous à la section [Exemple : appel asynchrone (Event) de fonctions Lambda](#PostgreSQL-Lambda-Event). Tous les autres exemples répertoriés utilisent l’appel synchrone.
Pour en savoir plus sur les types d’appel Lambda, consultez [Appel de fonctions Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-invocation.html) dans le *Guide du développeur AWS Lambda *. Pour plus d’informations sur `aws_lambda_arn_1`, consultez [aws\$1commons.create\$1lambda\$1function\$1arn](PostgreSQL-Lambda-functions.md#aws_commons.create_lambda_function_arn).
**Topics**
+ [Exemple : appel synchrone (RequestResponse) de fonctions Lambda](#PostgreSQL-Lambda-RequestResponse)
+ [Exemple : appel asynchrone (Event) de fonctions Lambda](#PostgreSQL-Lambda-Event)
+ [Exemple : capture du journal d’exécution Lambda dans une réponse de fonction](#PostgreSQL-Lambda-log-response)
+ [Exemple : inclusion du contexte client dans une fonction Lambda](#PostgreSQL-Lambda-client-context)
+ [Exemple : appel d’une version spécifique d’une fonction Lambda](#PostgreSQL-Lambda-function-version)
## Exemple : appel synchrone (RequestResponse) de fonctions Lambda
Voici deux exemples d’appel synchrone de fonction Lambda. Les résultats de ces appels de fonction `aws_lambda.invoke` sont identiques.
```
SELECT * FROM aws_lambda.invoke('aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json);
```
```
SELECT * FROM aws_lambda.invoke('aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json, 'RequestResponse');
```
Les paramètres sont décrits comme suit :
+ `:'aws_lambda_arn_1'` — Ce paramètre identifie la structure composite créée dans [Étape 4 : utiliser les fonctions d’assistance Lambda avec votre instance de base de données RDS pour PostgreSQL (Facultatif)](PostgreSQL-Lambda.md#PostgreSQL-Lambda-specify-function), avec la fonction d’assistance `aws_commons.create_lambda_function_arn`. Vous pouvez également créer cette structure en ligne dans votre appel `aws_lambda.invoke` comme suit.
```
SELECT * FROM aws_lambda.invoke(aws_commons.create_lambda_function_arn('my-function', 'aws-region'),
'{"body": "Hello from Postgres!"}'::json
);
```
+ `'{"body": "Hello from PostgreSQL!"}'::json` : données utiles JSON à passer à la fonction Lambda.
+ `'RequestResponse'` : type d’appel Lambda.
## Exemple : appel asynchrone (Event) de fonctions Lambda
Voici un exemple d’appel de fonction Lambda asynchrone. Le type d’appel `Event` planifie l’appel de fonction Lambda avec la charge utile d’entrée spécifiée et renvoie une réponse immédiatement. Utiliser le type d’appel `Event` dans certains flux de travail qui ne dépendent pas des résultats de la fonction Lambda.
```
SELECT * FROM aws_lambda.invoke('aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json, 'Event');
```
## Exemple : capture du journal d’exécution Lambda dans une réponse de fonction
Vous pouvez inclure les 4 derniers Ko du journal d’exécution dans la réponse de la fonction à l’aide du paramètre `log_type` dans votre appel de fonction `aws_lambda.invoke`. Par défaut, ce paramètre est défini sur `None`, mais vous pouvez spécifier `Tail` afin de capturer les résultats du journal d’exécution Lambda dans la réponse, comme indiqué ci-dessous.
```
SELECT *, select convert_from(decode(log_result, 'base64'), 'utf-8') as log FROM aws_lambda.invoke(:'aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json, 'RequestResponse', 'Tail');
```
Définissez le paramètre [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke) de la fonction `log_type` sur `Tail` pour inclure le journal d’exécution dans la réponse. La valeur par défaut du paramètre `log_type` est `None`.
Le `log_result` qui est retourné est une chaîne `base64` encodée. Vous pouvez décoder le contenu à l’aide d’une combinaison des fonctions PostgreSQL `decode` et `convert_from`.
Pour plus d’informations sur `log_type`, consultez [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke).
## Exemple : inclusion du contexte client dans une fonction Lambda
La fonction `aws_lambda.invoke` possède un paramètre `context` que vous pouvez utiliser pour transférer des informations séparées de la charge utile, comme indiqué ci-dessous.
```
SELECT *, convert_from(decode(log_result, 'base64'), 'utf-8') as log FROM aws_lambda.invoke(:'aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json, 'RequestResponse', 'Tail');
```
Pour inclure le contexte client, utilisez un objet JSON pour le paramètre [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke) de la fonction `context`.
Pour plus d’informations sur le paramètre `context`, consultez la référence [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke).
## Exemple : appel d’une version spécifique d’une fonction Lambda
Vous pouvez spécifier une version particulière d’une fonction Lambda en incluant le paramètre `qualifier` avec l’appel `aws_lambda.invoke`. Vous trouverez ci-dessous un exemple de ce procédé qui utilise `'custom_version'` comme alias pour la version.
```
SELECT * FROM aws_lambda.invoke('aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json, 'RequestResponse', 'None', NULL, 'custom_version');
```
Vous pouvez également fournir un qualificatif de fonction Lambda avec les informations de nom de la fonction à la place, comme suit.
```
SELECT * FROM aws_lambda.invoke(aws_commons.create_lambda_function_arn('my-function:custom_version', 'us-west-2'),
'{"body": "Hello from Postgres!"}'::json);
```
Pour plus d’informations sur `qualifier` et d’autres paramètres, consultez la référence [aws\$1lambda.invoke](PostgreSQL-Lambda-functions.md#aws_lambda.invoke).
# Messages d'erreur de fonction Lambda
Dans la liste suivante, vous trouverez des informations sur les messages d'erreur, avec les causes et les solutions possibles.
+ **Problèmes de configuration de VPC**
Les problèmes de configuration du VPC peuvent entraîner les messages d'erreur suivants lors de la tentative de connexion :
```
ERROR: invoke API failed
DETAIL: AWS Lambda client returned 'Unable to connect to endpoint'.
CONTEXT: SQL function "invoke" statement 1
```
Une cause fréquente de cette erreur est un groupe de sécurité VPC mal configuré. Assurez-vous que vous disposez d'une règle sortante pour TCP ouverte sur le port 443 de votre groupe de sécurité VPC afin que votre VPC puisse se connecter au VPC Lambda.
Si votre instance de base de données est privée, vérifiez la configuration DNS privée de votre VPC. Assurez-vous de définir le `rds.custom_dns_resolution` paramètre sur 1 et de le configurer AWS PrivateLink comme indiqué dans[Étape 1 : configurer votre instance de base de données pour les connexions sortantes vers AWS Lambda](PostgreSQL-Lambda.md#PostgreSQL-Lambda-network). Pour plus d'informations, consultez [Interface VPC endpoints](https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html#vpce-private-dns) ().AWS PrivateLink
+ **Manque d'autorisations nécessaires pour appeler les fonctions Lambda**
Si l'un des messages d'erreur suivants s'affiche, l'utilisateur (rôle) qui appelle la fonction ne dispose pas des autorisations nécessaires.
```
ERROR: permission denied for schema aws_lambda
```
```
ERROR: permission denied for function invoke
```
Un utilisateur (rôle) doit recevoir des autorisations spécifiques pour appeler les fonctions Lambda. Pour de plus amples informations, veuillez consulter [Étape 6 : accorder aux autres utilisateurs l’autorisation d’appeler les fonctions Lambda](PostgreSQL-Lambda.md#PostgreSQL-Lambda-grant-users-permissions).
+ **Traitement inapproprié des erreurs dans vos fonctions Lambda4**
Si une fonction Lambda lance une exception pendant le traitement de la demande, `aws_lambda.invoke` échoue avec une erreur PostgreSQL telle que la suivante.
```
SELECT * FROM aws_lambda.invoke('aws_lambda_arn_1', '{"body": "Hello from Postgres!"}'::json);
ERROR: lambda invocation failed
DETAIL: "arn:aws:lambda:us-west-2:555555555555:function:my-function" returned error "Unhandled", details: "".
```
Assurez-vous de gérer les erreurs dans vos fonctions Lambda ou dans votre application PostgreSQL.
# Référence des fonctions et des paramètres AWS Lambda
Voici la référence pour les fonctions et les paramètres à utiliser pour invoquer Lambda avec RDS pour PostgreSQL.
**Topics**
+ [aws\$1lambda.invoke](#aws_lambda.invoke)
+ [aws\$1commons.create\$1lambda\$1function\$1arn](#aws_commons.create_lambda_function_arn)
+ [Paramètres aws\$1lambda](#aws_lambda.parameters)
## aws\$1lambda.invoke
Exécute une fonction Lambda pour une instance de base de données RDS pour PostgreSQL.
Pour plus de détails sur l'appel de fonctions Lambda, consultez également la section [Appel](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html) dans le *Manuel du développeur AWS Lambda*.
**Syntaxe**
------
#### [ JSON ]
```
aws_lambda.invoke(
IN function_name TEXT,
IN payload JSON,
IN region TEXT DEFAULT NULL,
IN invocation_type TEXT DEFAULT 'RequestResponse',
IN log_type TEXT DEFAULT 'None',
IN context JSON DEFAULT NULL,
IN qualifier VARCHAR(128) DEFAULT NULL,
OUT status_code INT,
OUT payload JSON,
OUT executed_version TEXT,
OUT log_result TEXT)
```
```
aws_lambda.invoke(
IN function_name aws_commons._lambda_function_arn_1,
IN payload JSON,
IN invocation_type TEXT DEFAULT 'RequestResponse',
IN log_type TEXT DEFAULT 'None',
IN context JSON DEFAULT NULL,
IN qualifier VARCHAR(128) DEFAULT NULL,
OUT status_code INT,
OUT payload JSON,
OUT executed_version TEXT,
OUT log_result TEXT)
```
------
#### [ JSONB ]
```
aws_lambda.invoke(
IN function_name TEXT,
IN payload JSONB,
IN region TEXT DEFAULT NULL,
IN invocation_type TEXT DEFAULT 'RequestResponse',
IN log_type TEXT DEFAULT 'None',
IN context JSONB DEFAULT NULL,
IN qualifier VARCHAR(128) DEFAULT NULL,
OUT status_code INT,
OUT payload JSONB,
OUT executed_version TEXT,
OUT log_result TEXT)
```
```
aws_lambda.invoke(
IN function_name aws_commons._lambda_function_arn_1,
IN payload JSONB,
IN invocation_type TEXT DEFAULT 'RequestResponse',
IN log_type TEXT DEFAULT 'None',
IN context JSONB DEFAULT NULL,
IN qualifier VARCHAR(128) DEFAULT NULL,
OUT status_code INT,
OUT payload JSONB,
OUT executed_version TEXT,
OUT log_result TEXT
)
```
------Paramètres d'entrée
**function\$1name**
Nom d'identification de la fonction Lambda. La valeur peut être le nom de la fonction, un ARN ou un ARN partiel. Pour obtenir la liste des formats possibles, consultez [Formats de nom de fonction Lambda](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html#API_Invoke_RequestParameters) dans le *Manuel du développeur AWS Lambda*.
*payload*
Entrée de la fonction Lambda. Le format peut être JSON ou JSONB. Pour plus d’informations, consultez la documentation PostgreSQL sur les [types JSON](https://www.postgresql.org/docs/current/datatype-json.html).
*région*
(Facultatif) Région Lambda de la fonction. Par défaut, RDS résout la Région AWS à partir de l’ARN complet dans le `function_name` ou utilise la Région de l’instance de base de données RDS pour PostgreSQL. Si cette valeur de région est en conflit avec celle fournie dans l'ARN `function_name`, une erreur est déclenchée.
*invocation\$1type*
Type d'appel de la fonction Lambda. La valeur est sensible à la casse. Les valeurs possibles sont notamment les suivantes :
+ `RequestResponse` – Valeur par défaut Ce type d'appel d'une fonction Lambda est synchrone et renvoie une charge utile de réponse dans le résultat. Utilisez le type d'appel `RequestResponse` lorsque votre flux de travail dépend de la réception immédiate du résultat de la fonction Lambda.
+ `Event` – Ce type d'appel d'une fonction Lambda est asynchrone et retourne une réponse immédiatement sans retourner de charge utile. Utilisez le type d'appel `Event` lorsque vous n'avez pas besoin des résultats de la fonction Lambda avant que votre flux de travail ne progresse.
+ `DryRun` – Ce type d'appel teste l'accès sans exécuter la fonction Lambda.
*log\$1type*
Type de journal Lambda à renvoyer dans le paramètre de sortie `log_result`. La valeur est sensible à la casse. Les valeurs possibles sont notamment les suivantes :
+ Tail – Le paramètre de sortie `log_result` renvoyé inclura les 4 derniers Ko du journal d'exécution.
+ None – Aucune information de journal Lambda n'est renvoyée.
*context*
Contexte client au format JSON ou JSONB. Les champs à utiliser incluent alors `custom` et `env`.
*qualifier*
Qualificateur qui identifie la version d'une fonction Lambda à appeler. Si cette valeur est en conflit avec celle fournie dans l'ARN `function_name`, une erreur est déclenchée.Paramètres de sortie
*status\$1code*
Code de réponse d'état HTTP. Pour plus d'informations, consultez [Éléments de réponse à l'appel de la fonction Lambda](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html#API_Invoke_ResponseElements) dans le *AWS LambdaManuel du développeur *.
*payload*
Informations renvoyées à partir de la fonction Lambda exécutée. Le format est en JSON ou JSONB.
*executed\$1version*
Version de la fonction Lambda exécutée.
*log\$1result*
Informations du journal d'exécution renvoyées si la valeur `log_type` est `Tail` lorsque la fonction Lambda a été appelée. Le résultat contient les 4 derniers Ko du journal d'exécution codé en Base64.
## aws\$1commons.create\$1lambda\$1function\$1arn
Crée une structure `aws_commons._lambda_function_arn_1` pour contenir les informations de nom de fonction Lambda. Vous pouvez utiliser les résultats de la fonction `aws_commons.create_lambda_function_arn` dans le paramètre `function_name` de la fonction [aws\$1lambda.invoke](#aws_lambda.invoke) aws\$1lambda.invoke.
**Syntaxe**
```
aws_commons.create_lambda_function_arn(
function_name TEXT,
region TEXT DEFAULT NULL
)
RETURNS aws_commons._lambda_function_arn_1
```Paramètres d'entrée
*function\$1name*
Chaîne de texte obligatoire contenant le nom de la fonction Lambda. La valeur peut être un nom de fonction, un ARN partiel ou un ARN complet.
*région*
Chaîne de texte facultative contenant la région AWS dans laquelle se trouve la fonction Lambda. Pour obtenir la liste des noms de régions et les valeurs associées, consultez [Régions, zones de disponibilité et zones locales ](Concepts.RegionsAndAvailabilityZones.md).
## Paramètres aws\$1lambda
Dans le tableau, vous pouvez trouver les paramètres associés à la fonction `aws_lambda`.
| Paramètre | Description |
| --- | --- |
| `aws_lambda.connect_timeout_ms` | Il s’agit d’un paramètre dynamique qui définit le temps d’attente maximal lors de la connexion à AWS Lambda. Les valeurs par défaut sont `1000`. Les valeurs autorisées pour ce paramètre sont comprises entre 1 et 900 000. |
| `aws_lambda.request_timeout_ms` | Il s’agit d’un paramètre dynamique qui définit le temps d’attente maximal lors de la réception d’une réponse d’AWS Lambda. Les valeurs par défaut sont `3000`. Les valeurs autorisées pour ce paramètre sont comprises entre 1 et 900 000. |
| `aws_lambda.endpoint_override` | Indique le point de terminaison qui peut être utilisé pour se connecter à AWS Lambda. Une chaîne vide sélectionne le point de terminaison AWS Lambda par défaut pour la région. La base de données doit être redémarrée pour que ce changement de paramètre statique soit pris en compte. |