.svg)
Grundlegendes zu Datenentitäten in Dynamics 365 F&O
Bevor Sie sich für eine Integrationsmethode entscheiden, ist es hilfreich zu verstehen, wie Microsoft Dynamics 365 Finance & Operations (F&O) Daten für den externen Austausch strukturiert.
Anstatt seine Rohdatenbanktabellen direkt externen Systemen zugänglich zu machen, verwendet F&O Datenentitäten: vereinfachte, strukturierte Darstellungen der zugrunde liegenden Datenkonzepte wie „Kunde“, „Lieferant“ oder „Produktionsauftrag“. Datenentitäten wenden die relevante Geschäftslogik, Validierungsregeln und Sicherheitsrichtlinien automatisch an, unabhängig davon, welche Integrationsmethode auf sie zugreift. Alle drei Hauptmuster, OData, DMF und Dual-Write, interagieren mit F&O über diese Datenentitäten und nicht direkt mit der Datenbank.
Dies ist in der Praxis wichtig, da externe Systeme so eine saubere, kontrollierte Ansicht der ERP-Daten erhalten, anstatt sich in komplexen normalisierten Schemata zurechtfinden zu müssen. Es bedeutet auch, dass jede auf Datenentitäten aufbauende Integration die Validierungslogik übernimmt, die das ERP auf diese Daten anwendet, wodurch das Risiko verringert wird, dass korrupte oder inkonsistente Datensätze in das System gelangen.
OData: synchrone Echtzeitintegration für Ströme mit geringem Volumen
Open Data Protocol (OData) ist das Standardprotokoll für die RESTful-API-Kommunikation in Dynamics 365 F&O. Es arbeitet synchron: Wenn ein externes System eine Anfrage sendet, wartet es darauf, dass F&O eine Antwort verarbeitet und zurückgibt, bevor es fortfährt. Dies macht OData zur richtigen Wahl für Szenarien, in denen eine sofortige Bestätigung wichtig ist und das Datenvolumen gering ist.
Wenn Hersteller OData verwenden
- PLM-Integrationen: Erstellen Sie einen neuen Produktmaster oder aktualisieren Sie eine bestimmte Stücklistenversion (BOM) direkt aus einem PLM-System, wobei das PLM bestätigen muss, dass der Datensatz akzeptiert wurde, bevor es fortfahren kann.
- Logistik und Versand: Abfrage von Frachtraten in Echtzeit oder Aktualisierung eines Sendungsstatus, wenn ein Paket die Laderampe verlässt.
- Leichte MES-Signale: Senden einer Echtzeitbenachrichtigung an F&O, dass eine Maschine einen Produktionsschritt abgeschlossen und eine definierte Menge an Rohstoffen verbraucht hat.
Wo OData zusammenbricht
Dynamics 365 F&O wendet strenge Drosselungsgrenzen für OData an, um die Systemleistung zu schützen. Wenn ein externes System, wie z. B. ein hochvolumiges WMS oder ein aggressives Analysetool, zu viele schnelle Anfragen sendet, drosselt F&O diese oder lehnt sie ab. Dies kann zu Timeouts bei Anfragen und Integrationsfehlern in genau den Momenten führen, in denen Betriebssysteme Daten am dringendsten benötigen.
OData sollte ausschließlich Transaktionsdaten mit geringem Volumen und hoher Dringlichkeit vorbehalten sein. Die Verwendung für Massenoperationen ist eine der häufigsten Ursachen für Instabilität der Dynamics 365-Integration in Produktionsumgebungen.
DMF: asynchrone Stapelverarbeitung für große Datenmengen
Das Data Management Framework (DMF), in früheren Versionen von Dynamics 365 auch als DIXF bezeichnet, behandelt das gegenteilige Szenario: große Datenmengen, die keine sofortige Reaktion erfordern. Anstatt Anfragen synchron zu verarbeiten, akzeptiert DMF Dateien in Formaten wie XML, CSV oder JSON über eine Speicherwarteschlange und verarbeitet sie nach Zeitplan, ohne mit Live-ERP-Vorgängen um Systemressourcen zu konkurrieren.
Wenn Hersteller DMF verwenden
- WMS-Integration: Verarbeitung von Inventurerfassungen am Ende der Schicht, Massenkommissionierrouten oder Anpassungen großer Zykluszahlen aus einem Lagersystem eines Drittanbieters.
- Aktuelle Informationen zur Beschaffung: Import von Lieferantenkatalogen oder gleichzeitiges Aktualisieren von Tausenden von Lieferterminen von Bestellungen aus einem Lieferantenportal.
- Data Warehousing und Analytik: Exportieren großer Datensätze in eine BYOD-Umgebung (Bring Your Own Database) oder in Azure Data Lake, sodass Business Intelligence-Tools komplexe Abfragen ausführen können, ohne die Live-ERP-Leistung zu beeinträchtigen.
Der Kompromiss, den es zu verstehen gilt
DMF führt Latenz ein. Da es asynchron ist, erhält das empfangende System keine sofortige Bestätigung, dass die Daten akzeptiert wurden. Bei Vorgängen, bei denen das Timing nicht entscheidend ist und das Datenvolumen hoch ist, lohnt sich dieser Kompromiss eindeutig. Für alles, was Feedback in Echtzeit erfordert, ist DMF nicht das richtige Tool.
Dual-Write: Synchronisation nahezu in Echtzeit innerhalb des Microsoft-Ökosystems
Dual-Write ist Microsofts native Infrastruktur für die bidirektionale Synchronisation nahezu in Echtzeit zwischen Dynamics 365 F&O und Microsoft Dataverse, der zugrunde liegenden Datenbank für Dynamics 365 Customer Engagement-Anwendungen wie Vertrieb, Außendienst und Kundenservice.
Wenn Dual-Write konfiguriert ist, löst eine Datenänderung in F&O fast sofort ein entsprechendes Update in Dataverse aus und umgekehrt. Es ist das richtige Tool, wenn ein Hersteller Stammdaten benötigt, um in allen Microsoft-Anwendungen ohne manuelle Synchronisierungsschritte einheitlich zu bleiben.
Wenn Hersteller Dual-Write verwenden
Ein Vertriebsmitarbeiter erstellt ein neues Kundenkonto in Dynamics 365 Sales. Dual-Write leitet diesen Kundendatensatz automatisch an F&O weiter. Produktkataloge, Preisstrukturen und Kundendatensätze bleiben im gesamten Microsoft-Ökosystem konsistent, ohne dass jemand manuell Daten zwischen den Systemen eingeben muss.
Wo Dual-Write Grenzen hat
Da Dual-Write synchron über zwei separate Datenbanken hinweg arbeitet, führt dies zu einem Leistungsaufwand. Wenn ein System vorübergehend nicht verfügbar ist, kann die Transaktion in beiden Fällen fehlschlagen. Daher eignet es sich gut für den Abgleich von Stammdaten, Kundendatensätzen, Produktkatalogen und Preisgestaltung, aber nicht für umfangreiche Transaktionsdaten wie Tausende einzelner Bestandsbewegungen oder Rohtelemetrie von Sensoren in der Werkstatt, wo DMF oder OData die geeignetere Wahl sind.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
