LabEx
Rejoindre

Acheminer les événements de commande avec EventBridge

AWSBeginner
Pratiquer maintenant

Introduction

La préparation des commandes a besoin des nouvelles commandes passées, tandis que les événements de facturation et d'annulation doivent aller ailleurs. Vous acheminerez les événements correspondants vers une file et vérifierez quels messages arrivent réellement.

Terminez d'abord Envoyer et consommer des tâches avec SQS et Protégez un compartiment avec une politique de ressource. Cette VM indépendante fournit son propre accès CLI et ses données de référence ; les files et identifiants d'accès précédents ne sont pas réutilisés.

Lien avec les certifications

Ce laboratoire propose une pratique des sujets d’examen suivants.

Préparer un bus et une file de destination

Dans cette étape, créez les emplacements indépendants où les événements entrent et où le travail correspondant attend un consommateur.

Utilisez AWS View à côté de Terminal pour comparer les requêtes CLI avec les ressources et résultats réels de ce laboratoire. Conservez les données de référence fournies.

Amazon EventBridge achemine les événements qui décrivent des faits survenus. Un bus reçoit les événements, une règle compare les champs et une cible reçoit les événements correspondants. Un bus personnalisé sépare les événements de cette application du bus par défaut. Une file SQS conserve les livraisons jusqu'à leur traitement par un consommateur. Commencez dans le répertoire du projet. Les affectations du shell enregistrent les identifiants renvoyés par la CLI ; --query sélectionne le champ nécessaire et --output text le rend utilisable par la commande suivante.

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 réponse du bus contient son ARN et QUEUE_URL identifie la file pour les opérations sur les messages. L'ARN de la file l'identifie dans une cible ou une politique de permission. Ces identifiants ont des rôles différents.

Inspectez les deux ressources vides :

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

Il n'y a pas encore de règles et la file ne possède aucun message disponible ni en cours de livraison. AWS View affiche votre bus personnalisé et la file vide. Exécutez la vérification de la préparation.

Sélectionner les commandes et autoriser une seule règle

Dans cette étape, reliez une règle de correspondance à la file et autorisez uniquement les livraisons de cette règle.

Producteur, bus, règle et file

Une règle de correspondance sélectionne l'événement ; l'autorisation de la file pour la règle source permet séparément sa livraison.

Un modèle d'événement, ou event pattern, est un filtre sur les champs d'événement. source nomme le producteur, tandis que detail-type nomme la catégorie d'événement. Chaque tableau ci-dessous liste les valeurs acceptées. Un document intégré écrit le JSON littéral entre les marqueurs JSON ; les guillemets autour du marqueur empêchent le développement par le shell. file:// demande à la CLI de lire ce fichier.

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 règle est activée, mais une correspondance seule n'autorise pas la livraison. La politique de ressource de la file doit permettre au service EventBridge d'envoyer, avec aws:SourceArn limité à cette règle. Écrivez une politique JSON ordinaire ; le shell insère les ARN de votre file et de votre règle.

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

L'API d'attributs stocke la politique comme une chaîne JSON ; --rawfile lit donc ce document dans l'attribut Policy. L'autorisation couvre une file et une règle d'origine.

Une cible est la destination de la règle. Son identifiant permet de mettre à jour ou de supprimer cette connexion ultérieurement :

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 vaut zéro pour la configuration de la cible, la règle décrite possède le modèle prévu et l'ARN cible correspond à votre file. AWS View affiche maintenant la règle et sa destination de file. Il n'y a toujours aucun événement à livrer. Exécutez la vérification de la connexion.

Prouver les frontières de correspondance et de livraison

Dans cette étape, publiez des événements correspondants et indépendants, puis testez un échec de permission de source sans ajouter de nouveau message à la file.

Un événement EventBridge possède des champs de routage et une charge utile detail. L'API PutEvents accepte Detail comme une chaîne encodée en JSON. Écrivez trois entrées lisibles : une commande passée, un événement de facturation et une annulation. jq convertit chaque objet Detail en chaîne requise par l'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 réponse de publication signale zéro entrée échouée et un identifiant d'événement pour chaque entrée acceptée. Seule route-order correspond aux deux champs : la file contient donc un message disponible. AWS View affiche son enveloppe complète d'événement : source, type de détail, compte, région et détail.

Lisez le corps réellement visible par le consommateur. Une réception masque normalement un message pendant son délai de visibilité ; --visibility-timeout 0 rend cette inspection immédiatement visible de nouveau. La requête affiche uniquement son identifiant et son corps, sans afficher l'identifiant de réception. Cette inspection ne termine pas le traitement métier et n'acquitte pas le message.

fromjson rend chaque corps JSON lisible tout en conservant son identifiant de message SQS. Il modifie uniquement la sortie affichée.

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

Le corps possède detail.id égal à route-order et detail.quantity égal à 2. Les entrées de facturation et d'annulation n'ont pas atteint cette file.

L'exemple ci-dessous montre la règle de correspondance activée, sa cible de file et l'événement réel complet de commande, y compris le compte et la région.

AWS View affiche l'événement de commande correspondant dans la file de destination

Pointez maintenant la politique de file vers un autre ARN source en gardant la règle et la cible activées :

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 accepte cet événement, mais la règle ne possède pas l'autorisation requise sur la file. Le message d'origine reste le seul événement en file ; denied-order est absent. Distinguez l'acceptation d'événement de la livraison à la cible lors du diagnostic d'un pipeline. Cet exercice n'examine pas les nouvelles tentatives de livraison.

Rétablissez l'autorisation prévue et inspectez de nouveau :

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

Seule la route-order d'origine est présente. La politique corrigée autorise les livraisons suivantes ; ce laboratoire ne dépend pas d'une nouvelle tentative d'un événement précédemment refusé. Exécutez la vérification du routage.

Supprimer le pipeline d'événements

Dans cette étape, supprimez votre cible, votre règle, votre bus personnalisé et la file jetable, en conservant les ressources indépendantes.

Supprimez la cible avant de supprimer sa règle. Supprimez ensuite le bus personnalisé et la file. Supprimer la file détruit l'événement fictif conservé pour l'inspection du routage ; aucun résultat métier n'a été affirmé pour lui.

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"

Des requêtes réussies en lecture seule établissent ce qui reste :

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

Seul le bus par défaut reste, sa liste de règles est vide, les URL de files sont absentes et l'élément de référence indique keep unchanged. Les erreurs d'authentification ou de réseau n'établissent pas la suppression. AWS View affiche les listes de ressources personnalisées vides et la référence conservée.

Supprimez les fichiers ordinaires que vous avez créés :

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

Exécutez la vérification du nettoyage avant de terminer la VM.

Résumé

Vous avez créé un bus EventBridge personnalisé, sélectionné les événements de commandes passées et connecté une cible de file avec une autorisation exacte de la règle source. Les corps réels dans la file ont montré quels événements atteignaient le consommateur et le test de source refusée a séparé l'acceptation de l'événement de sa livraison. Vous avez supprimé vos ressources en conservant le bus par défaut et les données de référence.

L'unité suivante transforme une enveloppe d'événement en charge utile plus petite, adaptée aux besoins d'un consommateur de file.

Connexe AWS Cours
Les bases d’AWS pour débutants

Les bases d’AWS pour débutants

aws
AWS S3 pour débutants

AWS S3 pour débutants

aws
AWS IAM pour débutants

AWS IAM pour débutants

aws