Datenintegration · Prio 8 · Version 4

File Transfer / ETL / Data Warehouse

CSV/XML/Fixed-Width-Dateien, SFTP, ETL-Strecken, Staging-Tabellen, Datenqualitaet und Reporting-Lieferketten.

← Startseite
Kurzverständnis und Systemgrenze

Dateibasierte Integration lebt lange, weil sie robust, auditierbar und fuer Partner einfach ist. Typische Formate sind CSV, XML, fixed-width, Excel-Exporte oder komprimierte Paketdateien mit Kontrollsummen.

Die Semantik steckt in Dateinamen, Spaltenreihenfolge, Encoding, Trennzeichen, Headern, Trailer-Zeilen, Kontrollsummen und fachlichen Abstimmregeln. Diese Regeln fehlen oft im Code und existieren nur in Betriebswissen.

Modernisierung muss Datenqualitaet, Lineage und Wiederholbarkeit erhalten. Ein neues Event-Streaming ersetzt nicht automatisch regulatorische Lieferdateien oder historische DWH-Beladung.

Daten- und Verantwortungsgrenze: File- und ETL-Strecken besitzen oft keine Online-Fachlogik, aber sie erzeugen analytische Wahrheit und externe Lieferpflichten. Eine fehlende Datei kann fachlich schlimmer sein als ein HTTP-Fehler, weil sie Monatsreporting oder Partnerabrechnung blockiert.
Fachliche und technische Darstellung
Fachliche Sicht File Transfer / ETL / Data Warehouse
Fachliche Sicht: Prozess, Verantwortung, Nachweis.
Technische Sicht File Transfer / ETL / Data Warehouse
Technische Sicht: Komponenten, Protokolle, Betriebsbezug.
Wichtige Begriffe und Artefakte

Staging

Zwischenbereich fuer technische Aufnahme und fachliche Validierung.

Trailer Record

Schlusssatz mit Anzahl, Summe oder Hash zur Abstimmung.

Data Quality Rule

Regel fuer Vollstaendigkeit, Wertebereich, Referenzdaten oder Dubletten.

Lineage

Herkunft und Transformation eines Datenfeldes ueber Systeme hinweg.

Typischer Ablauf Schritt für Schritt
  1. Partner oder Kernsystem legt Datei auf SFTP ab.
  2. Importjob prueft Name, Encoding, Header, Trailer und Kontrollsumme.
  3. Daten landen in Staging-Tabellen mit technischer Lauf-ID.
  4. ETL transformiert, validiert und laedt DWH oder Fachsystem.
  5. Abstimmbericht meldet geladene, fehlerhafte und abgewiesene Datensaetze.
Ausführliche Praxisbeispiele mit Code und Konfiguration

Die Beispiele sind bewusst nicht minimalistisch. Sie zeigen typische Artefakte, die man in echten Legacy-Analysen findet: Schnittstellenverträge, Containerkonfiguration, SQL/PL-SQL, Jobdefinitionen, Queue-Regeln oder Adaptercode.

Fixed-Width Vertrag
Position  Laenge  Feld              Regel
1-10      10      PARTNER_ID        numerisch, fuehrende Nullen
11-22     12      CONTRACT_NO       alphanumerisch
23-30     8       BOOKING_DATE      YYYYMMDD
31-42     12      AMOUNT_CENT       signed integer, Cent
43-45     3       CURRENCY          ISO-4217
46-46     1       RECORD_TYPE       D=Detail, T=Trailer
Staging Tabellenmodell
CREATE TABLE STG_PARTNER_FILE_RUN (
  RUN_ID        NUMBER PRIMARY KEY,
  FILE_NAME     VARCHAR2(255),
  FILE_HASH     VARCHAR2(128),
  STATUS        VARCHAR2(30),
  RECEIVED_AT   TIMESTAMP,
  LOADED_AT     TIMESTAMP
);
CREATE TABLE STG_PARTNER_BOOKING (
  RUN_ID        NUMBER,
  LINE_NO       NUMBER,
  CONTRACT_NO   VARCHAR2(12),
  AMOUNT_CENT   NUMBER,
  ERROR_CODE    VARCHAR2(40),
  RAW_LINE      VARCHAR2(4000)
);
Shell Import mit atomarem Move
set -euo pipefail
IN=/sftp/incoming
WORK=/data/work
ARCHIVE=/data/archive
file="$1"
sha256sum "$IN/$file" > "$WORK/$file.sha256"
mv "$IN/$file" "$WORK/$file.processing"
java -jar partner-import.jar --file "$WORK/$file.processing" --checksum "$WORK/$file.sha256"
mv "$WORK/$file.processing" "$ARCHIVE/$file.done"
Risiken, Fehlerbilder und Diagnose
AspektBeschreibung
Fachliches RisikoUnklare Verantwortung fuer Partnerdatei fuehrt zu widerspruechlichen Entscheidungen zwischen Alt- und Neusystem.
Technisches RisikoSFTP und angrenzende Komponenten werden isoliert betrachtet; Laufzeitkopplung bleibt verborgen.
BetriebsrisikoFehlerkanal, Monitoring, Restart oder manuelle Klaerung sind nicht ausreichend dokumentiert.
MigrationsrisikoNeue Architektur uebernimmt Daten oder Schnittstellen, ohne fachliche Invarianten und historische Sonderfaelle abzusichern.
Typische Fallen:
  • Encoding oder Dezimaltrennzeichen aendert sich ohne Schemafehler.
  • Datei wird doppelt verarbeitet, weil Lauf-ID oder Hash fehlt.
  • DWH-Reports basieren auf transformierten Feldern, deren Herkunft niemand kennt.
  • Neue APIs werden gebaut, aber Partner koennen nur Dateien liefern.
Modernisierungspfad und geeignete Entwurfsmuster
PatternEinsatz in diesem System
Strangler Fig PatternNeue Funktionalitaet vor das Altsystem setzen und Altanteile schrittweise herausloesen.
Anti-Corruption LayerAltbegriffe, technische Codes und Datenformate vom neuen Domänenmodell trennen.
FacadeKomplexe Legacy-Operationen hinter klaren fachlichen Use-Case-Methoden kapseln.
AdapterProtokolle und Formate wie SOAP, MQ, Copybook, SQL oder File in Ports uebersetzen.
Golden Master TestBestehendes Verhalten mit Referenzdaten erfassen und gegen neue Implementierung vergleichen.
Empfohlene Schritte:
  • Fuehre Dateivertrag mit Format, Encoding, Pflichtfeldern, Kontrollsummen und Beispiel ein.
  • Nutze Staging mit Lauf-ID, Hash, Status und Fehlerdetails.
  • Automatisiere Datenqualitaetsberichte und fachliche Abstimmung.
  • Plane Koexistenz von File, API und Event, statt Dateien vorschnell abzuschaffen.
Analysefragen für echte Projekte
  • Wer besitzt fachlich die Wahrheit fuer Partnerdatei?
  • Welche technische Komponente ist kritisch: SFTP, CSV/XML/Fixed Width, ETL Tool?
  • Welche Daten werden veraendert, gelesen, abgeleitet oder nur transportiert?
  • Welche Fehler sind fachlich erwartbar und welche sind technische Stoerungen?
  • Welche Protokolle, Dateien, Tabellen, Queues oder Reports bilden den offiziellen Vertrag?
  • Wie wird ein Fehler heute erkannt, korrigiert und gegenueber dem Fachbereich nachgewiesen?
  • Welche Teile lassen sich lesend modernisieren und welche sind schreibend hochkritisch?
  • Welche Tests sichern aktuelles Verhalten, bevor Refactoring oder Migration beginnt?
Übung

Definiere fuer eine Partnerdatei einen technischen und fachlichen Vertrag. Baue dazu Staging-Status, Duplicate-Erkennung, Trailer-Abstimmung, Fehlerdatei und Wiederverarbeitungsregel.

⌂ Cockpit