App braucht zuverlässiges Messaging? Eine Service-Bus-Queue erstellen

Ein Onlineshop nimmt eine Bestellung an, aber sein Versanddienst ist vorübergehend nicht erreichbar. Ein direkter Aufruf würde die Bestellung von dessen Verfügbarkeit abhängig machen. Mit Azure Service Bus sendet der Shop eine Nachricht an eine Queue. Der Versanddienst verarbeitet sie, sobald er wieder bereit ist und bevor die Nachricht abläuft.

Ein Namespace enthält Messaging-Ressourcen. Eine Queue hält Nachrichten zur Verarbeitung bereit. Der Sender fügt Aufgaben hinzu; der Empfänger verarbeitet sie. In diesem Lab übernimmst du beide Rollen im Portal. Du brauchst keine Anwendung, kein SDK und keine Installation.

Namespace und Queue erstellen

Suche im Azure-Portal nach Service Bus, wähle Create und trage ein:

Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-servicebus-test-weu
Namespace name: sb-ctmessagingweu
Region: West Europe
Pricing tier: Standard

Der Namespace-Name muss global eindeutig sein. Ergänze bei Bedarf ein Suffix und verwende diesen Namen durchgehend. Wähle Standard, damit du diesen Namespace in den späteren Trips zu Topics, Subscriptions und Sessions wiederverwenden kannst. Basic würde für diese Queue-Übung allein ausreichen. Bei Standard fallen eine Grundgebühr und nutzungsabhängige Kosten an. Prüfe die Kostenschätzung vor dem Erstellen.

Lass den öffentlichen Netzwerkzugriff für dieses Portal-Lab aktiviert. Wähle Review + create → Create. Öffne nach der Bereitstellung den Namespace und dann Entities → Queues → + Queue. Vergib den Namen orders und behalte die übrigen Standardwerte bei. Sessions bleiben deaktiviert.

Screenshot 1: Übersicht der Queue orders mit ihrem Namespace und leerer Queue.

Messaging-Zugriff zuweisen

Öffne am Namespace Access control (IAM) → Add role assignment. Weise deinem angemeldeten Benutzer Azure Service Bus Data Owner für diesen Namespace zu. Dafür brauchst du die Berechtigung zur Rollenzuweisung, beispielsweise als uneingeschränkter Owner deiner Lab-Subscription.

Azure-Ressourcen-Owner und Service Bus Data Owner erfüllen unterschiedliche Aufgaben: Ressourcenverwaltung gewährt nicht automatisch Nachrichtenzugriff über Microsoft Entra ID. Die Datenrolle erlaubt dem Lab-Benutzer das Senden und Empfangen. Für echte Anwendungen gibt es die engeren Rollen Data Sender und Data Receiver.

Öffne orders → Service Bus Explorer → Settings, wähle Microsoft Entra ID und speichere. Falls der Zugriff direkt nach der Zuweisung abgelehnt wird, warte einige Minuten auf die Übernahme der Rolle und öffne Explorer erneut.

Bestellung senden und ansehen

Wähle Send messages, stelle Application/Json ein und füge ein:

{
  "orderId": "CT-1001",
  "product": "Notebook",
  "quantity": 1
}

Sende einmal; wiederholtes Senden bleibt deaktiviert. Wechsle zu Peek Mode → Peek from start und wähle die Nachricht aus, um ihren Inhalt anzusehen.

Peek ist eine Vorschau: Die Bestellung bleibt für einen Empfänger verfügbar. Das JSON beschreibt nur die Aufgabe. Service Bus versendet die Bestellung nicht selbst und führt keine Geschäftslogik aus.

Screenshot 2: Service Bus Explorer mit der eingereihten Bestellung und ihrem JSON-Inhalt.

Empfangen und bestätigen

Wechsle zu Receive Mode → Receive messages. Wähle PeekLock, fordere 1 Nachricht an und empfange sie. Markiere die empfangene Zeile und wähle Complete, solange ihre Sperre noch gültig ist. Im Lab steht Complete für die Bestätigung des Workers, dass er die Bestellung verarbeitet hat.

Aktion	Was mit der Nachricht passiert
Peek	Zeigt sie an, ohne sie zu reservieren oder zu entfernen.
Empfangen mit PeekLock	Reserviert sie vorübergehend für diesen Empfänger.
Complete	Bestätigt die erfolgreiche Verarbeitung und entfernt sie.
Abandon lock oder Ablauf der Sperre	Ermöglicht einen weiteren Zustellversuch. Wiederholte Fehler können sie schließlich in die Dead-Letter-Queue verschieben.

Verwende hier nicht ReceiveAndDelete: Dabei verschwindet die Nachricht schon beim Empfang, bevor ein Worker die erfolgreiche Verarbeitung bestätigen kann. Mit PeekLock kann die Arbeit nach einem Worker-Ausfall erneut zugestellt werden. Empfänger müssen trotzdem mit mehrfachen Zustellungen umgehen, etwa indem sie prüfen, ob Bestellung CT-1001 bereits verarbeitet wurde.

Meldet Complete eine abgelaufene Sperre, empfange die Nachricht erneut und bestätige sie zügig. Prüfe anschließend mit Peek Mode → Peek from start, dass keine Nachricht mehr vorhanden ist. Aktualisiere die Queue-Übersicht; die Anzahl unter Active messages kann sich etwas verzögert ändern.

Screenshot 3: Queue orders nach der Bestätigung mit null aktiven Nachrichten.

Abschluss

Du hast eine Aufgabe unabhängig vom Empfänger gesendet, ohne Entfernen angesehen und anschließend ihre erfolgreiche Verarbeitung bestätigt. Behalte den Namespace für die nächsten Messaging-Trips oder lösche rg-cloudtrips-servicebus-test-weu nach Abschluss, um laufende Namespace-Kosten zu beenden.