Skip to content

Integration Platform

Integration workloads connect applications, services and data sources: they exchange messages, publish APIs, move data in batches and run workflows. The Integration Platform is an optional solution on top of the Managed Cloud Platform (MCP) for exactly this. It offers shared integration services (Service Bus, Event Hubs, API Management, a container registry), ready-made Terraform modules for the integration services themselves (Logic Apps, Function Apps, Container Apps, Data Factory), and the automation that connects them in a secure and compliant way. Integration builders focus on the integration; the platform team owns the underlying building blocks.

Optional offering, reference design

The Integration Platform is not part of the core MCP hub and spoke. Which parts are available on your platform, which versions run, and which options are enabled depends on your platform. The pages in this section describe the reference design and the usual defaults of the code. Your deployment may differ. Ask your platform team. Contract details (support hours, response and resolution targets, fees) are in your agreement and not in this documentation (Operating models).

Who it is for

Reader Start here
Integration builder (workload team) Request and change, Modules, Service Bus
Integration platform engineer (platform team) Architecture, Prerequisites, Service Bus automation, Operations
Architect, security officer, owner of the service Service description, Architecture, Decisions

"Platform team" means whoever runs the platform in your situation: XMMS under a managed-service contract, or your own team when you manage the platform yourself (Operating models). The Integration Platform adds a second role next to it, the integration platform engineer. See Operating model.

Terminology

Term Meaning
Ingredient A reusable, compliant infrastructure package of the platform. Three kinds: platform services, shared services and modules.
Recipe A standardised integration pattern that combines ingredients, for example an API-triggered workflow or a time-triggered job.
Shared service Costly, commonly used integration infrastructure that serves several workloads (Service Bus, Event Hubs, API Management, Azure Container Registry). Lives in its own spoke and has its own lifecycle.
Module A Terraform module that deploys one integration service (Logic App, Function App, Container App, Data Factory) in a workload spoke, connected to the spoke's resources.
Integration workload A workload that contains integration-specific resources and uses the platform. It consists of one or more integration spokes.
Integration spoke A spoke of the MCP, extended with spoke extensions so that it can use the shared services.
Spoke extension Code that runs with the spoke deployment and gives the spoke access to a shared service (Spoke extensions).
Control plane The automation that manages the content of a shared service (for example queues and topics) from configuration files.

General MCP terms are in the glossary.

What you get

Area What the platform offers Page
Service description Ingredients, security alignment, monitoring, standard changes Service description
Architecture Layers, workloads, environments, networking, identity, resilience Architecture
Roles Integration platform engineer and integration builder, who owns what Operating model
Requests Standard changes and how a change reaches the platform Request and change
Modules Function App, Logic App, Container App and Data Factory in your spoke Modules, Deploy integration resources
Messaging Queues, topics and subscriptions from JSON files, with access through groups Service Bus
Shared services API Management, Event Hubs, container registry Shared services
Resilience Availability zones, dependencies, composite availability Availability
Decisions Architecture decisions, condensed Decisions

Scope

In scope Out of scope
Shared services for messaging, events, APIs and container images, and their connection to integration spokes The integrations themselves (logic, mappings, authentication patterns, data transformation). Integration builders decide how.
Terraform modules for Logic Apps, Function Apps, Container Apps and Data Factory in an integration spoke The data plane of the deployed resources: data-plane access and its alignment with your identity governance stay with you
Configuration-driven management of Service Bus entities and their access groups Network connectivity, firewall rules and the spoke itself. Those are MCP hub and spoke (What you get).
Monitoring and alerts of the shared services and modules Alerts about your own application logic
Private DNS and the DNS forwarding requirements for private endpoints Backup of application data (see Availability)

How it relates to the platform

The Integration Platform is built on the MCP hub and spoke. Every shared service lives in a spoke, every integration workload lives in a spoke, and all traffic between them passes the hub firewall. Nothing is connected by default.

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

The generic shared services and spoke extensions of the MCP are described in Shared services (workload view) and Spoke extensions (platform view). The pages here add what is specific to integration.