Introducción
El productor envía un evento de pedido completo, pero el consumidor solo necesita un ID de pedido y una cantidad. Transformarás dos eventos en mensajes compactos de cola, conservando el filtro de enrutamiento.
Completa primero Enrutar eventos de pedidos con EventBridge. Construye esta canalización en su VM independiente; no se reutiliza ningún bus, regla ni cola anterior.
Relación con las certificaciones
Este laboratorio ofrece práctica para los siguientes temas de examen.
- Solutions Architect – Associate (SAA-C03) · Tarea 2.1: Transformación de entrada EventBridge para cargas de consumidores.
- Developer – Associate (DVA-C02) · Tarea 1.1: Transformación de entrada EventBridge para cargas de consumidores.
- CloudOps Engineer – Associate (SOA-C03) · Tarea 1.2: Transformación de entrada EventBridge para cargas de consumidores.
- DevOps Engineer – Professional (DOP-C02) · Tarea 4.3: Práctica de fundamentos: Transformación de entrada EventBridge para cargas de consumidores.
- Data Engineer – Associate (DEA-C01) · Tarea 1.2: Práctica de fundamentos: Transformación de entrada EventBridge para cargas de consumidores.
Preparar recursos de enrutamiento independientes
En este paso, crea un bus personalizado y una cola vacía para trabajos de preparación de pedidos.
Usa AWS View junto a Terminal para comparar las consultas CLI con los recursos y resultados reales de este laboratorio. Conserva los datos de referencia proporcionados.
El evento del productor contiene metadatos de enrutamiento, información del cliente y un pedido anidado. El consumidor de cola solo necesita el ID de pedido y la cantidad. La transformación de entrada elige campos del evento y construye el cuerpo de destino, reduciendo la dependencia del consumidor respecto al envoltorio del productor.
Este entorno de trabajo nuevo contiene acceso CLI configurado y datos de referencia ajenos al trabajo. No reutiliza recursos de EV01. Empieza en el directorio del proyecto. Las asignaciones de shell guardan identificadores devueltos; --query selecciona un campo de respuesta y --output text permite reutilizar ese campo en el siguiente comando.
cd /home/labex/project
BUS_NAME=labex-ev02-bus
RULE_NAME=labex-ev02-orders
aws events create-event-bus --name "$BUS_NAME"
QUEUE_URL=$(aws sqs create-queue \
--queue-name labex-ev02-jobs \
--query QueueUrl \
--output text)
QUEUE_ARN=$(aws sqs get-queue-attributes \
--queue-url "$QUEUE_URL" \
--attribute-names QueueArn \
--query Attributes.QueueArn \
--output text)
El ARN del bus identifica el destino del evento; la URL de cola se usa para operaciones de mensajes, mientras su ARN identifica un destino de regla. Confirma el estado inicial:
aws events list-rules --event-bus-name "$BUS_NAME"
aws sqs get-queue-attributes \
--queue-url "$QUEUE_URL" \
--attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible
No hay reglas ni mensajes. Haz clic en AWS View junto a Terminal para inspeccionar el mismo bus personalizado y la cola vacía. Ejecuta la comprobación de preparación.
Conectar un destino con un transformador de entrada
En este paso, selecciona pedidos realizados, autoriza la regla y define la carga útil compacta del consumidor.
Selecciona los campos anidados del pedido y construye el cuerpo id/quantity del consumidor; conserva el filtro de enrutamiento.
El patrón de una regla busca coincidencias en el productor y la categoría de evento. Un documento de entrada entre comillas escribe JSON literal sin expansión del shell; file:// lee ese archivo en la solicitud CLI.
cat > order-pattern.json <<'JSON'
{"source":["labex.orders"],"detail-type":["OrderPlaced"]}
JSON
RULE_ARN=$(aws events put-rule \
--name "$RULE_NAME" \
--event-bus-name "$BUS_NAME" \
--event-pattern file://order-pattern.json \
--state ENABLED \
--query RuleArn \
--output text)
La cola necesita un permiso exacto para la regla de origen. Escribe JSON ordinario de política usando los ARN de tu cola y regla. Después, --rawfile lo codifica como el atributo SQS Policy cuyo valor es una cadena.
cat > queue-policy.json <<EOF
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "events.amazonaws.com"
},
"Action": "sqs:SendMessage",
"Resource": "$QUEUE_ARN",
"Condition": {
"ArnEquals": {
"aws:SourceArn": "$RULE_ARN"
}
}
}
]
}
EOF
jq -n --rawfile policy queue-policy.json '{Policy:$policy}' > queue-attributes.json
aws sqs set-queue-attributes \
--queue-url "$QUEUE_URL" \
--attributes file://queue-attributes.json
Un InputPathsMap asigna nombres a campos seleccionados por JSONPath. $ significa la raíz del evento; $.detail.order.id selecciona el ID de pedido anidado. Un InputTemplate usa marcadores entre corchetes angulares para construir el mensaje. El marcador de ID está dentro de comillas de cadena JSON; la cantidad es un número JSON y no tiene comillas. El ejemplo usa IDs simples y cantidades enteras positivas.
cat > targets.json <<EOF
[
{
"Id": "order-queue",
"Arn": "$QUEUE_ARN",
"InputTransformer": {
"InputPathsMap": {
"id": "\$.detail.order.id",
"quantity": "\$.detail.order.quantity"
},
"InputTemplate": "{\"id\":\"<id>\",\"quantity\":<quantity>}"
}
}
]
EOF
aws events put-targets \
--rule "$RULE_NAME" \
--event-bus-name "$BUS_NAME" \
--targets file://targets.json
aws events list-targets-by-rule --rule "$RULE_NAME" --event-bus-name "$BUS_NAME"
FailedEntryCount es cero. El destino enumerado incluye el ARN de tu cola y las dos rutas de asignación y la plantilla. Una configuración correcta todavía necesita una prueba de entrega real. AWS View muestra la regla habilitada y el transformador; la cola permanece vacía. Ejecuta la comprobación de conexión.
Comparar dos cargas útiles reales del consumidor
En este paso, publica dos pedidos realizados distintos e inspecciona los mensajes de cola resultantes.
Escribe los detalles de eventos como objetos JSON ordinarios. PutEvents requiere que cada Detail sea una cadena codificada en JSON; el breve comando jq siguiente convierte únicamente ese campo. Cada evento también contiene información sintética del cliente que el consumidor de preparación de pedidos no necesita. Un tercer evento de cancelación comprueba que el filtro de enrutamiento sigue aplicándose.
cat > event-inputs.json <<EOF
[
{
"EventBusName": "$BUS_NAME",
"Source": "labex.orders",
"DetailType": "OrderPlaced",
"Detail": {
"order": {
"id": "transform-order-a",
"quantity": 2
},
"customer": {
"email": "synthetic-a@example.test"
}
}
},
{
"EventBusName": "$BUS_NAME",
"Source": "labex.orders",
"DetailType": "OrderPlaced",
"Detail": {
"order": {
"id": "transform-order-b",
"quantity": 4
},
"customer": {
"email": "synthetic-b@example.test"
}
}
},
{
"EventBusName": "$BUS_NAME",
"Source": "labex.orders",
"DetailType": "OrderCancelled",
"Detail": {
"order": {
"id": "cancelled-order",
"quantity": 9
}
}
}
]
EOF
jq 'map(.Detail |= tojson)' event-inputs.json > events.json
aws events put-events --entries file://events.json
aws sqs get-queue-attributes \
--queue-url "$QUEUE_URL" \
--attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible
Se aceptan los tres eventos, pero solo coinciden los dos pedidos realizados. La cola tiene dos mensajes disponibles. Recibirlos con visibilidad cero los deja disponibles inmediatamente después de la inspección. La consulta muestra únicamente los IDs y cuerpos de mensajes, manteniendo privados los identificadores de recepción.
fromjson hace legible cada cuerpo JSON y conserva su ID de mensaje SQS. Solo cambia la salida mostrada.
aws sqs receive-message \
--queue-url "$QUEUE_URL" \
--max-number-of-messages 10 \
--visibility-timeout 0 \
--output json | jq '[.Messages[] | {MessageId, Body: (.Body | fromjson)}]'
Los cuerpos son {"id":"transform-order-a","quantity":2} y {"id":"transform-order-b","quantity":4}; su orden no se evalúa. Tienen IDs de mensaje distintos y valores derivados de los eventos correspondientes. Ninguno contiene el correo electrónico del cliente, metadatos de enrutamiento ni un objeto order anidado. El pedido cancelado está ausente. Esto demuestra la transformación y la entrega, no la preparación completada del pedido ni la confirmación del mensaje.
AWS View muestra las asignaciones del destino junto a los cuerpos compactos reales de cola.
El siguiente ejemplo muestra ambas asignaciones de campos anidados y los dos mensajes compactos reales del consumidor.
Ejecuta la comprobación de carga útil.
Eliminar la canalización desechable
En este paso, elimina tus recursos de enrutamiento y conserva el estado ajeno al trabajo.
Elimina el destino antes de su regla y después elimina el bus personalizado y la cola. La cola contiene únicamente mensajes sintéticos de inspección; eliminarla los descarta sin afirmar que se haya realizado procesamiento de negocio.
aws events remove-targets \
--rule "$RULE_NAME" \
--event-bus-name "$BUS_NAME" \
--ids order-queue
aws events delete-rule --name "$RULE_NAME" --event-bus-name "$BUS_NAME"
aws events delete-event-bus --name "$BUS_NAME"
aws sqs delete-queue --queue-url "$QUEUE_URL"
Las consultas nativas correctas de inventario demuestran la eliminación:
aws events list-event-buses
aws events list-rules --event-bus-name default
aws sqs list-queues
aws dynamodb scan --table-name labex-ev02-reference --query Items
Solo permanece el bus predeterminado, sin reglas; las URL de cola están ausentes. El elemento de referencia todavía indica keep unchanged. Los errores de red o autenticación no demuestran la eliminación. AWS View muestra los recursos personalizados vacíos y la referencia conservada.
Elimina los archivos ordinarios creados en este laboratorio:
rm -f event-inputs.json order-pattern.json queue-policy.json queue-attributes.json targets.json events.json
Ejecuta la comprobación de limpieza antes de finalizar la VM.
Resumen
Asignaste campos anidados de pedidos a un contrato compacto para el consumidor SQS, verificaste valores distintos de dos eventos reales y conservaste el filtrado de eventos y los permisos de la regla de origen. Eliminaste la canalización desechable, conservando los datos de referencia.
La siguiente unidad conecta tareas reales de negocio en un flujo de pedidos.
