Wer ein großes Enterprise-ERP betreibt, steht bei der Shop-Anbindung vor anderen Fragen als ein Betrieb mit einer schlanken Warenwirtschaft. Dynamics 365 Finance, das umfangreiche Finance-und-Operations-System von Microsoft, ist bewusst von Business Central zu unterscheiden: mehr Datenvolumen, strengere Governance und ein eigenes Integrationsmodell. Zwei Wege führen die Daten zwischen Finance und dem Online-Shop hin und her, nämlich OData-Entities für Echtzeit und einzelne Datensätze sowie das Data Management Framework (DMF) für Massendaten und Datenpakete. Die 2026 Release Wave 1 rollt von April bis September 2026 (Microsoft Learn) aus und baut genau diese Integrationsbausteine weiter aus. Dieser Beitrag zeigt, wie Sie Artikel, Preise und Aufträge sauber synchronisieren, wann OData und wann DMF der richtige Weg ist und wie Sie mit den API-Grenzen des Systems umgehen, damit ein Massenimport den laufenden Betrieb nicht ausbremst.
Das Wichtigste in Kürze
- Dynamics 365 Finance (Finance and Operations) ist nicht Business Central: höheres Datenvolumen, Mehrmandantenfähigkeit und ein eigenes Integrationsmodell. Zwei Transportwege — OData für Echtzeit, DMF für Massendaten — decken zusammen Artikel, Preise und Aufträge ab.
- OData-Entities liefern einzelne Datensätze synchron, sind aber je Mandant auf 6.000 Anfragen pro 300 Sekunden (Microsoft Learn) gedeckelt; darüber antwortet der Dienst mit dem Statuscode HTTP 429.
- Das Data Management Framework bündelt große Mengen in Datenpaketen und wiederkehrenden Integrationen und ist der richtige Weg für die Erstbefüllung des Katalogs und für nächtliche Vollabgleiche.
- Service-Protection-Grenzen von 6.000 Requests je 300 Sekunden (Microsoft Learn) und ein prioritätsbasiertes Throttling schützen den Dienst; Integrationen lassen sich als hoch, mittel oder niedrig (Microsoft Learn) einstufen.
- Business Events und Change Tracking ersetzen ständiges Abfragen: Finance meldet Änderungen, statt dass der Shop pausenlos pollt. Das entlastet die API-Grenzen und hält Bestände aktuell.
Dynamics 365 Finance ist nicht Business Central
Microsoft führt unter der Marke Dynamics 365 zwei sehr unterschiedliche ERP-Welten. Business Central richtet sich an kleine und mittlere Betriebe und bringt eine schlanke, gut dokumentierte REST-API mit; die Anbindung dieses Systems beschreibt der Beitrag zur Business-Central-Shop-Anbindung. Dynamics 365 Finance, oft als Finance and Operations oder kurz F&O bezeichnet, spielt in einer anderen Liga. Es verwaltet Konzernstrukturen mit mehreren Mandanten, komplexe Handelsvereinbarungen und Datenmengen, die einzelne Requests schnell an ihre Grenzen bringen. Wer die beiden Systeme verwechselt, plant die falsche Architektur: Was in Business Central ein einfacher API-Aufruf ist, verlangt in Finance eine bewusste Entscheidung zwischen synchronem OData und paketbasiertem Datenimport.
Der wirtschaftliche Hintergrund ist bekannt: 61 Prozent (Bitkom, Digitalisierung der Wirtschaft 2025) der Unternehmen schöpfen ihr Datenpotenzial nicht voll aus, weil Informationen in unverbundenen Systemen liegen. In F&O-Landschaften ist dieser Effekt besonders teuer, weil dort viele Datenarten zusammenlaufen. Eine saubere Kopplung zwischen Finance und Shop entscheidet deshalb darüber, ob der Shop belastbare Verfügbarkeiten und Preise zeigt oder ob im Hintergrund dauerhaft von Hand nachgepflegt wird. Wie viel technische Disziplin dabei nötig ist, zeigt schon der Vergleich mit anderen Enterprise-Systemen wie SAP, die ähnliche Governance-Anforderungen stellen.
OData-Entities als Echtzeit-Tür zum Shop
OData ist der synchrone Zugang zu Finance. Das System stellt sogenannte Data Entities bereit, also fachlich zusammengefasste Sichten auf Tabellen, die über einen REST-ähnlichen Endpunkt abrufbar sind. Ein Aufruf liefert einzelne Datensätze im JSON-Format und unterstützt Abfrageparameter wie $filter und $select, mit denen sich die übertragene Datenmenge gezielt eingrenzen lässt. Weil F&O mehrere Mandanten kennt, muss jeder Aufruf die richtige Gesellschaft adressieren, entweder über den cross-company-Parameter oder über den fest zugeordneten Kontext des Integrationsbenutzers. Für die Anbindung eines Shops ist OData der passende Weg bei allem, was aktuell und einzeln sein muss: eine Auftragsübergabe, eine Preisabfrage, eine Statusrückmeldung.
Die Grenze von OData liegt im Volumen. Jeder Datensatz ist ein eigener Request, und die Zahl der Requests ist gedeckelt. Fragt der Shop pausenlos ganze Kataloge über OData ab, läuft er unweigerlich in die Drosselung. Deshalb gehört OData dorthin, wo wenige, aktuelle Datensätze zählen, und nicht dorthin, wo Zehntausende Artikel auf einmal bewegt werden. Ob die Anbindung dabei direkt oder über eine Zwischenschicht laufen sollte, ordnet der Beitrag zur Frage REST-API oder Middleware ein. In der Praxis übernimmt eine eigene Integrationsschicht oder API-Entwicklung die Übersetzung zwischen den OData-Entities von Finance und dem Datenmodell des Shops.
Das Data Management Framework für Massendaten
Für große Datenmengen ist nicht OData, sondern das Data Management Framework der richtige Weg. Im DMF werden Data Entities zu Datenprojekten gebündelt, die als Import- oder Exportpaket ganze Datensätze in Formaten wie CSV oder XML verarbeiten. Das ist die passende Technik für die Erstbefüllung eines Shop-Katalogs, für nächtliche Vollabgleiche oder für die Übergabe umfangreicher Preislisten. Über die sogenannten Recurring Integrations lassen sich diese Pakete geplant und automatisiert über HTTPS ein- und ausschleusen, mit einem Enqueue- und Dequeue-Mechanismus, der den Zustand jedes Pakets nachvollziehbar macht.
Der Preis dieser Leistungsfähigkeit ist die Systemlast. DMF-Exporte laufen als Batch-Jobs und können den Datenbankserver deutlich belasten, wenn sie zur falschen Zeit oder zu häufig starten. Deshalb gehören große Abgleiche in lastarme Zeitfenster und brauchen eine bewusste Planung. Wie sich Massenimporte staffeln lassen, ohne die Grenzen der Cloud-Plattform zu reißen, behandelt der Beitrag zu Cloud-ERP-API-Limits und Massenimporten im Detail. Für die Zusammenführung mehrerer Systeme jenseits des reinen Shops ist zudem oft eine Middleware als zentrale Drehscheibe sinnvoll.
OData-Entities
Synchroner Zugriff auf einzelne Datensätze im JSON-Format, mit $filter und $select für gezielte Abfragen.
Data Management Framework
Datenpakete und Import- oder Export-Projekte für Massendaten wie Katalog, Preise und Erstbefüllung.
Recurring Integrations
Geplante, automatisierte Paketübergabe über HTTPS mit Enqueue- und Dequeue-Mechanismus.
Business Events
Finance meldet Ereignisse aktiv an einen Endpunkt, statt vom Shop abgefragt zu werden.
Change Tracking
Nur geänderte Datensätze werden übertragen, was Delta-Abgleiche schlank und schnell hält.
Custom Services
Eigene Geschäftslogik als dedizierter Endpunkt, wenn Standard-Entities nicht ausreichen.
OData oder DMF: wann welcher Weg
Die wichtigste Entscheidung jeder F&O-Anbindung ist die Wahl des Transportwegs je Datenart. Faustregel: Alles, was aktuell und einzeln ist, läuft über OData; alles, was groß und geplant ist, über das DMF. Eine Auftragsübergabe direkt nach dem Kauf gehört zu OData, weil sie sofort ankommen soll. Der nächtliche Abgleich von 40.000 Artikeln gehört zum DMF, weil er als Paket effizienter und schonender läuft. Viele Projekte kombinieren beide Wege: DMF für die Grundlast, OData für die Echtzeit-Ereignisse darauf.
| Kriterium | OData-Entities | Data Management Framework |
|---|---|---|
| Datenmenge | Einzelne bis wenige Datensätze | Große Mengen und Vollabgleiche |
| Aktualität | Echtzeit, synchron | Batch, geplant oder ausgelöst |
| Typischer Einsatz | Auftrag, Preisabfrage, Statusrückmeldung | Katalog-Erstimport, nächtlicher Abgleich |
| Format | JSON je Datensatz | Datenpakete wie CSV oder XML je Projekt |
| Grenze | Service-Protection-Limits je Request | Ressourcenlast auf dem Batch-Server |
| Fehlerbild | HTTP-Status je Aufruf | Ausführungsprotokoll je Datenprojekt |
Artikel, Preise und Aufträge sauber synchronisieren
Eine belastbare Anbindung trennt die Datenarten und legt für jede das führende System fest. Bei Artikeln, Preisen und Beständen ist das in der Regel Finance, bei Bestellungen zunächst der Shop, der die Aufträge dann an Finance übergibt. Entscheidend ist ein sauberes Feld-Mapping zwischen dem Shop-Datenmodell und den F&O-Entities, damit Nummernkreise, Einheiten und Steuerkennzeichen an beiden Enden zusammenpassen. Wie eine solche Feldzuordnung methodisch aufgebaut wird, beschreibt der Beitrag zum Daten-Mapping zwischen ERP und Shop.
- Artikel und Stammdaten: Erstbefüllung per DMF-Datenprojekt, danach nur noch OData-Deltas bei Änderungen. Nummernkreise, Einheiten und Kategorien gehören fest ins Mapping.
- Preise und Handelsvereinbarungen: Finance ist führend. Preislisten und kundenspezifische Konditionen fließen in den Shop, nicht umgekehrt, damit im Warenwirtschaftssystem eine einzige Preiswahrheit bleibt.
- Bestände: Lager- oder standortbezogene Verfügbarkeit wird aggregiert. Kritische Artikel per Ereignis, der übrige Katalog per kurzem Delta-Sync.
- Aufträge: Der Shop übergibt Bestellungen per OData als Sales Order an Finance; Auftragsstatus und Versandinformationen fließen zurück in das Kundenkonto.
- Belege und Rechnungen: Rechnungen und Gutschriften stammen aus Finance. Die E-Rechnung nach XRechnung und ZUGFeRD wird als eigener Prozess betrachtet, weil sie strengeren Formatregeln folgt.
Sobald Daten in beide Richtungen fließen, kann derselbe Datensatz an zwei Stellen gleichzeitig geändert werden. Für diesen Fall braucht es klare Regeln, welches System bei einem Konflikt gewinnt. Wie sich solche Kollisionen auflösen lassen, ohne Daten zu verlieren, zeigt der Beitrag zur bidirektionalen Synchronisation und Konfliktauflösung.
API-Limits und Throttling beherrschen
Finance schützt sich selbst gegen Überlast, und zwar auf mehreren Ebenen. Die Service-Protection-Grenzen erlauben ab Version 10.0.19 je Umgebung 6.000 Requests pro 300 Sekunden (Microsoft Learn) und begrenzen zusätzlich die kombinierte Ausführungszeit auf 1.200 Sekunden pro 300 Sekunden (Microsoft Learn). Parallel deckelt das prioritätsbasierte Throttling OData-Anfragen bei 6.000 pro 300 Sekunden je Nutzer (Microsoft Learn). Wird eine Grenze überschritten, antwortet der Dienst mit HTTP 429 und einem Retry-After-Hinweis, der angibt, wie lange der Aufrufer warten soll. Die früheren benutzerbasierten Limits werden seit dem 31. März 2023 (Microsoft Learn) nicht mehr erzwungen.
Der eigentliche Trick liegt in der Priorisierung. Administratoren stufen jede Integration als hoch, mittel oder niedrig ein. Erreicht die Auslastung des Webservers 60 Prozent (Microsoft Learn) an CPU oder Speicher, werden zuerst niedrig priorisierte Anfragen zur Wiederholung aufgefordert; ab 70 Prozent (Microsoft Learn) trifft es auch die mittlere Stufe. So bleibt der interaktive Nutzer arbeitsfähig, während eine unkritische Hintergrundintegration kurz wartet. Wer seine Aufrufe entsprechend einstuft und auf HTTP 429 mit einem sauberen Wiederholungsverfahren reagiert, läuft nicht gegen die Wand. Die dazu passenden Idempotenz- und Retry-Strategien sorgen dafür, dass eine Wiederholung keinen Auftrag doppelt anlegt.
Auf HTTP 429 richtig reagieren
Business Events statt Polling
Der schonendste Weg, die API-Grenzen zu entlasten, ist es, gar nicht erst pausenlos abzufragen. Finance kann über Business Events aktiv melden, wenn ein Ereignis eintritt, etwa ein gebuchter Beleg oder eine geänderte Preisliste. Der Shop oder die Middleware reagiert dann gezielt, statt in kurzen Intervallen nachzusehen, ob sich etwas getan hat. In Verbindung mit Change Tracking, das nur die tatsächlich veränderten Datensätze markiert, entsteht ein ereignisgetriebener Fluss, der die Zahl der Requests drastisch senkt. Wann sich dieser Ansatz gegenüber dem klassischen Abfragen lohnt, wägt der Beitrag Webhooks gegen Polling ab.
Sichere Anbindung und Berechtigungen
Der Zugriff auf Finance läuft über Microsoft Entra ID. Die Integration registriert sich dort als Anwendung und authentifiziert sich über das OAuth-2.0-Verfahren mit Client Credentials, bevor sie OData oder DMF nutzen darf. In F&O wird dieser Anwendung ein eigener Integrationsbenutzer zugeordnet, dessen Berechtigungen bewusst knapp gehalten werden: nur die Entities und Vorgänge, die die Anbindung wirklich braucht. Dieses Prinzip der geringsten Rechte hält den Schaden klein, falls ein Zugangstoken einmal in falsche Hände gerät. Ein aufschlussreicher Vergleich ist die tokenbasierte Anmeldung anderer Enterprise-Systeme, etwa über den Service Layer von SAP Business One, der einer ähnlichen Logik folgt.
Implementierung Schritt für Schritt
- Datenarten und führende Systeme klären: Festlegen, welche Datenart aus Finance kommt und welche aus dem Shop, und das Feld-Mapping dokumentieren.
- Transportweg je Datenart wählen: OData für Echtzeit-Einzelsätze, DMF für Massendaten und Erstbefüllung, kombiniert wo nötig.
- Zugang einrichten: Anwendung in Microsoft Entra ID registrieren, Integrationsbenutzer in F&O mit minimalen Rechten anlegen, Entities freischalten.
- Throttling einplanen: Integrationen priorisieren, Retry-Verhalten auf HTTP 429 umsetzen, Massenläufe in lastarme Zeitfenster legen.
- Testen und produktiv schalten: Auftragsübergabe, Vollimport und Lastspitzen in einer Testumgebung durchspielen, dann mit engem Monitoring live gehen.
Zwei Wege, eine Datenwahrheit
Nicht jede Verbindung braucht Echtzeit, und nicht jede Massenlast gehört in einen einzelnen Request. Die Kunst der F&O-Anbindung ist, je Datenart den richtigen Weg zu wählen.