Introduction
Un service de commandes doit accepter une tâche maintenant et la traiter plus tard. Vous créerez une file, recevrez une tâche, exécuterez un traitement fourni et confirmerez la commande stockée avant d'acquitter le message.
Terminez d'abord Lire et écrire dans DynamoDB depuis Lambda et ses prérequis guidés. Cette VM indépendante fournit un traitement, son rôle limité, une table de commandes vide et des données de référence ; aucune file ni tâche n'est préparée.
Lien avec les certifications
Ce laboratoire propose une pratique des sujets d’examen suivants.
- Cloud Practitioner (CLF-C02) · Tâche 3.8: Livraison, traitement et acquittement des messages SQS.
- Solutions Architect – Associate (SAA-C03) · Tâche 2.1: Livraison, traitement et acquittement des messages SQS.
- Developer – Associate (DVA-C02) · Tâche 1.1: Livraison, traitement et acquittement des messages SQS.
- DevOps Engineer – Professional (DOP-C02) · Tâche 5.1: Pratique des fondamentaux : Livraison, traitement et acquittement des messages SQS.
- Solutions Architect – Professional (SAP-C02) · Tâche 2.4: Pratique des fondamentaux : Livraison, traitement et acquittement des messages SQS.
Créer une file de tâches indépendante
Dans cette étape, créez une file vide et inspectez le traitement fourni avant tout envoi de tâche.
Utilisez AWS View à côté de Terminal pour comparer les files actuelles, les résultats du traitement et les commandes stockées. Conservez les données de référence indépendantes.
Amazon Simple Queue Service (SQS) stocke les tâches sous forme de messages pour un consommateur. Un producteur envoie les tâches et un consommateur les traite. Une file sépare leurs rythmes : le producteur n'a pas besoin d'attendre que le consommateur termine. Une file Standard peut livrer un message plusieurs fois ; réception et acquittement sont des opérations distinctes.
Commencez dans l'espace de travail préparé :
cd /home/labex/project
Inspectez le traitement fourni et la table de commandes vide. Le traitement calcule 250 centimes par article plus 100 centimes de frais. Son rôle d'exécution peut écrire uniquement dans la table des commandes ; la table de référence contient des données indépendantes à conserver.
aws lambda get-function-configuration --function-name labex-q01-worker --query '{Name:FunctionName,Role:Role,Runtime:Runtime}'
aws dynamodb scan --table-name labex-q01-orders --query Items
Vous devez obtenir une liste d'éléments vide. Créez votre propre file. --query QueueUrl --output text sélectionne son adresse en texte brut ; $(...) stocke cette sortie dans la variable du shell QUEUE_URL pour les commandes suivantes.
QUEUE_URL=$(aws sqs create-queue --queue-name labex-q01-jobs --attributes VisibilityTimeout=300 --query QueueUrl --output text)
Le délai de visibilité donne au consommateur 300 secondes avant qu'un message reçu puisse redevenir disponible. Il s'agit d'un masquage temporaire, pas d'une suppression. Nous explorerons l'expiration et la nouvelle livraison dans le laboratoire suivant.
Inspectez l'identité de la file et ses compteurs actuels :
aws sqs get-queue-attributes --queue-url "$QUEUE_URL" --attribute-names QueueArn VisibilityTimeout ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible
Vous devez obtenir 300 pour VisibilityTimeout et 0 pour les deux compteurs de messages. Les compteurs sont des indicateurs opérationnels approximatifs, pas une garantie d'achèvement métier. Dans AWS View, votre file apparaît avec zéro tâche disponible et zéro tâche en cours de livraison ; la fonction Lambda fournie n'a aucune exécution et la table des commandes est toujours vide.
La console officielle affiche les mêmes nom, type, URL et ARN de file que vous inspectez avec la CLI. Ce sont des valeurs d'exemple ; continuez avec votre propre QUEUE_URL. Utilisez AWS View pour observer les ressources de ce laboratoire.
Source : AWS SQS.
Envoyer et recevoir une tâche de commande
Dans cette étape, envoyez une tâche et recevez-la pour observer la différence entre les messages disponibles et ceux en cours de livraison.
Recevez, traitez, puis acquittez : supprimez le message de la file uniquement après avoir confirmé la commande stockée, avec l'identifiant de réception actuel.
Le corps d'un message est constitué de données applicatives. SQS conserve le JSON comme texte ; votre consommateur doit l'interpréter. Envoyez une petite tâche fictive de commande :
aws sqs send-message --queue-url "$QUEUE_URL" --message-body '{"id":"queue-order","quantity":2}'
La réponse inclut un MessageId et MD5OfMessageBody. L'identifiant de message identifie le message ; le MD5 résume les octets du corps. Cela confirme l'acceptation par la file, pas une commande terminée. AWS View affiche maintenant une tâche disponible, tandis que la table des commandes reste vide.
Recevez un message et enregistrez la réponse. > redirige la sortie vers received.json au lieu de l'afficher. --wait-time-seconds 5 permet une courte attente par interrogation longue si aucune tâche n'est immédiatement disponible.
aws sqs receive-message --queue-url "$QUEUE_URL" --max-number-of-messages 1 --wait-time-seconds 5 --message-system-attribute-names ApproximateReceiveCount --output json > received.json
Lisez le corps applicatif non secret et le nombre de réceptions avec jq, qui sélectionne des champs du JSON :
jq '.Messages[0] | {MessageId,Body,Attributes}' received.json
Vous devez obtenir un corps contenant queue-order et la quantité 2, avec un nombre de réceptions de 1 à la première réception. La réponse complète contient aussi un identifiant de réception, ou receipt handle : une valeur pour cette tentative de livraison particulière. Vous utiliserez l'identifiant le plus récent pour acquitter ce message.
aws sqs get-queue-attributes --queue-url "$QUEUE_URL" --attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible
Vous devez obtenir 0 message disponible et 1 message non visible. Dans AWS View, la tâche est en cours de livraison, mais il n'existe toujours aucune commande. La recevoir ne l'a ni traitée ni supprimée. Passez à l'étape suivante dans les 300 secondes. Si vous passez plus de temps à lire, recevez-la de nouveau dans le même fichier pour obtenir son dernier identifiant de réception avant de la traiter et de la supprimer.
Cet exemple réel montre la livraison avant le traitement. Les identifiants de message diffèrent dans votre espace de travail.
Traiter la tâche avant de l'acquitter
Dans cette étape, traitez le corps reçu, vérifiez la commande persistée, puis acquittez le message.
Utilisez le corps réellement reçu comme entrée du traitement. fromjson convertit la chaîne JSON dans la réponse SQS en objet JSON ; la redirection écrit cet objet dans job.json.
jq '.Messages[0].Body | fromjson' received.json > job.json
La fonction Lambda fournie accepte cet objet de commande. Comme dans le cours Lambda, fileb://job.json envoie les octets du fichier et le nom de fichier final reçoit la réponse de la fonction. Invoquez le traitement :
aws lambda invoke --function-name labex-q01-worker --payload fileb://job.json worker-response.json
Un statut réussi de l'API Invoke ne suffit pas à établir la réussite du traitement. Inspectez le corps de la réponse :
cat worker-response.json
Vous devez obtenir processed: true, une quantité de 2 et total_cents: 600. Lisez ensuite l'élément stocké au lieu de vous fier uniquement au message renvoyé par la fonction :
aws dynamodb get-item --table-name labex-q01-orders --key '{"id":{"S":"queue-order"}}' --consistent-read --query Item
Vous devez obtenir queue-order, une quantité de 2 et un total de 600. AWS View affiche l'entrée et le résultat réels du traitement ainsi que la même commande persistée. La tâche reste en cours de livraison jusqu'à son acquittement. Si la réponse du traitement ou l'élément stocké est incorrect, gardez le message pour le diagnostic au lieu de le supprimer.
Après confirmation de la commande, sélectionnez l'identifiant de réception actuel en texte brut et supprimez cette livraison de la file :
RECEIPT_HANDLE=$(jq -r '.Messages[0].ReceiptHandle' received.json)
aws sqs delete-message --queue-url "$QUEUE_URL" --receipt-handle "$RECEIPT_HANDLE"
Une suppression réussie n'affiche normalement rien. Relisez les compteurs :
aws sqs get-queue-attributes --queue-url "$QUEUE_URL" --attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible
Les deux compteurs doivent être 0. AWS View affiche une file vide et une commande stockée. Vous avez séparé l'acceptation par la file, la livraison temporaire, le traitement métier et l'acquittement. Une file Standard peut toujours livrer de nouveau les messages dans les applications réelles ; cette séquence ne garantit pas un traitement exactement une fois de bout en bout. Les unités suivantes enseignent une protection durable contre les doublons.
Nettoyer uniquement votre file et vos résultats
Dans cette étape, supprimez votre file, votre résultat et les journaux en conservant les ressources fournies.
Supprimez la file et la commande que vous avez créées, en conservant le traitement fourni, les structures des tables et les données de référence. Supprimer une file détruit les tâches restantes : confirmez donc d'abord la réussite de l'étape précédente.
aws sqs delete-queue --queue-url "$QUEUE_URL"
aws dynamodb delete-item --table-name labex-q01-orders --key '{"id":{"S":"queue-order"}}'
L'exécution du traitement a créé un groupe CloudWatch Logs. Supprimez les journaux d'exécution de ce laboratoire pendant le nettoyage :
aws logs delete-log-group --log-group-name /aws/lambda/labex-q01-worker
Contrôlez l'état des ressources avec des requêtes réussies aux services :
aws sqs list-queues
aws dynamodb scan --table-name labex-q01-orders --query Items
aws dynamodb scan --table-name labex-q01-reference --query Items
Aucune URL de file ne doit rester, la liste des éléments de commandes doit être vide et l'élément de référence doit toujours indiquer keep unchanged. AWS View affiche l'absence de files, de commandes et de journaux d'exécution, avec le traitement fourni et la référence toujours présents. Une erreur d'authentification ou de réseau ne prouve pas une suppression réussie.
Supprimez les fichiers ordinaires de réponse après avoir contrôlé les ressources :
rm -f received.json job.json worker-response.json
Utilisez la vérification de l'étape avant de terminer votre environnement.
Résumé
Vous avez créé une file SQS Standard, envoyé et reçu une tâche de commande JSON, vérifié le traitement Lambda réel et l'élément DynamoDB persisté, puis acquitté le message avec son identifiant de réception. Vous avez distingué l'acceptation, la livraison en cours et l'achèvement métier, puis supprimé votre file, votre commande et les journaux d'exécution en conservant les ressources fournies.
