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.
# Utilisation de Lambda avec Amazon SQS
**Note**
Si vous souhaitez envoyer des données à une cible autre qu'une fonction Lambda ou enrichir les données avant de les envoyer, consultez [Amazon EventBridge ](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-pipes.html) Pipes.
Vous pouvez utiliser une fonction Lambda pour traiter les messages figurant dans une file d’attente Amazon Simple Queue Service (Amazon SQS). Lambda prend en charge à la fois les [files d’attente standard](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/standard-queues.html) et les [files d’attente FIFO (premier entré, premier sorti)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/FIFO-queues.html) pour les [mappages des sources d’événements](invocation-eventsourcemapping.md). Vous pouvez également utiliser le mode provisionné pour allouer des ressources d'interrogation dédiées pour vos mappages de sources d'événements Amazon SQS. [La fonction Lambda et la file d'attente Amazon SQS doivent être Région AWS identiques, bien qu'elles puissent être différentes. Comptes AWS](with-sqs-cross-account-example.md)
Lorsque vous traitez des messages Amazon SQS, vous devez implémenter une logique de réponse partielle de lot afin d’éviter que les messages traités avec succès soient de nouveau essayés en cas d’échec de certains messages d’un lot. L'[utilitaire Batch Processor](https://docs.powertools.aws.dev/lambda/python/latest/utilities/batch/) de Powertools AWS Lambda simplifie cette implémentation en gérant automatiquement la logique de réponse partielle par lots, en réduisant le temps de développement et en améliorant la fiabilité.
**Topics**
+ [
## Comprendre le comportement d’interrogation et de traitement par lots pour les mappages des sources d’événements Amazon SQS
](#sqs-polling-behavior)
+ [
## Utilisation du mode provisionné avec les mappages de sources d'événements Amazon SQS
](#sqs-provisioned-mode)
+ [
## Configuration du mode provisionné pour le mappage des sources d'événements Amazon SQS
](#sqs-configuring-provisioned-mode)
+ [
## Exemple d’événement de message de file d’attente standard
](#example-standard-queue-message-event)
+ [
## Exemple d’événement de message de file d’attente FIFO
](#sample-fifo-queues-message-event)
+ [
# Création et configuration d’un mappage des sources d’événements Amazon SQS
](services-sqs-configure.md)
+ [
# Configuration du comportement de mise à l’échelle pour les mappages des sources d’événements SQS
](services-sqs-scaling.md)
+ [
# Gestion des erreurs pour une source d’événements SQS dans Lambda
](services-sqs-errorhandling.md)
+ [
# Paramètres Lambda pour les mappages des sources d’événement Amazon SQS
](services-sqs-parameters.md)
+ [
# Utilisation du filtrage des événements avec une source d’événement Amazon SQS
](with-sqs-filtering.md)
+ [
# Didacticiel : utilisation de Lambda avec Amazon SQS
](with-sqs-example.md)
+ [
# Didacticiel : utilisation d’une file d’attente Amazon SQS entre comptes en tant que source d’événement
](with-sqs-cross-account-example.md)
## Comprendre le comportement d’interrogation et de traitement par lots pour les mappages des sources d’événements Amazon SQS
Avec les mappages des sources d’événements Amazon SQS, Lambda interroge la file d’attente et invoque votre fonction de [manière synchrone](invocation-sync.md) avec un événement. Chaque événement peut contenir un lot de plusieurs messages provenant de la file d’attente. Lambda reçoit ces événements un lot à la fois, et invoque votre fonction une fois pour chaque lot. Après que la fonction a traité un lot avec succès, Lambda supprime ses messages de la file d’attente.
Quand Lambda reçoit un lot, les messages restent dans la file d’attente mais sont masqués pendant toute la durée du [délai de visibilité](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html) de la file d’attente. Si votre fonction traite tous les messages d’un lot avec succès, Lambda supprime les messages depuis la file d’attente. Par défaut, si votre fonction rencontre une erreur lors du traitement d’un lot, tous les messages de ce lot redeviennent visibles dans la file d’attente une fois le délai de visibilité expiré. Pour cette raison, le code de votre fonction peut traiter le même message plusieurs fois sans effets secondaires involontaires.
**Avertissement**
Les mappages des sources d’événements Lambda traitent chaque événement au moins une fois, et le traitement des enregistrements peut être dupliqué. Pour éviter les problèmes potentiels liés à des événements dupliqués, nous vous recommandons vivement de rendre votre code de fonction idempotent. Pour en savoir plus, consultez [Comment rendre ma fonction Lambda idempotente](https://repost.aws/knowledge-center/lambda-function-idempotent) dans le Knowledge Center. AWS
Pour empêcher Lambda de traiter un message plusieurs fois, vous pouvez soit configurer le mappage de votre source d'événements pour inclure les [défaillances d'éléments de lot](services-sqs-errorhandling.md#services-sqs-batchfailurereporting) dans la réponse de votre fonction, soit utiliser l'[DeleteMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_DeleteMessage.html)API pour supprimer les messages de la file d'attente lorsque votre fonction Lambda les traite correctement.
Pour de plus amples informations sur les paramètres de configuration pris en charge par Lambda pour les mappages des sources d’événements SQS, consultez [Création d’un mappage des sources d’événements SQS](services-sqs-configure.md#events-sqs-eventsource).
## Utilisation du mode provisionné avec les mappages de sources d'événements Amazon SQS
Pour les charges de travail où vous devez optimiser le débit de votre mappage des sources d’événements, vous pouvez utiliser le mode provisionné. En mode provisionné, vous définissez des limites minimales et maximales pour le nombre de sondeurs d’événements alloués. Ces sondeurs d’événements alloués sont dédiés à votre mappage des sources d’événements et peuvent gérer les pics de messages inattendus grâce à une mise à l’échelle automatique réactive. Le mappage des sources d'événements Amazon SQS configuré en mode provisionné évolue 3 fois plus vite (jusqu'à 1 000 appels simultanés par minute) et prend en charge une simultanéité 16 fois supérieure (jusqu'à 20 000 appels simultanés) par rapport à la capacité de mappage des sources d'événements Amazon SQS par défaut. Nous vous recommandons d'utiliser le mode provisionné pour les charges de travail basées sur les événements Amazon SQS soumises à des exigences de performance strictes, telles que les sociétés de services financiers traitant les flux de données du marché, les plateformes de commerce électronique fournissant des recommandations personnalisées en temps réel et les sociétés de jeux gérant les interactions avec les joueurs en direct. L’utilisation du mode alloué génère des coûts supplémentaires. Pour connaître les tarifs détaillés, consultez la section [AWS Lambda des prix](https://aws.amazon.com/lambda/pricing/).
Chaque sondeur d'événements en mode provisionné peut gérer jusqu'à 1 % MB/s du débit, jusqu'à 10 appels simultanés ou jusqu'à 10 appels d'API d'interrogation Amazon SQS par seconde. La plage de valeurs acceptées pour le nombre minimum de sondeurs d'événements (MinimumPollers) est comprise entre 2 et 200, avec une valeur par défaut de 2. La plage de valeurs acceptées pour le nombre maximum de sondeurs d'événements (MaximumPollers) est comprise entre 2 et 2 000, avec une valeur par défaut de 200. MaximumPollers doit être supérieur ou égal à MinimumPollers.
### Déterminer les sondeurs d'événements requis
Pour estimer le nombre de sondeurs d'événements nécessaires pour garantir des performances de traitement des messages optimales lors de l'utilisation du mode provisionné pour SQS ESM, collectez les indicateurs suivants pour votre application : pic d'événements SQS par seconde nécessitant un traitement à faible latence, taille moyenne de la charge utile des événements SQS, durée moyenne de la fonction Lambda et taille de lot configurée.
Vous pouvez d'abord estimer le nombre d'événements SQS par seconde (EPS) pris en charge par un sondeur d'événements pour votre charge de travail à l'aide de la formule suivante :
```
EPS per event poller =
minimum(
ceiling(1024 / average event size in KB),
ceiling(10 / average function duration in seconds) * batch size,
min(100, 10 * batch size)
)
```
Ensuite, vous pouvez calculer le nombre minimum de sondeurs requis en utilisant la formule ci-dessous. Ce calcul garantit que vous fournissez une capacité suffisante pour répondre à vos besoins de trafic de pointe.
```
Required event pollers = (Peak number of events per second in Queue) / EPS per event poller
```
Prenons l'exemple d'une charge de travail avec une taille de lot par défaut de 10, une taille moyenne des événements de 3 Ko, une durée de fonctionnement moyenne de 100 ms et une exigence de gestion de 1 000 événements par seconde. Dans ce scénario, chaque sondeur d'événements prendra en charge environ 100 événements par seconde (EPS). Par conséquent, vous devez définir un nombre minimum de sondeurs à 10 pour répondre de manière adéquate à vos besoins de pointe en matière de trafic. Si votre charge de travail présente les mêmes caractéristiques mais avec une durée de fonctionnement moyenne d'une seconde, chaque sondeur ne prendra en charge que 10 EPS, ce qui vous obligera à configurer au moins 100 sondeurs pour prendre en charge 1 000 événements par seconde avec une faible latence.
Nous recommandons d'utiliser une taille de lot par défaut de 10 ou plus pour optimiser l'efficacité des sondeurs d'événements en mode provisionné. Des lots de plus grande taille permettent à chaque sondeur de traiter un plus grand nombre d'événements par appel, ce qui améliore le débit et la rentabilité. Lorsque vous planifiez votre capacité de sondeurs d'événements, tenez compte des pics de trafic potentiels et envisagez de définir une valeur de minimumPollers légèrement supérieure au minimum calculé pour créer une zone tampon. En outre, surveillez les caractéristiques de votre charge de travail au fil du temps, car les modifications de la taille des messages, de la durée des fonctions ou des modèles de trafic peuvent nécessiter des ajustements de la configuration de votre sondeur d'événements afin de maintenir des performances et une rentabilité optimales. Pour une planification précise de la capacité, nous vous recommandons de tester votre charge de travail spécifique afin de déterminer l'EPS réel que chaque enquêteur peut piloter.
## Configuration du mode provisionné pour le mappage des sources d'événements Amazon SQS
Vous pouvez configurer le mode provisionné pour le mappage de vos sources d'événements Amazon SQS à l'aide de la console ou de l'API Lambda.
**Pour configurer le mode provisionné pour un mappage de source d'événements Amazon SQS existant (console)**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez la fonction avec le mappage des sources d'événements Amazon SQS pour laquelle vous souhaitez configurer le mode provisionné.
1. Choisissez **Configuration**, puis **Déclencheurs**.
1. **Choisissez le mappage des sources d'événements Amazon SQS pour lequel vous souhaitez configurer le mode provisionné, puis choisissez Modifier.**
1. Sous **Configuration du mappage des sources d’événements**, choisissez **Configurer le mode provisionné**.
+ Pour le **nombre minimal de sondeurs**, entrez une valeur comprise entre 2 et 200. Si vous ne spécifiez aucune valeur, Lambda choisit une valeur par défaut de 2.
+ Pour le **nombre maximum de sondeurs d'événements**, entrez une valeur comprise entre 2 et 2 000. Cette valeur doit être supérieure ou égale à la valeur du **Nombre minimal de sondeurs d’événements**. Si vous ne spécifiez aucune valeur, Lambda choisit la valeur par défaut 200.
1. Choisissez **Enregistrer**.
Vous pouvez configurer le mode provisionné par programmation à l'aide de l'`ProvisionedPollerConfig`objet de votre. `EventSourceMappingConfiguration` Par exemple, la commande `UpdateEventSourceMapping` CLI suivante configure une `MinimumPollers` valeur de 5 et une `MaximumPollers` valeur de 100.
```
aws lambda update-event-source-mapping \
--uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
--provisioned-poller-config '{"MinimumPollers": 5, "MaximumPollers": 100}'
```
Après avoir configuré le mode alloué, vous pouvez observer l’utilisation des sondeurs d’événements pour votre charge de travail en surveillant la métrique `ProvisionedPollers`. Pour plus d'informations, consultez la section Métriques de mappage des sources d'événements.
Pour désactiver le mode provisionné et revenir au mode par défaut (à la demande), vous pouvez utiliser la commande `UpdateEventSourceMapping` CLI suivante :
```
aws lambda update-event-source-mapping \
--uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
--provisioned-poller-config '{}'
```
**Note**
Le mode provisionné ne peut pas être utilisé conjointement avec le paramètre de simultanéité maximale. Lorsque vous utilisez le mode provisionné, vous contrôlez la simultanéité maximale grâce au nombre maximal de sondeurs d'événements.
Pour plus d'informations sur la configuration du mode provisionné, consultez[Création et configuration d’un mappage des sources d’événements Amazon SQS](services-sqs-configure.md).
## Exemple d’événement de message de file d’attente standard
**Example Événement de message Amazon SQS (file d’attente standard)**
```
{
"Records": [
{
"messageId": "059f36b4-87a3-44ab-83d2-661975830a7d",
"receiptHandle": "AQEBwJnKyrHigUMZj6rYigCgxlaS3SLy0a...",
"body": "Test message.",
"attributes": {
"ApproximateReceiveCount": "1",
"SentTimestamp": "1545082649183",
"SenderId": "AIDAIENQZJOLO23YVJ4VO",
"ApproximateFirstReceiveTimestamp": "1545082649185"
},
"messageAttributes": {
"myAttribute": {
"stringValue": "myValue",
"stringListValues": [],
"binaryListValues": [],
"dataType": "String"
}
},
"md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3",
"eventSource": "aws:sqs",
"eventSourceARN": "arn:aws:sqs:us-east-2:123456789012:my-queue",
"awsRegion": "us-east-2"
},
{
"messageId": "2e1424d4-f796-459a-8184-9c92662be6da",
"receiptHandle": "AQEBzWwaftRI0KuVm4tP+/7q1rGgNqicHq...",
"body": "Test message.",
"attributes": {
"ApproximateReceiveCount": "1",
"SentTimestamp": "1545082650636",
"SenderId": "AIDAIENQZJOLO23YVJ4VO",
"ApproximateFirstReceiveTimestamp": "1545082650649"
},
"messageAttributes": {},
"md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3",
"eventSource": "aws:sqs",
"eventSourceARN": "arn:aws:sqs:us-east-2:123456789012:my-queue",
"awsRegion": "us-east-2"
}
]
}
```
Par défaut, Lambda interroge jusqu’à 10 messages à la fois dans votre file d’attente, et envoie ce lot à votre fonction. Pour éviter d’invoquer la fonction avec un petit nombre d’enregistrements, vous pouvez configurer la source d’événement de manière à les mettre en mémoire tampon pendant 5 minutes en configurant une fenêtre de lot. Avant d’invoquer la fonction, Lambda continue d’interroger les messages de la file d’attente standard jusqu’à ce que la fenêtre de lot expire, que le [quota de taille des données utiles de l’invocation](gettingstarted-limits.md) soit atteint ou que la taille maximale configurée du lot soit atteinte.
Si vous utilisez une fenêtre de lot et que votre file d’attente SQS contient un trafic très faible, Lambda peut attendre 20 secondes avant d’invoquer votre fonction. C’est le cas même si vous définissez une fenêtre de lot inférieure à 20 secondes.
**Note**
Sous Java, vous pouvez rencontrer des erreurs de pointeur nul lors de la désérialisation de JSON. Cela peut être dû à la façon dont les cas « Records » (Enregistrements) et « eventSourceARN » sont convertis par le mappeur d’objets JSON.
## Exemple d’événement de message de file d’attente FIFO
Pour les files d’attente FIFO, les enregistrements contiennent des attributs supplémentaires liés à la déduplication et au séquençage.
**Example Événement de message Amazon SQS (file d’attente FIFO)**
```
{
"Records": [
{
"messageId": "11d6ee51-4cc7-4302-9e22-7cd8afdaadf5",
"receiptHandle": "AQEBBX8nesZEXmkhsmZeyIE8iQAMig7qw...",
"body": "Test message.",
"attributes": {
"ApproximateReceiveCount": "1",
"SentTimestamp": "1573251510774",
"SequenceNumber": "18849496460467696128",
"MessageGroupId": "1",
"SenderId": "AIDAIO23YVJENQZJOL4VO",
"MessageDeduplicationId": "1",
"ApproximateFirstReceiveTimestamp": "1573251510774"
},
"messageAttributes": {},
"md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3",
"eventSource": "aws:sqs",
"eventSourceARN": "arn:aws:sqs:us-east-2:123456789012:fifo.fifo",
"awsRegion": "us-east-2"
}
]
}
```
# Création et configuration d’un mappage des sources d’événements Amazon SQS
Pour traiter les messages Amazon SQS avec Lambda, configurez votre file d’attente avec les paramètres appropriés, puis créez un mappage des sources d’événements Lambda.
**Topics**
+ [
## Configuration d’une file d’attente à utiliser avec Lambda
](#events-sqs-queueconfig)
+ [
## Configuration des autorisations de rôle d’exécution Lambda
](#events-sqs-permissions)
+ [
## Création d’un mappage des sources d’événements SQS
](#events-sqs-eventsource)
## Configuration d’une file d’attente à utiliser avec Lambda
Si vous n’avez pas encore de file d’attente Amazon SQS, [créez-en une](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-configure-create-queue.html) à utiliser en tant que source d’événement pour votre fonction Lambda. [La fonction Lambda et la file d'attente Amazon SQS doivent être Région AWS identiques, bien qu'elles puissent être différentes. Comptes AWS](with-sqs-cross-account-example.md)
Pour laisser à votre fonction le temps de traiter chaque lot d’enregistrements, définissez le [délai de visibilité](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html) de la file d’attente source à au moins six fois le [délai de configuration](configuration-timeout.md) sur votre fonction. Le délai supplémentaire permet à Lambda d’effectuer une nouvelle tentative si l’exécution de la fonction est limitée pendant le traitement d’un lot précédent.
**Note**
Le délai d’expiration de votre fonction doit être inférieur ou égal au délai d’expiration de visibilité de la file d’attente. Lambda valide cette exigence lorsque vous créez ou mettez à jour un mappage des sources d’événements, et renvoie une erreur si le délai d’expiration de la fonction dépasse le délai d’expiration de visibilité de la file d’attente.
Par défaut, si Lambda rencontre une erreur à un moment donné lors du traitement d’un lot, tous les messages de ce lot retournent dans la file d’attente. Après le [délai de visibilité](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html), les messages redeviennent visibles pour Lambda. Vous pouvez configurer le mappage des sources d’événements pour utiliser les [réponses par lots partielles](services-sqs-errorhandling.md#services-sqs-batchfailurereporting) afin que seuls les messages ayant échoué soient renvoyés dans la file d’attente. En outre, en cas d’échec répété du traitement d’un message, Amazon SQS peut envoyer celui-ci à une [file d’attente de lettres mortes](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html). Nous vous recommandons de définir `maxReceiveCount` sur la [stratégie de redirection](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html#policies-for-dead-letter-queues) de votre file d’attente source sur au moins 5. Cela donne à Lambda la possibilité d’effectuer quelques tentatives avant d’envoyer les messages ayant échoué directement à la file d’attente de lettres mortes.
## Configuration des autorisations de rôle d’exécution Lambda
La politique [ AWSLambdaSQSQueueExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaSQSQueueExecutionRole.html) AWS gérée inclut les autorisations dont Lambda a besoin pour lire depuis votre file d'attente Amazon SQS. Vous pouvez ajouter cette politique gérée au [rôle d’exécution](lambda-intro-execution-role.md) de votre fonction.
En option, si vous utilisez une file d’attente chiffrée, vous devez également ajouter l’autorisation suivante à votre rôle d’exécution :
+ [kms:Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html)
## Création d’un mappage des sources d’événements SQS
Créez un mappage de source d’événement pour indiquer à Lambda d’envoyer des éléments de votre file d’attente à une fonction Lambda. Vous pouvez créer plusieurs mappages de source d’événement pour traiter des éléments de plusieurs files d’attente avec une seule fonction. Quand Lambda invoque la fonction cible, l’événement peut contenir plusieurs éléments, jusqu’à une *taille de lot* maximale configurable.
Pour configurer votre fonction afin qu'elle puisse lire depuis Amazon SQS, associez la politique [ AWSLambdaSQSQueueExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaSQSQueueExecutionRole.html) AWS gérée à votre rôle d'exécution. Créez ensuite un mappage des sources d’événements **SQS** à partir de la console en suivant les étapes suivantes.
**Pour ajouter des autorisations et créer un déclencheur**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez le nom d’une fonction.
1. Choisissez l’onglet **Configuration**, puis **Permissions** (Autorisations).
1. Sous **Nom du rôle**, cliquez sur le lien vers votre rôle d’exécution. Ce lien ouvre le rôle dans la console IAM.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/execution-role.png)
1. Choisissez **Ajouter des autorisations**, puis **Attacher des politiques**.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/attach-policies.png)
1. Dans le champ de recherche, entrez `AWSLambdaSQSQueueExecutionRole`. Ajoutez cette politique à votre rôle d’exécution. Il s'agit d'une politique AWS gérée qui contient les autorisations dont votre fonction a besoin pour lire depuis une file d'attente Amazon SQS. Pour plus d'informations sur cette politique, consultez [ AWSLambdaSQSQueueExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaSQSQueueExecutionRole.html)la *référence des politiques AWS gérées*.
1. Revenez à votre fonction dans la console Lambda. Sous **Function overview (Vue d’ensemble de la fonction)**, choisissez **Add trigger (Ajouter un déclencheur)**.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/add-trigger.png)
1. Choisissez un type de déclencheur.
1. Configurez les options requises, puis choisissez **Add (Ajouter)**.
Lambda prend en charge les options de configuration suivantes pour les sources d’événements Amazon SQS :
**File d’attente SQS**
La file d’attente Amazon SQS à partir de laquelle lire les enregistrements. [La fonction Lambda et la file d'attente Amazon SQS doivent être Région AWS identiques, bien qu'elles puissent être différentes. Comptes AWS](with-sqs-cross-account-example.md)
**Activation du déclencheur**
L’état du mappage des sources d’événements. **Activez le déclencheur** est sélectionné par défaut.
**Taille de lot**
Le nombre maximum d’enregistrements à envoyer à la fonction dans chaque lot. Pour une file d’attente standard, cela peut aller jusqu’à 10 000 registres. Pour une file d’attente FIFO, le maximum est de 10. Pour une taille de lot supérieure à 10, vous devez également définir la fenêtre de lot (`MaximumBatchingWindowInSeconds`) sur au moins 1 seconde.
Configurez le [délai d’attente de votre fonction](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/configurations#timeouts) de façon à laisser suffisamment de temps pour traiter le lot entier d’éléments. Si les éléments sont longs à traiter, choisissez une taille de lot plus petite. Une grande taille de lot peut améliorer l’efficacité pour des charges de travail qui sont très rapides ou qui induisent beaucoup d’efforts supplémentaires. Si vous configurez une [simultanéité réservée](configuration-concurrency.md) sur votre fonction, définissez un minimum de cinq exécutions simultanées pour réduire le risque d’erreurs de limitation lorsque Lambda invoque votre fonction.
Lambda transmet tous les registres du lot à la fonction en un seul appel, tant que la taille totale des événements ne dépasse pas le [quota de taille des données utiles d’invocation](gettingstarted-limits.md) pour une invocation synchrone (6 Mo). Des métadonnées sont générées par Lambda et Amazon SQS pour chaque registre. Ces métadonnées supplémentaires sont comptabilisées dans la taille de charge utile totale, ce qui peut entraîner l’envoi dans un lot d’un nombre total d’enregistrements inférieur à la taille du lot configuré. Les champs de métadonnées qu’Amazon SQS envoie peuvent être de longueur variable. Pour plus d'informations sur les champs de métadonnées Amazon SQS, consultez la documentation relative aux opérations d'[ReceiveMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html)API dans le manuel *Amazon Simple Queue Service API Reference*.
**Fenêtre de lot**
Intervalle de temps maximal (en secondes) pour collecter des enregistrements avant d’invoquer la fonction. Cela s’applique uniquement aux files d’attente standards.
Si vous utilisez une fenêtre de lot supérieure à 0 seconde, vous devez tenir compte de l’augmentation du temps de traitement dans le [délai de visibilité](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html) de votre file d’attente. Nous vous recommandons de paramétrer votre délai de visibilité de file d’attente à six fois le [délai d’expiration de la fonction](configuration-timeout.md), en plus de la valeur de `MaximumBatchingWindowInSeconds`. Cela permet à votre fonction Lambda de traiter chaque lot d’événements et de réessayer en cas d’erreur de limitation.
Lorsque les messages sont disponibles, Lambda commence à les traiter par lots. Lambda commence à traiter cinq lots à la fois avec cinq invocations simultanés de votre fonction. Si les messages sont toujours disponibles, Lambda ajoute jusqu'à 300 appels simultanés de votre fonction par minute, jusqu'à un maximum de 1 250 appels simultanés. En mode provisionné, chaque sondeur d'événements peut gérer jusqu'à 1 % MB/s du débit, jusqu'à 10 appels simultanés ou jusqu'à 10 appels d'API d'interrogation Amazon SQS par seconde. Lambda adapte le nombre de sondeurs d'événements entre le minimum et le maximum configurés, en ajoutant rapidement jusqu'à 1 000 appels simultanés par minute afin de fournir un traitement à faible latence de vos événements Amazon SQS. Vous pouvez contrôler la mise à l'échelle et la simultanéité grâce à ces paramètres minimaux et maximaux d'un sondeur d'événements. Pour en savoir plus sur la mise à l'échelle et la simultanéité des fonctions, consultez[Présentation de la mise à l’échelle de fonction Lambda](lambda-concurrency.md).
Pour traiter plus de messages, vous pouvez optimiser votre fonction Lambda pour un débit plus élevé. Pour plus d'informations, consultez [Comprendre comment s' AWS Lambda adapte aux files d'attente standard Amazon SQS.](https://aws.amazon.com/blogs/compute/understanding-how-aws-lambda-scales-when-subscribed-to-amazon-sqs-queues/#:~:text=If there are more messages,messages from the SQS queue.)
**Critères de filtrage**
Ajoutez des critères de filtrage pour contrôler les événements que Lambda envoie à votre fonction pour traitement. Pour de plus amples informations, veuillez consulter [Contrôle des événements envoyés par Lambda à votre fonction](invocation-eventfiltering.md).
**Simultanéité maximum**
Le nombre maximum de fonctions simultanées que la source d’événement peut invoquer. Ne peut pas être utilisé lorsque le mode provisionné est activé. Pour de plus amples informations, veuillez consulter [Configuration de la simultanéité maximale pour les sources d’événements Amazon SQS](services-sqs-scaling.md#events-sqs-max-concurrency).
**Mode alloué**
Lorsque cette option est activée, alloue des ressources de sondage dédiées au mappage des sources de votre événement. Vous pouvez configurer le nombre minimum (2-200) et maximum (2-2000) de sondeurs d'événements. Chaque sondeur d'événements peut gérer jusqu'à 1 % MB/sec du débit, jusqu'à 10 appels simultanés ou jusqu'à 10 appels d'API d'interrogation Amazon SQS par seconde.
Remarque : vous ne pouvez pas utiliser simultanément le mode provisionné et la simultanéité maximale. Lorsque le mode provisionné est activé, utilisez le paramètre du nombre maximum de sondeurs pour contrôler la simultanéité.
# Configuration du comportement de mise à l’échelle pour les mappages des sources d’événements SQS
Vous pouvez contrôler le comportement de dimensionnement de vos mappages de sources d'événements Amazon SQS via des paramètres de simultanéité maximale ou en activant le mode provisionné. Ces options s'excluent mutuellement.
Par défaut, Lambda adapte automatiquement les sondeurs d'événements en fonction du volume des messages. Lorsque vous activez le mode provisionné, vous allouez un nombre minimum et maximum de ressources de sondage dédiées qui restent prêtes à gérer les modèles de trafic attendus. Cela vous permet d'optimiser les performances de votre mappage des sources d'événements de deux manières :
+ Mode standard (par défaut) : Lambda gère automatiquement le dimensionnement, en commençant par un petit nombre de sondeurs, puis en augmentant ou en diminuant en fonction de la charge de travail.
+ Mode provisionné : vous configurez des ressources d'interrogation dédiées avec des limites minimales et maximales, ce qui permet une mise à l'échelle 3 fois plus rapide et une capacité de traitement jusqu'à 16 fois supérieure.
Pour les files d’attente standard, Lambda utilise une [interrogation longue](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-short-and-long-polling.html#sqs-long-polling) pour interroger une file d’attente jusqu’à ce qu’elle devienne active. Lorsque les messages sont disponibles, Lambda commence à traiter cinq lots à la fois avec cinq invocations simultanées de votre fonction. Si les messages sont toujours disponibles, Lambda augmente le nombre de processus lisant des lots de 300 appels simultanés supplémentaires par minute. Le nombre maximum d'appels qu'un mappage de source d'événement peut traiter simultanément est de 1 250. Lorsque le trafic est faible, Lambda réduit le traitement à cinq appels simultanés et peut l'optimiser jusqu'à deux appels simultanés afin de réduire les appels Amazon SQS et les coûts correspondants. Toutefois, cette optimisation n’est pas disponible lorsque vous activez le paramètre de simultanéité maximale.
Pour les files d’attente FIFO, Lambda envoie les messages à votre fonction dans l’ordre de leur réception. Lorsque vous envoyez un message à une file d’attente FIFO, vous spécifiez un [ID de groupe de messages](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/using-messagegroupid-property.html). Amazon SQS veille à ce que les messages du même groupe soient livrés à Lambda dans l’ordre. Lorsque Lambda lit vos messages par lots, chaque lot peut contenir des messages provenant de plusieurs groupes de messages, mais l’ordre des messages est conservé. Si la fonction renvoie une erreur, toutes les nouvelles tentatives sont effectuées sur les messages concernés avant que Lambda reçoive des messages supplémentaires du même groupe.
En mode provisionné, chaque sondeur d'événements peut gérer jusqu'à 1 % MB/sec du débit, jusqu'à 10 appels simultanés ou jusqu'à 10 appels d'API d'interrogation Amazon SQS par seconde. Lambda adapte le nombre d'interrogateurs d'événements entre le minimum et le maximum configurés, en ajoutant rapidement jusqu'à 1 000 appels simultanés par minute afin de fournir un traitement cohérent et à faible latence de vos événements Amazon SQS. L’utilisation du mode alloué génère des coûts supplémentaires. Pour connaître les tarifs détaillés, consultez [AWS Lambda les tarifs](https://aws.amazon.com/lambda/pricing/). Chaque sondeur d'événements utilise de [longs sondages dans](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-short-and-long-polling.html) votre file d'attente SQS, avec jusqu'à 10 sondages par seconde, ce qui entraîne des coûts liés aux demandes d'API SQS. Consultez la [tarification d'Amazon SQS](https://aws.amazon.com/sqs/pricing/ ) pour plus de détails. Vous pouvez contrôler la mise à l'échelle et la simultanéité par le biais de ces paramètres minimaux et maximaux d'un sondeur d'événements, plutôt que d'utiliser le paramètre de simultanéité maximale, car ces options ne peuvent pas être utilisées conjointement.
**Note**
Vous ne pouvez pas utiliser le paramètre de simultanéité maximale et le mode provisionné en même temps. Lorsque le mode provisionné est activé, vous contrôlez le dimensionnement et la simultanéité du mappage de votre source d'événements Amazon SQS via le nombre minimum et maximum de sondeurs d'événements.
## Configuration de la simultanéité maximale pour les sources d’événements Amazon SQS
Vous pouvez utiliser le paramètre de simultanéité maximale pour contrôler le comportement de mise à l’échelle de vos sources d’événements SQS. Notez que la simultanéité maximale ne peut pas être utilisée lorsque le mode provisionné est activé. Le paramètre de simultanéité maximale limite le nombre d’instances simultanées de la fonction qu’une source d’événements Amazon SQS peut invoquer. La simultanéité maximale est un paramètre de niveau source d’événement. Si vous avez plusieurs sources d’événements Amazon SQS mappées à une fonction, chaque source d’événements peut avoir un paramètre de simultanéité maximale séparé. Vous pouvez utiliser la simultanéité maximale pour empêcher une file d’attente d’utiliser toute la [simultanéité réservée](configuration-concurrency.md) de la fonction ou le reste du [quota de simultanéité du compte](gettingstarted-limits.md). La configuration de la simultanéité maximale sur une source d’événements Amazon SQS est gratuite.
Il est important de noter que la simultanéité maximale et la simultanéité réservée sont deux paramètres indépendants. Ne définissez pas une simultanéité maximale supérieure à la simultanéité réservée de la fonction. Si vous configurez la simultanéité maximale, assurez-vous que la simultanéité réservée de votre fonction est supérieure ou égale à la simultanéité maximale totale pour toutes les sources d’événements Amazon SQS sur la fonction. Sinon, Lambda peut limiter vos messages.
Lorsque le quota de simultanéité de votre compte est défini sur la valeur par défaut de 1 000, un mappage des sources d’événements Amazon SQS peut être mis à l’échelle pour invoquer des instances de fonction jusqu’à cette valeur, sauf si vous spécifiez une simultanéité maximale.
Si vous recevez une augmentation du quota de simultanéité par défaut de votre compte, Lambda risque de ne pas être en mesure d’invoquer des instances de fonctions concurrentes jusqu’à votre nouveau quota. Par défaut, Lambda peut effectuer une mise à l’échelle pour invoquer jusqu’à 1 250 instances de fonctions simultanées pour un mappage des sources d’événements Amazon SQS. Si cela ne correspond pas à votre cas d'utilisation, contactez le AWS support pour discuter d'une augmentation de la simultanéité du mappage des sources d'événements Amazon SQS de votre compte.
**Note**
Pour les files d'attente FIFO, les appels simultanés sont plafonnés soit par le nombre de [groupes de messages IDs](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/using-messagegroupid-property.html) (`messageGroupId`), soit par le paramètre de simultanéité maximal, selon le plus faible des deux. Par exemple, si vous avez six groupes de messages IDs et que la simultanéité maximale est fixée à 10, votre fonction peut avoir un maximum de six appels simultanés.
Vous pouvez configurer la simultanéité maximale sur les mappages des sources d’événements Amazon SQS nouveaux et existants.
**Configuration de la simultanéité maximale à l’aide de la console Lambda**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez le nom d’une fonction.
1. Sous **Function overview** (Vue d’ensemble des fonctions), choisissez **SQS**. Cela ouvre l’onglet **Configuration**.
1. Sélectionnez le déclencheur Amazon SQS et choisissez **Edit** (Modifier).
1. Pour **Maximum concurrency** (Simultanéité maximale), saisissez un nombre compris entre 2 et 1 000. Pour désactiver la simultanéité maximale, laissez la case vide.
1. Choisissez **Enregistrer**.
**Configurez la simultanéité maximale à l'aide de AWS Command Line Interface ()AWS CLI**
Utilisez la commande [update-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-event-source-mapping.html) avec l’option `--scaling-config`. Exemple :
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--scaling-config '{"MaximumConcurrency":5}'
```
Pour désactiver la simultanéité maximale, entrez une valeur vide pour `--scaling-config` :
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--scaling-config "{}"
```
**Configuration de la simultanéité maximale à l’aide de l’API Lambda**
Utilisez l'[UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)action [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)ou avec un [ScalingConfig](https://docs.aws.amazon.com/lambda/latest/api/API_ScalingConfig.html)objet.
# Gestion des erreurs pour une source d’événements SQS dans Lambda
Pour gérer les erreurs liées à une source d’événement SQS, Lambda utilise automatiquement une stratégie de nouvelle tentative associée à une stratégie de backoff. Vous pouvez également personnaliser le comportement de gestion des erreurs en configurant votre mappage des sources d’événements SQS de manière à renvoyer des [réponses par lots partielles](#services-sqs-batchfailurereporting).
## Stratégie d’interruption pour les invocations ayant échoué
Lorsqu’une invocation échoue, Lambda tente de réessayer l’invocation tout en mettant en œuvre une stratégie d’interruption. La stratégie d’interruption diffère légèrement selon que Lambda a rencontré l’échec à cause d’une erreur dans votre code de fonction, ou à cause de la limitation.
+ Si votre **code de fonction** est à l’origine de l’erreur, Lambda arrête le traitement et effectue une nouvelle tentative d’invocation. Dans le même temps, Lambda réduit progressivement les tentatives en diminuant la quantité de simultanéité allouée à votre mappage des sources d’événements Amazon SQS. Une fois le délai de visibilité de votre file d’attente expiré, le message réapparaît dans la file d’attente.
+ Si l’invocation échoue en raison d’une **limitation**, Lambda réduit progressivement les tentatives en diminuant la quantité de simultanéité allouée à votre mappage des sources d’événements Amazon SQS. Lambda continue à réessayer le message jusqu’à ce que l’horodatage du message dépasse le délai de visibilité de votre file d’attente, auquel cas Lambda abandonne le message.
## Mise en œuvre de réponses partielles de lot
Lorsque votre fonction Lambda rencontre une erreur lors du traitement d’un lot, tous les messages de ce lot redeviennent par défaut visibles dans la file d’attente, y compris les messages traités avec succès par Lambda. Par conséquent, votre fonction peut finir par traiter le même message plusieurs fois.
Pour éviter de retraiter les messages traités avec succès d’un lot en échec, vous pouvez configurer le mappage des sources d’événements pour que seuls les messages ayant échoué soient à nouveau visibles. C’est ce que l’on appelle une réponse partielle de lot. Pour activer les réponses partielles par lots, spécifiez `ReportBatchItemFailures` l'[FunctionResponseTypes](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html#lambda-UpdateEventSourceMapping-request-FunctionResponseTypes)action lors de la configuration du mappage des sources d'événements. Cela permet à votre fonction de renvoyer un succès partiel, ce qui peut contribuer à réduire le nombre de nouvelles tentatives inutiles sur les enregistrements.
**Note**
L'[utilitaire Batch Processor](https://docs.powertools.aws.dev/lambda/python/latest/utilities/batch/) de Powertools for AWS Lambda gère automatiquement toute la logique de réponse partielle par lots. Cet utilitaire simplifie la mise en œuvre de modèles de traitement par lots et réduit le code personnalisé nécessaire pour gérer correctement les échecs d’éléments de lots. Il est disponible pour Python, Java, TypeScript et .NET.
Lorsque `ReportBatchItemFailures` est activé, Lambda ne [réduit pas la taille de l’interrogation des messages](#services-sqs-backoff-strategy) lorsque les invocations de fonctions échouent. Si vous vous attendez à ce que certains messages échouent et que vous ne voulez pas que ces échecs aient un impact sur le taux de traitement des messages, utilisez `ReportBatchItemFailures`.
**Note**
Gardez les points suivants à l’esprit lorsque vous utilisez des réponses partielles de lot :
Si la fonction génère une exception, l’ensemble du lot est considéré comme un échec complet.
Si vous utilisez cette fonctionnalité avec une file d’attente FIFO, votre fonction doit arrêter le traitement des messages après le premier échec et renvoyer tous les messages échoués et non traités dans `batchItemFailures`. Cela permet de préserver l’ordre des messages dans votre file d’attente.
**Pour activer les rapports partiels de lot**
1. Consultez les [bonnes pratiques pour la mise en œuvre des réponses partielles de lot](https://docs.aws.amazon.com/prescriptive-guidance/latest/lambda-event-filtering-partial-batch-responses-for-sqs/best-practices-partial-batch-responses.html).
1. Exécutez la commande suivante pour activer `ReportBatchItemFailures` pour votre fonction. Pour récupérer l'UUID du mappage de votre source d'événements, exécutez la [list-event-source-mappings](https://docs.aws.amazon.com/cli/latest/reference/lambda/list-event-source-mappings.html) AWS CLI commande.
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--function-response-types "ReportBatchItemFailures"
```
1. Mettez à jour le code de votre fonction afin de capturer toutes les exceptions et de renvoyer les messages d’échec dans une réponse JSON `batchItemFailures`. La `batchItemFailures` réponse doit inclure une liste de messages IDs, sous forme de valeurs `itemIdentifier` JSON.
Supposons, par exemple, que vous disposiez d'un lot de cinq messages IDs `id1`, avec le message `id2``id3`,`id4`,, et`id5`. Votre fonction traite avec succès `id1`, `id3` et `id5`. Pour rendre les messages `id2` et `id4` visibles de nouveau dans la file d’attente, votre fonction doit renvoyer la réponse suivante :
```
{
"batchItemFailures": [
{
"itemIdentifier": "id2"
},
{
"itemIdentifier": "id4"
}
]
}
```
Voici quelques exemples de code de fonction qui renvoie la liste des messages ayant échoué IDs dans le lot :
------
#### [ .NET ]
**SDK pour .NET**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures).
Signalement des échecs d’articles par lots SQS avec Lambda à l’aide de .NET.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
using Amazon.Lambda.Core;
using Amazon.Lambda.SQSEvents;
// Assembly attribute to enable the Lambda function's JSON input to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace sqsSample;
public class Function
{
public async Task FunctionHandler(SQSEvent evnt, ILambdaContext context)
{
List batchItemFailures = new List();
foreach(var message in evnt.Records)
{
try
{
//process your message
await ProcessMessageAsync(message, context);
}
catch (System.Exception)
{
//Add failed message identifier to the batchItemFailures list
batchItemFailures.Add(new SQSBatchResponse.BatchItemFailure{ItemIdentifier=message.MessageId});
}
}
return new SQSBatchResponse(batchItemFailures);
}
private async Task ProcessMessageAsync(SQSEvent.SQSMessage message, ILambdaContext context)
{
if (String.IsNullOrEmpty(message.Body))
{
throw new Exception("No Body in SQS Message.");
}
context.Logger.LogInformation($"Processed message {message.Body}");
// TODO: Do interesting work based on the new message
await Task.CompletedTask;
}
}
```
------
#### [ Go ]
**Kit SDK pour Go V2**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures).
Signalement des échecs d’articles par lots SQS avec Lambda à l’aide de Go.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
package main
import (
"context"
"fmt"
"github.com/aws/aws-lambda-go/events"
"github.com/aws/aws-lambda-go/lambda"
)
func handler(ctx context.Context, sqsEvent events.SQSEvent) (map[string]interface{}, error) {
batchItemFailures := []map[string]interface{}{}
for _, message := range sqsEvent.Records {
if len(message.Body) > 0 {
// Your message processing condition here
fmt.Printf("Successfully processed message: %s\n", message.Body)
} else {
// Message processing failed
fmt.Printf("Failed to process message %s\n", message.MessageId)
batchItemFailures = append(batchItemFailures, map[string]interface{}{"itemIdentifier": message.MessageId})
}
}
sqsBatchResponse := map[string]interface{}{
"batchItemFailures": batchItemFailures,
}
return sqsBatchResponse, nil
}
func main() {
lambda.Start(handler)
}
```
------
#### [ Java ]
**SDK pour Java 2.x**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures).
Signalement des échecs d’articles par lots SQS avec Lambda à l’aide de Java.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.SQSEvent;
import com.amazonaws.services.lambda.runtime.events.SQSBatchResponse;
import java.util.ArrayList;
import java.util.List;
public class ProcessSQSMessageBatch implements RequestHandler {
@Override
public SQSBatchResponse handleRequest(SQSEvent sqsEvent, Context context) {
List batchItemFailures = new ArrayList();
for (SQSEvent.SQSMessage message : sqsEvent.getRecords()) {
try {
//process your message
} catch (Exception e) {
//Add failed message identifier to the batchItemFailures list
batchItemFailures.add(new SQSBatchResponse.BatchItemFailure(message.getMessageId()));
}
}
return new SQSBatchResponse(batchItemFailures);
}
}
```
------
#### [ JavaScript ]
**SDK pour JavaScript (v3)**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures).
Signaler les défaillances d'éléments de lot SQS avec JavaScript Lambda à l'aide de.
```
// Node.js 20.x Lambda runtime, AWS SDK for Javascript V3
export const handler = async (event, context) => {
const batchItemFailures = [];
for (const record of event.Records) {
try {
await processMessageAsync(record, context);
} catch (error) {
batchItemFailures.push({ itemIdentifier: record.messageId });
}
}
return { batchItemFailures };
};
async function processMessageAsync(record, context) {
if (record.body && record.body.includes("error")) {
throw new Error("There is an error in the SQS Message.");
}
console.log(`Processed message: ${record.body}`);
}
```
Signaler les défaillances d'éléments de lot SQS avec TypeScript Lambda à l'aide de.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
import { SQSEvent, SQSBatchResponse, Context, SQSBatchItemFailure, SQSRecord } from 'aws-lambda';
export const handler = async (event: SQSEvent, context: Context): Promise => {
const batchItemFailures: SQSBatchItemFailure[] = [];
for (const record of event.Records) {
try {
await processMessageAsync(record);
} catch (error) {
batchItemFailures.push({ itemIdentifier: record.messageId });
}
}
return {batchItemFailures: batchItemFailures};
};
async function processMessageAsync(record: SQSRecord): Promise {
if (record.body && record.body.includes("error")) {
throw new Error('There is an error in the SQS Message.');
}
console.log(`Processed message ${record.body}`);
}
```
------
#### [ PHP ]
**Kit SDK pour PHP**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures).
Signalement des échecs d’articles par lots SQS avec Lambda à l’aide de PHP.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
logger = $logger;
}
/**
* @throws JsonException
* @throws \Bref\Event\InvalidLambdaEvent
*/
public function handleSqs(SqsEvent $event, Context $context): void
{
$this->logger->info("Processing SQS records");
$records = $event->getRecords();
foreach ($records as $record) {
try {
// Assuming the SQS message is in JSON format
$message = json_decode($record->getBody(), true);
$this->logger->info(json_encode($message));
// TODO: Implement your custom processing logic here
} catch (Exception $e) {
$this->logger->error($e->getMessage());
// failed processing the record
$this->markAsFailed($record);
}
}
$totalRecords = count($records);
$this->logger->info("Successfully processed $totalRecords SQS records");
}
}
$logger = new StderrLogger();
return new Handler($logger);
```
------
#### [ Python ]
**Kit SDK for Python (Boto3)**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures).
Signalement des échecs d’articles par lots SQS avec Lambda à l’aide de Python.
```
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
def lambda_handler(event, context):
if event:
batch_item_failures = []
sqs_batch_response = {}
for record in event["Records"]:
try:
print(f"Processed message: {record['body']}")
except Exception as e:
batch_item_failures.append({"itemIdentifier": record['messageId']})
sqs_batch_response["batchItemFailures"] = batch_item_failures
return sqs_batch_response
```
------
#### [ Ruby ]
**Kit SDK pour Ruby**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda-with-batch-item-handling).
Signalement des échecs d’articles par lots SQS avec Lambda à l’aide de Ruby.
```
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
require 'json'
def lambda_handler(event:, context:)
if event
batch_item_failures = []
sqs_batch_response = {}
event["Records"].each do |record|
begin
# process message
rescue StandardError => e
batch_item_failures << {"itemIdentifier" => record['messageId']}
end
end
sqs_batch_response["batchItemFailures"] = batch_item_failures
return sqs_batch_response
end
end
```
------
#### [ Rust ]
**SDK pour Rust**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/lambda-function-sqs-report-batch-item-failures).
Signalement des échecs d’articles par lots SQS avec Lambda à l’aide de Rust.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
use aws_lambda_events::{
event::sqs::{SqsBatchResponse, SqsEvent},
sqs::{BatchItemFailure, SqsMessage},
};
use lambda_runtime::{run, service_fn, Error, LambdaEvent};
async fn process_record(_: &SqsMessage) -> Result<(), Error> {
Err(Error::from("Error processing message"))
}
async fn function_handler(event: LambdaEvent) -> Result {
let mut batch_item_failures = Vec::new();
for record in event.payload.records {
match process_record(&record).await {
Ok(_) => (),
Err(_) => batch_item_failures.push(BatchItemFailure {
item_identifier: record.message_id.unwrap(),
}),
}
}
Ok(SqsBatchResponse {
batch_item_failures,
})
}
#[tokio::main]
async fn main() -> Result<(), Error> {
run(service_fn(function_handler)).await
}
```
------
Si les événements ayant échoué ne retournent pas dans la file d'attente, voir [Comment résoudre les problèmes liés à la fonction Lambda SQS](https://aws.amazon.com/premiumsupport/knowledge-center/lambda-sqs-report-batch-item-failures/) ? ReportBatchItemFailures dans le AWS Knowledge Center.
### Conditions de réussite et d’échec
Lambda traite un lot comme un succès complet si votre fonction renvoie l’un des éléments suivants :
+ Une liste `batchItemFailures` vide
+ Une liste `batchItemFailures` nulle
+ Une `EventResponse` vide
+ Une `EventResponse` nulle
Lambda traite un lot comme un échec complet si votre fonction renvoie l’un des éléments suivants :
+ Une réponse JSON non valide
+ Une chaîne `itemIdentifier` vide
+ Un `itemIdentifier` nul
+ Un `itemIdentifier` avec un nom de clé incorrect
+ Une valeur `itemIdentifier` avec un ID de message inexistant
### CloudWatch métriques
Pour déterminer si votre fonction signale correctement les défaillances d'articles par lots, vous pouvez surveiller les métriques `NumberOfMessagesDeleted` et `ApproximateAgeOfOldestMessage` Amazon SQS sur Amazon. CloudWatch
+ `NumberOfMessagesDeleted` suit le nombre de messages supprimés de votre file d’attente. Si cela tombe à 0, cela indique que la réponse de votre fonction ne renvoie pas correctement les messages d’échec.
+ `ApproximateAgeOfOldestMessage` suit combien de temps le message le plus ancien est resté dans votre file d’attente. Une forte augmentation de cette métrique peut indiquer que votre fonction ne renvoie pas correctement les messages d’échec.
### Utilisation de Powertools pour le AWS Lambda traitement par lots
L'utilitaire de traitement par lots de Powertools for gère AWS Lambda automatiquement la logique de réponse partielle par lots, réduisant ainsi la complexité de la mise en œuvre du signalement des défaillances par lots. Voici des exemples d’utilisation de l’utilitaire de traitement par lots :
**Python**
Pour des exemples complets et des instructions de configuration, consultez la [documentation de l’utilitaire de traitement par lots](https://docs.powertools.aws.dev/lambda/python/latest/utilities/batch/).
Traitement des messages Amazon SQS à l'aide d'un AWS Lambda traitement par lots.
```
import json
from aws_lambda_powertools import Logger
from aws_lambda_powertools.utilities.batch import BatchProcessor, EventType, process_partial_response
from aws_lambda_powertools.utilities.data_classes import SQSEvent
from aws_lambda_powertools.utilities.typing import LambdaContext
processor = BatchProcessor(event_type=EventType.SQS)
logger = Logger()
def record_handler(record):
logger.info(record)
# Your business logic here
# Raise an exception to mark this record as failed
def lambda_handler(event, context: LambdaContext):
return process_partial_response(
event=event,
record_handler=record_handler,
processor=processor,
context=context
)
```
**TypeScript**
Pour des exemples complets et des instructions de configuration, consultez la [documentation de l’utilitaire de traitement par lots](https://docs.aws.amazon.com/powertools/typescript/latest/features/batch/).
Traitement des messages Amazon SQS à l'aide d'un AWS Lambda traitement par lots.
```
import { BatchProcessor, EventType, processPartialResponse } from '@aws-lambda-powertools/batch';
import { Logger } from '@aws-lambda-powertools/logger';
import type { SQSEvent, Context } from 'aws-lambda';
const processor = new BatchProcessor(EventType.SQS);
const logger = new Logger();
const recordHandler = async (record: any): Promise => {
logger.info('Processing record', { record });
// Your business logic here
// Throw an error to mark this record as failed
};
export const handler = async (event: SQSEvent, context: Context) => {
return processPartialResponse(event, recordHandler, processor, {
context,
});
};
```
# Paramètres Lambda pour les mappages des sources d’événement Amazon SQS
Tous les types de sources d'événements Lambda partagent les mêmes opérations [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)et les mêmes opérations d'[UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)API. Cependant, seuls certains paramètres s’appliquent à Amazon SQS.
| Paramètre | Obligatoire | Par défaut | Remarques |
| --- | --- | --- | --- |
| BatchSize | N | 10 | Pour les files d’attente standard, le maximum est de 10 000. Pour les files d’attente FIFO, le maximum est de 10. |
| Activé | N | VRAI | Aucune |
| EventSourceArn | Y | N/A | ARN du flux de données ou d’un consommateur de flux |
| FunctionName | Y | N/A | Aucune |
| FilterCriteria | N | N/A | [Contrôle des événements envoyés par Lambda à votre fonction](invocation-eventfiltering.md) |
| FunctionResponseTypes | N | N/A | Pour permettre à votre fonction de signaler des échecs spécifiques dans un lot, incluez la valeur `ReportBatchItemFailures` dans `FunctionResponseTypes`. Pour de plus amples informations, veuillez consulter [Mise en œuvre de réponses partielles de lot](services-sqs-errorhandling.md#services-sqs-batchfailurereporting). |
| MaximumBatchingWindowInSeconds | N | 0 | La fenêtre de traitement par lots n’est pas prise en charge pour les files d’attente FIFO |
| ProvisionedPollerConfig | N | N/A | Configure le nombre minimum (2-200) et maximum (2-2000) de sondeurs d'événements dédiés pour le mappage des sources d'événements SQS. Chaque sondeur peut gérer jusqu'à 1 % MB/sec du débit et 10 appels simultanés. |
| ScalingConfig | N | N/A | [Configuration de la simultanéité maximale pour les sources d’événements Amazon SQS](services-sqs-scaling.md#events-sqs-max-concurrency) |
# Utilisation du filtrage des événements avec une source d’événement Amazon SQS
Vous pouvez utiliser le filtrage d’événements pour contrôler les enregistrements d’un flux ou d’une file d’attente que Lambda envoie à votre fonction. Pour obtenir des informations générales sur le fonctionnement du filtrage des événements, consultez [Contrôle des événements envoyés par Lambda à votre fonction](invocation-eventfiltering.md).
Cette section porte sur le filtrage des événements pour les sources Amazon SQS.
**Note**
Les mappages des sources d’événements Amazon SQS prennent uniquement en charge le filtrage sur la clé `body`.
**Topics**
+ [
## Notions de base du filtrage des événements Amazon SQS
](#filtering-SQS)
## Notions de base du filtrage des événements Amazon SQS
Supposons que votre file d’attente Amazon SQS contienne des messages au format JSON suivant.
```
{
"RecordNumber": 1234,
"TimeStamp": "yyyy-mm-ddThh:mm:ss",
"RequestCode": "AAAA"
}
```
Un exemple d’enregistrement pour cette file d’attente ressemblerait à ce qui suit.
```
{
"messageId": "059f36b4-87a3-44ab-83d2-661975830a7d",
"receiptHandle": "AQEBwJnKyrHigUMZj6rYigCgxlaS3SLy0a...",
"body": "{\n "RecordNumber": 1234,\n "TimeStamp": "yyyy-mm-ddThh:mm:ss",\n "RequestCode": "AAAA"\n}",
"attributes": {
"ApproximateReceiveCount": "1",
"SentTimestamp": "1545082649183",
"SenderId": "AIDAIENQZJOLO23YVJ4VO",
"ApproximateFirstReceiveTimestamp": "1545082649185"
},
"messageAttributes": {},
"md5OfBody": "e4e68fb7bd0e697a0ae8f1bb342846b3",
"eventSource": "aws:sqs",
"eventSourceARN": "arn:aws:sqs:us-west-2:123456789012:my-queue",
"awsRegion": "us-west-2"
}
```
Pour filtrer en fonction du contenu de vos messages Amazon SQS, utilisez la clé `body` dans l’enregistrement du message Amazon SQS. Supposons que vous vouliez traiter uniquement les enregistrements où le `RequestCode` de votre message Amazon SQS est « BBBB ». L’objet `FilterCriteria` serait le suivant.
```
{
"Filters": [
{
"Pattern": "{ \"body\" : { \"RequestCode\" : [ \"BBBB\" ] } }"
}
]
}
```
Pour plus de clarté, voici la valeur du `Pattern` de filtre étendu en JSON simple :
```
{
"body": {
"RequestCode": [ "BBBB" ]
}
}
```
Vous pouvez ajouter votre filtre à l’aide de la console, d’AWS CLI ou d’un modèle AWS SAM.
------
#### [ Console ]
Pour ajouter ce filtre à l’aide de la console, suivez les instructions de [Attacher des critères de filtre à un mappage de sources d’événements (console)](invocation-eventfiltering.md#filtering-console) et saisissez la chaîne suivante comme **critère de filtre**.
```
{ "body" : { "RequestCode" : [ "BBBB" ] } }
```
------
#### [ AWS CLI ]
Pour créer un nouveau mappage des sources d’événements avec ces critères de filtrage à l’aide de l’outil AWS Command Line Interface (AWS CLI), exécutez la commande suivante.
```
aws lambda create-event-source-mapping \
--function-name my-function \
--event-source-arn arn:aws:sqs:us-east-2:123456789012:my-queue \
--filter-criteria '{"Filters": [{"Pattern": "{ \"body\" : { \"RequestCode\" : [ \"BBBB\" ] } }"}]}'
```
Pour ajouter ces critères de filtre à un mappage des sources d’événements existant, exécutez la commande suivante.
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--filter-criteria '{"Filters": [{"Pattern": "{ \"body\" : { \"RequestCode\" : [ \"BBBB\" ] } }"}]}'
```
------
#### [ AWS SAM ]
Pour ajouter ce filtre à l’aide d’AWS SAM, ajoutez l’extrait suivant au modèle YAML de votre source d’événement.
```
FilterCriteria:
Filters:
- Pattern: '{ "body" : { "RequestCode" : [ "BBBB" ] } }'
```
------
Supposons que vous vouliez que votre fonction ne traite que les enregistrements où `RecordNumber` est supérieur à 9 999. L’objet `FilterCriteria` serait le suivant.
```
{
"Filters": [
{
"Pattern": "{ \"body\" : { \"RecordNumber\" : [ { \"numeric\": [ \">\", 9999 ] } ] } }"
}
]
}
```
Pour plus de clarté, voici la valeur du `Pattern` de filtre étendu en JSON simple :
```
{
"body": {
"RecordNumber": [
{
"numeric": [ ">", 9999 ]
}
]
}
}
```
Vous pouvez ajouter votre filtre à l’aide de la console, d’AWS CLI ou d’un modèle AWS SAM.
------
#### [ Console ]
Pour ajouter ce filtre à l’aide de la console, suivez les instructions de [Attacher des critères de filtre à un mappage de sources d’événements (console)](invocation-eventfiltering.md#filtering-console) et saisissez la chaîne suivante comme **critère de filtre**.
```
{ "body" : { "RecordNumber" : [ { "numeric": [ ">", 9999 ] } ] } }
```
------
#### [ AWS CLI ]
Pour créer un nouveau mappage des sources d’événements avec ces critères de filtrage à l’aide de l’outil AWS Command Line Interface (AWS CLI), exécutez la commande suivante.
```
aws lambda create-event-source-mapping \
--function-name my-function \
--event-source-arn arn:aws:sqs:us-east-2:123456789012:my-queue \
--filter-criteria '{"Filters": [{"Pattern": "{ \"body\" : { \"RecordNumber\" : [ { \"numeric\": [ \">\", 9999 ] } ] } }"}]}'
```
Pour ajouter ces critères de filtre à un mappage des sources d’événements existant, exécutez la commande suivante.
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--filter-criteria '{"Filters": [{"Pattern": "{ \"body\" : { \"RecordNumber\" : [ { \"numeric\": [ \">\", 9999 ] } ] } }"}]}'
```
------
#### [ AWS SAM ]
Pour ajouter ce filtre à l’aide d’AWS SAM, ajoutez l’extrait suivant au modèle YAML de votre source d’événement.
```
FilterCriteria:
Filters:
- Pattern: '{ "body" : { "RecordNumber" : [ { "numeric": [ ">", 9999 ] } ] } }'
```
------
Pour Amazon SQS, le corps du message peut être n’importe quelle chaîne. Toutefois, cela peut être problématique si votre `FilterCriteria` s’attend à ce que `body` se présente dans un format JSON valide. Le scénario inverse est également vrai, si le corps du message entrant est au format JSON, mais que votre critère de filtre s’attend à ce que `body` soit une chaîne de texte brut, cela peut entraîner un comportement inattendu.
Pour éviter ce problème, assurez-vous que le format du corps dans vos `FilterCriteria` correspond au format attendu de `body` dans les messages que vous recevez de votre file d’attente. Avant de filtrer vos messages, Lambda évalue automatiquement le format du corps de votre message entrant et de votre modèle de filtre pour `body`. En cas de décalage, Lambda abandonne le message. Le tableau suivant résume cette évaluation :
| Format du `body` du message entrant | Format du `body` du modèle de filtre | Action obtenue. |
| --- | --- | --- |
| Chaîne de texte brut | Chaîne de texte brut | Lambda filtre en fonction de vos critères de filtre. |
| Chaîne de texte brut | Pas de modèle de filtre pour les propriétés des données | Lambda filtre (uniquement selon les autres propriétés de métadonnées) en fonction de vos critères de filtre. |
| Chaîne de texte brut | JSON valide | Lambda rejette le message. |
| JSON valide | Chaîne de texte brut | Lambda rejette le message. |
| JSON valide | Pas de modèle de filtre pour les propriétés des données | Lambda filtre (uniquement selon les autres propriétés de métadonnées) en fonction de vos critères de filtre. |
| JSON valide | JSON valide | Lambda filtre en fonction de vos critères de filtre. |
# Didacticiel : utilisation de Lambda avec Amazon SQS
Dans ce didacticiel, vous créerez une fonction Lambda qui consomme les messages d’une file d’attente [Amazon Simple Queue Service (Amazon SQS)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html). La fonction Lambda s’exécute chaque fois qu’un nouveau message est ajouté à la file d’attente. La fonction écrit les messages dans un flux Amazon CloudWatch Logs. Le diagramme suivant montre les ressources AWS utilisées pour compléter ce tutoriel.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/sqs_tut_resources.png)
Pour compléter ce didacticiel, effectuez les tâches suivantes :
1. Créez une fonction Lambda qui écrit des messages dans Logs. CloudWatch
1. Créer une file d’attente Amazon SQS.
1. Créez un mappage des sources d’événements Lambda. Le mappage des sources d’événements lit la file d’attente Amazon SQS et invoque votre fonction Lambda lorsqu’un nouveau message est ajouté.
1. Testez la configuration en ajoutant des messages à votre file d'attente et en surveillant les résultats dans CloudWatch Logs.
## Conditions préalables
### Installez le AWS Command Line Interface
Si vous ne l'avez pas encore installé AWS Command Line Interface, suivez les étapes décrites dans la [section Installation ou mise à jour de la dernière version du AWS CLI pour l'](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)installer.
Ce tutoriel nécessite un terminal de ligne de commande ou un shell pour exécuter les commandes. Sous Linux et macOS, utilisez votre gestionnaire de shell et de package préféré.
**Note**
Sous Windows, certaines commandes CLI Bash que vous utilisez couramment avec Lambda (par exemple `zip`) ne sont pas prises en charge par les terminaux intégrés du système d’exploitation. [Installez le sous-système Windows pour Linux](https://docs.microsoft.com/en-us/windows/wsl/install-win10) afin d’obtenir une version intégrée à Windows d’Ubuntu et Bash.
## Créer le rôle d’exécution
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/sqs_tut_steps1.png)
Un [rôle d'exécution](lambda-intro-execution-role.md) est un rôle Gestion des identités et des accès AWS (IAM) qui accorde à une fonction Lambda l'autorisation d' Services AWS accès et de ressources. Pour permettre à votre fonction de lire des éléments depuis Amazon SQS, joignez la politique d'**AWSLambdaSQSQueueExecutionRole**autorisation.
**Pour créer un rôle d’exécution et attacher une politique d’autorisations Amazon SQS**
1. Ouvrez la [page Rôles](https://console.aws.amazon.com/iam/home#/roles) de la console IAM.
1. Sélectionnez **Créer un rôle**.
1. Pour **Type d’entité de confiance**, choisissez **Service AWS **.
1. Pour **Cas d’utilisation**, choisissez **Lambda**.
1. Choisissez **Suivant**.
1. Dans le champ de recherche **Politiques d’autorisations**, saisissez **AWSLambdaSQSQueueExecutionRole**.
1. Sélectionnez la **AWSLambdaSQSQueueExecutionRole**politique, puis cliquez sur **Suivant**.
1. Sous **Détails du rôle**, pour **Nom du rôle**, saisissez **lambda-sqs-role**, puis sélectionnez **Créer un rôle**.
Après la création du rôle, notez l’Amazon Resource Name (ARN) de votre rôle d’exécution. Vous en aurez besoin dans les étapes suivantes.
## Créer la fonction
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/sqs_tut_steps2.png)
Créez une fonction Lambda qui traite vos messages Amazon SQS. Le code de fonction enregistre le corps du message Amazon SQS dans Logs. CloudWatch
Ce didacticiel utilise le runtime Node.js 24, mais nous avons également fourni des exemples de code dans d'autres langages d'exécution. Vous pouvez sélectionner l’onglet dans la zone suivante pour voir le code de l’exécution qui vous intéresse. Le JavaScript code que vous allez utiliser dans cette étape se trouve dans le premier exemple présenté dans l'**JavaScript**onglet.
------
#### [ .NET ]
**SDK pour .NET**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda).
Utilisation d’un événement SQS avec Lambda en utilisant .NET.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
using Amazon.Lambda.Core;
using Amazon.Lambda.SQSEvents;
// Assembly attribute to enable the Lambda function's JSON input to be converted into a .NET class.
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace SqsIntegrationSampleCode
{
public async Task FunctionHandler(SQSEvent evnt, ILambdaContext context)
{
foreach (var message in evnt.Records)
{
await ProcessMessageAsync(message, context);
}
context.Logger.LogInformation("done");
}
private async Task ProcessMessageAsync(SQSEvent.SQSMessage message, ILambdaContext context)
{
try
{
context.Logger.LogInformation($"Processed message {message.Body}");
// TODO: Do interesting work based on the new message
await Task.CompletedTask;
}
catch (Exception e)
{
//You can use Dead Letter Queue to handle failures. By configuring a Lambda DLQ.
context.Logger.LogError($"An error occurred");
throw;
}
}
}
```
------
#### [ Go ]
**Kit SDK pour Go V2**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda).
Consommation d’un événement SQS avec Lambda à l’aide de Go.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
package integration_sqs_to_lambda
import (
"fmt"
"github.com/aws/aws-lambda-go/events"
"github.com/aws/aws-lambda-go/lambda"
)
func handler(event events.SQSEvent) error {
for _, record := range event.Records {
err := processMessage(record)
if err != nil {
return err
}
}
fmt.Println("done")
return nil
}
func processMessage(record events.SQSMessage) error {
fmt.Printf("Processed message %s\n", record.Body)
// TODO: Do interesting work based on the new message
return nil
}
func main() {
lambda.Start(handler)
}
```
------
#### [ Java ]
**SDK pour Java 2.x**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda).
Utilisation d’un événement SQS avec Lambda à l’aide de Java.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.SQSEvent;
import com.amazonaws.services.lambda.runtime.events.SQSEvent.SQSMessage;
public class Function implements RequestHandler {
@Override
public Void handleRequest(SQSEvent sqsEvent, Context context) {
for (SQSMessage msg : sqsEvent.getRecords()) {
processMessage(msg, context);
}
context.getLogger().log("done");
return null;
}
private void processMessage(SQSMessage msg, Context context) {
try {
context.getLogger().log("Processed message " + msg.getBody());
// TODO: Do interesting work based on the new message
} catch (Exception e) {
context.getLogger().log("An error occurred");
throw e;
}
}
}
```
------
#### [ JavaScript ]
**SDK pour JavaScript (v3)**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/blob/main/integration-sqs-to-lambda).
Consommation d'un événement SQS avec JavaScript Lambda en utilisant.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
exports.handler = async (event, context) => {
for (const message of event.Records) {
await processMessageAsync(message);
}
console.info("done");
};
async function processMessageAsync(message) {
try {
console.log(`Processed message ${message.body}`);
// TODO: Do interesting work based on the new message
await Promise.resolve(1); //Placeholder for actual async work
} catch (err) {
console.error("An error occurred");
throw err;
}
}
```
Consommation d'un événement SQS avec TypeScript Lambda en utilisant.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
import { SQSEvent, Context, SQSHandler, SQSRecord } from "aws-lambda";
export const functionHandler: SQSHandler = async (
event: SQSEvent,
context: Context
): Promise => {
for (const message of event.Records) {
await processMessageAsync(message);
}
console.info("done");
};
async function processMessageAsync(message: SQSRecord): Promise {
try {
console.log(`Processed message ${message.body}`);
// TODO: Do interesting work based on the new message
await Promise.resolve(1); //Placeholder for actual async work
} catch (err) {
console.error("An error occurred");
throw err;
}
}
```
------
#### [ PHP ]
**Kit SDK pour PHP**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda).
Consommation d’un événement SQS avec Lambda à l’aide de PHP.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
logger = $logger;
}
/**
* @throws InvalidLambdaEvent
*/
public function handleSqs(SqsEvent $event, Context $context): void
{
foreach ($event->getRecords() as $record) {
$body = $record->getBody();
// TODO: Do interesting work based on the new message
}
}
}
$logger = new StderrLogger();
return new Handler($logger);
```
------
#### [ Python ]
**Kit SDK for Python (Boto3)**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda).
Utilisation d’un événement SQS avec Lambda à l’aide de Python.
```
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
def lambda_handler(event, context):
for message in event['Records']:
process_message(message)
print("done")
def process_message(message):
try:
print(f"Processed message {message['body']}")
# TODO: Do interesting work based on the new message
except Exception as err:
print("An error occurred")
raise err
```
------
#### [ Ruby ]
**Kit SDK pour Ruby**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda).
Utilisation d’un événement SQS avec Lambda à l’aide de Ruby.
```
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0
def lambda_handler(event:, context:)
event['Records'].each do |message|
process_message(message)
end
puts "done"
end
def process_message(message)
begin
puts "Processed message #{message['body']}"
# TODO: Do interesting work based on the new message
rescue StandardError => err
puts "An error occurred"
raise err
end
end
```
------
#### [ Rust ]
**SDK pour Rust**
Il y en a plus à ce sujet GitHub. Trouvez l’exemple complet et découvrez comment le configurer et l’exécuter dans le référentiel d’[exemples sans serveur](https://github.com/aws-samples/serverless-snippets/tree/main/integration-sqs-to-lambda).
Consommation d’un événement SQS avec Lambda à l’aide de Rust.
```
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
use aws_lambda_events::event::sqs::SqsEvent;
use lambda_runtime::{run, service_fn, Error, LambdaEvent};
async fn function_handler(event: LambdaEvent) -> Result<(), Error> {
event.payload.records.iter().for_each(|record| {
// process the record
tracing::info!("Message body: {}", record.body.as_deref().unwrap_or_default())
});
Ok(())
}
#[tokio::main]
async fn main() -> Result<(), Error> {
tracing_subscriber::fmt()
.with_max_level(tracing::Level::INFO)
// disable printing the name of the module in every log line.
.with_target(false)
// disabling time is handy because CloudWatch will add the ingestion time.
.without_time()
.init();
run(service_fn(function_handler)).await
}
```
------
**Pour créer une fonction Lambda Node.js.**
1. Créez un répertoire pour le projet, puis passez à ce répertoire.
```
mkdir sqs-tutorial
cd sqs-tutorial
```
1. Copiez l'exemple de JavaScript code dans un nouveau fichier nommé`index.js`.
1. Créez un package de déploiement à l’aide de la commande `zip` suivante.
```
zip function.zip index.js
```
1. Créez une fonction Lambda à l’aide de la commande AWS CLI [create-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-function.html). Pour le paramètre `role`, entrez l’ARN du rôle d’exécution que vous avez créé précédemment.
**Note**
La fonction Lambda et la file d’attente Amazon SQS doivent se trouver dans la même Région AWS.
```
aws lambda create-function --function-name ProcessSQSRecord \
--zip-file fileb://function.zip --handler index.handler --runtime nodejs24.x \
--role arn:aws:iam::111122223333:role/lambda-sqs-role
```
## Tester la fonction
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/sqs_tut_steps3.png)
Appelez votre fonction Lambda manuellement à l'aide de la `invoke` AWS CLI commande et d'un exemple d'événement Amazon SQS.
**Pour invoquer la fonction Lambda avec un exemple d’événement**
1. Enregistrez le JSON suivant en tant que fichier nommé `input.json`. Ce JSON simule un événement qu’Amazon SQS pourrait envoyer à votre fonction Lambda, où `"body"` contient le message réel de la file d’attente. Dans cet exemple, le message est `"test"`.
**Example Événement Amazon SQS**
Il s’agit d’un événement de test : vous n’avez pas besoin de modifier le message ou le numéro de compte.
```
{
"Records": [
{
"messageId": "059f36b4-87a3-44ab-83d2-661975830a7d",
"receiptHandle": "AQEBwJnKyrHigUMZj6rYigCgxlaS3SLy0a...",
"body": "test",
"attributes": {
"ApproximateReceiveCount": "1",
"SentTimestamp": "1545082649183",
"SenderId": "AIDAIENQZJOLO23YVJ4VO",
"ApproximateFirstReceiveTimestamp": "1545082649185"
},
"messageAttributes": {},
"md5OfBody": "098f6bcd4621d373cade4e832627b4f6",
"eventSource": "aws:sqs",
"eventSourceARN": "arn:aws:sqs:us-east-1:111122223333:my-queue",
"awsRegion": "us-east-1"
}
]
}
```
1. Exécutez la AWS CLI commande [d'appel](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/invoke.html) suivante. Cette commande renvoie CloudWatch les journaux dans la réponse. Pour de plus amples informations sur la récupération des journaux, veuillez consulter [Accédez aux journaux avec AWS CLI](monitoring-cloudwatchlogs-view.md#monitoring-cloudwatchlogs-cli).
```
aws lambda invoke --function-name ProcessSQSRecord --payload file://input.json out --log-type Tail \
--query 'LogResult' --output text --cli-binary-format raw-in-base64-out | base64 --decode
```
L'**cli-binary-format**option est obligatoire si vous utilisez AWS CLI la version 2. Pour faire de ce paramètre le paramètre par défaut, exécutez `aws configure set cli-binary-format raw-in-base64-out`. Pour plus d’informations, consultez les [options de ligne de commande globales prises en charge par l’AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) dans le *Guide de l’utilisateur AWS Command Line Interface version 2*.
1. Recherchez le journal `INFO` dans la réponse. C’est ici que la fonction Lambda enregistre le corps du message. Vous devriez voir des journaux qui ressemblent à ceci :
```
2023-09-11T22:45:04.271Z 348529ce-2211-4222-9099-59d07d837b60 INFO Processed message test
2023-09-11T22:45:04.288Z 348529ce-2211-4222-9099-59d07d837b60 INFO done
```
## Créez une file d’attente Amazon SQS.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/sqs_tut_steps4.png)
Créez une file d’attente Amazon SQS que la fonction Lambda peut utiliser en tant que source d’événement. La fonction Lambda et la file d’attente Amazon SQS doivent se trouver dans la même Région AWS.
**Pour créer une file d’attente**
1. Ouvrez la [console Amazon SQS](https://console.aws.amazon.com/sqs).
1. Choisissez **Créez une file d’attente**.
1. Entrez un nom pour la queue. Conservez les paramètres par défaut de toutes les autres options.
1. Choisissez **Créez une file d’attente**.
Une fois la file d’attente créée, notez son ARN. Vous en aurez besoin à l’étape suivante lorsque vous associerez la file d’attente à votre fonction Lambda.
## Configurer la source de l’événement
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/sqs_tut_steps5.png)
Connectez la file d’attente Amazon SQS à votre fonction Lambda en créant un [mappage des sources d’événements](invocation-eventsourcemapping.md). Le mappage des sources d’événements lit la file d’attente Amazon SQS et invoque votre fonction Lambda lorsqu’un nouveau message est ajouté.
Pour créer un mappage entre votre file d'attente Amazon SQS et votre fonction Lambda, utilisez la commande. [create-event-source-mapping](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-event-source-mapping.html) AWS CLI Exemple :
```
aws lambda create-event-source-mapping --function-name ProcessSQSRecord --batch-size 10 \
--event-source-arn arn:aws:sqs:us-east-1:111122223333:my-queue
```
Pour obtenir la liste de vos mappages de sources d'événements, utilisez la [list-event-source-mappings](https://awscli.amazonaws.com/v2/documentation/api/2.1.29/reference/lambda/list-event-source-mappings.html)commande. Exemple :
```
aws lambda list-event-source-mappings --function-name ProcessSQSRecord
```
## Envoyer un message de test
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/sqs_tut_steps6.png)
**Pour envoyer un message Amazon SQS à la fonction Lambda**
1. Ouvrez la [console Amazon SQS](https://console.aws.amazon.com/sqs).
1. Choisissez la queue que vous avez créée précédemment.
1. Choisissez **Envoyer et recevoir des messages**.
1. Sous **Corps du message**, entrez un message de test, tel que « ceci est un message de test ».
1. Choisissez **Send Message** (Envoyer un message).
Lambda interroge la file d’attente concernant les mises à jour. Lorsqu’il y a un nouveau message, Lambda invoque votre fonction avec ces nouvelles données d’événement de la file d’attente. Si le gestionnaire de la fonction revient sans exception, Lambda considère le message comme traité avec succès et commence à lire de nouveaux messages dans la file d’attente. Après avoir traité un message avec succès, Lambda le supprime automatiquement de la file d’attente. Si le gestionnaire renvoie une exception, Lambda considère que le traitement du lot de messages a échoué et invoque la fonction avec le même lot de messages.
## Consultez les CloudWatch journaux
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/sqs_tut_steps7.png)
**Pour confirmer que la fonction a traité le message**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez la SQSRecord fonction **Process**.
1. Sélectionnez **Monitor (Surveiller)**.
1. Choisissez **Afficher CloudWatch les journaux**.
1. Dans la CloudWatch console, choisissez le **flux de log** pour la fonction.
1. Recherchez le journal `INFO`. C’est ici que la fonction Lambda enregistre le corps du message. Vous devriez voir le message que vous avez envoyé depuis la file d’attente Amazon SQS. Exemple :
```
2023-09-11T22:49:12.730Z b0c41e9c-0556-5a8b-af83-43e59efeec71 INFO Processed message this is a test message.
```
## Nettoyage de vos ressources
Vous pouvez maintenant supprimer les ressources que vous avez créées pour ce didacticiel, sauf si vous souhaitez les conserver. En supprimant AWS les ressources que vous n'utilisez plus, vous évitez des frais inutiles pour votre Compte AWS.
**Pour supprimer le rôle d’exécution**
1. Ouvrez la [page Roles (Rôles)](https://console.aws.amazon.com/iam/home#/roles) de la console IAM.
1. Sélectionnez le rôle d’exécution que vous avez créé.
1. Sélectionnez **Delete (Supprimer)**.
1. Saisissez le nom du rôle dans le champ de saisie de texte et choisissez **Delete** (Supprimer).
**Pour supprimer la fonction Lambda**
1. Ouvrez la [page Functions (Fonctions)](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda.
1. Sélectionnez la fonction que vous avez créée.
1. Sélectionnez **Actions**, **Supprimer**.
1. Saisissez **confirm** dans la zone de saisie de texte et choisissez **Delete** (Supprimer).
**Pour supprimer la file d’attente Amazon SQS**
1. Connectez-vous à la console Amazon SQS AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/sqs/](https://console.aws.amazon.com/sqs/)
1. Sélectionnez la file d’attente que vous avez créée.
1. Sélectionnez **Delete (Supprimer)**.
1. Saisissez **confirm** dans le champ de saisie de texte.
1. Sélectionnez **Supprimer**.
# Didacticiel : utilisation d’une file d’attente Amazon SQS entre comptes en tant que source d’événement
Dans ce didacticiel, vous allez créer une fonction Lambda qui consomme les messages d'une file d'attente Amazon Simple Queue Service (Amazon SQS) d'un autre compte. AWS Ce didacticiel implique deux AWS comptes : le **compte A** fait référence au compte qui contient votre fonction Lambda, et le **compte B** fait référence au compte qui contient la file d'attente Amazon SQS.
## Conditions préalables
### Installez le AWS Command Line Interface
Si vous ne l'avez pas encore installé AWS Command Line Interface, suivez les étapes décrites dans la [section Installation ou mise à jour de la dernière version du AWS CLI pour l'](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)installer.
Ce tutoriel nécessite un terminal de ligne de commande ou un shell pour exécuter les commandes. Sous Linux et macOS, utilisez votre gestionnaire de shell et de package préféré.
**Note**
Sous Windows, certaines commandes CLI Bash que vous utilisez couramment avec Lambda (par exemple `zip`) ne sont pas prises en charge par les terminaux intégrés du système d’exploitation. [Installez le sous-système Windows pour Linux](https://docs.microsoft.com/en-us/windows/wsl/install-win10) afin d’obtenir une version intégrée à Windows d’Ubuntu et Bash.
## Création du rôle d’exécution (compte A)
Dans le **compte A**, créez un [rôle d'exécution](lambda-intro-execution-role.md) qui autorise votre fonction à accéder aux AWS ressources requises.
**Pour créer un rôle d’exécution**
1. Ouvrez la [page Rôles](https://console.aws.amazon.com/iam/home#/roles) dans la console Gestion des identités et des accès AWS (IAM).
1. Choisissez **Create role** (Créer un rôle).
1. Créez un rôle avec les propriétés suivantes :
+ **Trusted entity** (Entité de confiance) – **AWS Lambda**.
+ **Permissions (Autorisations** – **AWSLambdaSQSQueueExecutionRole**
+ **Nom de rôle** – **cross-account-lambda-sqs-role**
La **AWSLambdaSQSQueueExecutionRole**politique dispose des autorisations dont la fonction a besoin pour lire des éléments depuis Amazon SQS et pour écrire des journaux dans Amazon CloudWatch Logs.
## Créer la fonction (compte A)
Dans le **Compte A**, créez une fonction Lambda qui traite vos messages Amazon SQS. La fonction Lambda et la file d’attente Amazon SQS doivent se trouver dans la même Région AWS.
L'exemple de code Node.js suivant écrit chaque message dans CloudWatch un journal de connexion.
**Example index.mjs**
```
export const handler = async function(event, context) {
event.Records.forEach(record => {
const { body } = record;
console.log(body);
});
return {};
}
```
**Pour créer la fonction**
**Note**
Suivre ces étapes permet de créer une fonction Node.js. Pour les autres langages, les étapes sont similaires mais certains détails sont différents.
1. Enregistrez l’exemple de code en tant que fichier nommé `index.mjs`.
1. Créez un package de déploiement.
```
zip function.zip index.mjs
```
1. Créez la fonction à l'aide de la commande `create-function` AWS Command Line Interface (AWS CLI). Remplacez `arn:aws:iam::111122223333:role/cross-account-lambda-sqs-role` par l’ARN du rôle d’exécution que vous avez créé auparavant.
```
aws lambda create-function --function-name CrossAccountSQSExample \
--zip-file fileb://function.zip --handler index.handler --runtime nodejs24.x \
--role arn:aws:iam::111122223333:role/cross-account-lambda-sqs-role
```
## Testez la fonction (compte A)
Dans le **compte A**, testez votre fonction Lambda manuellement à l'aide de la `invoke` AWS CLI commande et d'un exemple d'événement Amazon SQS.
Si le gestionnaire revient normalement sans exception, Lambda considère le message comme traité avec succès et commence à lire de nouveaux messages dans la file d’attente. Après avoir traité un message avec succès, Lambda le supprime automatiquement de la file d’attente. Si le gestionnaire renvoie une exception, Lambda considère que le traitement du lot de messages a échoué et invoque la fonction avec le même lot de messages.
1. Enregistrez le JSON suivant en tant que fichier nommé `input.txt`.
```
{
"Records": [
{
"messageId": "059f36b4-87a3-44ab-83d2-661975830a7d",
"receiptHandle": "AQEBwJnKyrHigUMZj6rYigCgxlaS3SLy0a...",
"body": "test",
"attributes": {
"ApproximateReceiveCount": "1",
"SentTimestamp": "1545082649183",
"SenderId": "AIDAIENQZJOLO23YVJ4VO",
"ApproximateFirstReceiveTimestamp": "1545082649185"
},
"messageAttributes": {},
"md5OfBody": "098f6bcd4621d373cade4e832627b4f6",
"eventSource": "aws:sqs",
"eventSourceARN": "arn:aws:sqs:us-east-1:111122223333:example-queue",
"awsRegion": "us-east-1"
}
]
}
```
Le JSON précédent simule un événement qu’Amazon SQS pourrait envoyer à votre fonction Lambda, où `"body"` contient le message réel de la file d’attente.
1. Exécutez la commande suivante `invoke` AWS CLI .
```
aws lambda invoke --function-name CrossAccountSQSExample \
--cli-binary-format raw-in-base64-out \
--payload file://input.txt outputfile.txt
```
L'**cli-binary-format**option est obligatoire si vous utilisez AWS CLI la version 2. Pour faire de ce paramètre le paramètre par défaut, exécutez `aws configure set cli-binary-format raw-in-base64-out`. Pour plus d’informations, consultez les [options de ligne de commande globales AWS CLI prises en charge](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) dans le *Guide de l’utilisateur AWS Command Line Interface version 2*.
1. Vérifiez la sortie dans le fichier `outputfile.txt`.
## Créer une file d’attente Amazon SQS (Compte B)
Dans **Compte B**, créez une file d’attente Amazon SQS que la fonction Lambda dans **Compte B** peut utiliser comme source d’événement. La fonction Lambda et la file d’attente Amazon SQS doivent se trouver dans la même Région AWS.
**Pour créer une file d’attente**
1. Ouvrez la [console Amazon SQS](https://console.aws.amazon.com/sqs).
1. Choisissez **Créez une file d’attente**.
1. Créez une fille d’attente avec les propriétés suivantes.
+ **Type**–**Standard**
+ **Nom** – **LambdaCrossAccountQueue**
+ **Configuration**— Conservez les paramètres par défaut.
+ **Stratégie d’accès** – Choisissez **Avancé**. Collez dans la stratégie JSON suivante. Remplacez les valeurs suivantes :
+ `111122223333`: Compte AWS ID du **compte A**
+ `444455556666`: Compte AWS ID du **compte B**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Id": "Queue1_Policy_UUID",
"Statement": [
{
"Sid": "Queue1_AllActions",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/cross-account-lambda-sqs-role"
]
},
"Action": "sqs:*",
"Resource": "arn:aws:sqs:us-east-1:444455556666:LambdaCrossAccountQueue"
}
]
}
```
------
Cette stratégie accorde au rôle d’exécution Lambda dans**Compte A**autorisations pour consommer des messages de cette file d’attente Amazon SQS.
1. Après avoir créé la file d’attente, enregistrez son Amazon Resource Name (ARN). Vous en aurez besoin à l’étape suivante lorsque vous associerez la file d’attente à votre fonction Lambda.
## Configurer la source de l’événement (Compte A)
Dans le **compte A**, créez un mappage de source d'événement entre la file d'attente Amazon SQS du **compte B** et votre fonction Lambda en exécutant la commande suivante. `create-event-source-mapping` AWS CLI Remplacez `arn:aws:sqs:us-east-1:444455556666:LambdaCrossAccountQueue` par l’ARN de la file d’attente Amazon SQS que vous avez créée à l’étape précédente.
```
aws lambda create-event-source-mapping --function-name CrossAccountSQSExample --batch-size 10 \
--event-source-arn arn:aws:sqs:us-east-1:444455556666:LambdaCrossAccountQueue
```
Pour obtenir une liste de vos mappages de source d’événements, exécutez la commande suivante.
```
aws lambda list-event-source-mappings --function-name CrossAccountSQSExample \
--event-source-arn arn:aws:sqs:us-east-1:444455556666:LambdaCrossAccountQueue
```
## Tester la configuration
Maintenant, vous pouvez tester la configuration comme suit :
1. Dans**Compte B**, ouvrez[Console Amazon SQS](https://console.aws.amazon.com/sqs).
1. Choisissez **LambdaCrossAccountQueue**celui que vous avez créé précédemment.
1. Choisissez **Send and receive messages (Envoyer et recevoir des messages)**.
1. Sous **Message body** (Corps du message), saisissez un message test.
1. Choisissez **Send Message (Envoyer un message)**.
Votre fonction Lambda dans**Compte A**doit recevoir le message. Lambda continuera d’interroger la file d’attente pour les mises à jour. Lorsqu’il y a un nouveau message, Lambda invoque votre fonction avec ces nouvelles données d’événement de la file d’attente. Votre fonction s'exécute et crée des journaux sur Amazon CloudWatch. Vous pouvez afficher les journaux dans la [console CloudWatch ](https://console.aws.amazon.com/cloudwatch).
## Nettoyage de vos ressources
Vous pouvez maintenant supprimer les ressources que vous avez créées pour ce didacticiel, sauf si vous souhaitez les conserver. En supprimant AWS les ressources que vous n'utilisez plus, vous évitez des frais inutiles pour votre Compte AWS.
Dans**Compte A**, nettoyez votre rôle d’exécution et votre fonction Lambda.
**Pour supprimer le rôle d’exécution**
1. Ouvrez la [page Roles (Rôles)](https://console.aws.amazon.com/iam/home#/roles) de la console IAM.
1. Sélectionnez le rôle d’exécution que vous avez créé.
1. Sélectionnez **Delete (Supprimer)**.
1. Saisissez le nom du rôle dans le champ de saisie de texte et choisissez **Delete** (Supprimer).
**Pour supprimer la fonction Lambda**
1. Ouvrez la [page Functions (Fonctions)](https://console.aws.amazon.com/lambda/home#/functions) de la console Lambda.
1. Sélectionnez la fonction que vous avez créée.
1. Sélectionnez **Actions**, **Supprimer**.
1. Saisissez **confirm** dans la zone de saisie de texte et choisissez **Delete** (Supprimer).
Dans**Compte B**, nettoyez la file d’attente Amazon SQS.
**Pour supprimer la file d’attente Amazon SQS**
1. Connectez-vous à la console Amazon SQS AWS Management Console et ouvrez-la à l'adresse. [https://console.aws.amazon.com/sqs/](https://console.aws.amazon.com/sqs/)
1. Sélectionnez la file d’attente que vous avez créée.
1. Sélectionnez **Delete (Supprimer)**.
1. Saisissez **confirm** dans le champ de saisie de texte.
1. Sélectionnez **Supprimer**.