Einführung
Der Produzent sendet ein vollständiges Bestellereignis, aber der Verbraucher benötigt nur eine Bestell-ID und eine Menge. Du formst zwei Ereignisse in kompakte Warteschlangennachrichten um und erhältst dabei den Routingfilter.
Schließe zuerst Bestellereignisse mit EventBridge weiterleiten ab. Baue diese Pipeline in ihrer unabhängigen VM auf; es wird kein früherer Bus, keine frühere Regel und keine frühere Warteschlange wiederverwendet.
Bezug zu Zertifizierungen
Dieses Lab bietet praktische Übungen zu den folgenden Prüfungsthemen.
- Solutions Architect – Associate (SAA-C03) · Aufgabe 2.1: EventBridge-Eingabetransformation für Consumer-Nutzdaten.
- Developer – Associate (DVA-C02) · Aufgabe 1.1: EventBridge-Eingabetransformation für Consumer-Nutzdaten.
- CloudOps Engineer – Associate (SOA-C03) · Aufgabe 1.2: EventBridge-Eingabetransformation für Consumer-Nutzdaten.
- DevOps Engineer – Professional (DOP-C02) · Aufgabe 4.3: Grundlagenübung: EventBridge-Eingabetransformation für Consumer-Nutzdaten.
- Data Engineer – Associate (DEA-C01) · Aufgabe 1.2: Grundlagenübung: EventBridge-Eingabetransformation für Consumer-Nutzdaten.
Unabhängige Routingressourcen vorbereiten
Erstelle in diesem Schritt einen eigenen Bus und eine leere Warteschlange für Aufträge zur Bestellabwicklung.
Verwende AWS View neben Terminal, um die CLI-Abfragen mit den tatsächlichen Ressourcen und Ergebnissen dieses Labs zu vergleichen. Erhalte die bereitgestellten Referenzdaten.
Das Ereignis des Produzenten enthält Routingmetadaten, Kundeninformationen und eine verschachtelte Bestellung. Der Warteschlangenverbraucher benötigt nur die Bestell-ID und die Menge. Eingabetransformation wählt Felder aus dem Ereignis und erstellt den Zielinhalt, wodurch die Abhängigkeit des Verbrauchers vom Umschlag des Produzenten sinkt.
Dieser neue Arbeitsbereich enthält konfigurierten CLI-Zugriff und unbeteiligte Referenzdaten. Er verwendet keine EV01-Ressourcen wieder. Beginne im Projektverzeichnis. Shellzuweisungen speichern zurückgegebene Kennungen; --query wählt ein Antwortfeld aus, und --output text macht dieses Feld im nächsten Befehl wiederverwendbar.
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)
Die Bus-ARN bezeichnet das Ereignisziel; die Warteschlangen-URL wird für Nachrichtenoperationen verwendet, während ihre ARN ein Regelziel bezeichnet. Bestätige den Anfangszustand:
aws events list-rules --event-bus-name "$BUS_NAME"
aws sqs get-queue-attributes \
--queue-url "$QUEUE_URL" \
--attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible
Es gibt keine Regeln oder Nachrichten. Klicke auf AWS View neben Terminal, um denselben eigenen Bus und die leere Warteschlange zu untersuchen. Führe die Vorbereitungsprüfung aus.
Ein Ziel mit einem Input Transformer verbinden
Gleiche in diesem Schritt aufgegebene Bestellungen ab, autorisiere die Regel und definiere die kompakte Nutzlast für den Verbraucher.
Wähle die verschachtelten Bestellfelder aus und erstelle den id/quantity-Inhalt des Verbrauchers; erhalte den Routingfilter.
Das Muster einer Regel gleicht Produzent und Ereigniskategorie ab. Ein Here-Dokument mit einer in Anführungszeichen gesetzten Markierung schreibt wörtliches JSON ohne Shellersetzung; file:// liest diese Datei in die CLI-Anfrage ein.
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)
Die Warteschlange benötigt eine genaue Berechtigung für die Quellregel. Schreibe gewöhnliches Richtlinien-JSON mit deinen Warteschlangen- und Regel-ARNs. --rawfile codiert es anschließend als SQS-Attribut Policy mit einem Zeichenfolgenwert.
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
Eine InputPathsMap benennt Felder, die durch JSONPath ausgewählt werden. $ bedeutet die Wurzel des Ereignisses; $.detail.order.id wählt die verschachtelte Bestell-ID aus. Eine InputTemplate verwendet Platzhalter in spitzen Klammern, um die Nachricht zu konstruieren. Der ID-Platzhalter steht innerhalb der Anführungszeichen einer JSON-Zeichenfolge; die Menge ist eine JSON-Zahl und hat keine Anführungszeichen. Das Beispiel verwendet einfache IDs und positive ganzzahlige Mengen.
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 ist null. Das aufgelistete Ziel enthält deine Warteschlangen-ARN und die beiden Zuordnungspfade sowie die Vorlage. Erfolgreiche Konfiguration benötigt weiterhin einen tatsächlichen Zustelltest. AWS View zeigt die aktivierte Regel und den Transformer; die Warteschlange bleibt leer. Führe die Verbindungsprüfung aus.
Zwei tatsächliche Verbrauchernutzlasten vergleichen
Veröffentliche in diesem Schritt zwei unterschiedliche aufgegebene Bestellungen und untersuche die resultierenden Warteschlangennachrichten.
Schreibe die Ereignisdetails als gewöhnliche JSON-Objekte. PutEvents benötigt jedes Detail als JSON-codierte Zeichenfolge; der kurze jq-Befehl unten wandelt nur dieses Feld um. Jedes Ereignis enthält außerdem fiktive Kundeninformationen, die der Verbraucher zur Auftragsabwicklung nicht benötigt. Ein drittes Stornierungsereignis testet, dass der Routingfilter weiterhin gilt.
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
Alle drei Ereignisse werden angenommen, aber nur die beiden aufgegebenen Bestellungen passen. Die Warteschlange hat zwei verfügbare Nachrichten. Ein Empfang mit einer Sichtbarkeitsfrist von null lässt die Nachrichten unmittelbar nach der Untersuchung verfügbar. Die Abfrage zeigt nur Nachrichten-IDs und Inhalte und hält die Empfangskennungen privat.
fromjson macht jeden JSON-Inhalt lesbar und behält dabei seine SQS-Nachrichten-ID bei. Es ändert nur die angezeigte Ausgabe.
aws sqs receive-message \
--queue-url "$QUEUE_URL" \
--max-number-of-messages 10 \
--visibility-timeout 0 \
--output json | jq '[.Messages[] | {MessageId, Body: (.Body | fromjson)}]'
Die Inhalte sind {"id":"transform-order-a","quantity":2} und {"id":"transform-order-b","quantity":4}; ihre Reihenfolge wird nicht bewertet. Sie haben unterschiedliche Nachrichten-IDs und Werte, die aus den entsprechenden Ereignissen abgeleitet sind. Keiner enthält Kunden-E-Mail, Routingmetadaten oder ein verschachteltes order-Objekt. Die stornierte Bestellung fehlt. Dies belegt Transformation und Zustellung, keine abgeschlossene Auftragsabwicklung oder Nachrichtenbestätigung.
AWS View zeigt die Zuordnungen des Ziels neben den tatsächlichen kompakten Warteschlangeninhalten.
Das Beispiel unten zeigt sowohl die Zuordnungen der verschachtelten Felder als auch die beiden tatsächlichen kompakten Verbrauchernachrichten.
Führe die Nutzlastprüfung aus.
Die temporäre Pipeline entfernen
Entferne in diesem Schritt deine Routingressourcen und erhalte unbeteiligten Zustand.
Entferne das Ziel vor seiner Regel und lösche dann den eigenen Bus und die Warteschlange. Die Warteschlange enthält nur fiktive Nachrichten zur Untersuchung; ihre Löschung verwirft diese, ohne Geschäftsverarbeitung zu behaupten.
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"
Erfolgreiche Bestandsabfragen direkt beim Dienst belegen die Löschung:
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
Nur der Standardbus bleibt erhalten, ohne Regeln; Warteschlangen-URLs fehlen. Das Referenzelement enthält weiterhin keep unchanged. Netzwerk- oder Authentifizierungsfehler belegen keine Löschung. AWS View zeigt leere eigene Ressourcen und die erhaltene Referenz.
Entferne die gewöhnlichen Dateien, die in diesem Lab erstellt wurden:
rm -f event-inputs.json order-pattern.json queue-policy.json queue-attributes.json targets.json events.json
Führe die Bereinigungsprüfung aus, bevor du die VM beendest.
Zusammenfassung
Du hast verschachtelte Bestellfelder einem kompakten Nachrichtenformat für den SQS-Verbraucher zugeordnet, unterschiedliche Werte aus zwei tatsächlichen Ereignissen geprüft und Ereignisfilterung sowie Berechtigungen für die Quellregel erhalten. Du hast die temporäre Pipeline entfernt und dabei die Referenzdaten erhalten.
Die nächste Einheit verbindet tatsächliche Geschäftsaufgaben in einem Bestellworkflow.
