LabEx
Únete

Enrutar eventos de pedidos con EventBridge

AWSBeginner
Practicar Ahora

Introducción

El equipo de preparación de pedidos necesita los pedidos recién realizados, mientras los eventos de facturación y cancelación corresponden a otros destinos. Enrutarás los eventos coincidentes a una cola y verificarás qué mensajes llegan realmente.

Completa primero Enviar y consumir trabajos con SQS y Proteger un bucket con una política de recursos. Esta VM independiente proporciona su propio acceso CLI y datos de referencia; no se reutilizan colas ni credenciales anteriores.

Relación con las certificaciones

Este laboratorio ofrece práctica para los siguientes temas de examen.

Preparar un bus y una cola de destino

En este paso, crea los lugares independientes donde entran los eventos y donde el trabajo coincidente espera a un consumidor.

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.

Amazon EventBridge enruta eventos que describen cosas que han ocurrido. Un bus recibe eventos, una regla busca coincidencias en campos y un destino recibe eventos coincidentes. Un bus personalizado separa los eventos de esta aplicación del bus predeterminado. Una cola SQS conserva las entregas hasta que un consumidor las procesa. Empieza en el directorio del proyecto. Las asignaciones de shell guardan identificadores devueltos por CLI; --query selecciona el campo necesario y --output text permite usarlo en el siguiente comando.

cd /home/labex/project
BUS_NAME=labex-ev01-bus
RULE_NAME=labex-ev01-orders
aws events create-event-bus --name "$BUS_NAME"
QUEUE_URL=$(aws sqs create-queue \
  --queue-name labex-ev01-jobs \
  --query QueueUrl \
  --output text)
QUEUE_ARN=$(aws sqs get-queue-attributes \
  --queue-url "$QUEUE_URL" \
  --attribute-names QueueArn \
  --query Attributes.QueueArn \
  --output text)

La respuesta del bus contiene su ARN y QUEUE_URL identifica la cola para las operaciones de mensajes. El ARN de cola la identifica en un destino o una política de permisos. Estos identificadores tienen finalidades distintas.

Inspecciona ambos recursos vacíos:

aws events list-rules --event-bus-name "$BUS_NAME"
aws sqs get-queue-attributes \
  --queue-url "$QUEUE_URL" \
  --attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible

Todavía no hay reglas y la cola no tiene mensajes disponibles ni en curso. AWS View muestra tu bus personalizado y la cola vacía. Ejecuta la comprobación de preparación.

Seleccionar pedidos coincidentes y autorizar una regla

En este paso, conecta una regla de coincidencia a la cola y autoriza únicamente las entregas de esa regla.

productor, bus, regla y cola

Una regla coincidente selecciona el evento; el permiso de la cola para la regla de origen permite su entrega de forma independiente.

Un patrón de eventos es un filtro sobre campos de eventos. source indica el productor y detail-type indica la categoría de evento. Cada matriz siguiente enumera los valores aceptados. Un documento de entrada escribe el JSON literal entre los marcadores JSON; las comillas del marcador impiden la expansión del shell. file:// indica a CLI que lea ese archivo.

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 regla está habilitada, pero una coincidencia por sí sola no autoriza la entrega. La política de recursos de la cola debe permitir que el servicio EventBridge envíe mensajes, con aws:SourceArn limitado a esta regla. Escribe una política JSON ordinaria; el shell inserta los ARN de tu cola y regla.

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

La API de atributos almacena la política como una cadena JSON, por lo que --rawfile lee ese documento en el atributo Policy. El permiso cubre una cola y una regla de origen.

Un destino es el receptor de la regla. Su ID permite actualizar o eliminar esa conexión más adelante:

cat > targets.json <<EOF
[
  {
    "Id": "order-queue",
    "Arn": "$QUEUE_ARN"
  }
]
EOF
aws events put-targets \
  --rule "$RULE_NAME" \
  --event-bus-name "$BUS_NAME" \
  --targets file://targets.json
aws events describe-rule --name "$RULE_NAME" --event-bus-name "$BUS_NAME"
aws events list-targets-by-rule --rule "$RULE_NAME" --event-bus-name "$BUS_NAME"

FailedEntryCount es cero para la configuración del destino, la regla descrita tiene el patrón previsto y el ARN de destino coincide con tu cola. AWS View ahora muestra la regla y su destino de cola. Todavía no hay ningún evento que entregar. Ejecuta la comprobación de conexión.

Demostrar los límites de coincidencia y entrega

En este paso, publica eventos coincidentes y ajenos al trabajo, y después prueba un fallo de permiso de origen sin añadir un mensaje nuevo a la cola.

Un evento EventBridge tiene campos de enrutamiento y una carga útil detail. La API PutEvents acepta Detail como una cadena codificada en JSON. Escribe tres entradas legibles: un pedido realizado, un evento de facturación y una cancelación. jq convierte cada objeto Detail en la cadena requerida por la API.

cat > event-inputs.json <<EOF
[
  {
    "EventBusName": "$BUS_NAME",
    "Source": "labex.orders",
    "DetailType": "OrderPlaced",
    "Detail": {
      "id": "route-order",
      "quantity": 2
    }
  },
  {
    "EventBusName": "$BUS_NAME",
    "Source": "labex.billing",
    "DetailType": "OrderPlaced",
    "Detail": {
      "id": "billing-event",
      "quantity": 9
    }
  },
  {
    "EventBusName": "$BUS_NAME",
    "Source": "labex.orders",
    "DetailType": "OrderCancelled",
    "Detail": {
      "id": "cancelled-event",
      "quantity": 1
    }
  }
]
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

La respuesta de publicación informa de cero entradas fallidas y un ID de evento por cada entrada aceptada. Solo route-order coincide con ambos campos, por lo que la cola contiene un mensaje disponible. AWS View muestra su envoltorio completo de evento: origen, tipo de detalle, cuenta, región y detalle.

Lee el cuerpo real visible para el consumidor. La recepción normalmente oculta un mensaje durante su tiempo de espera de visibilidad; --visibility-timeout 0 hace que vuelva a estar visible inmediatamente tras esta inspección. La consulta imprime únicamente su ID y cuerpo, sin mostrar el identificador de recepción. Esta inspección no completa el procesamiento de negocio ni confirma el mensaje.

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)}]'

El cuerpo tiene detail.id igual a route-order y detail.quantity igual a 2. Las entradas de facturación y cancelación no llegaron a esta cola.

El siguiente ejemplo muestra la regla de coincidencia habilitada, su destino de cola y el evento de pedido completo real, incluidas la cuenta y la región.

AWS View muestra el evento de pedido coincidente en la cola de destino

Ahora dirige la política de cola a un ARN de origen distinto, manteniendo habilitados la regla y el destino:

jq --arg wrong "${RULE_ARN}-other" '.Statement[0].Condition.ArnEquals["aws:SourceArn"]=$wrong' queue-policy.json > wrong-source-policy.json
jq -n --rawfile policy wrong-source-policy.json '{Policy:$policy}' > wrong-source-attributes.json
aws sqs set-queue-attributes \
  --queue-url "$QUEUE_URL" \
  --attributes file://wrong-source-attributes.json
cat > event-inputs.json <<EOF
[
  {
    "EventBusName": "$BUS_NAME",
    "Source": "labex.orders",
    "DetailType": "OrderPlaced",
    "Detail": {
      "id": "denied-order",
      "quantity": 4
    }
  }
]
EOF
jq 'map(.Detail |= tojson)' event-inputs.json > denied-event.json
aws events put-events --entries file://denied-event.json
aws sqs get-queue-attributes \
  --queue-url "$QUEUE_URL" \
  --attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible

EventBridge acepta este evento, pero la regla carece del permiso de cola requerido. El mensaje original sigue siendo el único evento en cola; denied-order está ausente. Diferencia la aceptación del evento de su entrega al destino al diagnosticar una canalización. Este ejercicio no examina los reintentos de entrega.

Restablece el permiso previsto e inspecciona de nuevo:

aws sqs set-queue-attributes \
  --queue-url "$QUEUE_URL" \
  --attributes file://queue-attributes.json
aws sqs receive-message \
  --queue-url "$QUEUE_URL" \
  --max-number-of-messages 10 \
  --visibility-timeout 0 \
  --output json | jq '[.Messages[] | {MessageId, Body: (.Body | fromjson)}]'

Solo está presente el route-order original. La política corregida autoriza las entregas posteriores; este laboratorio no depende de que se reintente un evento denegado anteriormente. Ejecuta la comprobación de enrutamiento.

Eliminar la canalización de eventos

En este paso, elimina tu destino, regla, bus personalizado y cola desechable, conservando los recursos ajenos al trabajo.

Elimina el destino antes de eliminar su regla. Después elimina el bus personalizado y la cola. La eliminación de la cola descarta el evento sintético conservado para inspeccionar el enrutamiento; no se afirmó ningún resultado de negocio para él.

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 correctas de solo lectura demuestran qué permanece:

aws events list-event-buses
aws events list-rules --event-bus-name default
aws sqs list-queues
aws dynamodb scan --table-name labex-ev01-reference --query Items

Solo permanece el bus predeterminado, su lista de reglas está vacía, las URL de cola están ausentes y el elemento de referencia indica keep unchanged. Los errores de autenticación o de red no demuestran la eliminación. AWS View muestra las listas vacías de recursos personalizados y la referencia conservada.

Elimina los archivos ordinarios que creaste:

rm -f event-inputs.json order-pattern.json queue-policy.json queue-attributes.json targets.json events.json wrong-source-policy.json wrong-source-attributes.json denied-event.json

Ejecuta la comprobación de limpieza antes de finalizar la VM.

Resumen

Creaste un bus EventBridge personalizado, seleccionaste eventos de pedidos realizados y conectaste un destino de cola con un permiso exacto para la regla de origen. Los cuerpos reales de cola mostraron qué eventos llegaron al consumidor y la prueba de origen denegado separó la aceptación del evento de su entrega. Eliminaste los recursos propios, conservando el bus predeterminado y los datos de referencia.

La siguiente unidad transforma un envoltorio de evento en la carga útil más pequeña que necesita un consumidor de cola.

Relacionado AWS Cursos
Fundamentos de AWS para principiantes

Fundamentos de AWS para principiantes

aws
AWS S3 para principiantes

AWS S3 para principiantes

aws
AWS IAM para principiantes

AWS IAM para principiantes

aws