Transformer les événements de commande pour un consommateur de file

Introduction

Le producteur envoie un événement complet de commande, mais le consommateur a besoin uniquement d'un identifiant de commande et d'une quantité. Vous transformerez deux événements en messages de file compacts en conservant le filtre de routage.

EventBridge sélectionne les événements entrants et les dirige vers SQS, une file qui conserve les messages. L’accès CLI est déjà configuré ; aucun compte AWS personnel ni clé d’accès n’est nécessaire.

Terminez d'abord Acheminer les événements de commande avec EventBridge. Construisez ce pipeline dans sa VM indépendante ; aucun bus, aucune règle ni file précédents ne sont réutilisés.

Lien avec les certifications

Vue d’ensemble du laboratoire

Préparer des ressources de routage indépendantes

Dans cette étape, créez un bus personnalisé et une file vide pour les tâches de préparation des commandes.

Utilisez AWS View en haut 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.

L'événement du producteur contient des métadonnées de routage, des informations client et une commande imbriquée. Le consommateur de la file a besoin uniquement de l'identifiant de commande et de la quantité. La transformation d'entrée sélectionne des champs de l'événement et construit le corps de destination, réduisant la dépendance du consommateur à l'enveloppe du producteur.

Cet espace de travail neuf contient un accès CLI configuré et des données de référence indépendantes. Il ne réutilise pas les ressources d'EV01. Commencez dans le répertoire du projet. Les affectations du shell enregistrent les identifiants renvoyés ; --query sélectionne un champ de réponse et --output text rend ce champ réutilisable dans la commande suivante.

cd /home/labex/project
BUS_NAME=labex-ev02-bus

Définissez RULE_NAME pour les opérations suivantes :

RULE_NAME=labex-ev02-orders

Créez le bus d’événements de l’exercice :

aws events create-event-bus --name "$BUS_NAME"

Enregistrez la valeur renvoyée dans QUEUE_URL :

QUEUE_URL=$(aws sqs create-queue \
  --queue-name labex-ev02-jobs \
  --query QueueUrl \
  --output text)
echo "$QUEUE_URL"

Enregistrez la valeur renvoyée dans QUEUE_ARN :

QUEUE_ARN=$(aws sqs get-queue-attributes \
  --queue-url "$QUEUE_URL" \
  --attribute-names QueueArn \
  --query Attributes.QueueArn \
  --output text)
echo "$QUEUE_ARN"

L'ARN du bus identifie la destination de l'événement ; l'URL de file sert aux opérations sur les messages, tandis que son ARN identifie une cible de règle. Confirmez l'état initial :

aws events list-rules --event-bus-name "$BUS_NAME"

Consultez les attributs de la file $QUEUE_URL :

aws sqs get-queue-attributes \
  --queue-url "$QUEUE_URL" \
  --attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible

Il n'y a aucune règle ni aucun message. Observez AWS View en haut pour inspecter le même bus personnalisé et la file vide. Exécutez la vérification de la préparation.

Connecter une cible avec un transformateur d'entrée

Dans cette étape, sélectionnez les commandes passées, autorisez la règle et définissez la charge utile compacte du consommateur.

Le modèle d'une règle compare le producteur et la catégorie d'événement. Un document intégré avec un marqueur entre guillemets écrit le JSON littéral sans développement par le shell ; file:// lit ce fichier dans la requête CLI.

Réutilisez le routage et l’autorisation de la règle source d’EV01 pour établir ce pipeline indépendant. Le nouveau choix concerne le contrat du consommateur : la cible transforme un événement correspondant en champs nécessaires au consommateur de la file. Le filtre détermine toujours quels événements atteignent cette cible.

cat > order-pattern.json <<'JSON'
{"source":["labex.orders"],"detail-type":["OrderPlaced"]}
JSON

Enregistrez la valeur renvoyée dans RULE_ARN :

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)
echo "$RULE_ARN"

La file a besoin d'une autorisation exacte de la règle source. Écrivez une politique JSON ordinaire avec les ARN de votre file et de votre règle. --rawfile l'encode ensuite comme attribut SQS Policy de type chaîne.

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

Écrivez la configuration dans queue-attributes.json :

jq -n --rawfile policy queue-policy.json '{Policy:$policy}' > queue-attributes.json

Appliquez les attributs à la file $QUEUE_URL :

aws sqs set-queue-attributes \
  --queue-url "$QUEUE_URL" \
  --attributes file://queue-attributes.json

Un InputPathsMap nomme les champs sélectionnés par JSONPath. $ signifie la racine de l'événement ; $.detail.order.id sélectionne l'identifiant de commande imbriqué. Un InputTemplate utilise des espaces réservés entre chevrons pour construire le message. L'espace réservé de l'identifiant est entre guillemets de chaîne JSON ; la quantité est un nombre JSON sans guillemets. L'exemple utilise des identifiants simples et des quantités entières positives.

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

Appliquez les cibles de livraison de la règle d’événements :

aws events put-targets \
  --rule "$RULE_NAME" \
  --event-bus-name "$BUS_NAME" \
  --targets file://targets.json

Consultez les cibles de livraison de la règle d’événements :

aws events list-targets-by-rule --rule "$RULE_NAME" --event-bus-name "$BUS_NAME"

FailedEntryCount vaut zéro. La cible listée inclut l'ARN de votre file et les deux chemins de mappage ainsi que le modèle. Une configuration réussie nécessite toujours un test de livraison réelle. AWS View affiche la règle activée et le transformateur ; la file reste vide. Exécutez la vérification de la connexion.

Comparer deux charges utiles réelles du consommateur

Dans cette étape, publiez deux commandes passées distinctes et inspectez les messages résultants dans la file.

Écrivez les détails d'événement comme des objets JSON ordinaires. PutEvents exige que chaque Detail soit une chaîne encodée en JSON ; la courte commande jq ci-dessous convertit uniquement ce champ. Chaque événement contient aussi des informations client fictives dont le consommateur de préparation des commandes n'a pas besoin. Un troisième événement d'annulation teste que le filtre de routage s'applique toujours.

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

Écrivez la configuration dans events.json :

jq 'map(.Detail |= tojson)' event-inputs.json > events.json

Publiez le lot d’événements fourni :

aws events put-events --entries file://events.json

Consultez les attributs de la file $QUEUE_URL :

aws sqs get-queue-attributes \
  --queue-url "$QUEUE_URL" \
  --attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible

Les trois événements sont acceptés, mais seules les deux commandes passées correspondent. La file possède deux messages disponibles. Une réception avec une visibilité de zéro laisse les messages immédiatement disponibles après inspection. La requête affiche uniquement les identifiants de message et les corps, sans divulguer les identifiants de réception.

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

Les corps sont {"id":"transform-order-a","quantity":2} et {"id":"transform-order-b","quantity":4} ; leur ordre n'est pas évalué. Ils ont des identifiants de message distincts et des valeurs dérivées des événements correspondants. Aucun ne contient d'e-mail client, de métadonnées de routage ni d'objet order imbriqué. La commande annulée est absente. Cela prouve la transformation et la livraison, pas l'achèvement de la préparation ni l'acquittement des messages.

AWS View affiche les mappages de la cible à côté des corps compacts réels dans la file.

Exécutez la vérification de la charge utile.

Supprimer le pipeline jetable

Dans cette étape, supprimez vos ressources de routage et conservez l'état indépendant.

Supprimez la cible avant sa règle, puis supprimez le bus personnalisé et la file. La file contient uniquement des messages fictifs d'inspection ; sa suppression les détruit sans affirmer qu'un traitement métier a eu lieu.

aws events remove-targets \
  --rule "$RULE_NAME" \
  --event-bus-name "$BUS_NAME" \
  --ids order-queue

Supprimez uniquement la règle d’événements de l’exercice :

aws events delete-rule --name "$RULE_NAME" --event-bus-name "$BUS_NAME"

Supprimez uniquement le bus d’événements de l’exercice :

aws events delete-event-bus --name "$BUS_NAME"

Supprimez la file de l’exercice $QUEUE_URL :

aws sqs delete-queue --queue-url "$QUEUE_URL"

Des requêtes natives d'inventaire réussies établissent la suppression :

aws events list-event-buses

Consultez les règles d’événements restantes :

aws events list-rules --event-bus-name default

Consultez les files SQS restantes :

aws sqs list-queues

Consultez l’enregistrement de référence sans lien avec l’exercice :

aws dynamodb scan --table-name labex-ev02-reference --query Items

Seul le bus par défaut reste, sans règles ; les URL de files sont absentes. L'élément de référence indique toujours keep unchanged. Les erreurs de réseau ou d'authentification ne prouvent pas la suppression. AWS View affiche les ressources personnalisées vides et la référence conservée.

Supprimez les fichiers ordinaires créés dans ce laboratoire :

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

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

Résumé

Vous avez mappé des champs de commande imbriqués vers un contrat compact pour un consommateur SQS, vérifié des valeurs distinctes provenant de deux événements réels et conservé le filtrage des événements ainsi que les permissions de la règle source. Vous avez supprimé le pipeline jetable en conservant les données de référence.

La branche workflow commence à l’unité suivante après ses prérequis Lambda–DynamoDB ; elle ne dépend pas de ce pipeline de routage.

Pour approfondir ce sujet, consultez la documentation AWS : Chemins d’entrée et modèles de charge cible.