Ereignisse sollen einen anderen Dienst anstoßen? Event-Grid-Topic und Subscription erstellen

Wann nutzt du welchen Dienst? Nutze Service Bus für „Erledige diese Aufgabe zuverlässig“, etwa eine Bestellung mit Wiederholungsversuchen zu verarbeiten. Nutze Event Grid für „Das ist passiert – informiere interessierte Dienste“, etwa eine Function nach einem Datei-Upload auszulösen.

Eine Bestellung wurde erstellt und ein anderer Dienst soll reagieren. Event Grid leitet eine Benachrichtigung über das Ereignis an ein konfiguriertes Ziel weiter. Der Sender veröffentlicht einmal an einem Topic. Eine Event Subscription legt fest, wohin passende Ereignisse gelangen.

In diesem Lab ist das Ziel Azure Queue Storage. Das Ereignis in dieser Queue nachzuweisen zeigt die Zustellung an einen anderen Dienst. Es läuft keine Anwendung zur Bestellverarbeitung: Ein Worker oder eine Function könnte die Queue später auslesen. Du brauchst keine Service-Bus-Ressourcen, keine VM und keine lokale Installation.

Topic und Ziel erstellen

Verwende CloudTrips TEST und erstelle rg-cloudtrips-eventgrid-test-weu in West Europe. Suche im Azure-Portal nach Event Grid Topics → Create:

Name: egt-ctordersweu
Region: West Europe
Event schema / Input schema: Event Grid Schema

Erstelle ein benutzerdefiniertes Topic unter Event Grid Topics, kein Topic innerhalb eines Event Grid Namespace. Lass für dieses kleine Lab öffentlichen Netzwerkzugriff und lokale bzw. schlüsselbasierte Authentifizierung aktiviert. Ergänze bei einem bereits vergebenen Namen ein Suffix und verwende den tatsächlichen Namen im Sendebefehl unten.

Erstelle in derselben Ressourcengruppe ein Storage-Konto namens stcteventsweu mit Standard, LRS und dem Kontotyp General-purpose v2. Storage-Namen sind global eindeutig; passe deinen bei Bedarf an. Lass öffentlichen Netzwerkzugriff aktiviert und anonymen Blob-Zugriff deaktiviert.

Um Queue-Nachrichten mit deiner angemeldeten Identität zu erstellen und anzusehen, weise deinem Benutzer am Storage-Konto über Access control (IAM) die Rolle Storage Queue Data Contributor zu. Eine neue Zuweisung kann einige Minuten benötigen. Für dieses Lab brauchst du die Berechtigung zur Rollenzuweisung. Event-Grid-Operationen und Storage-Nutzung können Kosten verursachen.

Erstelle unter Data storage → Queues die Queue order-events.

Event Grid die Zustellung erlauben

Öffne egt-ctordersweu → Identity → System assigned, setze Status: On und speichere.

Weise am Storage-Konto → Access control (IAM) → Add role assignment der verwalteten Identität des Topics Storage Queue Data Message Sender zu. Wähle Managed identity und suche egt-ctordersweu unter Event Grid Topics. Damit darf Event Grid Nachrichten im Ziel ablegen. Das ist eine andere Berechtigung als dein eigener Queue-Zugriff.

Kehre zum Topic zurück → Overview → + Event Subscription:

Name: es-ctorders-to-queue
Event Schema: Event Grid Schema
Endpoint Type: Storage Queues
Endpoint: stcteventsweu / order-events
Managed Identity Type: System Assigned

Wähle über Select an endpoint dein tatsächliches Storage-Konto und die Queue aus. Aktiviere in den Endpunkteinstellungen die systemseitig zugewiesene Identität für die Zustellung. Behalte für diesen ersten Test die Standardfilter bei und erstelle die Event Subscription. Warte vor dem Senden auf die erfolgreiche Bereitstellung.

Screenshot 1: Event Subscription mit Event-Grid-Topic und Storage-Queue als Ziel.

Ein Bestellereignis veröffentlichen

Öffne Azure Cloud Shell → Bash. Eine Sitzung ohne Storage-Konto reicht aus. Führe den folgenden Block aus. Ändere topic_name, falls dein Topic anders heißt. Meldet die Kontoprüfung eine erforderliche Anmeldung, führe az login --use-device-code aus, schließe die angezeigten Anmeldeschritte ab und starte den Block erneut.

Der Python-Code nutzt integrierte Bibliotheken; pip-Pakete sind nicht nötig. Er ruft den Topic-Schlüssel über deine Azure-CLI-Anmeldung ab, ohne ihn auszugeben. Dein Lab-Owner-Konto darf diesen Schlüssel abrufen. Für die Veröffentlichung wird der Schlüssel verwendet; für die Zustellung an Storage die oben konfigurierte verwaltete Identität.

az account show --output table
az account set --subscription 'CloudTrips TEST'

python3 - <<'PYTHON'
import json
import subprocess
import uuid
from datetime import datetime, timezone
from urllib.request import Request, urlopen

resource_group = "rg-cloudtrips-eventgrid-test-weu"
topic_name = "egt-ctordersweu"

def az_value(*args):
    return subprocess.check_output(
        ["az", *args, "--output", "tsv"], text=True
    ).strip()

endpoint = az_value(
    "eventgrid", "topic", "show", "--resource-group", resource_group,
    "--name", topic_name, "--query", "endpoint"
)
key = az_value(
    "eventgrid", "topic", "key", "list", "--resource-group", resource_group,
    "--name", topic_name, "--query", "key1"
)
event = {
    "id": str(uuid.uuid4()),
    "eventType": "CloudTrips.OrderCreated",
    "subject": "orders/CT-5001",
    "eventTime": datetime.now(timezone.utc).isoformat(),
    "dataVersion": "1.0",
    "data": {"orderId": "CT-5001", "product": "Notebook", "quantity": 1}
}
request = Request(
    endpoint, data=json.dumps([event]).encode("utf-8"),
    headers={"Content-Type": "application/json", "aeg-sas-key": key},
    method="POST"
)
with urlopen(request, timeout=30) as response:
    print(f"Accepted: HTTP {response.status}; event ID: {event['id']}")
PYTHON

Erwarte Accepted: HTTP 200 und eine Ereignis-ID. Das bestätigt die Annahme durch Event Grid. Der nächste Schritt prüft die Zustellung.

Screenshot 2: Cloud Shell mit angenommenem Ereignis und dessen ID.

Zustellung an die Queue prüfen

Öffne dein Storage-Konto → Data storage → Queues → order-events und aktualisiere die Ansicht. Verwende Microsoft-Entra-Authentifizierung, falls das Portal eine Auswahl anbietet. Prüfe den Text der empfangenen Nachricht. Suche CloudTrips.OrderCreated, orders/CT-5001 und dieselbe Ereignis-ID wie in Cloud Shell. Falls die Ansicht Base64-Decodierung anbietet, aktiviere sie nur bei codiertem Text.

Screenshot 3: Nachricht in der Storage-Queue mit dem zugestellten Bestellereignis.

Das Topic hat die Benachrichtigung angenommen, die Event Subscription hat das Ziel festgelegt und Event Grid hat sie an Storage zugestellt. Event Subscription bezeichnet hier eine Routing-Konfiguration, nicht deine Azure-Abrechnungssubscription.

Ist die Queue nach kurzer Wartezeit leer, öffne am Topic Metrics und prüfe Matched Events, Delivery Succeeded Events und Delivery Failed Events für die letzte Stunde. Kontrolliere Ziel, Zustellidentität und deren Rolle Storage Queue Data Message Sender. Rollenübernahme und Wiederholungsversuche können die Zustellung verzögern. Eine erfolgreiche Veröffentlichung beweist noch nicht die Annahme durch das Ziel.

Event Grid kann ein Ereignis mehrfach zustellen und garantiert keine Zustellreihenfolge. Eine empfangende Anwendung sollte doppelte Ereignis-IDs erkennen. Fehlgeschlagene Zustellungen werden nur innerhalb konfigurierter Grenzen wiederholt. Dieses Lab richtet kein Dead-Letter-Ziel ein.

Abschluss

Behalte die Ressourcengruppe für den Event-Grid-Domain-Trip. Andernfalls lösche rg-cloudtrips-eventgrid-test-weu nach Abschluss. Das Löschen nur der Event Subscription beendet diese Route, lässt Topic und Storage-Ressourcen jedoch bestehen.