Service Bus: Queues, Topics und Zugriff

Die Integration Platform bietet Azure Service Bus als gemeinsamen Messaging-Service. Du legst keinen eigenen Namespace an. Du beschreibst die queues, topics und subscriptions, die dein workload braucht, in JSON-Dateien, öffnest einen pull request, und die Plattform legt sie an, ebenso die Entra-ID-Gruppen, die steuern, wer senden und empfangen darf. Diese Seite richtet sich an Workload-Teams. Für Operatoren: siehe Service-Bus-Automatisierung (Plattformseite).

Optionales Angebot, pro Plattform festgelegt

Ob der Shared Service Service Bus verfügbar ist, in welchen Umgebungen und mit welchen Optionen, hängt von deiner Plattform ab. Namen, Standardwerte und Gruppenmuster auf dieser Seite sind die üblichen Werte des Referenzdesigns. Frag dein Plattform-Team.

So funktioniert es

Drei Schichten arbeiten zusammen (ADR-012):

Schicht	Was sie tut	Wer sie betreibt
Shared Service	Der Service-Bus-Namespace (Premium) und sein Netzwerk. Keine Entitäten.	Plattform-Team
Spoke extension	Gibt deinem spoke die Rechte, die er auf dem Namespace braucht, wenn der spoke deployt wird (Spoke extensions)	Plattform-Team, mit dem spoke-Deployment
Service-Bus-Automatisierung	Legt deine queues, topics und subscriptions aus JSON-Dateien an, und die Zugriffsgruppen pro Entität	Integration platform engineers, aus deinen pull requests

flowchart LR
    json["queues.json, topics.json,<br/>workload.json<br/>(your pull request)"] --> auto["Service Bus automation"]
    auto -->|"creates"| ent["Queues, topics,<br/>subscriptions"]
    auto -->|"creates"| grp["Entra ID groups<br/>per entity and role"]
    grp -->|"role assignment"| ent
    you["Your team"] -->|"adds managed identities<br/>to the groups"| grp
    app["Logic App, Function App,<br/>Container App"] -->|"Entra ID, private endpoint"| ent

Der Namespace ist nur über einen private endpoint erreichbar. Verbinde dich mit Entra ID, nicht mit Connection Strings oder Keys.

Queues definieren

Lege irgendwo unter deinem Konfigurationsordner eine Datei an, die genau queues.json heißt. Eine Datei enthält ein queue-Objekt oder eine Liste von queue-Objekten. Behalte den Dateinamen: Die Automatisierung sammelt jede queues.json (und topics.json) im Ordner und allen Unterordnern, du kannst Ordner also pro workload, Domäne oder Umgebung organisieren. Doppelte Definitionen derselben queue in verschiedenen Ordnern sind zu vermeiden.

{
  "workload": "orders",
  "name": "intake",
  "max_delivery_count": 10
}

Feld	Pflicht	Standard	Bedeutung
workload	ja		Der workload, dem die queue gehört. Muss zu einer Workload-Definition passen (siehe unten).
name	ja		Name der queue. Die queue in Azure heißt sbq-<workload>-<name>.
max_delivery_count	nein	10	Zustellversuche, bevor eine Nachricht in die Dead-Letter-Queue geht
lock_duration	nein	PT1M	Sperrzeit, während ein Receiver eine Nachricht verarbeitet (ISO-8601-Dauer)
max_size_in_megabytes	nein	1024	Größe der queue
requires_session	nein	false	Session-fähige queue
requires_duplicate_detection	nein	false	Duplicate Detection, mit duplicate_detection_history_time_window (Standard PT10M)
dead_lettering_on_message_expiration	nein	false	Abgelaufene Nachrichten in die Dead-Letter-Queue verschieben
forward_dead_lettered_messages_to	nein	keiner	Dead-Letter-Nachrichten an eine andere Entität weiterleiten
default_message_ttl, auto_delete_on_idle, max_message_size_in_kilobytes, partitioning_enabled, express_enabled, batched_operations_enabled, status	nein	siehe Modul	Weitere Service-Bus-Eigenschaften, durchgereicht

Topics, subscriptions und rules definieren

Ein topic gehört dem workload, der veröffentlicht. Jede subscription nennt den workload, der konsumiert.

{
  "workload": "orders",
  "name": "order-created",
  "subscriptions": [
    {
      "workload": "billing",
      "name": "billing",
      "rules": [
        {
          "name": "only-eu",
          "filter_type": "SqlFilter",
          "sql_filter": "region = 'EU'"
        }
      ]
    }
  ]
}

Feld	Hinweise
Topic-Felder	workload, name, support_ordering (Standard false), requires_duplicate_detection, max_size_in_megabytes (Standard 1024) und dieselben durchgereichten Eigenschaften wie bei queues
Subscription-Felder	workload, name, max_delivery_count (Standard 10), dead_lettering_on_filter_evaluation_error (Standard true), lock_duration (Standard PT1M), requires_session und mehr
Rules	name und filter_type. SqlFilter nimmt sql_filter. CorrelationFilter nimmt ein correlation_filter-Objekt (correlation_id, label, message_id, to, reply_to, session_id, content_type, properties). Eine optionale action.

Namen in Azure: topic sbt-<workload>-<name>, subscription sbts-<subscription workload>-<subscription name>.

Eine queue pro subscription (Standard)

Für jede subscription legt die Automatisierung außerdem eine queue mit dem Namen sbq-<subscription workload>-<topic name>-<subscription name> an und leitet die subscription dorthin weiter. Du hörst auf diese queue, nicht auf die subscription. Das ist ADR-008. Es gibt dir:

• Dead-Lettering auf einer queue, die nur deinem workload gehört;
• einen Retry einer fehlgeschlagenen Nachricht, ohne sie erneut an das topic zu senden, sodass andere Subscriber sie nicht doppelt erhalten;
• ein einfacheres Modell: Du musst nur wissen, wie man aus einer queue liest.

Die queue erbt ihre Größen- und Duplicate-Detection-Einstellungen vom topic. Das Verhalten ist ein Schalter der Automatisierung (auto_generate_queue_for_topic_subscription, Standard true). Hat das Plattform-Team ihn ausgeschaltet, lesen Receiver stattdessen aus der subscription.

Den workload definieren

Jeder workload, der in einer Datei auftaucht, braucht eine Workload-Definition (workload.json) mit dem Namen und den Identitäten seines spokes, damit die Automatisierung weiß, wessen Service Principal und Gruppen sie verwenden soll. Frag dein Plattform-Team, wer diese Datei pflegt und wo sie liegt. Die Felder, die die Automatisierung liest, sind name, service_principal_object_id, owner_group_id, contributor_group_id und reader_group_id. Wird ein workload in einer queue oder einem topic verwendet, hat aber keine Definition, schlägt der plan fehl.

Wer was darf: Gruppen

Für jede Entität legt die Automatisierung Entra-ID-Gruppen in der Administrative Unit der Plattform an. Dein Team ist Owner der Gruppen (über den Service Principal deines spokes) und verwaltet die Mitgliedschaft.

Gruppe	Angelegt für	Rolle, die sie bekommt	Mitglieder bei der Erstellung
Sender-Gruppe	Jede queue und jedes topic	Azure Service Bus Data Sender auf dieser Entität	Leer. Du fügst managed identities und Service Principals hinzu.
Receiver-Gruppe	Jede queue und jede subscription, die nicht an eine queue weitergeleitet wird	Azure Service Bus Data Receiver auf dieser Entität	Leer. Du fügst Identitäten hinzu.
Operators-Gruppe	Einmal pro workload	Sender- und Receiver-Rechte auf jeder Entität des workloads, für Support-Aktionen wie das manuelle erneute Senden einer fehlgeschlagenen Nachricht	Die Owners- und Contributors-Gruppen deines Workload-spokes

Die Namen folgen einem Muster, das das Plattform-Team festlegt, mit {workload} und {entity} als Platzhaltern. Das Referenz- muster ist integration-workload-{workload}-{entity}-sender und ...-receiver, wobei die Entität der Azure-Name der queue oder des topics ist, zum Beispiel sbq-orders-intake. Frag dein Plattform-Team nach dem Muster deiner Plattform.

Die Readers-Gruppe deines spokes wird außerdem der schreibgeschützten Gruppe der Plattform für den Namespace hinzugefügt, damit Reader den Namespace im Portal sehen können.

Einer Anwendung Zugriff geben

1. Finde die Gruppe für Entität und Rolle (zum Beispiel die Sender-Gruppe von sbq-orders-intake). Dein Plattform-Team kann dir die Objekt-IDs geben (die Automatisierung gibt sie pro workload aus).
2. Füge die managed identity deiner Logic App, Function App oder Container App in Microsoft Entra ID zur Gruppe hinzu.
3. Warte ein paar Minuten. Eine Gruppenänderung braucht kurz, bis sie am Namespace wirkt.
4. Verbinde dich mit dem Hostnamen des Namespaces (<namespace>.servicebus.windows.net) und Entra-ID-Authentifizierung.

Dafür brauchst du keinen pull request. Das ist der Sinn des Gruppenmodells (ADR-005). Du brauchst aber eine Firewallregel, wenn der Sender außerhalb deines spokes liegt oder der Traffic nicht bereits erlaubt ist (Firewallregeln und IP groups).

Füge Identitäten nicht im Portal zu den Entitätsrollen hinzu

Gib Zugriff über die Gruppen. Eine Rollenzuweisung, die jemand direkt auf einer queue hinzufügt, ist nicht Teil des Codes, und das nächste Deployment kann sie entfernen oder einen Zustand hinterlassen, den niemand prüfen kann.

Entitäten ändern oder entfernen

Ändere das JSON und öffne einen pull request. Lies den plan des pull requests, um zu sehen, was passiert.

• Die meisten Eigenschaften ändern sich direkt.
• Das Entfernen einer queue, eines topics oder einer subscription entfernt auch ihre Gruppen und löscht die Nachrichten darin.
• Eine Namensänderung legt eine neue Entität an und entfernt die alte.
• Partitionierung eines laufenden Namespaces ist eine Änderung mit Auswirkung auf Daten. Frag zuerst das Plattform-Team.

Wie aus dem pull request eine Änderung wird: Anfragen und Änderungen.

Betriebshinweise für Workload-Teams

Thema	Was du wissen solltest
Verfügbarkeit	Der Premium-Namespace ist standardmäßig zonenredundant. Geo-Disaster-Recovery ist eine optionale Maßnahme der Plattform (Verfügbarkeit).
Durchsatz	Messaging Units skaliert das Plattform-Team manuell. Das Skalieren kann Verbindungen kurz zurücksetzen, also implementiere einen Retry in deinem Client.
Dead Letters	Beobachte das Wachstum der Dead Letters auf deinen queues. Alerting auf dem Namespace liegt bei der Plattform. Alerts zu deiner Anwendung liegen bei dir.
Gemeinsame Nutzung	Mehrere workloads teilen sich einen Namespace. Gruppen auf Entitätsebene halten sie getrennt: Deine Gruppe gibt keinen Zugriff auf die queue eines anderen workloads.

Verwandt

• Anfragen und Änderungen
• Service-Bus-Automatisierung (Plattformseite)
• Entscheidungen
• Shared Services