Datenintegration
Ina Rogalev
24. September 2026
Viele Unternehmen verbinden Business Central mit Shops, Lagerlösungen, CRM-Systemen, Reporting-Werkzeugen oder eigenen Anwendungen. Häufig laufen diese Verbindungen seit Jahren zuverlässig – und beruhen doch auf einer Technik, die Microsoft nun schrittweise zurückbaut: den über die Seite „Webdienste“ veröffentlichten Schnittstellen.
Das ist kein Grund für hektische Umstellungen. Es ist aber ein klarer Auftrag, bestehende Schnittstellen rechtzeitig zu prüfen. Die moderne Alternative sind die Standard-APIs von Business Central oder – wenn der Standard nicht ausreicht – eigens entwickelte API-Endpunkte.
Über die Seite Webdienste in Business Central konnten bisher Objekte aus dem System als Schnittstelle bereitgestellt werden.
Typische Anwendungsfälle waren:
Die Vorgehensweise war praktisch, hatte jedoch einen grundsätzlichen Nachteil: Eine Benutzeroberfläche ist keine stabile Programmierschnittstelle. Personalisiert ein Benutzer eine Seite – etwa indem er Spalten hinzufügt, entfernt oder anders anordnet –, kann sich dies auf den bereitgestellten Endpunkt auswirken. Das gilt insbesondere dann, wenn die angebundene Anwendung mit demselben Benutzerkonto auf Business Central zugreift.
Weitere Informationen zur bisherigen Veröffentlichung finden Sie in der Microsoft-Dokumentation: Webdienst veröffentlichen, SOAP-Webdienste und OData-Webdienste.
Microsoft unterscheidet zwischen SOAP und OData. Entscheidend für die Bestandsaufnahme ist, welche Pages, Queries und Codeunits in Ihrem Mandanten über die Seite „Webdienste“ veröffentlicht wurden und welches externe System sie nutzt.
Wichtig: Microsoft hat SOAP-Webdienste abgekündigt und empfiehlt, Integrationen künftig mit OData V4 oder vorzugsweise mit API-Seiten und API-Abfragen umzusetzen. Prüfen Sie deshalb jeden über „Webdienste“ veröffentlichten Endpunkt anhand seiner Objektart – Page, Query oder Codeunit –, seiner verwendeten Technologie und seines fachlichen Zwecks.
Die verbindliche Quelle für die Abkündigungen ist die Microsoft-Dokumentation zu veralteten Plattformfunktionen.
APIs sind speziell für den Datenaustausch zwischen Systemen konzipiert. Im Unterschied zu einer Seite im Business-Central-Client sind sie eindeutig definiert und versioniert. Das bringt vor allem drei Vorteile:
Für Key User ist dabei besonders wichtig: Nicht die vertraute Seite in Business Central ist künftig der Vertrag mit dem angebundenen System, sondern die fachlich definierte API.
Business Central bringt bereits eine umfangreiche Auswahl an Standard-APIs mit. Sie sollten immer der erste Prüfpunkt sein, bevor eine individuelle Schnittstelle gebaut wird.
Standard APIs für operative Geschäftsprozesse
Die Standard APIs in Version 2.0 decken viele zentrale Geschäftsobjekte ab, beispielsweise Debitoren, Kreditoren, Artikel, Verkaufsbelege, Einkaufsbelege und Buchungen. Sie eignen sich besonders für klassische Integrationen mit Shop, CRM, Lager oder anderen Geschäftsanwendungen.
Analytics APIs für Auswertungen
Die Analytics APIs sind auf Analyse- und Reporting-Szenarien ausgerichtet. Sie bieten eine geeignete Grundlage, um Daten etwa in Power BI oder andere Auswertungswerkzeuge zu übergeben, ohne dafür eine Bildschirmseite als Datenquelle zu verwenden.
Finance APIs für Finanzberichte
Für Finanz- und Berichtsanforderungen stellt Microsoft eigene Finance APIs bereit. Ein Beispiel ist die Ressource Accounting Period. Diese APIs sind für die Anforderungen des Finanzreportings gedacht und sollten bei entsprechenden Auswertungen gezielt geprüft werden.
Wenn der Standard nicht genügt
Nicht jeder individuelle Prozess lässt sich mit einer Standard-API abbilden. Dann kann ein Business-Central-Partner eine eigene API-Seite oder API-Abfrage als Erweiterung entwickeln. So bleibt die Schnittstelle klar abgegrenzt, dokumentierbar und unabhängig von Änderungen an einer Benutzeroberfläche.
Die Liste „Webdienste“ zeigt, welche Endpunkte veröffentlicht sind. Sie zeigt jedoch nicht, ob und wie häufig sie noch von anderen Systemen verwendet werden. Diese Lücke schließt die Telemetrie in Business Central beziehungsweise Azure Application Insights: Eingehende Aufrufe von SOAP-, OData- und API-Endpunkten werden dort protokolliert.
Der zentrale Microsoft-Telemetriecode für eingehende Webdienstaufrufe lautet RT0008. Zu jedem Signal lassen sich unter anderem folgende Informationen auswerten:
Microsoft stellt für diese Auswertung Beispielabfragen in Kusto Query Language (KQL) bereit. Die vollständige Beschreibung des Signals RT0008, der verfügbaren Felder und der Beispielabfragen finden Sie in der Microsoft-Dokumentation: Eingehende Webdienstanforderungen per Telemetrie analysieren. Einen Überblick über die Webdienst-Telemetrie liefert Microsoft ebenfalls.
Für eine belastbare Entscheidung sollte die Telemetrie über einen ausreichend langen Zeitraum betrachtet werden – einschließlich Monatsabschluss, saisonaler Prozesse und wiederkehrender Integrationsläufe. So lässt sich unterscheiden, welche veröffentlichten Webdienste noch relevant sind und welche ohne Auswirkung abgelöst oder bereinigt werden können.
Der erste Schritt ist keine technische Umstellung, sondern Transparenz. Gehen Sie strukturiert vor:
Schnittstellen inventarisieren: Prüfen Sie die Seite „Webdienste“ in Business Central. Dokumentieren Sie für jeden Eintrag Objektart, Objekt-ID, Service-Name, OData- bzw. SOAP-URL und den fachlichen Zweck. Ergänzen Sie diese Liste anschließend mit den tatsächlichen Aufrufen aus der Telemetrie.
Verantwortliche und Verbraucher zuordnen: Klären Sie, welches externe System die Schnittstelle nutzt, wer dort verantwortlich ist und ob Daten nur gelesen oder auch geschrieben werden.
Betroffene Endpunkte priorisieren: Bewerten Sie alle veröffentlichten SOAP- und OData-Endpunkte vor den nächsten Updates. Berücksichtigen Sie dabei Objektart, fachliche Kritikalität und geplante Versionswechsel.
Passende API auswählen: Prüfen Sie zunächst die Standard-, Analytics- oder Finance APIs. Reicht keine davon aus, beschreiben Sie den fachlichen Bedarf für eine individuelle API.
Umstellung testen und abstimmen: Eine neue API-Adresse allein genügt nicht. Prüfen Sie gemeinsam mit dem Anbieter des angebundenen Systems Datenfelder, Berechtigungen, Fehlerfälle und die Ergebnisse im Fachprozess.
Eine einfache Liste mit „Schnittstelle“, „Objektart“, „genutztes System“, „fachlicher Zweck“, „SOAP/OData“, „Alternative API“ und „verantwortliche Person“ ist hierfür ein guter Start.
Die Abschaltung betrifft nicht die tägliche Arbeit in Business Central, sondern die technische Basis bestimmter Integrationen. Gerade deshalb wird sie leicht übersehen. Wer die bestehenden Webdienste jetzt aufnimmt und die passenden APIs auswählt, verhindert Zeitdruck vor einem Update und schafft zugleich eine stabilere Grundlage für künftige Anbindungen.
N4 unterstützt Sie bei der Bestandsaufnahme – auch mithilfe der Telemetrie –, der Bewertung Ihrer Schnittstellen und der Umstellung auf zukunftssichere Business-Central-APIs.
MARKUS WEILAND
head of microsoft dynamics
Das könnte Sie auch interessieren
