Bestellereignisse für einen Warteschlangenverbraucher umformen

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.

EventBridge filtert eingehende Ereignisse und leitet sie an SQS weiter, eine Warteschlange für Nachrichten. Der CLI-Zugriff ist bereits eingerichtet; ein persönliches AWS-Konto oder Zugriffsschlüssel sind nicht erforderlich.

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

Laborübersicht

Unabhängige Routingressourcen vorbereiten

Erstelle in diesem Schritt einen eigenen Bus und eine leere Warteschlange für Aufträge zur Bestellabwicklung.

Verwende AWS View oben, 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

Setze RULE_NAME für die folgenden Schritte:

RULE_NAME=labex-ev02-orders

Erstelle den Ereignisbus der Übung:

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

Speichere den zurückgegebenen Wert in QUEUE_URL:

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

Speichere den zurückgegebenen Wert in QUEUE_ARN:

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

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"

Prüfe die Attribute der Warteschlange $QUEUE_URL:

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

Es gibt keine Regeln oder Nachrichten. Betrachte AWS View oben, 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.

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.

Verwende das Routing und die Berechtigung der Quellregel aus EV01 erneut, um diese unabhängige Pipeline aufzubauen. Neu ist der Verbrauchervertrag: Das Ziel wandelt ein passendes Ereignis in die Felder um, die der Queue-Verbraucher benötigt. Der Filter entscheidet weiterhin, welche Ereignisse dieses Ziel erreichen.

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

Speichere den zurückgegebenen Wert in 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"

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

Schreibe die Konfiguration in queue-attributes.json:

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

Wende die Attribute auf die Warteschlange $QUEUE_URL an:

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

Wende die Zustellungsziele der Ereignisregel an:

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

Prüfe die Zustellungsziele der Ereignisregel:

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

Schreibe die Konfiguration in events.json:

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

Veröffentliche den bereitgestellten Ereignisstapel:

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

Prüfe die Attribute der Warteschlange $QUEUE_URL:

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.

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

Lösche nur die Ereignisregel der Übung:

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

Lösche nur den Ereignisbus der Übung:

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

Lösche die Warteschlange der Übung $QUEUE_URL:

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

Erfolgreiche Bestandsabfragen direkt beim Dienst belegen die Löschung:

aws events list-event-buses

Prüfe die verbleibenden Ereignisregeln:

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

Prüfe die verbleibenden SQS-Warteschlangen:

aws sqs list-queues

Prüfe den nicht betroffenen Referenzdatensatz:

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.

Der Workflow-Zweig beginnt mit der nächsten Einheit nach deren Lambda–DynamoDB-Voraussetzungen; er hängt nicht von dieser Ereignispipeline ab.

Weitere Informationen bietet die AWS-Dokumentation: Eingabepfade und Zielnutzlastvorlagen.