Bestellereignisse mit EventBridge weiterleiten

Einführung

Die Auftragsabwicklung benötigt neu aufgegebene Bestellungen, während Abrechnungs- und Stornierungsereignisse an andere Stellen gehören. Du leitest passende Ereignisse an eine Warteschlange weiter und prüfst, welche Nachrichten tatsächlich ankommen.

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 Aufträge mit SQS senden und verarbeiten und Einen Bucket mit einer Ressourcenrichtlinie schützen ab. Diese unabhängige VM stellt eigenen CLI-Zugriff und Referenzdaten bereit; frühere Warteschlangen und Zugangsdaten werden nicht wiederverwendet.

Bezug zu Zertifizierungen

Laborübersicht

Einen Bus und eine Zielwarteschlange vorbereiten

Erstelle in diesem Schritt die unabhängigen Orte, an denen Ereignisse eintreffen und passende Arbeit auf einen Verbraucher wartet.

Verwende AWS View oben, um die CLI-Abfragen mit den tatsächlichen Ressourcen und Ergebnissen dieses Labs zu vergleichen. Erhalte die bereitgestellten Referenzdaten.

Amazon EventBridge leitet Ereignisse weiter, die beschreiben, was geschehen ist. Ein Bus empfängt Ereignisse, eine Regel gleicht Felder ab, und ein Ziel empfängt passende Ereignisse. Ein eigener Bus trennt die Ereignisse dieser Anwendung vom Standardbus. Eine SQS-Warteschlange hält Zustellungen vor, bis ein Verbraucher sie verarbeitet. Beginne im Projektverzeichnis. Shellzuweisungen speichern Kennungen, die von der CLI zurückgegeben werden; --query wählt das benötigte Feld aus, und --output text macht es für den nächsten Befehl verwendbar.

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

Setze RULE_NAME für die folgenden Schritte:

RULE_NAME=labex-ev01-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-ev01-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 Busantwort enthält seine ARN, und QUEUE_URL bezeichnet die Warteschlange für Nachrichtenoperationen. Die Warteschlangen-ARN bezeichnet sie in einem Ziel oder einer Berechtigungsrichtlinie. Diese Kennungen dienen unterschiedlichen Zwecken.

Untersuche beide leeren Ressourcen:

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 noch keine Regeln, und die Warteschlange enthält keine verfügbaren oder in Bearbeitung befindlichen Nachrichten. AWS View zeigt deinen eigenen Bus und die leere Warteschlange. Führe die Vorbereitungsprüfung aus.

Bestellungen abgleichen und eine Regel autorisieren

Verbinde in diesem Schritt eine passende Regel mit der Warteschlange und autorisiere nur die Zustellungen dieser Regel.

Ein Ereignismuster ist ein Filter über Ereignisfelder. source nennt den Produzenten, während detail-type die Ereigniskategorie nennt. Jedes Array unten listet akzeptierte Werte auf. Ein Here-Dokument schreibt das wörtliche JSON zwischen den Markierungen JSON; die Anführungszeichen um die Markierung verhindern Shellersetzung. file:// weist die CLI an, diese Datei zu lesen.

Beide Musterfelder müssen übereinstimmen: Der Bestellproduzent allein wählt keine Stornierung aus, und der Typ OrderPlaced allein wählt kein Abrechnungsereignis aus. Das source des Ereignisses ist ein Routingwert; aws:SourceArn in der Queue-Richtlinie bezeichnet die Regel, die es zustellen darf.

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 Regel ist aktiviert, aber eine Übereinstimmung allein autorisiert keine Zustellung. Die Ressourcenrichtlinie der Warteschlange muss dem EventBridge-Dienst das Senden erlauben, begrenzt durch aws:SourceArn auf diese Regel. Schreibe eine gewöhnliche JSON-Richtlinie; die Shell setzt deine Warteschlangen- und Regel-ARNs ein.

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

Die Attribut-API speichert die Richtlinie als JSON-Zeichenfolge, daher liest --rawfile dieses Dokument in das Attribut Policy ein. Die Berechtigung umfasst eine Warteschlange und eine Ursprungsregel.

Ein Ziel ist der Empfänger der Regel. Seine ID ermöglicht dir, diese Verbindung später zu aktualisieren oder zu entfernen:

cat > targets.json <<EOF
[
  {
    "Id": "order-queue",
    "Arn": "$QUEUE_ARN"
  }
]
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 das Auswahlmuster der Ereignisregel:

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

Prüfe die Zustellungsziele der Ereignisregel:

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

FailedEntryCount ist für die Zielkonfiguration null, die beschriebene Regel hat das vorgesehene Muster, und die Ziel-ARN entspricht deiner Warteschlange. AWS View zeigt jetzt die Regel und ihr Warteschlangenziel. Es gibt weiterhin kein Ereignis zur Zustellung. Führe die Verbindungsprüfung aus.

Abgleich- und Zustellgrenzen nachweisen

Veröffentliche in diesem Schritt passende und unbeteiligte Ereignisse und teste dann einen Fehler der Quellberechtigung, ohne eine neue Warteschlangennachricht hinzuzufügen.

Ein EventBridge-Ereignis hat Routingfelder und eine detail-Nutzlast. Die API PutEvents akzeptiert Detail als JSON-codierte Zeichenfolge. Schreibe drei lesbare Einträge: eine aufgegebene Bestellung, ein Abrechnungsereignis und eine Stornierung. jq wandelt jedes Detail-Objekt in die von der API benötigte Zeichenfolge um.

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

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

Die Veröffentlichungsantwort meldet null fehlgeschlagene Einträge und eine Ereignis-ID für jeden angenommenen Eintrag. Nur route-order passt auf beide Felder, daher enthält die Warteschlange eine verfügbare Nachricht. AWS View zeigt ihren vollständigen Ereignisumschlag: Quelle, Detailtyp, Konto, Region und Detail.

Lies den tatsächlichen, für den Verbraucher sichtbaren Inhalt. Der Empfang verbirgt eine Nachricht normalerweise für ihre Sichtbarkeitsfrist; --visibility-timeout 0 macht sie nach dieser Untersuchung sofort wieder sichtbar. Die Abfrage gibt nur ihre ID und ihren Inhalt aus und hält die Empfangskennung aus der Anzeige heraus. Diese Untersuchung schließt keine Geschäftsverarbeitung ab und bestätigt die Nachricht nicht.

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

Der Inhalt hat detail.id gleich route-order und detail.quantity gleich 2. Die Abrechnungs- und Stornierungseinträge haben diese Warteschlange nicht erreicht.

Richte jetzt die Warteschlangenrichtlinie auf eine andere Quell-ARN, während Regel und Ziel aktiviert bleiben:

jq --arg wrong "${RULE_ARN}-other" '.Statement[0].Condition.ArnEquals["aws:SourceArn"]=$wrong' queue-policy.json > wrong-source-policy.json

Schreibe die Konfiguration in wrong-source-attributes.json:

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

Wende die Attribute auf die Warteschlange $QUEUE_URL an:

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

Schreibe die bereitgestellte Definition in event-inputs.json:

cat > event-inputs.json <<EOF
[
  {
    "EventBusName": "$BUS_NAME",
    "Source": "labex.orders",
    "DetailType": "OrderPlaced",
    "Detail": {
      "id": "denied-order",
      "quantity": 4
    }
  }
]
EOF

Schreibe die Konfiguration in denied-event.json:

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

Veröffentliche den bereitgestellten Ereignisstapel:

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

Prüfe die Attribute der Warteschlange $QUEUE_URL:

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

EventBridge nimmt dieses Ereignis an, aber der Regel fehlt die erforderliche Warteschlangenberechtigung. Die ursprüngliche Nachricht bleibt das einzige Ereignis in der Warteschlange; denied-order fehlt. Unterscheide bei der Diagnose einer Pipeline die Ereignisannahme von der Zielzustellung. Diese Übung untersucht keine Zustellwiederholungen.

Stelle die vorgesehene Berechtigung wieder her und untersuche erneut:

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

Lies die zugestellten Nachrichten aus der Warteschlange $QUEUE_URL:

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

Nur das ursprüngliche route-order ist vorhanden. Die korrigierte Richtlinie autorisiert nachfolgende Zustellungen; dieses Lab hängt nicht davon ab, dass ein früher verweigertes Ereignis erneut versucht wird. Führe die Routingprüfung aus.

Die Ereignispipeline entfernen

Entferne in diesem Schritt dein Ziel, deine Regel, deinen eigenen Bus und die temporäre Warteschlange und erhalte dabei unbeteiligte Ressourcen.

Entferne das Ziel, bevor du seine Regel löschst. Lösche dann den eigenen Bus und die Warteschlange. Das Löschen der Warteschlange verwirft das fiktive Ereignis, das zur Routinguntersuchung aufbewahrt wurde; für dieses wurde kein Geschäftsergebnis behauptet.

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 reine Leseabfragen belegen, was erhalten bleibt:

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-ev01-reference --query Items

Nur der Standardbus bleibt erhalten, seine Regelliste ist leer, Warteschlangen-URLs fehlen, und das Referenzelement enthält keep unchanged. Authentifizierungs- oder Netzwerkfehler belegen keine Löschung. AWS View zeigt die leeren Listen eigener Ressourcen und die erhaltene Referenz.

Entferne die gewöhnlichen Dateien, die du erstellt hast:

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

Führe die Bereinigungsprüfung aus, bevor du die VM beendest.

Zusammenfassung

Du hast einen eigenen EventBridge-Bus erstellt, Ereignisse zur Bestellaufgabe abgeglichen und ein Warteschlangenziel mit einer genauen Berechtigung für die Quellregel verbunden. Tatsächliche Warteschlangeninhalte zeigten, welche Ereignisse den Verbraucher erreichten, und der Test mit verweigerter Quelle trennte Ereignisannahme von Zustellung. Du hast eigene Ressourcen entfernt und dabei Standardbus und Referenzdaten erhalten.

Die nächste Einheit formt einen Ereignisumschlag in die kleinere Nutzlast um, die ein Warteschlangenverbraucher benötigt.

Weitere Informationen bietet die AWS-Dokumentation: Ereignismuster und Feldabgleich; Zielressourcenrichtlinien und Zustellberechtigungen.