Introducción
Un servicio de pedidos necesita aceptar un trabajo ahora y procesarlo después. Crearás una cola, recibirás un trabajo, ejecutarás un procesador proporcionado y confirmarás el pedido almacenado antes de confirmar el mensaje.
Completa primero Leer y escribir en DynamoDB desde Lambda y sus requisitos previos guiados. Esta VM independiente proporciona un procesador, su rol con permisos limitados, una tabla de pedidos vacía y datos de referencia; no hay ninguna cola ni trabajo preparado.
Relación con las certificaciones
Este laboratorio ofrece práctica para los siguientes temas de examen.
- Cloud Practitioner (CLF-C02) · Tarea 3.8: Entrega, procesamiento y confirmación de mensajes SQS.
- Solutions Architect – Associate (SAA-C03) · Tarea 2.1: Entrega, procesamiento y confirmación de mensajes SQS.
- Developer – Associate (DVA-C02) · Tarea 1.1: Entrega, procesamiento y confirmación de mensajes SQS.
- DevOps Engineer – Professional (DOP-C02) · Tarea 5.1: Práctica de fundamentos: Entrega, procesamiento y confirmación de mensajes SQS.
- Solutions Architect – Professional (SAP-C02) · Tarea 2.4: Práctica de fundamentos: Entrega, procesamiento y confirmación de mensajes SQS.
Crear una cola de trabajos independiente
En este paso, crea una cola vacía e inspecciona el procesador proporcionado antes de enviar cualquier trabajo.
Usa AWS View junto a Terminal para comparar las colas actuales, los resultados del procesador y los pedidos almacenados. Conserva los datos de referencia ajenos al trabajo.
Amazon Simple Queue Service (SQS) almacena trabajos como mensajes para un consumidor. Un productor envía trabajos y un consumidor los procesa. Una cola separa sus tiempos: el productor no tiene que esperar a que el consumidor termine. Una cola Standard puede entregar un mensaje más de una vez; recibir y confirmar son operaciones independientes.
Empieza en el directorio de trabajo preparado:
cd /home/labex/project
Inspecciona el procesador proporcionado y la tabla de pedidos vacía. El procesador calcula 250 céntimos por unidad más una tarifa de 100 céntimos. Su rol de ejecución solo puede escribir en la tabla de pedidos; la tabla de referencia contiene datos ajenos al trabajo que debes conservar.
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
Espera una lista de elementos vacía. Crea tu propia cola. --query QueueUrl --output text selecciona su dirección como texto sin formato; $(...) almacena esa salida en la variable de shell QUEUE_URL para comandos posteriores.
QUEUE_URL=$(aws sqs create-queue --queue-name labex-q01-jobs --attributes VisibilityTimeout=300 --query QueueUrl --output text)
El tiempo de espera de visibilidad da a un consumidor 300 segundos antes de que un mensaje recibido pueda volver a estar disponible. Es una ocultación temporal, no una eliminación. Exploraremos su vencimiento y las nuevas entregas en el siguiente laboratorio.
Inspecciona la identidad de la cola y sus recuentos actuales:
aws sqs get-queue-attributes --queue-url "$QUEUE_URL" --attribute-names QueueArn VisibilityTimeout ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible
Espera que VisibilityTimeout sea 300 y ambos recuentos de mensajes sean 0. Los recuentos son señales operativas aproximadas, no una garantía de finalización del trabajo de negocio. En AWS View, tu cola aparece con cero trabajos disponibles y cero en curso; la función Lambda proporcionada no tiene ejecuciones y la tabla de pedidos sigue vacía.
La consola oficial muestra el mismo nombre, tipo, URL y ARN de cola que inspeccionas con CLI. Estos son valores de ejemplo; continúa con tu propia QUEUE_URL. Usa AWS View para observar los recursos de este laboratorio.
Fuente: AWS SQS.
Enviar y recibir un trabajo de pedido
En este paso, envía un trabajo y recíbelo para observar la diferencia entre mensajes disponibles y en curso.
Recibe, procesa y después confirma: elimina el mensaje de la cola solo después de confirmar el pedido almacenado, usando el identificador de recepción actual.
El cuerpo de un mensaje contiene datos de la aplicación. SQS almacena el JSON como texto; tu consumidor debe interpretarlo. Envía un pequeño trabajo de pedido sintético:
aws sqs send-message --queue-url "$QUEUE_URL" --message-body '{"id":"queue-order","quantity":2}'
La respuesta incluye un MessageId y MD5OfMessageBody. El ID del mensaje identifica el mensaje; el MD5 resume los bytes del cuerpo. Esto confirma que la cola lo ha aceptado, no que el pedido se haya completado. AWS View ahora muestra un trabajo disponible, mientras la tabla de pedidos permanece vacía.
Recibe un mensaje y guarda la respuesta. > redirige la salida a received.json en lugar de mostrarla. --wait-time-seconds 5 permite una breve espera de sondeo largo si no hay un trabajo disponible inmediatamente.
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
Lee el cuerpo seguro de la aplicación y el recuento de recepciones con jq, que selecciona campos de JSON:
jq '.Messages[0] | {MessageId,Body,Attributes}' received.json
Espera un cuerpo que contenga queue-order y la cantidad 2, con un recuento de recepciones de 1 en la primera recepción. La respuesta completa también contiene un identificador de recepción, o receipt handle: un valor para este intento de entrega concreto. Usarás el identificador más reciente al confirmar este mensaje.
aws sqs get-queue-attributes --queue-url "$QUEUE_URL" --attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible
Espera 0 disponibles y 1 no visible. En AWS View, el trabajo está en curso, pero todavía no hay ningún pedido. Recibirlo no lo ha procesado ni eliminado. Continúa al siguiente paso antes de que transcurran 300 segundos. Si dedicas más tiempo a leer, vuelve a recibirlo en el mismo archivo para obtener su identificador de recepción más reciente antes de procesarlo y eliminarlo.
Este ejemplo real muestra la entrega antes del procesamiento. Los IDs de mensaje son distintos en tu entorno de trabajo.
Procesar el trabajo antes de confirmarlo
En este paso, procesa el cuerpo recibido, verifica el pedido persistido y después confirma el mensaje.
Usa el cuerpo que recibiste realmente como entrada del procesador. fromjson convierte la cadena JSON dentro de la respuesta SQS en un objeto JSON; la redirección escribe ese objeto en job.json.
jq '.Messages[0].Body | fromjson' received.json > job.json
La función Lambda proporcionada acepta este objeto de pedido. Como en el curso de Lambda, fileb://job.json envía los bytes del archivo y el nombre de archivo final recibe la respuesta de la función. Invoca el procesador:
aws lambda invoke --function-name labex-q01-worker --payload fileb://job.json worker-response.json
Un estado correcto de la API Invoke por sí solo no demuestra un procesamiento correcto. Inspecciona el cuerpo de la respuesta:
cat worker-response.json
Espera processed: true, la cantidad 2 y total_cents: 600. Después lee el elemento almacenado, en lugar de confiar únicamente en el mensaje devuelto por la función:
aws dynamodb get-item --table-name labex-q01-orders --key '{"id":{"S":"queue-order"}}' --consistent-read --query Item
Espera queue-order, la cantidad 2 y el total 600. AWS View muestra la entrada y el resultado reales del procesador y el mismo pedido persistido. El trabajo permanece en curso hasta que lo confirmes. Si la respuesta del procesador o el elemento almacenado son incorrectos, conserva el mensaje para diagnosticar el problema en lugar de eliminarlo.
Después de confirmar el pedido, selecciona el identificador de recepción actual como texto sin formato y elimina esa entrega de la cola:
RECEIPT_HANDLE=$(jq -r '.Messages[0].ReceiptHandle' received.json)
aws sqs delete-message --queue-url "$QUEUE_URL" --receipt-handle "$RECEIPT_HANDLE"
Una eliminación correcta normalmente no imprime nada. Vuelve a leer los recuentos:
aws sqs get-queue-attributes --queue-url "$QUEUE_URL" --attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible
Ambos recuentos deben ser 0. AWS View muestra una cola vacía y un pedido almacenado. Has separado la aceptación en la cola, la entrega temporal, el procesamiento de negocio y la confirmación. Una cola Standard todavía puede volver a entregar mensajes en aplicaciones reales; esta secuencia no garantiza exactamente una vez de extremo a extremo. Las unidades posteriores enseñan una protección duradera contra duplicados.
Eliminar únicamente tu cola y tus resultados
En este paso, elimina tu cola, tu resultado y tus registros, conservando los recursos proporcionados.
Elimina la cola y el pedido que creaste, conservando el procesador proporcionado, las estructuras de tablas y los datos de referencia. La eliminación de una cola descarta todos los trabajos restantes, por lo que primero debes confirmar que el paso anterior se completó correctamente.
aws sqs delete-queue --queue-url "$QUEUE_URL"
aws dynamodb delete-item --table-name labex-q01-orders --key '{"id":{"S":"queue-order"}}'
La ejecución del procesador creó un grupo de CloudWatch Logs. Elimina los registros de ejecución de este laboratorio como parte de la limpieza:
aws logs delete-log-group --log-group-name /aws/lambda/labex-q01-worker
Comprueba el estado de los recursos mediante consultas correctas a los servicios:
aws sqs list-queues
aws dynamodb scan --table-name labex-q01-orders --query Items
aws dynamodb scan --table-name labex-q01-reference --query Items
No debe quedar ninguna URL de cola, la lista de elementos de pedidos debe estar vacía y el elemento de referencia todavía debe indicar keep unchanged. AWS View muestra que no hay colas, pedidos ni registros de ejecución, mientras siguen presentes el procesador proporcionado y la referencia. Un error de autenticación o de red no demuestra que la eliminación se haya realizado correctamente.
Elimina los archivos ordinarios de respuesta después de comprobar los recursos:
rm -f received.json job.json worker-response.json
Usa la comprobación del paso antes de finalizar tu entorno.
Resumen
Creaste una cola SQS Standard, enviaste y recibiste un trabajo de pedido JSON, verificaste el procesamiento real de Lambda y el elemento persistido en DynamoDB, y confirmaste el mensaje con su identificador de recepción. Diferenciaste la aceptación, la entrega en curso y la finalización del trabajo de negocio, y después eliminaste tu cola, tu pedido y tus registros de ejecución, conservando los recursos proporcionados.
