Multi-Stack Integration on Microsoft Fabric

Overview#

Multi-stack integration is the pattern for combining Fabric with external databases, object stores, APIs, and applications while keeping OneLake as the governed analytical convergence point ^[S1]. Fabric provides several integration levers: shortcuts for zero-copy references, Mirroring for replicated operational databases, Data Factory for movement and orchestration, and API for GraphQL for application-facing access ^{[S2] [S3] [S4] [S5]}.

Fabric Jumpstart is relevant to this pattern because it publishes deployable Fabric scenarios that can include datasets, notebooks, pipelines, reports, and supporting assets; teams can use those accelerators as integration reference implementations before building a governed production version ^[S7].

Core concepts#

Shortcuts expose data from other OneLake locations or external storage as a reference rather than a copy ^[S2]. Mirroring continuously replicates supported external databases into OneLake for analytics ^[S3]. Data Factory pipelines and Copy activity handle scheduled movement and orchestration when a controlled load is the right model ^{[S4] [S6]}. API for GraphQL exposes selected Fabric data through a typed application API surface ^[S5].

The design decision is not which connector exists, but which integration contract is correct: reference, replicate, copy, transform, or serve ^{[S2] [S3] [S4] [S5]}.

Integration decision matrix#

How it works and best practices#

Use shortcuts when data should remain owned and governed at the source but queried from Fabric ^[S2]. Use Mirroring when an operational database should feed OneLake continuously for analytics ^[S3]. Use pipelines and Copy activity when batch movement, orchestration, retries, and load windows matter ^{[S4] [S6]}. Use GraphQL when the consumer is an application that needs a constrained API rather than broad workspace access ^[S5].

Treat Jumpstart deployments as reference implementations. The catalog can install complete examples into a workspace, but production integration still needs approved sources, workspace ownership, security review, and capacity planning ^{[S1] [S4] [S7]}.

# Evaluation workspace only: use a Jumpstart to inspect a reference pattern.
# The specific item name should be selected from the live catalog.
import jumpstart

jumpstart.list()
jumpstart.install("name", item_prefix="eval_")

Worked integration example#

A customer 360 architecture can reference partner files through shortcuts, mirror an operational CRM database into OneLake, use pipelines for nightly enrichment, and expose a narrow GraphQL endpoint to a support application ^{[S2] [S3] [S4] [S5]}.

# Application query shape: request the fields the support app needs.
# The endpoint/schema are designed in Fabric API for GraphQL; this is an illustrative client query.
query CustomerCaseContext($customerId: ID!) {
  customer(id: $customerId) {
    id
    name
    openCases {
      id
      severity
      status
    }
  }
}

Inference: the GraphQL query illustrates the constrained-consumer pattern; the sourced claim is that Fabric API for GraphQL exposes selected Fabric data through a GraphQL API surface ^[S5].

integration_contract:
  authoritative_sources:
    crm: mirrored_to_onelake
    partner_reference: shortcut_read_only
  orchestration:
    nightly_enrichment: data_factory_pipeline
  serving:
    support_app: graphql_api
    analysts: lakehouse_or_warehouse_query

Inference: this YAML is an architecture contract, not a Fabric deployment format. The individual integration paths are sourced to Mirroring, shortcuts, Data Factory, and GraphQL ^{[S2] [S3] [S4] [S5]}.

What goes wrong#

Copying every external dataset into Fabric by default creates duplicated ownership and refresh obligations. The better choice may be a shortcut or mirrored source depending on authority, freshness, and operational constraints ^{[S2] [S3]}. Exposing raw tables through an API without a designed contract can also leak internal data shape into application dependencies ^[S5].

Another failure mode is evaluating an accelerator and then promoting it unchanged. Jumpstart proves that a solution can deploy quickly into a workspace, but it does not prove the workspace's data ownership, API contract, capacity behavior, or governance fit for production ^{[S4] [S7]}.

Internals#

Architecture & design#

The integration architecture has separate paths for referenced data, replicated data, copied data, transformed data, and served application data ^{[S2] [S3] [S4] [S5]}. OneLake is the analytical convergence point where Fabric engines can reuse the resulting data ^[S1].

How it works internally#

Shortcut access resolves through configured identity and permission behavior, while Mirroring creates an analytical OneLake representation from supported source database changes ^{[S2] [S3]}. Copy activity uses parallel movement controls for scalable ingestion ^[S6].

Jumpstart installation is a Python-driven deployment flow backed by the fabric-jumpstart package and fabric-cicd, so an accelerator can deploy multiple Fabric item types as a coordinated workspace payload rather than as isolated manual setup steps ^[S7].

Performance characteristics#

Performance depends on the chosen path. Shortcuts avoid copy latency but depend on external access and caching behavior, Mirroring depends on replication freshness, Copy activity depends on parallelism and source/sink throughput, and GraphQL depends on endpoint query design ^{[S2] [S3] [S5] [S6]}.

Worked example: support application plus analytics#

1. Mirror CRM operational tables into OneLake so analytical workloads can read current customer state ^[S3].
2. Add a shortcut to partner reference data so Fabric consumers can query the data without owning another copy ^[S2].
3. Use a Data Factory pipeline for scheduled enrichment and exception handling ^[S4].
4. Publish a GraphQL endpoint for the support application and keep analyst access on Fabric-native query surfaces ^[S5].
5. Optionally install a Jumpstart in a sandbox to compare the team's design against a Microsoft-published deployable pattern before production build-out ^[S7].