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

AWSBeginner
Pratiquer maintenant

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.

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

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

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 à 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.

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
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)

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"
aws sqs get-queue-attributes \
  --queue-url "$QUEUE_URL" \
  --attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible

Il n'y a aucune règle ni aucun message. Cliquez sur AWS View à côté de Terminal 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.

Du détail d'événement au corps du consommateur

Sélectionnez les champs de commande imbriqués et construisez le corps id/quantity du consommateur ; conservez le filtre de routage.

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.

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 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
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 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
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 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
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

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.

L'exemple ci-dessous montre les deux mappages de champs imbriqués et les deux véritables messages compacts du consommateur.

AWS View affiche deux messages de commande transformés

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
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 natives d'inventaire réussies établissent la suppression :

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

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.

L'unité suivante relie de véritables tâches métier dans un workflow de commande.