// stack · schnittstelle
Business Central ist Microsofts ERP aus der Cloud — Finanzen, Verkauf, Einkauf und Lager in einem System. Was für eine Website zählt, ist die Tür nach draußen: eine veröffentlichte REST-API und OData-Webservices, angemeldet über Microsoft Entra ID. Diese Seite beschreibt, wie siteway daraus einen Produktkatalog, einen Kundenzugang und eine Anfragestrecke macht — ohne dass die Website bei jedem Aufruf im ERP nachfragt.
// definition
Business Central ist Microsofts Unternehmenslösung für kleine und mittlere Organisationen — in Microsofts eigenen Worten eine Business-Management-Lösung, die Geschäftsprozesse automatisiert und die Steuerung des Unternehmens unterstützt. Abgedeckt sind Finanzen, Verkauf, Einkauf, Lager und Versand, dazu Projekte, Anlagen, Fertigung, Lagerlogistik und Service. Betrieben wird das System als Dienst aus der Microsoft-Cloud.
Die Linie ist älter als der Name: Business Central setzt Dynamics NAV fort, das viele im Mittelstand noch unter dem Namen Navision kennen. Microsoft dokumentiert die Upgrade-Wege von NAV nach Business Central bis heute — für uns heißt das in der Praxis, dass wir es häufig mit gewachsenen Beständen, eigenen Feldern und langjährigen Anpassungen zu tun haben, nicht mit einer Standardinstallation von der Stange.
Interessant wird das System für eine Website an der Stelle, an der es Daten herausgibt. Business Central bringt dafür zwei dokumentierte Wege mit: eine veröffentlichte REST-API und OData-Webservices, für die Pages und Queries als Endpunkt freigegeben werden. Beide beruhen laut Microsoft auf OData in Version 4. Angemeldet wird über Microsoft Entra ID mit OAuth 2.0 — Zugriffsschlüssel mit einfacher Anmeldung sind für die Cloud-Variante abgekündigt und werden dort nicht mehr unterstützt.
// praxis
spiegeln · nicht durchreichen
Die wichtigste Entscheidung fällt vor der ersten Zeile Code: Die Website fragt das ERP nicht bei jedem Seitenaufruf. Wir spiegeln die benötigten Daten im festen Takt in das Datenmodell des CMS — als eigene Inhaltsart mit eigenen Feldern, eigener URL und eigener Sortierung. Ausgeliefert wird danach aus dem eigenen Bestand. Das hält die Seite schnell, macht sie unabhängig von der Erreichbarkeit des ERP und sorgt dafür, dass ein Wartungsfenster in der Cloud kein leeres Produktverzeichnis produziert. Live geht nur, was live sein muss — etwa eine Verfügbarkeitsprüfung direkt vor dem Absenden einer Bestellung.
Zuerst steht die Anmeldung. Für Integrationen, die ohne Nutzerinteraktion laufen, nennt Microsoft den Client-Credentials-Flow: Im Microsoft-Entra-Mandanten wird eine Anwendung registriert, sie erhält eine Anwendungs-ID und ein Geheimnis, dazu die Anwendungsberechtigung für den Zugriff auf APIs und Webservices. In Business Central wird dieselbe Anwendung über ihre Client-ID eingetragen, aktiviert und mit Objektberechtigungen versehen. Microsoft hält dabei ausdrücklich fest, dass Anwendungen das Berechtigungsset SUPER nicht bekommen können und nach dem Prinzip der geringsten Rechte einzurichten sind. Unser Server holt das Token und erneuert es, bevor es abläuft — im Browser taucht davon nichts auf.
Dann kommt das Mapping. Ein Artikelstamm im ERP hat sehr viele Felder; eine Website braucht davon einen bewussten Ausschnitt. Wir legen fest, welches ERP-Feld auf welches Website-Feld geht, was Pflicht ist, was optional bleibt und was das Haus gar nicht erst verlässt — Einkaufspreise, Deckungsbeiträge, Lieferantenkonditionen und interne Kennzeichen gehören nicht in ein öffentliches JSON. Für den Abgleich ist ein Feld besonders wertvoll: das Änderungsdatum. Damit holen wir beim zweiten Lauf nur noch, was sich seither bewegt hat.
Aktualisiert wird zweigleisig: ein geplanter Abgleich als Grundsicherung plus Webhooks für den schnellen Weg. Business Central kennt Abonnements, bei denen es eine hinterlegte Adresse aufruft, sobald sich ein Datensatz ändert. Beim Anlegen und beim Erneuern verlangt es einen Prüfwert zurück; erst danach ist das Abonnement aktiv. Laut Dokumentation laufen Abonnements nach drei Tagen ab, wenn sie nicht erneuert werden — die Erneuerung übernimmt bei uns derselbe geplante Lauf, der auch den Abgleich fährt. Ein optionaler Wert im Abonnement dient als gemeinsames Geheimnis; wir prüfen ihn, bevor irgendetwas verarbeitet wird.
Der Rückkanal ist die andere Richtung: Anfragen, Kunden und Aufträge, die auf der Website entstehen, schreiben wir als Datensatz ins ERP zurück — serverseitig, mit denselben Zugangsdaten, mit Prüfung der Antwort. Ein Formular erzeugt damit keinen Papierstapel, sondern einen Vorgang, der im System sichtbar ist.
Und schließlich das, was in Angeboten gern fehlt: der Fehlerfall. Microsoft begrenzt die Zahl der Anfragen und antwortet bei Überschreitung mit dem Statuscode 429; die Dokumentation verlangt vom aufrufenden System eine Wiederholungslogik mit Abkühlphase. Genau so bauen wir es: Filter auf das Änderungsdatum, seitenweiser Abruf, Sammelanfragen, Wiederholung mit wachsendem Abstand. Antwortet das ERP nicht oder unvollständig, bleibt der letzte gute Stand stehen und der Lauf wird protokolliert. Die buchbare Leistung dahinter beschreiben wir unter Schnittstellenentwicklung.
// technik · 6 details
belegt aus der microsoft-doku
Was hier steht, stammt aus der öffentlichen Dokumentation von Microsoft — Endpunktaufbau, Berechtigungen, Statuscodes und Grenzwerte im Original. Was dort nicht steht, steht hier auch nicht: Der genaue Feldbestand einer gewachsenen Installation ist Sache des Systems vor Ort und wird im Projekt gesichtet, nicht vermutet.
// d-01endpunkt
Die Cloud-Variante spricht über einen gemeinsamen Endpunkt unter api.businesscentral.dynamics.com. Seit es mehrere Umgebungen je Mandant gibt, muss der Name der Umgebung — etwa production oder sandbox — laut Microsoft in der Adresse stehen. Darunter liegen die Mandanten als companies, und darunter erst die Entitäten.
zweck: adressierung
// d-02anmeldung
Server zu Server ohne Nutzerinteraktion läuft über den Client-Credentials-Flow. Im Entra-Mandanten wird eine Anwendung registriert und bekommt Anwendungs-ID, Geheimnis und die Anwendungsberechtigung für APIs und Webservices. In Business Central wird sie über ihre Client-ID eingetragen, aktiviert und mit Objektrechten versehen — SUPER ist für Anwendungen ausgeschlossen.
zweck: authentifizierung
// d-03entitäten
Die veröffentlichte API kennt unter anderem items, customers, vendors, salesQuotes, salesOrders und salesInvoices. Ein Artikel führt dokumentierte Felder wie number, displayName, unitPrice, inventory, gtin, baseUnitOfMeasureCode und lastModifiedDateTime; über Navigationen hängen Kategorie, Varianten und Bild daran. Das Änderungsdatum trägt den Abgleich.
zweck: datenbestand
// d-04aktualität
Statt dauernd zu fragen, lässt sich Business Central melden: Ein Abonnement nennt Zieladresse und Ressource, beim Anlegen und Erneuern verlangt das System einen Prüfwert zurück. Die Meldung nennt Ressource und Art der Änderung — angelegt, geändert, gelöscht oder als Sammelmeldung. Abonnements laufen nach drei Tagen ab, wenn sie nicht erneuert werden.
zweck: ereignisgesteuert
// d-05grenzen
Die Cloud teilt Ressourcen, also gibt es Grenzen. Wird die Zahl der Anfragen überschritten, kommt der Statuscode 429 zurück; die Dokumentation verlangt eine Wiederholung mit Abkühlphase, wahlweise mit festem, steigendem oder exponentiell wachsendem Abstand. Sehr lange Anfragen brechen nach zehn Minuten mit einem Gateway-Timeout ab. Microsoft empfiehlt Filter, Sammelanfragen und Webhooks statt Dauerabfrage.
zweck: belastbarkeit
// d-06eigene felder
Die veröffentlichte API lässt sich laut Dokumentation nicht einfach um zusätzliche Felder erweitern — dafür muss der AL-Code kopiert und eine eigene API daraus gebaut werden. Daneben steht der klassische Weg: Pages und Queries werden als OData-Endpunkt freigegeben, Queries lesend. Wer im ERP eigene Felder pflegt, braucht dafür einen Endpunkt vom Dynamics-Partner.
zweck: sonderfelder
Aus gespiegelten ERP-Daten wird kein Datenbank-Dump, sondern eine Website. Der Produktkatalog filtert über die Felder, die im Mapping definiert sind — Kategorie, Einheit, Merkmale, Preisspanne — und arbeitet dabei auf dem eigenen Bestand, also ohne Wartezeit auf ein fremdes System. Jeder Artikel bekommt eine sprechende, dauerhafte URL mit Datenblatt: Artikelnummer, Bezeichnung, Einheit, Merkmale, Dokumente. Das ist die Seite, die in der Suche landet — nicht ein PDF im Archiv.
Darüber hinaus wird es persönlich. Im Kundenzugang sehen angemeldete Nutzerinnen und Nutzer ihre Aufträge, Lieferungen und Rechnungen — die Daten dafür holen wir gezielt und nur für den angemeldeten Kontakt, nicht auf Vorrat für alle. Und die Anfrage- oder Bestellstrecke schließt den Kreis: Was im Formular entsteht, wird zum Vorgang im ERP, statt zur E-Mail, die jemand abtippt. Für Suchmaschinen ergänzen wir strukturierte Daten aus denselben Feldern und eine Regel für Artikel, die aus dem Sortiment fallen.
Beim Datenschutz laufen zwei Richtungen auseinander. Artikel- und Preisdaten sind in der Regel unkritisch — Kunden-, Auftrags- und Rechnungsdaten sind es nie. Deshalb: Zugangsdaten in der Server-Konfiguration statt im Repository, Rechte der Anwendung auf das Nötigste beschränkt, personenbezogene Daten sparsam und nur so lange gespiegelt wie nötig, Übertragung ausschließlich serverseitig über TLS. Und weil Daten im Auftrag verarbeitet werden, gehören die passenden Verträge dazu — mehr dazu im Stack unter Sicherheit & Datenschutz.
// integration
drei systeme · ein muster
Der Weg ist systemunabhängig, und er ist immer derselbe: Die Daten aus Business Central werden im festen Takt ins CMS gespiegelt, das Frontend liest aus dem eigenen Bestand, und live geht nur, was live sein muss. Was dafür im CMS liegen muss, ist schnell benannt — eine eigene Inhaltsart mit genau den Feldern aus dem Mapping, Bilder und Dokumente in der Medienverwaltung des Systems, und die ID des Datensatzes aus dem ERP als Schlüssel. Über diesen Schlüssel erkennt der zweite Lauf den Datensatz wieder und aktualisiert ihn, statt eine Dublette anzulegen. Erst dadurch werden Artikel aus Business Central auf der Website zu echten Seiten mit dauerhafter URL statt zu einem eingebetteten Fremdinhalt.
Aktualität ist danach eine Frage von Takt, Webhook und Cache. Ausgeliefert wird aus Cache oder statisch erzeugten Seiten — schnell und unabhängig davon, ob das ERP gerade erreichbar ist. Meldet Business Central eine Änderung, holen wir gezielt diesen einen Datensatz nach und nehmen nur seine Detailseite und die betroffenen Listen aus dem Cache, statt die ganze Website zu leeren. Der geplante Lauf im Hintergrund bleibt daneben als Grundsicherung bestehen und erneuert nebenbei die Abonnements. Welches CMS darunter arbeitet, ändert an dieser Mechanik nichts — nur daran, wo die Daten am Ende liegen und was die Redaktion damit tun kann.
// cms-01typo3
TYPO3 bringt mit Extbase, TCA, dem Scheduler und Fluid alles mit, was eine Anbindung braucht. Wir bauen sie als eigene Extension: Das TCA beschreibt das Datenmodell, also die Inhaltsart mit genau den Feldern aus dem Mapping. Der Abruf der Business-Central-Daten läuft als Scheduler-Task in festem Takt, die Datensätze liegen als Records in einem Systemordner, Bilder und Dokumente in FAL. Zugangsdaten und Umgebungsname stehen in der Extension-Konfiguration, nicht im Code. Sprechende URLs für Liste und Detailseite kommen aus dem Site Handling, gerendert wird über Fluid-Templates. Die Redaktion sieht die Datensätze im Backend, pflegt eigene Texte in Feldern daneben, die der Import nicht anfasst, und platziert Teaser als Content-Element auf jeder Seite.
// cms-02wordpress
In WordPress entsteht die Anbindung als eigenes Plugin und nicht als Theme-Code — so bleibt sie beim Theme-Wechsel bestehen. Die Datensätze werden ein Custom Post Type mit eigenen Meta-Feldern für die ERP-Daten und Taxonomien für die Filter, also Kategorie, Einheit und Merkmale. Ein geplanter Lauf holt die Änderungen im festen Takt und hält den Bestand nach. Eine eigene REST-Route nimmt serverseitige Aufrufe entgegen — etwa eine eingehende Änderungsmeldung oder eine Verfügbarkeitsprüfung aus dem eigenen Frontend; die Aufrufe Richtung Business Central laufen ausschließlich serverseitig, Zugangsdaten liegen in der Server-Konfiguration und nie im Frontend. Fürs Frontend kommen Template-Dateien und Blöcke für den Editor dazu, damit die Redaktion Liste, Filter und Teaser dort platziert, wo sie hingehören.
// cms-03statamic
Statamic läuft auf Laravel — Inhalte sind Entries in Collections, Bilder Assets in Containern. Das passt zu einer ERP-Anbindung besonders gut: Ein Artisan-Command holt die Daten und schreibt sie als Entries in eine eigene Collection, der Laravel-Scheduler bestimmt den Takt und erneuert nebenbei die Abonnements. Ein Blueprint beschreibt das Datenmodell mit genau den Feldern aus dem Mapping. Zugangsdaten, Umgebungsname und Mandant stehen in der .env und damit außerhalb des Repositories. Route und Controller nehmen eingehende Änderungsmeldungen entgegen und prüfen sie, bevor etwas verarbeitet wird. Antlers oder Blade rendern Liste, Filter und Detailseite, Static Caching liefert sie aus. Im Control Panel pflegt die Redaktion Beschreibungstexte und Reihenfolge in Feldern, die der Import nicht anfasst.
// entscheidung
zuordnung statt rangliste
Business Central bietet mehr als einen Weg nach draußen, und keiner davon ist grundsätzlich besser — sie beantworten unterschiedliche Fragen. An drei Mustern lässt sich das zuordnen.
// e-01rest-api
Artikel, Kunden, Aufträge und Rechnungen im Standardumfang, ein Produktkatalog, ein Kundenzugang, eine Anfragestrecke: Dafür reicht die veröffentlichte REST-API. Sie ist von Microsoft dokumentiert, webhook-fähig und der von Microsoft empfohlene Weg. Der schnellste Start, wenn das ERP nah am Standard läuft.
json · dokumentiert
// e-02eigener endpunkt
Gewachsene Installationen tragen eigene Felder: technische Merkmale, Staffelpreise, Sortimentskennzeichen. Weil die veröffentlichte API sich nicht einfach erweitern lässt, braucht es dafür einen eigenen Endpunkt — eine eigene API oder eine freigegebene Page beziehungsweise Query im ERP. Das bringt der Dynamics-Partner bei, wir konsumieren ihn.
odata · sonderfelder
// e-03kombination
Häufig die ehrlichste Antwort: Die veröffentlichte API trägt die Grundlast — Stammdaten, Preise, Belege — und ein eigener Endpunkt ergänzt genau das, was sie nicht abbildet. Ein Weg für die Menge, ein Weg für die Präzision, beide über dieselbe Anmeldung und denselben Abgleichslauf.
grundlast + präzision
Fünf Fragen entscheiden die Richtung, und sie lassen sich in einem Gespräch beantworten. Welche Daten müssen wirklich auf die Website — und welche auf keinen Fall? Wie viele Datensätze sind es, und wie oft ändern sie sich? Reicht der Standardumfang der API, oder hängen die entscheidenden Informationen in eigenen Feldern? Soll die Website nur anzeigen oder auch zurückschreiben? Und wer richtet auf der ERP-Seite die Anwendung samt Rechten ein — dieser Schritt gehört dem Dynamics-Partner oder der internen IT, nicht uns.
Danach steht das Mapping als Dokument, bevor gebaut wird. Dieselbe Logik greift bei anderen Warenwirtschaften und CRM-Systemen: SAP bringt eigene Schnittstellen mit, weclapp ist als Cloud-ERP von vornherein API-nah gebaut, und Salesforce beantwortet dieselben Fragen für die Vertriebsseite. Welche Anbindung ein Projekt bekommt, klären wir im Konzept — vor dem Bauen, mit Begründung.
// faq
Business Central ist Microsofts Unternehmenslösung für kleine und mittlere Organisationen. Microsoft beschreibt sie als Business-Management-Lösung, die Geschäftsprozesse automatisiert und die Steuerung des Unternehmens unterstützt — Finanzen, Verkauf, Einkauf, Lager, Projekte, Fertigung und Service. Betrieben wird sie als Dienst aus der Microsoft-Cloud. Die Produktlinie setzt Dynamics NAV fort, den früheren Namen der Reihe kennen viele noch als Navision; Microsoft dokumentiert die Upgrade-Wege von NAV nach Business Central bis heute. Für eine Website zählt vor allem, dass Business Central seine Daten über eine veröffentlichte REST-API und über OData-basierte Webservices nach außen gibt.
Über eine Schnittstelle, die serverseitig läuft. Business Central stellt dafür zwei dokumentierte Wege bereit: die veröffentlichte REST-API und OData-basierte Webservices, für die Pages und Queries als Endpunkt freigegeben werden. Beide beruhen auf OData in Version 4. Der Server der Website meldet sich an, holt die benötigten Datensätze als JSON und schreibt sie in das eigene Datenmodell. Ausgeliefert wird danach aus diesem eigenen Bestand — der Browser der Besucherin spricht nie direkt mit dem ERP.
Über OAuth 2.0. Für Integrationen, die ohne Nutzerinteraktion laufen, nennt Microsoft den Client-Credentials-Flow: Im Microsoft-Entra-Mandanten wird eine Anwendung registriert, sie erhält eine Anwendungs-ID und ein Geheimnis, dazu die Anwendungsberechtigung für den Zugriff auf APIs und Webservices von Business Central. In Business Central selbst wird dieselbe Anwendung über ihre Client-ID eingetragen, aktiviert und mit Objektberechtigungen versehen. Microsoft hält dabei ausdrücklich fest, dass Anwendungen das Berechtigungsset SUPER nicht bekommen können und nach dem Prinzip der geringsten Rechte eingerichtet werden sollen. Das Token holt sich unser Server beim Token-Endpunkt von Microsoft und erneuert es, bevor es abläuft.
Die REST-API ist der von Microsoft empfohlene Weg und liefert einen festen Satz an Entitäten, etwa Artikel, Kunden, Verkaufsaufträge, Verkaufsrechnungen und Angebote. Sie lässt sich nicht einfach um zusätzliche Felder erweitern — laut Dokumentation muss dafür der AL-Code kopiert und eine eigene API daraus gebaut werden. OData-Webservices entstehen dagegen, indem eine Page oder eine Query im System als Endpunkt veröffentlicht wird; Queries sind dabei lesend. Praktisch heißt das: Standardfelder über die veröffentlichte API, Sonderfelder über einen eigenen Endpunkt, den der Dynamics-Partner im ERP bereitstellt.
Indem sie es nicht fragt. Die Daten werden im festen Takt gespiegelt und liegen danach im Datenmodell der Website. Dazu kommt der Push-Weg: Business Central kennt Webhook-Abonnements, die über einen eigenen Endpunkt angelegt werden. Beim Anlegen ruft Business Central die hinterlegte Adresse auf und erwartet einen Prüfwert zurück; erst danach ist das Abonnement aktiv. Die Benachrichtigung nennt die geänderte Ressource und die Art der Änderung — angelegt, geändert, gelöscht oder als Sammelmeldung bei sehr vielen Änderungen. Laut Dokumentation laufen Abonnements nach drei Tagen ab, wenn sie nicht erneuert werden; die Erneuerung übernimmt bei uns ein geplanter Lauf. Ein optionaler Wert im Abonnement dient als gemeinsames Geheimnis, mit dem sich eingehende Benachrichtigungen prüfen lassen.
Damit wird von Anfang an gerechnet. Microsoft begrenzt die Zahl der Anfragen und antwortet bei Überschreitung mit dem Statuscode 429; die Dokumentation verlangt vom aufrufenden System eine Wiederholungslogik mit Abkühlphase, etwa mit fester, steigender oder exponentiell wachsender Wartezeit. Für sehr lange Anfragen gilt eine Ausführungsgrenze von zehn Minuten, danach kommt ein Gateway-Timeout zurück. Unsere Anbindung arbeitet deshalb mit Filtern auf das Änderungsdatum, mit Sammelanfragen und mit seitenweisem Abruf statt mit einem großen Rundumschlag. Fällt ein Lauf aus, bleibt der letzte gute Stand stehen, der Fehler wird protokolliert und der Abruf mit Abstand wiederholt. Ein abgebrochener Import darf nie den Bestand leeren.
Vier Dinge, je nach Projekt einzeln oder zusammen. Ein Produktkatalog mit eigenen Filtern über Kategorie, Einheit und Preisspanne, gespeist aus den Artikeldaten. Datenblätter mit Artikelnummer, Bezeichnung, Einheit und weiteren Merkmalen als dauerhafte, indexierbare Seite. Ein Kundenzugang, in dem angemeldete Nutzerinnen und Nutzer ihre Aufträge und Rechnungen sehen. Und eine Anfrage- oder Bestellstrecke, die aus dem Formular heraus einen Datensatz im ERP anlegt, statt eine E-Mail zu erzeugen, die jemand abtippt.
Ja, in allen dreien — und wir bauen die Anbindung jeweils selbst, mit den Bordmitteln des Systems. In TYPO3 entsteht eine eigene Extension: das TCA beschreibt das Datenmodell, der Abruf läuft als Scheduler-Task, die Datensätze liegen als Records im Backend, gerendert wird über Fluid, die Zugangsdaten stehen in der Extension-Konfiguration. In WordPress entsteht ein eigenes Plugin statt Theme-Code: ein Custom Post Type mit Meta-Feldern trägt die Daten, ein geplanter Lauf hält sie nach, eine eigene REST-Route nimmt serverseitige Aufrufe entgegen. In Statamic liegt Laravel darunter: ein Artisan-Command im Scheduler holt die Daten, ein Blueprint beschreibt das Datenmodell, die Datensätze werden Entries in einer Collection, die Zugangsdaten stehen in der Datei mit den Umgebungsvariablen. Die Mechanik ist überall dieselbe, nur die Werkzeuge heißen anders.
// womit das zusammenhängt
systeme, ergebnisse & leistung
// stack · schnittstelle
Das andere große ERP im Mittelstand und Konzernumfeld — andere Mechanik, dieselbe Frage: Was gehört auf die Website und was nicht?
zur technik →
// stack · schnittstelle
Cloud-ERP, das von vornherein auf Schnittstellen gebaut ist: Artikel, Aufträge und Kunden auf demselben Weg auf die Website.
zur technik →
// stack · schnittstelle
Die Vertriebsseite derselben Aufgabe: Leads und Kontakte aus der Website in ein CRM schreiben, statt sie per E-Mail zu verteilen.
zur technik →
// leistung · ergebnis
Was aus Artikeldaten wird: Liste mit Filtern, Datenblatt mit dauerhafter URL, Dokumente am Produkt.
zur leistung →
// leistung · ergebnis
Der angemeldete Bereich: Aufträge, Lieferungen und Rechnungen sichtbar machen — sparsam, geprüft, serverseitig.
zur leistung →
// leistung · buchen
Die Technik hier, das Angebot dort: Analyse, Mapping, Umsetzung, Monitoring und Betrieb der Anbindung. Hier wird gebucht.
zur leistung →
// Daten aus Business Central auf deine Website?
Projekt anfragen