Integration Platform¶

Integration-workloads verbinden Anwendungen, Services und Datenquellen: Sie tauschen Nachrichten aus, veröffentlichen APIs, verschieben Daten im Batch und führen Workflows aus. Die Integration Platform ist dafür eine optionale Lösung auf der Managed Cloud Platform (MCP). Sie bietet gemeinsame Integrationsservices (Service Bus, Event Hubs, API Management, eine Container Registry), fertige Terraform-Module für die Integrationsservices selbst (Logic Apps, Function Apps, Container Apps, Data Factory) und die Automatisierung, die sie sicher und konform verbindet. Integration builders konzentrieren sich auf die Integration; das Plattform-Team verantwortet die darunterliegenden Bausteine.

Optionales Angebot, Referenzdesign

Die Integration Platform ist nicht Teil des Core-MCP-hub-and-spoke. Welche Teile auf deiner Plattform verfügbar sind, welche Versionen laufen und welche Optionen aktiviert sind, hängt von deiner Plattform ab. Die Seiten in diesem Abschnitt beschreiben das Referenzdesign und die üblichen Standardwerte des Codes. Dein Deployment kann abweichen. Frag dein Plattform-Team. Vertragsdetails (support-Zeiten, Reaktions- und Lösungsziele, Gebühren) stehen in deiner Vereinbarung und nicht in dieser Dokumentation (Betriebsmodelle).

Für wen sie ist¶

Leser	Hier anfangen
Integration builder (Workload-Team)	Anfragen und Änderungen, Module, Service Bus
Integration platform engineer (Plattform-Team)	Architektur, Voraussetzungen, Service-Bus-Automatisierung, Betrieb
Architekt, Security Officer, Owner des Services	Servicebeschreibung, Architektur, Entscheidungen

„Plattform-Team“ bedeutet, wer auch immer die Plattform in deiner Situation betreibt: XMMS im Rahmen eines managed-service-Vertrags oder dein eigenes Team, wenn du die Plattform selbst betreibst (Betriebsmodelle). Die Integration Platform fügt daneben eine zweite Rolle hinzu, den integration platform engineer. Siehe Betriebsmodell.

Terminologie¶

Begriff	Bedeutung
Ingredient	Ein wiederverwendbares, konformes Infrastrukturpaket der Plattform. Drei Arten: Plattform-Services, Shared Services und Module.
Recipe	Ein standardisiertes Integrationsmuster, das Ingredients kombiniert, zum Beispiel ein API-getriggerter Workflow oder ein zeitgesteuerter Job.
Shared Service	Kostenintensive, häufig genutzte Integrationsinfrastruktur, die mehrere workloads bedient (Service Bus, Event Hubs, API Management, Azure Container Registry). Liegt in einem eigenen spoke und hat einen eigenen Lebenszyklus.
Modul	Ein Terraform-Modul, das einen Integrationsservice (Logic App, Function App, Container App, Data Factory) in einem Workload-spoke deployt, verbunden mit den Ressourcen des spokes.
Integration-workload	Ein workload, der integrationsspezifische Ressourcen enthält und die Plattform nutzt. Er besteht aus einem oder mehreren Integration-spokes.
Integration-spoke	Ein spoke der MCP, erweitert um spoke extensions, damit er die Shared Services nutzen kann.
Spoke extension	Code, der mit dem spoke-Deployment läuft und dem spoke Zugriff auf einen Shared Service gibt (Spoke extensions).
Control plane	Die Automatisierung, die den Inhalt eines Shared Service (zum Beispiel queues und topics) aus Konfigurationsdateien verwaltet.

Allgemeine MCP-Begriffe stehen im Glossar.

Was du bekommst¶

Bereich	Was die Plattform bietet	Seite
Servicebeschreibung	Ingredients, Security-Ausrichtung, Monitoring, Standardänderungen	Servicebeschreibung
Architektur	Layers, workloads, Umgebungen, Netzwerk, Identität, Resilienz	Architektur
Rollen	Integration platform engineer und integration builder, wer was verantwortet	Betriebsmodell
Anfragen	Standardänderungen und wie eine Änderung die Plattform erreicht	Anfragen und Änderungen
Module	Function App, Logic App, Container App und Data Factory in deinem spoke	Module, Integrationsressourcen deployen
Messaging	Queues, topics und subscriptions aus JSON-Dateien, mit Zugriff über Gruppen	Service Bus
Shared Services	API Management, Event Hubs, Container Registry	Shared Services
Resilienz	Availability Zones, Abhängigkeiten, zusammengesetzte Verfügbarkeit	Verfügbarkeit
Entscheidungen	Architekturentscheidungen, verdichtet	Entscheidungen

Umfang¶

Im Umfang	Nicht im Umfang
Shared Services für Messaging, Events, APIs und Container-Images und ihre Anbindung an Integration-spokes	Die Integrationen selbst (Logik, Mappings, Authentifizierungsmuster, Datentransformation). Wie, entscheiden die integration builders.
Terraform-Module für Logic Apps, Function Apps, Container Apps und Data Factory in einem Integration-spoke	Die Data Plane der deployten Ressourcen: Data-plane-Zugriff und seine Abstimmung mit deiner Identity Governance bleiben bei dir
Konfigurationsgesteuerte Verwaltung von Service-Bus-Entitäten und ihren Zugriffsgruppen	Netzwerkkonnektivität, Firewallregeln und der spoke selbst. Diese gehören zum MCP hub-and-spoke (Was du bekommst).
Monitoring und Alerts der Shared Services und Module	Alerts zu deiner eigenen Anwendungslogik
Private DNS und die DNS-Forwarding-Anforderungen für private endpoints	Backup von Anwendungsdaten (siehe Verfügbarkeit)

Wie sie zur Plattform passt¶

Die Integration Platform baut auf dem MCP hub-and-spoke auf. Jeder Shared Service liegt in einem spoke, jeder Integration- workload liegt in einem spoke, und der gesamte Traffic zwischen ihnen läuft über die hub-Firewall. Standardmäßig ist nichts verbunden.

flowchart LR
    subgraph mcp["MCP"]
        hub["Hub: firewall, DNS, connectivity"]
        canvas["Spoke canvas + spoke extensions"]
    end
    subgraph ip["Integration Platform"]
        ss["Shared services spoke<br/>Service Bus, Event Hubs, APIM, ACR"]
        cp["Control plane<br/>queue and topic configuration"]
        mods["Terraform modules"]
    end
    wl["Integration workload spokes<br/>Logic App, Function App,<br/>Container App, Data Factory"]
    canvas --> ss
    canvas --> wl
    cp -->|"configures"| ss
    mods -->|"deploy into"| wl
    wl -->|"uses via hub"| ss
    hub --- ss
    hub --- wl

Die generischen Shared Services und spoke extensions der MCP sind beschrieben in Shared Services (Sicht des workloads) und Spoke extensions (Sicht der Plattform). Die Seiten hier ergänzen, was für die Integration spezifisch ist.

Betriebsmodelle: Das Plattform-Team ist XMMS (Managed Service) oder dein eigenes Team (Eigenbetrieb)
Servicetypen: Core-, direkte und zusätzliche Services, Spoke-Varianten
Architekturreferenz: Schichten, Management Groups, Hub und Spokes
Nutzer: Was ein Workload-Team von der Plattform bekommt
Verantwortlichkeiten: Die generische Aufteilung zwischen Plattform-Team und Workload-Team