Dynamics 365 Business Central an den Shop anbinden

Business Central wird in vielen Unternehmen als zentrales System für Stammdaten, Lagerbestände und Auftragsabwicklung geführt. Der Shop wiederum ist der Vertriebskanal, der rund um die Uhr verfügbar sein muss. Ohne Integration entstehen zwei getrennte Datenbestände, die im Tagesgeschäft auseinanderlaufen: Der Shop zeigt veraltete Preise, Bestellungen müssen manuell ins ERP getippt werden, und Bestandsdifferenzen führen zu Überverkäufen. Eine Untersuchung von McKinsey zeigt, dass automatisierte End-to-End-Prozesse die Durchlaufzeit von der Bestellung bis zur Auftragsanlage deutlich senken (McKinsey, 2024).

Business Central bringt für die Integration gute Voraussetzungen mit. Die Plattform stellt standardisierte Web-Services bereit, die über das OData-Protokoll und eine moderne, AL-basierte API erreichbar sind. Das bedeutet: Es ist kein proprietärer Konnektor nötig, der bei jedem Update bricht. Stattdessen kommuniziert eine Middleware mit dokumentierten REST-Endpunkten, die Microsoft versioniert und langfristig pflegt (Microsoft Learn, 2025). Genau das macht die Anbindung robust und wartbar -- ein Aspekt, der bei der Wahl der Integrationsarchitektur oft unterschätzt wird.

Business Central stellt seine Daten über mehrere Schnittstellen-Varianten bereit, die sich in Komfort und Flexibilität unterscheiden. Für eine Shop-Anbindung sind vor allem zwei relevant: die generische OData-Schicht und die kuratierte AL-basierte API. Beide sprechen REST und liefern JSON, unterscheiden sich aber im Aufbau und in der Stabilität der Verträge.

Die OData-Endpunkte werden aus veröffentlichten Pages und Queries erzeugt. Sie sind sehr flexibel, weil sich praktisch jede Tabelle als Web-Service freigeben lässt -- inklusive Filter, Sortierung und $expand für verknüpfte Datensätze. Der Nachteil: Die Struktur hängt an der jeweiligen Page-Definition und kann sich bei Anpassungen ändern. Die AL-basierte API hingegen stellt ein stabiles, von Microsoft definiertes Schema bereit (z. B. items, customers, salesOrders) und ist für Integrationen die empfohlene Wahl, weil die Verträge versioniert sind (Microsoft Learn, 2025). Für Spezialfälle lassen sich zudem eigene API-Pages in AL definieren, die genau die Felder liefern, die die Schnittstelle benötigt.

Die Authentifizierung ist der erste Stolperstein vieler Business-Central-Anbindungen. Früher liessen sich die Web-Services per Basic-Authentifizierung mit Benutzername und Web-Service-Access-Key ansprechen. Microsoft hat diesen Weg für die Online-Variante zurückgebaut und setzt auf OAuth2 über Microsoft Entra ID (vormals Azure AD). Für Server-zu-Server-Integrationen ohne interaktiven Benutzer ist der Client-Credentials-Flow der richtige Weg (Microsoft Learn, 2025).

Der Ablauf in Kurzform: In Microsoft Entra ID wird eine App-Registrierung angelegt, die ein Client-Secret oder Zertifikat erhält. Dieser App werden die nötigen Berechtigungen für Business Central erteilt und in der Umgebung als Entra-Anwendung mit passenden Berechtigungssätzen registriert. Die Middleware fordert mit Client-ID und Secret ein Bearer-Token an und sendet dieses im Authorization-Header jeder API-Anfrage. Tokens sind kurzlebig, daher hält die Middleware das aktuelle Token in einem Cache vor und erneuert es rechtzeitig vor Ablauf.

Sicherheitsseitig gilt: Client-Secrets gehören nicht in den Quellcode, sondern in einen geschützten Secret-Store, und ein Zertifikat ist einem Secret vorzuziehen. Die erteilten Berechtigungen sollten nach dem Prinzip der minimalen Rechte vergeben werden -- die Integration braucht in der Regel Zugriff auf Artikel, Preise, Bestände, Kunden und Aufträge, aber nicht auf das gesamte Mandanten-Setup. So bleiben die Datenflüsse DSGVO-konform und nachvollziehbar.

In den meisten Szenarien ist Business Central das führende System für Artikelstammdaten und Preise, der Shop ist führend für redaktionelle Inhalte wie Beschreibungen, Bilder, SEO-Texte und Kategoriezuordnungen. Diese Datenhoheit muss vor Projektstart pro Entität festgelegt und dokumentiert werden, sonst überschreiben sich beide Systeme gegenseitig. Laut einer Analyse von Forrester scheitern viele Integrationsvorhaben weniger an der Technik als an unklaren Verantwortlichkeiten für Datenfelder (Forrester, 2025).

Bei den Artikeln werden Felder wie Nummer, Beschreibung, Basismengeneinheit, Gewicht, Steuerkennzeichen und Sperrkennzeichen übertragen. Wichtig ist die saubere Behandlung von Varianten: Business Central kennt Item Variants, während Shopsysteme Varianten über Eigenschaftsgruppen abbilden. Die Middleware muss diese Struktur übersetzen und einen Stammartikel mit konfigurierbaren Varianten erzeugen. Damit nicht bei jedem Lauf der komplette Katalog gelesen wird, filtert die Synchronisation über das Feld systemModifiedAt und holt nur Datensätze, die sich seit dem letzten Lauf geändert haben.

Die Preissynchronisation gehört zu den anspruchsvollsten Teilen. Business Central kennt Verkaufspreislisten (Sales Price Lists), Rabattgruppen und kundenindividuelle Konditionen, die nach Kundengruppe, Menge, Währung und Zeitraum differenziert sein können. Diese Logik muss in das Preismodell des Shops übersetzt werden -- typischerweise über Kundengruppen und Preisregeln mit Staffeln. Da kundenindividuelle Preise im B2B die Regel sind, ist eine verlässliche Preissynchronisation geschäftskritisch. Mehr Tiefe dazu finden Sie im Beitrag zu Webhooks versus Polling, der die Frage beleuchtet, wann ein Push-Mechanismus sinnvoller ist als regelmäßiges Abfragen.

Bestände sind die zeitkritischste Größe der Integration. Jede Lagerbewegung -- Wareneingang, Warenausgang, Umlagerung, Inventurkorrektur -- verändert die Verfügbarkeit, und ein verspätetes Update führt schnell zu Überverkäufen. Eine Untersuchung der Aberdeen Group zeigt, dass aktuelle Bestandsdaten die Quote von Überverkäufen deutlich senken (Aberdeen Group, 2024). Im B2B kommt hinzu, dass Kunden verlässliche Verfügbarkeitsaussagen erwarten, weil sie ihre eigene Disposition daran ausrichten.

Business Central unterscheidet zwischen dem reinen Lagerbestand (Quantity on Hand) und der tatsächlichen Verfügbarkeit, die reservierte Mengen und offene Aufträge berücksichtigt. Für den Shop ist meist die berechnete Verfügbarkeit die relevantere Größe, nicht der nackte Lagerbestand. Bei mehreren Lagerstandorten (Locations) muss zudem definiert werden, wie konsolidiert wird: als Summe aller Standorte, als Bestand eines bestimmten Versandlagers oder regionsspezifisch. Dieses Thema vertiefen wir auch im Hinblick auf Multi-Warehouse-Szenarien gemeinsam mit dem Fachbereich.

Bewährt hat sich eine Kombination aus zwei Mechanismen: ein häufiger Delta-Sync der Bestände alle zwei bis fünf Minuten sowie -- wo verfügbar -- ein ereignisgesteuerter Push aus Business Central. Da die OData-Schicht selbst keine Webhooks für beliebige Tabellen bietet, wird der Push häufig über eine kleine AL-Erweiterung realisiert, die bei relevanten Buchungen einen HTTP-Aufruf an die Middleware sendet. Der periodische Delta-Sync bleibt als Sicherheitsnetz aktiv, damit keine Änderung verloren geht.

Bei Bestellungen kehrt sich der Datenfluss um: Der Shop ist die Quelle, Business Central das Ziel. Sobald ein Kunde im Shop bestellt, soll ein Sales Order in Business Central entstehen -- vollständig, korrekt und zeitnah. Die Middleware übersetzt dabei den Warenkorb in einen Auftrag: Shop-Artikelnummern werden auf Business-Central-Items gemappt, der Kunde auf einen Geschäftspartner referenziert und Zahlungs- sowie Versandbedingungen zugeordnet.

Im B2B kommen Zusatzanforderungen hinzu: Bestellreferenznummern des Kunden, Kostenstellen, abweichende Lieferadressen und mehrstufige Freigaben. Die AL-API bietet hierfür die Entitäten salesOrders und salesOrderLines, mit denen sich Kopf- und Positionsdaten in einem strukturierten Vorgang anlegen lassen. Entscheidend ist, dass die Middleware jeden Auftrag vor der Übergabe validiert -- fehlende Pflichtfelder, ungültige Artikelnummern oder gesperrte Kunden werden abgefangen, bevor ein unvollständiger Beleg im ERP landet.

Bei wachsenden Katalogen und steigendem Bestellvolumen wird die Performance zur kritischen Größe. Ein Händler mit zehntausenden Artikeln und vielen Preislisten erzeugt ein erhebliches Datenvolumen, das die Middleware effizient verarbeiten muss, ohne die Business-Central-Umgebung zu überlasten. Microsoft setzt für die APIs Drosselungsgrenzen (Throttling) und beantwortet zu viele gleichzeitige Anfragen mit dem Statuscode 429 (Microsoft Learn, 2025). Eine robuste Integration respektiert diese Grenzen aktiv.

In der Praxis erreichen optimierte Integrationen mit diesen Maßnahmen Verarbeitungsraten, die selbst grosse Kataloge in vertretbarer Zeit abgleichen (Projekterfahrung). Der Initialimport bleibt ein Sonderfall: Er wird einmalig mit angepasster Batch-Strategie, temporär reduzierter Shop-Indexierung und über ein Wartungsfenster ausgeführt, damit die laufenden Limits nicht ausgereizt werden.

Aus über 50 ERP-Integrationsprojekten (Projekterfahrung) kehren bestimmte Probleme regelmäßig wieder. Wer sie kennt, plant sie von Anfang an ein, statt sie später im Live-Betrieb zu reparieren. Laut IDC ist die Komplexität der Integration einer der Hauptgründe, warum digitale Projekte länger dauern als geplant (IDC, 2024) -- gute Vorbereitung zahlt sich daher direkt aus.

Ein Anbindungsprojekt folgt einem strukturierten Ablauf. Die Erfahrung zeigt, dass eine gründliche Analysephase die wichtigste Investition ist: Je sauberer Anforderungen, Datenmodelle und Datenhoheit dokumentiert sind, desto reibungsloser verläuft die Umsetzung. Ein typisches Projekt lässt sich in fünf Phasen gliedern.