Verdammt sei diese Datenformat-Hölle

Einstellung

Du bist die Person, die bei ACME Corp. für die Betreuung und den Betrieb der Datenverarbeitungsinfrastruktur zuständig ist. Das ist die komplexe und empfindliche Maschinerie, die die gesamte schwere Datenverarbeitung in deinem Unternehmen übernimmt, aber nie die Anerkennung dafür bekommt. Es ist die Pumpe, die niemals aufhören darf zu pumpen, der Treibstoff, der alles am Laufen hält.

Doch wenn deine Eltern, Freunde oder sogar Kollegen dich fragen, was du bei ACME machst, schlafen sie mitten in deiner begeisterten Erklärung ein.

Seien wir ehrlich: Du bekommst nicht genug Anerkennung für das, was du für die Welt tust 🙃

Herausforderungen

Dein Job erfordert zwar nicht, dass du in einem Mechaniker-Outfit herumläufst, aber es fühlt sich oft so an, als müsstest du ständig beobachten, reparieren, korrigieren und einfach neuen Schwung in diese datenverarbeitende Infrastruktur bringen.

Während es viele alltägliche Herausforderungen gibt, ist eine davon das Thema VERÄNDERUNG. Ja, man sagt, niemals ein laufendes System ändern, aber so funktioniert die Welt nun mal nicht. Eine der häufigeren Veränderungen ist …

Datenformatänderung

AAHHHH! Alarmstufe Rot … Sirenen heulen …! Wenn es um Datenformatänderungen geht, treten oft mehrere Herausforderungen gleichzeitig auf:

1. Datenschnittstellen sind oft im Quellcode fest codiert. Du kannst sie nicht einfach "ändern" (wie der Chef vorschlägt), oder zumindest ist es nicht so einfach.
2. Während der Migration werden Daten sowohl im alten als auch im neuen Format empfangen. Selbst bei einer kleinen Änderung sind das immer noch zwei verschiedene Formate, die parallel verarbeitet werden müssen.
3. Es geht nicht nur um ein weiteres Feld. Manchmal handelt es sich um eine komplett neue Datenstruktur und eine Menge anderer Dinge gleichzeitig.
4. Geänderte Daten können eine interne Verarbeitung zusätzlicher Informationen erfordern. Auch hier gilt: Dinge sind möglicherweise fest codiert, und der Code muss geändert werden, um dies zu berücksichtigen.
5. Du hast keinen Kaffee mehr. Das hilft auch nicht.

Wir haben hier zwei Hauptprobleme:

1. Änderung des Codes und
2. Umgang mit der Formatmigration.

Das kann ganz schön Kopfschmerzen bereiten und lange Planungs-, Entwicklungs-, Release-, Test- und letztendlich Bereitstellungszyklen erfordern.

Wenn es doch nur einen besseren Weg gäbe, dies schnell und einfach zu erledigen ...

Generische Datenformate zur Rettung

layline.io bietet Generische Datenformate, die nicht alle der oben genannten Herausforderungen lösen können, aber die meisten davon, die meiste Zeit.

Was sind Generische Datenformate?

Wie der Name schon sagt, ermöglicht dieses Konzept die Definition von Datenformaten auf generische Weise. Dazu bietet es:

1. eine Sprache, um die Struktur (Grammatik) des Formats zu definieren, mit dem du dich auseinandersetzt.
2. Diese Sprache verwendet reguläre Ausdrücke, um einzelne Elemente einer Struktur zu definieren und zu identifizieren, und dann
3. Unterelemente dieser Struktur usw.
4. Sie ist objektorientiert, sodass du Elementstrukturen definieren und wiederverwenden kannst.

Wie sieht diese Sprache aus?

Schauen wir uns das an. Zu diesem Zweck arbeiten wir mit einem super einfachen Datenformat, das durch Kommas getrennt ist und einen Header-Datensatz, 1..n Detaildatensätze und einen Trailer-Datensatz enthalten muss.

Beispieldaten eines einfachen Banktransaktionsprotokolls:

H;Sample Bank Transactions
D;20-Aug-2021;NEFT;23237.00;00.00;37243.31
D;21-Aug-2021;NEFT;00.00;3724.33;33518.98
T;100

Und so wird dieses Format in layline.io mit der generischen Grammatiksprache definiert:

format {
  name = "Bank Transactions" 
  description = "Random bank transactions"

  start-element = "File"
  target-namespace = "BankIn"

  elements = [
    // File sequence
    {
      name = "File"
      type = "Sequence"
      references = [
        { name = "Header", referenced-element = "Header" },
        { name = "Details", max-occurs = "unlimited", referenced-element = "Detail" },
        { name = "Trailer", referenced-element = "Trailer" }
      ]
    },
    // Header record 
    {
      name = "Header"
      type = "Separated"
      regular-expression = "H"
      separator-regular-expression = ";"
      separator = ";"
      terminator-regular-expression = "\n"
      terminator = "\n"
      mapping = { message = "Header", element = "BT_IN" }
      parts = [
        { name = "RECORD_TYPE", type = "RegExpr", regular-expression = "[^;\n]*", value.type = "Text.String" },
        { name = "FILENAME", type = "RegExpr", regular-expression = "[^;\n]*", value.type = "Text.String" }
      ]
    },
    // Detail record
    {
      name = "Detail"
      type = "Separated"
      // ... ähnliche Struktur
    },
    // Trailer record
    {
      name = "Trailer"
      type = "Separated"
      // ... ähnliche Struktur
    }
  ]
}

Das format-Element

Alles beginnt mit dem obersten format-Element:

Neben einem name und einer description enthält es auch ein Array von elements. Diese Elemente definieren eine Reihe von Unterelementen (Klassen), die unterschiedliche Typen haben können.

Das File-Element vom Typ Sequence

Dieses Element definiert eine logische Struktur von Unterelementen in seiner references-Struktur:

Man kann erkennen, dass hier ein Baum aufgebaut wird:

Vorläufiges Fazit

Wir haben gelernt, dass die Funktionsweise der Grammatiksprache wie folgt ist:

1. Eine Grammatik besteht aus einer Reihe von Elementen.
2. Diese Elemente haben unterschiedliche Typen, die verschiedene Zwecke erfüllen.
3. Das anfängliche Element ist format, das auf ein Start-Element verweist.
4. Du kannst beliebig viele zusätzliche Elemente definieren.
5. Einige Elemente können dann auf andere Elemente verweisen.

Wie sieht es mit anderen, komplexeren Formaten aus?

Folgendes funktioniert ebenfalls:

• Sehr komplexe ASCII/Unicode-Formate
• Bedingtes Datenparsing durch Verwaltung des Parser-Zustands
• Binäre Strukturen
• Eine Mischung aus ASCII- und Binärformaten

Wir glauben, dass dies mehr als 80 % aller Datenübertragungsformate abdeckt.

Unterstützung für mehrere Formate

Du kannst beliebig viele Formate definieren. layline.io kompiliert alle zu einem "Super-Format" zur Laufzeit. Dies ermöglicht dir:

• auf alle Formate von überall zu verweisen,
• Daten von einem Format in ein anderes zu mappen,
• neue Nachrichteninstanzen basierend auf einem bestimmten Format zu erstellen,
• Daten in einem der definierten Formate zu importieren oder auszugeben.

Wo konfiguriere ich das alles?

Wir haben eine benutzerfreundliche Oberfläche bereitgestellt, die dir hilft, alle Konfigurationen vorzunehmen. Du findest sie im webbasierten layline.io Configuration Center unter Project --> Formats --> Generic Format:

Und es hört hier nicht auf. Während du deine Grammatik definierst, kannst du eine Beispieldatei hochladen und nebeneinander sehen, ob deine Grammatik mit der Struktur der Beispieldatei übereinstimmt:

Ziemlich cool, oder?

Zugriff auf Daten innerhalb der Logik

Sobald du eine oder mehrere Grammatiken in layline.io definiert hast, kannst du auf einzelne Elemente und Strukturen darin zugreifen:

Beispiel: Datenzugriff innerhalb eines Mapping-Assets

Beispiel: Datenzugriff innerhalb eines Javascript-Assets

Umgang mit Formatänderungen

Wenn wir auf die Herausforderungen zurückblicken, die wir zu Beginn besprochen haben, sollte jetzt klarer sein, wie einfach es ist, sich an Formatänderungen anzupassen.

• Ein weiteres Feld benötigt? Einfach zur Grammatik hinzufügen.
• Eine ganz neue Datensatzstruktur benötigt? Wiederum einfach zur Grammatik hinzufügen.
• Müssen eine alte und eine neue Version eines Detaildatensatzes gleichzeitig berücksichtigt werden? Kein Problem: Du kannst ein Choice-Element einfügen, um entweder eine Detail-Old- oder Detail-New-Version zuzulassen.
• Inhalte basierend auf anderen Inhalten berechnen? Einfach Formeln hinzufügen.

Alles ist abgedeckt.

Ressourcen

• Weitere Informationen über layline.io findest du hier.
• Kontaktiere uns unter hello@layline.io.