Abonnenten brauchen unterschiedliche Nachrichten? Service-Bus-Topic und Filter erstellen

Dein Shop verkauft Notizbücher und herunterladbare Anleitungen. Das Lager braucht physische Bestellungen, der Download-Dienst digitale. Sende beide an ein Topic. Jede Subscription nimmt dann die Nachrichten auf, die ihr Dienst benötigt.

Eine Queue verteilt Aufgaben auf konkurrierende Empfänger. Ein Topic gibt jeder passenden Subscription eine eigene Kopie. Das Bestätigen einer Nachricht in einer Subscription entfernt nicht die Kopie einer anderen. Subscription bedeutet hier ein Nachrichtenpostfach unter einem Topic, nicht deine Azure-Abrechnungssubscription.

Verwende sb-ctmessagingweu in rg-cloudtrips-servicebus-test-weu aus dem vorherigen Queue-Trip. Falls dein Namespace anders heißt, nutze deinen tatsächlichen Namen. Er muss Standard oder Premium verwenden. Behalte deine Rolle Azure Service Bus Data Owner und den Netzwerkzugriff für das Portal bei. Alle Schritte erfolgen im Azure-Portal; Anwendungscode ist nicht nötig.

Topic und Subscriptions erstellen

Öffne den Namespace → Entities → Topics → + Topic. Vergib den Namen order-events und behalte die übrigen Standardwerte bei.

Öffne order-events → Subscriptions → + Subscription und erstelle diese beiden Subscriptions. Sessions bleiben deaktiviert, die übrigen Einstellungen auf ihren Standardwerten:

Subscription	Vorgesehener Empfänger
warehouse	Verarbeitet physische Bestellungen
downloads	Liefert digitale Produkte aus

Erstelle beide Subscriptions und ihre Filter, bevor du Nachrichten sendest. Eine neue Subscription erhält keine Nachrichten, die vor ihrer Erstellung gesendet wurden.

Screenshot 1: Topic order-events mit warehouse und downloads unter Subscriptions.

Subscription-Filter festlegen

Öffne jede Subscription → Filters. Füge eine Filterregel mit SQL Filter und diesen Werten hinzu:

Subscription	Regelname	SQL-Ausdruck
warehouse	physical-orders	productType = 'physical'
downloads	digital-orders	productType = 'digital'

Speichere jede Regel und lösche anschließend die Regel $Default aus der jeweiligen Subscription. Prüfe vor dem Fortfahren, dass jeweils nur die gewünschte Regel übrig ist. Die Standardregel akzeptiert jede Nachricht. Eine zusätzliche einschränkende Regel begrenzt die Zustellung nicht, solange die Standardregel bestehen bleibt.

Der SQL-Ausdruck vergleicht eine Nachrichteneigenschaft. Eine SQL-Datenbank ist nicht nötig. Filter können den JSON-Inhalt nicht auswerten. Deshalb fügst du productType beim Senden separat als benutzerdefinierte Eigenschaft hinzu.

Screenshot 2: Filters-Seite der Subscription warehouse mit physical-orders und ihrem Ausdruck, ohne $Default.

Zwei unterschiedliche Bestellungen senden

Öffne order-events → Service Bus Explorer. Wähle bei Bedarf unter Settings die Authentifizierung Microsoft Entra ID. Wähle Send messages und Application/Json. Sende jede Nachricht einmal; wiederholtes Senden bleibt deaktiviert.

Trage für die erste Nachricht diesen Inhalt ein:

{
  "orderId": "CT-2001",
  "product": "Notebook"
}

Ergänze unter Custom Properties im Sendeformular:

Name / Key: productType
Type: String
Value: physical

Wähle Send. Ersetze für die zweite Nachricht den Inhalt durch:

{
  "orderId": "CT-2002",
  "product": "Downloadable guide"
}

Ändere den Wert der benutzerdefinierten Eigenschaft auf digital. Name productType und Typ String bleiben gleich. Sende einmal. Gib die Eigenschaftswerte ohne Anführungszeichen ein; diese gehören nur in die SQL-Ausdrücke.

Der Sender wählt das Topic. Er adressiert warehouse oder downloads nicht direkt.

Verteilung prüfen

Wähle im Service Bus Explorer des Topics Peek Mode, dann die Subscription warehouse und Peek from start. Prüfe den Inhalt. Wiederhole dies mit ausgewählter Subscription downloads.

Subscription	Erwartete Nachricht	Nachricht, die fehlen soll
warehouse	CT-2001 — Notebook	CT-2002
downloads	CT-2002 — Downloadable guide	CT-2001

Bei neuen Subscriptions und einmaligem Senden jeder Nachricht hat jede Subscription eine aktive Nachricht. Peek lässt sie im Postfach. Aktualisiere die Subscription-Liste des Topics, falls ihre Zähler noch nicht aktualisiert wurden.

Screenshot 3: Im Explorer ausgewählte Subscription downloads mit ausschließlich CT-2002 und ihrem Inhalt.

Erhalten beide Subscriptions beide Bestellungen, prüfe, ob noch eine $Default-Regel existiert. Erhält keine die Bestellung, kontrolliere Name, String-Typ und exakten Wert der benutzerdefinierten Eigenschaft. productType nur im JSON-Inhalt einzutragen reicht nicht. Sende nach einer Filterkorrektur eine neue Testnachricht: Eine Regeländerung entfernt keine zuvor angenommenen Nachrichten und stellt keine Nachrichten wieder her, zu denen keine Subscription passte.

Abschluss

Jeder Empfänger besitzt jetzt ein eigenes gefiltertes Postfach. Filter dürfen sich auch überschneiden: Passen zwei Subscriptions zur selben Nachricht, erhalten beide eine Kopie.

Empfange zum Leeren der Subscriptions jede Nachricht mit PeekLock und wähle Complete, wie im Queue-Trip. Behalte den Namespace für spätere Messaging-Trips. Lösche order-events, um dieses Topic samt Subscriptions zu entfernen, oder lösche die Lab-Ressourcengruppe nach Abschluss aller Messaging-Übungen. Für den Standard-Namespace fallen auch im leeren Zustand weiterhin Grundgebühren an.