Die Entwicklung von DataBridge in C#

DataBridge: eine universelle Synchronisierungsschicht mit dynamischem JSON und ExpandoObject-Nutzdaten

DataBridge entstand als wiederverwendbare Synchronisierungsplattform, die Geschäftsdaten aus einer lokalen Verwaltungsumgebung in entfernte Systeme wie HTTP-Dienste, Microsoft SQL Server und MySQL überträgt. Sie wurde nicht als einmaliges Exportwerkzeug konzipiert, sondern als dauerhafte Verbindung zwischen sehr unterschiedlichen technischen Umgebungen. Dabei bleibt sie flexibel genug, auch dann zu funktionieren, wenn die genaue Datenstruktur im Voraus noch nicht bekannt ist.

Eine der wichtigsten technischen Entscheidungen war ein dynamisches Nutzdatenmodell auf Basis von Dictionaries, JSON-Serialisierung und ExpandoObject-Instanzen, die über die interne ObjectFactory erzeugt werden. Dieser Ansatz macht DataBridge wesentlich universeller als eine herkömmliche Integration, die für jede Tabelle und jeden Datensatztyp starre DTO-Klassen voraussetzt.

Der Projektkontext

In vielen Unternehmen enthält das Quellsystem wertvolle Betriebsdaten, eignet sich aber nicht als direktes Backend für Webanwendungen, Portale, Dashboards oder Integrationen. Altsysteme haben häufig eingeschränkte Verbindungsmöglichkeiten, Tabellenstrukturen, die nicht für moderne Anwendungen ausgelegt sind, und betriebliche Vorgaben, die eine direkte Freigabe riskant machen.

DataBridge löst dies als Umwandlungs- und Synchronisierungsschicht. Sie liest Quelldaten, ermittelt Tabellenstrukturen, bereitet entfernte Tabellen vor, verfolgt den Synchronisierungsbedarf und sendet die Daten an das konfigurierte Ziel. Je nach Installation ist das ein HTTP-basierter Bridge-Endpunkt, Microsoft SQL Server oder MySQL.

Eine besondere Stärke der Umsetzung ist, dass für mögliche Datensatzstrukturen kein fest programmiertes Klassenmodell benötigt wird. Stattdessen verpackt DataBridge Datensätze dynamisch und überträgt sie in einer Struktur, die flexibel bleibt, bis die Empfängerseite über ihre Speicherung entscheidet.

Die zentrale Herausforderung: Daten übertragen, ohne jedes Schema fest zu programmieren

Herkömmliche Integrationen werden oft störanfällig, weil sie ein festes Objektmodell erwarten. Jede Tabelle, jede Feldliste und jeder Nutzdatentyp muss vorab im Code abgebildet werden. Für kleine Systeme funktioniert das. Teuer wird es, wenn eine Integration viele Tabellen, sich verändernde Strukturen, unterschiedliche Mandanten und mehrere entfernte Backends unterstützen muss.

DataBridge verfolgt einen universelleren Ansatz. Bei der Synchronisierung werden Quelldatensätze zunächst in einem Dictionary<string, object> gesammelt. Jede Zeile wird zu einer dynamischen Zuordnung von Feldnamen zu Werten statt zu einer starren Klasseninstanz. Zeichenketten werden bereinigt, Datumswerte in sicher übertragbare Zeichenketten normalisiert, boolesche Werte beibehalten und Zahlen einheitlich konvertiert. Vor dem Versand wird außerdem der Mandantenkontext ergänzt, etwa ADMINCODE.

Diese zwischengeschaltete Dictionary-Struktur ist entscheidend. Sie ermöglicht es, Daten zu übertragen, deren endgültige Form sich aus Metadaten und der Laufzeitkonfiguration ergibt, statt aus Annahmen zur Kompilierzeit. Anders gesagt: DataBridge kann Datensätze transportieren, ohne sie vollständig als stark typisierte C#-Modelle kennen zu müssen.

Die Rolle der ObjectFactory

Die interne ObjectFactory macht diese Flexibilität praktisch nutzbar. Ihre Methode CreateInstance nimmt ein Dictionary<string, object> entgegen und wandelt es in ein dynamisches ExpandoObject um. Jedes Schlüssel-Wert-Paar aus dem Dictionary wird zur Laufzeit in das erweiterbare Objekt kopiert.

Diese Infrastrukturkomponente wirkt schlicht, hat aber große Auswirkungen auf die Architektur. Sobald die Nutzdaten als ExpandoObject vorliegen, kann DataBridge sie in Anfrageobjekte aufnehmen, ohne für jede Tabelle oder Operation eine eigene kompilierte Klasse zu benötigen. Im Anfragemodell sind Felder wie data und parameters als generische object-Eigenschaften angelegt. Die vollständige Anfrage wird mit Newtonsoft.Json als JSON serialisiert.

Damit kann DataBridge Folgendes verpacken:

• Dynamische Datensatzsammlungen für Synchronisierungsstapel.
• Zur Laufzeit erzeugte Parameter für Vorgänge wie das Anlegen entfernter Tabellen.
• Schemabezogene Metadaten, die sich je nach Tabelle oder Mandant unterscheiden können.
• Strukturen, die sich nicht sinnvoll in einer statischen Klassenhierarchie festschreiben lassen.

Praktisch wandelt ObjectFactory ein einfaches Dictionary in einen übertragungsfertigen Objektgraphen um, der sich wie natives JSON verhält. So bleibt DataBridge anpassbar, ohne dass die Codebasis unübersichtlich wird.

Warum ExpandoObject hier wichtig ist

ExpandoObject ist hier nicht nur eine Komfortfunktion. Es ist wesentlich dafür, dass DataBridge universell einsetzbar bleibt.

Ein ExpandoObject kann Eigenschaften dynamisch zur Laufzeit erhalten. Das passt hervorragend zur Synchronisierung von Datensätzen aus Tabellen mit sehr unterschiedlichen Feldern. Statt Dutzende oder Hunderte spezifische Nutzdatenmodelle zu pflegen, kann DataBridge die Datenstruktur aus dem tatsächlichen Zeileninhalt aufbauen und unmittelbar weiterleiten.

Daraus ergeben sich mehrere wichtige Vorteile:

• Viele unterschiedliche Tabellen lassen sich unterstützen, ohne wiederholt separate Modelle pflegen zu müssen.
• Felder können aus der Datenbankstruktur ermittelt werden, statt im Quellcode vordefiniert sein zu müssen.
• Neue Tabellen oder Varianten lassen sich leichter ergänzen.
• Dieselbe Verarbeitungskette für Anfragen kann unterschiedliche Vorgänge und Übertragungsziele bedienen.

Genau deshalb verarbeitet DataBridge Nutzdaten tatsächlich universell. Das Übertragungsformat ist flexibel genug für unbekannte oder veränderliche JSON-Strukturen und zugleich ausreichend strukturiert für eine kontrollierte Verarbeitung auf der Empfängerseite.

Wie dynamische Nutzdaten DataBridge durchlaufen

Der interne Ablauf lässt sich als mehrstufige Umwandlungskette beschreiben.

1. Die Quelldatensätze werden aus der lokalen Mandantendatenbank gelesen.
2. Jede Zeile wird in ein Dictionary aus Feldnamen und Werten umgewandelt.
3. Das Dictionary wird normalisiert, damit Zeichenketten, Datumswerte, boolesche Werte und Zahlen sicher und einheitlich übertragen werden können.
4. ObjectFactory.CreateInstance wandelt das Dictionary in ein ExpandoObject um.
5. Das dynamische Objekt wird den Nutzdaten einer Anfrage hinzugefügt, die außerdem Tabellenname, Mandant, Primärschlüssel und Strukturmetadaten enthält.
6. Die Anfrage wird als JSON serialisiert und an das konfigurierte Backend gesendet.
7. Das empfangende Backend interpretiert die dynamischen Nutzdaten und setzt sie in SQL-Operationen zum Einfügen, Aktualisieren oder Löschen um.

Weil das Anfragemodell data und parameters als generische Objekte speichert, kann dieselbe äußere Anfragestruktur für viele Bridge-Aktionen verwendet werden. Dazu gehören die Synchronisierung von Datensätzen sowie das Anlegen und Entfernen von Tabellen. Die Umsetzung vermeidet unnötige Spezialisierung und hält die Bridge-Logik einheitlich.

Unbekanntes JSON empfangen, nutzbare Daten erzeugen

Eine besondere Stärke dieses Entwurfs ist, dass DataBridge JSON-artige Strukturen problemlos verarbeitet, selbst wenn die genaue Anordnung ihrer Eigenschaften erst zur Laufzeit bekannt wird. DataBridge baut diese Strukturen aus Dictionaries auf, serialisiert sie ohne starre Klassenvorgaben und rekonstruiert am anderen Ende wieder nutzbare Sammlungen von Schlüssel-Wert-Paaren.

Auf der Empfängerseite wandeln sowohl der Microsoft-SQL-Server- als auch der MySQL-Verarbeitungspfad die dynamischen Datensatznutzdaten zurück in Dictionaries um, damit die SQL-Erzeugung generisch damit arbeiten kann. Der mittlere Teil der Verbindung bleibt dadurch flexibel. Die Persistenzschicht behält dennoch präzise Kontrolle über Feldnamen, Werteformatierung, Primärschlüsselprüfungen und die Entscheidung zwischen Einfügen und Aktualisieren.

Das ist die entscheidende Balance der Architektur: dynamisch beim Transport, gezielt und kontrolliert bei der Ausführung.

Universell durch die Architektur, nicht durch das Marketing

Eine Plattform als „universell“ zu bezeichnen, ist nur dann aussagekräftig, wenn ihre interne Umsetzung diesen Anspruch trägt. Bei DataBridge zeigt sich das konkret:

• Dieselbe Anfragestruktur kann HTTP, Microsoft SQL Server oder MySQL ansprechen.
• Dasselbe Nutzdatenkonzept kann Datensätze unterschiedlicher Tabellen ohne eigene Modellklassen abbilden.
• Dieselbe dynamische Objekterzeugung wird für Datenstapel und Betriebsparameter wiederverwendet.
• Dieselbe Synchronisierungs-Engine funktioniert über unterschiedliche Mandanten und Bereitstellungsmodelle hinweg.

Deshalb ist der Ansatz mit ObjectFactory und ExpandoObject so wichtig. Er beseitigt unnötige Kopplungen zwischen Quell- und Übertragungsschema. Ändert sich die Datenstruktur, muss nicht die gesamte Verbindung angepasst werden. DataBridge kann weiterhin mit einer dynamischen, aber kontrollierten Darstellung der Nutzdaten arbeiten.

Praktische Vorteile des dynamischen Ansatzes

Die flexible JSON-Verarbeitung ist nicht nur eine technische Vorliebe. Sie bringt konkrete Vorteile im Betrieb.

• Neue oder geänderte Felder lassen sich mit wesentlich weniger Codeumbau berücksichtigen.
• Mehr Tabellen und kundenspezifische Varianten sind möglich, ohne dass das Klassenmodell ausufert.
• Die Wahl des Backends bleibt eine Konfigurationsfrage und erfordert keinen Neuentwurf der Nutzdaten.
• Die Transportschicht bleibt für unterschiedliche Synchronisierungsfunktionen wiederverwendbar.
• Das Projekt bleibt leichter wartbar, weil sich seine Logik auf das Erkennen und Umwandeln von Strukturen konzentriert statt auf zahllose Objektdefinitionen.

Für ein System, das ältere Unternehmenssoftware mit modernen Plattformen verbinden soll, ist das entscheidend. Integrationssoftware muss Unterschiede auffangen können. Genau dafür wurde DataBridge entwickelt.

Mehr als ein Werkzeug zur Datenübertragung

Neben dem dynamischen JSON-Ansatz enthält DataBridge auch die weitergehenden Mechanismen für eine zuverlässige Synchronisierung. Sie ermittelt Tabellendefinitionen und Primärschlüssel, bereitet entfernte Strukturen vor, verfolgt Synchronisierungsaufgaben und überträgt Datensätze stapelweise. Sie unterstützt sowohl Installationen mit einer einzigen Datenbank als auch separate entfernte Datenbanken je Mandant. Damit verbindet das Projekt Flexibilität zur Laufzeit mit einer methodischen Synchronisierung im praktischen Einsatz.

Das Ergebnis ist mehr als eine einfache Anbindung: eine Middleware-Plattform, die Verwaltungsdaten aus Altsystemen für Websites, Portale, Berichtssysteme und individuelle Unternehmensanwendungen nutzbar macht.

Fazit

Die Besonderheit von DataBridge liegt im Umgang mit Daten, die nicht vorab vollständig im Code festgelegt sein müssen. Datensätze werden als Dictionaries aufgebaut, über ObjectFactory in ExpandoObject-Instanzen umgewandelt, als JSON serialisiert und auf der Empfängerseite generisch rekonstruiert. So erreicht die Verbindung eine Anpassungsfähigkeit, die vielen herkömmlichen Integrationen fehlt.

Dieser flexible Umgang mit unbekanntem JSON macht DataBridge tatsächlich universell. Er ermöglicht die Verbindung sehr unterschiedlicher Systeme, hält die Transportschicht schlank und dynamisch und liefert trotzdem zuverlässige, kontrollierte Ergebnisse in der Zielumgebung. Für eine Integrationsplattform, die unterschiedliche Schemata, mehrere Backends und wachsende geschäftliche Anforderungen bewältigen soll, gehört das zu den stärksten Architekturentscheidungen.