Exemple d’événement de message de file d’attente standard Exemple d’événement de message de file d’attente FIFO Configuration d’une file d’attente à utiliser avec Lambda Autorisations du rôle d’exécution Création du mappage des sources d'événements Dimensionnement et traitement Simultanéité maximum API de mappage de la source d’événement Stratégie d’interruption pour les invocations ayant échoué Mise en œuvre de réponses partielles de lot Paramètres de configuration d’Amazon SQS

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

Vous pouvez utiliser une fonction Lambda pour traiter les messages figurant dans une file d’attente Amazon Simple Queue Service (Amazon SQS). Les mappages de source d’événement Lambda prennent en charge les files d’attente standard et les files d’attente FIFO (premier entré, premier sorti). Avec Amazon SQS, vous pouvez décharger des tâches d’un composant de votre application en les envoyant à une file d’attente, puis en les traitant de manière asynchrone.

Lambda interroge la file d’attente et invoque votre fonction Lambda de manière synchrone avec un événement contenant les messages de la file d’attente. Lambda lit les messages par lots, 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 lit un lot, les messages restent dans la file d’attente mais sont masqués pendant toute la durée du délai de visibilité de la file d’attente. Si votre fonction traite 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 de 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 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 dans la réponse de votre fonction, soit utiliser l'DeleteMessageaction d'API Amazon SQS pour supprimer les messages de la file d'attente au fur et à mesure que votre fonction Lambda les traite correctement. Pour plus d'informations sur l'utilisation de l'API Amazon SQS, consultez le manuel Amazon Simple Queue Service API Reference.

Exemple d’événement de message de file d’attente standard

Exemple É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": {},
            "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 de registres, vous pouvez indiquer à la source d’événement de 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 SQS jusqu’à ce que la fenêtre de lot expire, que le quota de taille de la charge utile de l’invocation 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.

Exemple É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"
        }
    ]
}

Configuration d’une file d’attente à utiliser avec Lambda

Créez une file d’attente SQS à utiliser en tant que source d’événement pour votre fonction Lambda. Configurez ensuite cette file d’attente pour autoriser votre fonction Lambda à traiter chaque lot d’événements, et à effectuer de nouvelles tentatives en réponse aux erreurs de limitation à mesure qu’il augmente son échelle.

Pour laisser à votre fonction le temps de traiter chaque lot d’enregistrements, définissez le délai de visibilité de la file d’attente source à au moins six fois le délai que vous configurez 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.

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. Si votre fonction renvoie une erreur, tous les éléments du lot retournent dans la file d’attente. Une fois le délai de visibilité expiré, Lambda reçoit à nouveau le message. Pour envoyer des messages à une deuxième file d’attente après plusieurs réceptions, configurez une file d’attente de lettres mortes sur votre file d’attente source.

Note

Veillez à configurer la file d’attente de lettres mortes sur la file d’attente source, non sur la fonction Lambda. La file d’attente de lettres mortes que vous configurez dans une fonction est utilisée pour la file d’attente d’invocation asynchrone et non pour les files d’attente source d’événement.

Si votre fonction renvoie une erreur ou si elle ne peut pas être invoquée parce qu’elle a atteint le niveau de simultanéité maximal, le traitement peut aboutir avec des tentatives supplémentaires. Pour donner aux messages une meilleure chance d’être traités avant de les envoyer dans la file d’attente de lettres mortes, définissez maxReceiveCount sur 5 au minimum dans la stratégie de réacheminement de la file d’attente source.

Autorisations du rôle d’exécution

La politique AWSLambdaSQSQueueExecutionRole AWS gérée inclut les autorisations dont Lambda a besoin pour lire depuis votre file d'attente Amazon SQS. Ajoutez cette politique gérée au rôle d'exécution 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

Ajouter des autorisations et créer le mappage des sources d'événements

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 AWS gérée à votre rôle d'exécution, puis créez un déclencheur SQS.

Pour ajouter des autorisations et créer un déclencheur

Ouvrez la page Functions (Fonctions) de la console Lambda.
Choisissez le nom d’une fonction.
Choisissez l'onglet Configuration, puis Permissions (Autorisations).
Sous Nom du rôle, choisissez le lien vers votre rôle d'exécution. Ce lien ouvre le rôle dans la console IAM.
Choisissez Ajouter des autorisations, puis Attacher des politiques.
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 AWSLambdaSQSQueueExecutionRolela référence des politiques AWS gérées.
Retournez à votre fonction dans la console Lambda. Sous Function overview (Vue d’ensemble de la fonction), choisissez Add trigger (Ajouter un déclencheur).
Choisissez un type de déclencheur.
Configurez les options requises, puis choisissez Add (Ajouter).

Lambda prend en charge les options suivantes pour les sources d’événement Amazon SQS :

File d’attente SQS

La file d’attente Amazon SQS à partir de laquelle lire les enregistrements.

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 la fonction, afin de 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 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 de la charge utile d’invocation 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'ReceiveMessageAPI 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é 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, 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 instances supplémentaires de votre fonction par minute, jusqu’à un maximum de 1 000 instances de fonction supplémentaires. Pour en savoir plus sur la mise à l’échelle et la simultanéité de la fonction, consultez Mise à l’échelle de fonction Lambda.

Pour traiter plus de messages, vous pouvez optimiser votre fonction Lambda pour un débit plus élevé. Consultez Comprendre comment AWS Lambda évolue avec les files d'attente standard Amazon SQS.

Simultanéité maximum

Le nombre maximum de fonctions simultanées que la source d’événement peut invoquer. Pour plus d’informations, consultez Configuration de la simultanéité maximale pour les sources d’événements Amazon SQS.

Critères de filtrage

Ajoutez des critères de filtrage pour contrôler les événements que Lambda envoie à votre fonction pour traitement. Pour plus d’informations, consultez Filtrage des événements Lambda.

Dimensionnement et traitement

Pour les files d’attente standard, Lambda utilise une interrogation longue 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 de lecture de lots jusqu’à 300 instances supplémentaires par minute. Le nombre maximum de lots qui peut être traité simultanément par un mappage de source d’événement est de 1 000.

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

Votre fonction peut être mise à l’échelle horizontale en simultanéité au nombre de groupes de messages actifs. Pour plus d'informations, consultez SQS FIFO en tant que source d'événements sur le AWS Compute Blog.

Configuration de la simultanéité maximale pour les sources d’événements Amazon SQS

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 de la fonction ou le reste du quota de simultanéité du compte. 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.

Si la simultanéité maximale n’est pas définie, Lambda peut mettre à l’échelle votre source d’événements Amazon SQS jusqu’au quota de simultanéité totale de votre compte, qui est de 1 000 par défaut.

Note

Pour les files d’attente FIFO, les invocations simultanées sont limitées soit par le nombre d’ID de groupes de messages (messageGroupId), soit par le paramètre de simultanéité maximal, selon ce qui est le plus bas. Par exemple, si vous avez six ID de groupe de messages et que la simultanéité maximale est fixée à dix, votre fonction peut avoir un maximum de six invocations simultanées.

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

Ouvrez la page Functions (Fonctions) de la console Lambda.
Choisissez le nom d’une fonction.
Sous Function overview (Vue d’ensemble des fonctions), choisissez SQS. Cela ouvre l’onglet Configuration.
Sélectionnez le déclencheur Amazon SQS et choisissez Edit (Modifier).
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.
Choisissez Enregistrer.

Configurez la simultanéité maximale à l'aide de AWS Command Line Interface ()AWS CLI

Utilisez la update-event-source-mappingcommande avec l'--scaling-configoption. 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'UpdateEventSourceMappingaction CreateEventSourceMappingou avec un ScalingConfigobjet.

API de mappage de la source d’événement

Pour gérer une source d’événement à l’aide de la AWS Command Line Interface (AWS CLI) ou un AWS SDK, vous pouvez utiliser les opérations d’API suivantes :

L'exemple suivant utilise le AWS CLI pour mapper une fonction nommée my-function à une file d'attente Amazon SQS spécifiée par son Amazon Resource Name (ARN), avec une taille de lot de 5 et une fenêtre de lot de 60 secondes.


aws lambda create-event-source-mapping --function-name my-function --batch-size 5 \
--maximum-batching-window-in-seconds 60 \
--event-source-arn arn:aws:sqs:us-east-2:123456789012:my-queue

Vous devriez voir la sortie suivante :


{
    "UUID": "2b733gdc-8ac3-cdf5-af3a-1827b3b11284",
    "BatchSize": 5,
    "MaximumBatchingWindowInSeconds": 60,
    "EventSourceArn": "arn:aws:sqs:us-east-2:123456789012:my-queue",
    "FunctionArn": "arn:aws:lambda:us-east-2:123456789012:function:my-function",
    "LastModified": 1541139209.351,
    "State": "Creating",
    "StateTransitionReason": "USER_INITIATED"
}

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êtera le traitement et réessaiera l'appel. Entre-temps, Lambda recule progressivement, réduisant ainsi le niveau de simultanéité alloué au mappage de votre source d'événements Amazon SQS. Une fois le délai de visibilité de votre file d'attente expiré, le message réapparaîtra 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'FunctionResponseTypesaction 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.

Lorsque ReportBatchItemFailures est activé, Lambda ne réduit pas la taille de l’interrogation des messages 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

Consultez les bonnes pratiques pour la mise en œuvre des réponses partielles de lot.
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 AWS CLI commande.
```
aws lambda update-event-source-mapping \
--uuid "a1b2c3d4-5678-90ab-cdef-11111EXAMPLE" \
--function-response-types "ReportBatchItemFailures"
```

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 réponse batchItemFailures doit inclure une liste d’identifiants de message, sous forme de valeurs JSON itemIdentifier.

Supposons par exemple que vous avez un lot de cinq messages avec des identifiants de message id1, 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 codes de fonctions qui renvoient la liste des identifiants des messages ayant échoué dans le lot :

.NET

AWS SDK for .NET

Note

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.

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<SQSBatchResponse> FunctionHandler(SQSEvent evnt, ILambdaContext context)
    {
        List<SQSBatchResponse.BatchItemFailure> batchItemFailures = new List<SQSBatchResponse.BatchItemFailure>();
        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 for Go V2

Note

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.

Signaler les défaillances d'éléments de 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"
	"encoding/json"
	"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 /* Your message processing condition here */ {			
			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

Note

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.

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<SQSEvent, SQSBatchResponse> {
    @Override
    public SQSBatchResponse handleRequest(SQSEvent sqsEvent, Context context) {
 
         List<SQSBatchResponse.BatchItemFailure> batchItemFailures = new ArrayList<SQSBatchResponse.BatchItemFailure>();
         String messageId = "";
         for (SQSEvent.SQSMessage message : sqsEvent.getRecords()) {
             try {
                 //process your message
                 messageId = message.getMessageId();
             } catch (Exception e) {
                 //Add failed message identifier to the batchItemFailures list
                 batchItemFailures.add(new SQSBatchResponse.BatchItemFailure(messageId));
             }
         }
         return new SQSBatchResponse(batchItemFailures);
     }
}

JavaScript

SDK pour JavaScript (v3)

Note

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.

Signaler les défaillances d'éléments de lot SQS avec JavaScript Lambda à l'aide de.


// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
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<SQSBatchResponse> => {
    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<void> {
    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

Note

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.

Signaler les défaillances d'éléments de lots SQS avec Lambda à l'aide de PHP.


// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
// SPDX-License-Identifier: Apache-2.0
<?php

use Bref\Context\Context;
use Bref\Event\Sqs\SqsEvent;
use Bref\Event\Sqs\SqsHandler;
use Bref\Logger\StderrLogger;

require __DIR__ . '/vendor/autoload.php';

class Handler extends SqsHandler
{
    private StderrLogger $logger;
    public function __construct(StderrLogger $logger)
    {
        $this->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

SDK pour Python (Boto3)

Note

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.

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
import json
def lambda_handler(event, context):
    if event:
        batch_item_failures = []
        sqs_batch_response = {}
     
        for record in event["Records"]:
            try:
                # process message
            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

Note

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.

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

Note

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.

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<SqsEvent>) -> Result<SqsBatchResponse, Error> {
    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 ? 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.

Paramètres de configuration d’Amazon SQS

Tous les types de sources d'événements Lambda partagent les mêmes opérations CreateEventSourceMappinget les mêmes opérations d'UpdateEventSourceMappingAPI. Cependant, seuls certains paramètres s’appliquent à Amazon SQS.

Paramètres de la source d’événement qui 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ées	N	VRAI
EventSourceArn	Y		ARN du flux de données ou d’un consommateur de flux
FunctionName	Y
FilterCriteria	N		Filtrage des événements Lambda
FunctionResponseTypes	N		Pour permettre à votre fonction de signaler des échecs spécifiques dans un lot, incluez la valeur `ReportBatchItemFailures` dans `FunctionResponseTypes`. Pour plus d’informations, consultez Mise en œuvre de réponses partielles de lot.
MaximumBatchingWindowInSeconds	N	0
ScalingConfig	N		Configuration de la simultanéité maximale pour les sources d’événements Amazon SQS

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Exemple de code

Didacticiel