Die lange Reise durch Azure Services für die XML-Transformation und ihre Lehren

Die lange Reise durch Azure Services für die XML-Transformation und ihre Lehren

Dennis van der Wals | 9. Februar 2023
#Contextual Commerce

Bei foryouandyour-customers helfen wir Ihnen die benötigte Datenlogistik zu implementieren, zu pflegen und zu verbessern.

Als Data Engineers bei for​you​and​your​cus​tom​ers in München haben wir mit einem Kunden an einem Projekt gearbeitet, bei dem es darum ging, eine riesige Menge verschiedener XMLs in ein einziges, großes kombiniertes XML zu transformieren und die aktuelle Talend-basierte Lösung zu ersetzen. Es war eine Reise voller Überraschungen und Lektionen, die wir gerne mit Ihnen teilen, weil Sie sie vielleicht auch mit XMLs erleben.

Die Konsolidierung von Produktdaten hilft dabei, die Konsistenz und Genauigkeit von Produktinformationen über alle digitalen Kanäle hinweg sicherzustellen. Dies kann das Vertrauen und die Zufriedenheit der Kunden erhöhen sowie die Suchmaschinenoptimierung (SEO) und die Konversionsraten verbessern. Mit einem zentralisierten und aktuellen Produktdatenspeicher können Unternehmen ihre Abläufe optimieren, manuelle Fehler reduzieren und Zeit sparen, was zu Kosteneinsparungen und höherer Effizienz führt. Darüber hinaus ermöglicht eine zentrale Quelle für Produktinformationen eine datengestützte Entscheidungsfindung und gibt Unternehmen die Möglichkeit, Kundenbedürfnisse und  Kundenpräferenzen besser zu verstehen. Bei foryouandyourcustomers helfen wir Ihnen, die erforderliche Datenlogistik zu implementieren, zu pflegen und zu verbessern.

Ich möchte meine Erfahrungen mit dem Kampf und dem Spaß an der Suche nach einem Weg zur Ablösung der bestehenden Talend-Lösung für einen unserer Kunden aus der industriellen Fertigungsindustrie mit Ihnen teilen. Ich werde technische Details für ein interessiertes Publikum weitergeben, damit die gleichen Probleme vermieden werden können, mit denen wir konfrontiert waren, und um zu zeigen, wie wir auf unserem Weg nicht aufgaben.

Die steigende Anzahl von Transformationen und die Ressourcenanforderungen mehrerer Schichten von SQL-Tabellen, Prozeduren, Abfragen und tMaps hatten das System destabilisiert und die Prozesse erheblich verlangsamt. Azure und seine Data Factory erwiesen sich als Retter und boten eine skalierbare und kostengünstige Cloud-Lösung. Die Einführung einer geeigneteren NoSQL-Struktur anstelle eines flachen SQL-Tabellendesigns trug dazu bei, die prozessinterne Zuordnung von Datenfeldern zu optimieren und den Entwicklungsprozess zu vereinfachen, indem die intuitiven visuellen Komponenten der Azure Data Factory genutzt wurden, wodurch die Lernkurve und der Aufwand für die Entwickler reduziert wurden Sehr langer Satz).

Mit einem klaren Ziel vor Augen arbeiteten wir unermüdlich, überwanden die Schwierigkeiten und feierten die Erfolge auf dem Weg. Unsere harte Arbeit zahlte sich aus und das Endergebnis war ein stabiles, effizientes System, das die wachsenden Anforderungen des Geschäfts unseres Kunden erfüllen konnte.

Eine schnelle Projektinitialisierung

Die Anfangsphase des Projekts zeichnete sich durch ihre relative Einfachheit aus, wie die folgenden Schlüsselschritte zeigen:

  1. Einrichtung eines Blob-Speicher-Repositoriums für die Übertragung von XML-Dateien.
  2. Konfiguration einer CosmosDB zur Speicherung der importierten Daten. In Anbetracht der Größenbeschränkungen von CosmosDB haben wir beschlossen, jedes XML-Dokument für die Speicherung in der Datenbank in seine einzelnen Elemente zu unterteilen.
  3. Entwicklung von zwei kritischen Verfahren: a) Import von XML in CosmosDB und b) Extraktion und Formatierung von Daten aus CosmosDB für die Ausgabe im gewünschten XML-Format. Diese Verfahren bildeten die Grundlage für die erfolgreiche Durchführung des Projekts und ebneten den Weg für weitere Fortschritte.

Die Erstellung zusätzlicher Container schlug manchmal fehl.

Die anfängliche Reise war nichts weniger als bemerkenswert. Dank der Leistungsfähigkeit von Azure Data Factory (ADF) konnten wir mit Leichtigkeit große Fortschritte machen. Die Copy-Step-Funktion bot eine einfache, aber effektive Möglichkeit, unseren Blob-Speicher als Quelle zu konfigurieren. Die Konvertierung von XML-Dateien in JSON verlief dank der Standardkonvertierung zwischen XML und JSON reibungslos. Für die Definition der Hierarchieebene, die als Grundlage für die Iteration von Elementen aus XML verwendet werden soll, und die Abbildung der ersten Ebene benötigten wir nur wenige Stunden.

 

Es war jedoch nicht alles eitel Sonnenschein, da wir auf dem Weg dorthin mit einigen Herausforderungen konfrontiert wurden. Der ADF-Editor erwies sich als Hindernis, da wir den erweiterten Modus aktivieren mussten, um auf alle erforderlichen Funktionen zugreifen zu können. Dies führte zu einem kleinen Rückschlag, da wir einige Zeit benötigten, um dies herauszufinden. Dank unserer Entschlossenheit und unseres Fachwissens konnten wir jedoch auch dieses Hindernis überwinden.

Für diejenigen, die sich für die Einzelheiten interessieren, sind in der folgenden Datei die einzelnen Schritte aufgeführt:

PDF herunterladen

Die Befüllung in CosmosDB verlief reibungslos und war mit der endgültigen Pipeline im Handumdrehen erledigt. Damit begann die nächste Phase des Projekts.

Die mächtigen NoSQL-Abfragen von CosmosDB

Als wir mit dem Mapping der Quell- auf die Zielstruktur fortfuhren, stießen wir jedoch auf eine neue Herausforderung. Unsere Datenstruktur bestand aus mindestens zwei iterierbaren Ebenen, aber der Datenbearbeitungseditor konnte nur auf die erste Ebene zugreifen. Ein einfacher Flattening-Schritt von Azure Data Factory reichte nicht aus, um auf alle erforderlichen Daten zuzugreifen.

Objekte können nur eine komplexere Ebene erhalten. 

Wir beschlossen, dieses Problem mit Hilfe von Self-Joining zu lösen. Anstatt die Daten einfach als Container-Anfrage aus CosmosDB zu lesen, führten wir eine Abfrage durch, die die Daten auf jede gewünschte Ebene verflachen konnte. Auf diese Weise konnten wir verschiedene Hierarchien und getrennte Datenströme extrahieren und anhand ihrer Schlüssel zusammenführen, wodurch das Problem der Datenhierarchie gelöst wurde.

Nachdem die erste Einrichtung abgeschlossen war, passten wir zwei weitere XML-Dateiformate an, aber während der Debugging-Sitzungen stießen wir auf ein weiteres Problem. Die Konvertierung von XML in JSON durch die Azure Data Factory bestimmt das JSON-Format für jede Datei.

Dies kann zu einer inkonsistenten Datenstruktur führen, wenn XML keine Informationen über seine Struktur liefert, insbesondere ob eine Ebene iterierbar ist oder nicht. Die Lösung bestand darin, spezifische Abfragen zu generieren, eine mit einem Self-Join und die andere mit einem einfachen Mapping, und dann beide Ströme zu verbinden.

 

Azure und seine Fehler

Wir bereiteten das Endergebnis der verbundenen Datenströme für die Aggregation vor, wobei die Ausgabe im JSON-Format erfolgte. Eine weitere Herausforderung ergab sich jedoch, als wir feststellten, dass Azure Data Flows keine XML-Dateien exportieren kann. Diese Hürde war jedoch noch nicht das Ende, denn während der Fehlersuche stellte sich ein dringenderes Problem heraus. Obwohl der Datenfluss in Ordnung zu sein schien, generierte er während des Debugging-Prozesses keine Ergebnisse. Wir versuchten das Problem zu lösen, indem wir den Datenfluss in eine Pipeline einbetteten, doch seine Ausführung schlug unerwartet fehl. Es dauerte mehrere Tage, in denen wir die Fehlermeldung analysierten und interpretierten, bis wir endlich die Ursache des Problems herausfanden:

Sie können leicht erkennen, dass es sich um “@pos” handelt, aber wir konnten es nicht loswerden.

In dieser Phase des Prozesses stießen wir auf ein bedeutendes Hindernis, das unseren gesamten bisherigen Fortschritt zunichte zu machen drohte. Das Problem ergab sich daraus, dass Azure Data Flows nicht in der Lage war, Strukturen zu interpretieren, die das Zeichen „@” enthielten. Die Ursache des Problems lag in der automatischen Konvertierung von XML, die dazu führte, dass allen Tag-Attributen, einschließlich tieferer Hierarchieebenen, „@” -Zeichen hinzugefügt wurden. Das Copy-Step-Mapping in ADF konnte keine Schlüssel für diese tieferen Ebenen setzen und es gab keinen Prozess, um das „@” -Zeichen nachträglich zu ersetzen.

Zusammenfassung der Reproduktion:

  1. Azures Prozesse fügen sich wiederholenden XML-Elemente bei der Konvertierung nach JSON ein „@”-Zeichen an alle ihre Attribute an.
  2. Azure bietet keine Möglichkeit, dieses Verhalten zu ändern.
  3. Dieses JSON wird in CosmosDB gespeichert.
  4. Azure benötigt die Datenstruktur des CosmosDB-Containers, um einen DataFlow zu erstellen.
  5. Azure generiert eine DataFlow-Beschreibung, die „@”-Zeichen in der Datenstrukturdefinition enthält.
  6. Azure hat keine Möglichkeit, das „@”-Zeichen zu umgehen.
  7. Azure kann einen solchen DataFlow im Debug-Modus ausführen, aber nicht in einer Pipeline.

Dies war kein triviales Problem und wir brauchten mehrere Tage, um Fehlermeldungen zu interpretieren und Fehler zu beheben, bevor wir erkannten, was passiert war. Wir erstellten ein Support-Ticket bei Azure in der Hoffnung, dass sie das Problem beheben könnten. Nachdem wir mehrere Wochen auf eine Lösung gewartet hatten, wurde uns klar, dass wir einen Workaround finden mussten.

Erschwerend kam hinzu, dass CosmosDB, in dem wir unsere Daten gespeichert hatten, ebenfalls von dem Problem mit dem „@”-Symbol betroffen war. Azure benötigt die Datenstruktur des CosmosDB-Containers, um einen DataFlow zu erstellen, und das ADF erzeugt eine DataFlow-Beschreibung, die „@”-Zeichen in der Strukturdefinition enthält. Darüber hinaus gibt es in Azure keine Möglichkeit, diese Zeichen zu umgehen, was bedeutet, dass der DataFlow zwar im Debug-Modus, aber nicht in einer Pipeline ausgeführt werden kann.

In Anbetracht dieser Herausforderungen standen wir vor einer schwierigen Entscheidung. Wir konnten keine Abfragen verwenden, um das Problem zu lösen, da diese auch das „@”-Symbol enthalten würden. Unsere Möglichkeiten waren begrenzt, aber wir entschieden uns schließlich dafür, die Importprozedur zu ändern, um CosmosDB zu umgehen, und stattdessen eine benutzerdefinierte Prozedur in Java oder Python zu verwenden. Diese Lösung würde den Prozess zwar komplizierter machen, aber es würde uns erlauben, die Dinge so einfach und generisch wie möglich zu halten.

Azure Logic Apps für die Datenumwandlung

Als wir uns eingehender mit der Lösung befassten, entdeckten wir eine fantastische Lösung in Azure Logic Apps. Dieses Tool erwies sich als vielseitig bei der Lösung der beiden Probleme 4 und 5 aus der obigen Liste, da es uns die Konvertierung zwischen XML- und JSON-Strukturen mit der Liquid-Vorlagensprache ermöglichte. Wir nutzten seine Funktionalität, indem wir ein Mapping in ein Integrationskonto luden und eine Logic-App als REST-Dienst erstellten und mit ihr verknüpften. Das Ergebnis war ein optimierter Prozess, bei dem der Inhalt der XML-Datei durch die Logik-App geleitet werden konnte, das Transformations-Mapping angewendet wurde und die resultierende JSON-Ausgabe empfangen werden konnte. Es war eine elegante Lösung, die sich wie eine Glühbirne anfühlte, und wir waren begeistert, sie gefunden zu haben.

Wir stießen jedoch auf ein Hindernis, als wir versuchten, die XML-Datei von einer ADF-Pipeline an den REST-Aufruf zu übergeben. Die verfügbaren Variablen und ihre Größenbeschränkungen hinderten uns daran, diese Methode zu verwenden. Stattdessen verwendeten wir den Copy-Step, um die XML-Datei zu lesen und in JSON zu konvertieren und den Inhalt direkt an die REST-API zu senden. Für diese Lösung mussten wir die Liquid-Vorlage anpassen, da sich die resultierende JSON-Struktur von der ursprünglichen XML-Struktur unterschied.

Das Parsen der Werte war nun schnell möglich, aber wir stießen erneut auf eine Einschränkung: Der Copy-Step kann die zurückgegebenen Werte nicht verarbeiten und auch nicht weiterverarbeiten. Die Logic-App konnte den Inhalt der XML-Datei empfangen, die Transformation durchführen und das resultierende JSON direkt in CosmosDB speichern, ohne dass ein Rückgabewert erforderlich war.

Wir fügten der Anwendung zusätzliche Logik hinzu, um all die verschiedenen Vorlagen und Mappings auf der Importseite zu handhaben und die Systemlandschaft schlank und einfach zu halten. Eine weitere Logic-App wurde erstellt, um das resultierende JSON zurück in die erforderliche XML-Struktur zu konvertieren. Dieser Prozess erforderte eine Konvertierung von JSON in Text, da Azure keine direkte JSON-zu-XML-Transformation anbietet.

Die optimierte Datenstruktur in CosmosDB erleichterte die DataFlow-Transformation erheblich, da die Self-Joins vermieden werden konnten. Die Struktur wurde bereits während des Imports geglättet, so dass sich die Gesamtzahl ähnlicher Schritte nicht erhöhte. Sie verlagerte sich lediglich vom DataFlow zu einer Logic-App.

Am Ende waren weniger Schritte erforderlich als ursprünglich angenommen, und trotz der Herausforderungen konnten wir die XML-Dateien erfolgreich transformieren.

Die Lösung

Nach der erfolgreichen Implementierung von Azure und seiner Datenfabrik war das Team begeistert und erleichtert. Die Lösung war skalierbar, kosteneffizient und bot ein zentrales Repositorium für Produktdaten. Die Einfachheit der Anfangsphase mit der Einrichtung eines Blob-Storage-Repositorys und der Konfiguration von CosmosDB machte den Projektstart zu einem Kinderspiel. Das Team sah sich auf dem Weg dorthin mit einigen Herausforderungen konfrontiert, wie zum Beispiel Problemen mit dem ADF-Editor, aber ihre Entschlossenheit und ihr Fachwissen halfen ihnen dabei. Die abschließende Befüllung von CosmosDB verlief reibungslos und das Team war bereit für die nächste Phase des Projekts. Die Möglichkeit, das Problem mehrerer iterierbarer Schichten durch die Verwendung von Self-Joining zu lösen, machte das Team noch zufriedener, da dies eine größere Flexibilität bei der Datenmanipulation ermöglichte. Das Team war dankbar für die Lösung, die Azure und seine Data Factory bereitstellten, die die Konsistenz und Genauigkeit der Produktinformationen verbesserte, manuelle Fehler reduzierte und eine datengestützte Entscheidungsfindung ermöglichte.

Weitere Magazinbeiträge