Quellen anbinden.

Ein Konnektor kapselt genau eine Art von Quelle: Protokoll, Anmeldung, seitenweises Lesen, Wiederholung nach Fehlern. Relationale Datenbanken erreicht FORGE über JDBC oder ODBC mit einem Lesekonto, das nur die freigegebenen Schemata sieht. Dienste mit HTTP-Schnittstelle liest es über REST oder OData; ein OData-Dienst beschreibt seine Entitäten selbst im Dokument $metadata und liefert große Mengen seitenweise, in OData v4 über @odata.nextLink, in OData v2, wie es SAP Gateway oft anbietet, über __next.

SAP bindet FORGE auf drei Wegen an, je nachdem, was das System bereitstellt: über OData-Dienste des SAP Gateway, über RFC-fähige Funktionsbausteine und BAPIs und über IDocs, die SAP mit ALE als Nachrichten versendet. Welcher Weg gilt, entscheidet die Art der Daten: Stammdaten und Belege eher über OData oder BAPI, Bewegungen, die SAP ohnehin als Nachricht verschickt, über IDoc.

Dateien kommen über SFTP oder aus Objektspeichern mit S3-Schnittstelle, in den Formaten CSV, JSON, XML oder Parquet. Ereignisströme liest FORGE aus Apache Kafka als Mitglied einer Consumer-Gruppe: Jede Partition hat einen Offset, den FORGE nach der Verarbeitung festschreibt. Die Reihenfolge gilt je Partition, nicht über Partitionen hinweg; der Schlüssel einer Nachricht bestimmt ihre Partition und damit, welche Nachrichten geordnet bleiben.

Wo die Quelle es erlaubt, liest FORGE Änderungen aus ihrem Transaktionslog statt aus den Tabellen. Bei PostgreSQL ist das die logische Replikation: Mit wal_level = logical, einer Publikation für die freigegebenen Tabellen und einem Replikationsslot liefert das Ausgabe-Plugin pgoutput jedes Einfügen, Ändern und Löschen je Zeile, gebündelt nach Transaktion und in der Reihenfolge der Commits. Der Slot hält das Write-Ahead-Log fest, bis FORGE den Empfang bis zu einer Position bestätigt hat.

Bei MySQL ist es das Binärlog im Zeilenformat (binlog_format = ROW, sinnvoll mit binlog_row_image = FULL). FORGE meldet sich dafür wie ein Replikat an und liest Ereignisse ab einer Position oder einer GTID. Andere Datenbanken haben eigene Wege, etwa Change Data Capture in SQL Server; Werkzeuge wie Debezium bündeln solche Verfahren hinter einer einheitlichen Form.

Log-basiertes Erfassen sieht auch Löschungen und Zwischenstände, die eine periodische Abfrage verpasst, und belastet die Quelle wenig; weil ein Replikationsslot das Log festhält, bis FORGE bestätigt, gehören eine Obergrenze wie max_slot_wal_keep_size und eine Überwachung dazu. Die Position im Log, bei PostgreSQL die LSN, bei MySQL Datei und Position oder die GTID, speichert FORGE erst, wenn die Änderungen sicher angekommen sind. Nach einem Neustart setzt der Konnektor dort wieder auf. Das ergibt Zustellung mindestens einmal; doppelt Gelesenes fällt über den Schlüssel der Zeile und die Logposition heraus.

Nicht jede Quelle hat ein lesbares Log. Dann fragt FORGE inkrementell ab: nur Zeilen, deren Änderungsspalte über dem zuletzt gesehenen Wert liegt, dem Wasserzeichen. Gespeichert wird das Paar aus Zeitstempel und Primärschlüssel, damit Zeilen mit gleichem Zeitstempel an der Grenze einer Seite weder doppelt kommen noch verloren gehen.

Transaktionen können in anderer Reihenfolge festschreiben, als ihre Zeitstempel vergeben wurden. Eine Zeile mit älterem Zeitstempel kann darum erst nach einer jüngeren sichtbar werden. Jede Abfrage liest deshalb ein Sicherheitsfenster überlappend zurück und verwirft Stände, die FORGE nach Schlüssel und Version schon kennt.

Löschungen sieht eine solche Abfrage nicht. Sie kommen über Löschmarken der Quelle, über eine Protokolltabelle, die ein Trigger füllt, oder über einen periodischen Abgleich der Schlüsselmengen von Quelle und Abschrift.

Beim Anbinden liest FORGE die Beschreibung der Quelle, statt sie abzutippen: den Katalog einer Datenbank über information_schema oder JDBC-DatabaseMetaData, das $metadata-Dokument eines OData-Dienstes, die Schnittstelle von RFC-Bausteinen, bei Kafka ein Schema-Register mit Avro, JSON Schema oder Protobuf, bei Dateien eine Stichprobe mit abgeleiteten Typen.

Jedes erkannte Schema bekommt eine Version. Ändert die Quelle ihr Schema, vergleicht FORGE alt und neu. Eine neue optionale Spalte wird übernommen. Ein geänderter Typ, eine umbenannte oder entfernte Spalte hält die betroffene Abbildung an, bis jemand entscheidet, statt still falsche Werte zu schreiben.

Jeder Wert, der in FORGE ankommt, trägt seine Herkunft: Quelle, Objekt in der Quelle (Tabelle, Entität oder Thema), Schlüssel der Zeile, Feld, Logposition oder Wasserzeichen und den Zeitpunkt des Lesens. Die Rohzone speichert die Zeilen unverändert und nur anhängend; jede spätere Umformung verweist auf die Rohzeile, aus der sie entstand.

So lässt sich für jede Eigenschaft eines Objekts zurückverfolgen, aus welcher Zeile welcher Quelle sie stammt und in welchem Lauf sie übernommen wurde. Die Begriffe folgen W3C PROV: Entität, Aktivität, Agent. Für den Austausch der Herkunft mit anderen Werkzeugen ist OpenLineage vorgesehen.

Zugangsdaten der Konnektoren liegen in einem Speicher für Geheimnisse, nicht in der Konfiguration. Jede Anbindung nutzt ein eigenes Konto mit Leserecht auf die freigegebenen Objekte; Schreiben ist ein eigener Weg mit eigenem Recht. Bei PostgreSQL begrenzt die Publikation, welche Tabellen das Konto mit dem Attribut REPLICATION liest. Bei MySQL sieht das Replikationskonto das Binärlog des ganzen Servers; FORGE verwirft nicht freigegebene Schemata beim Lesen und speichert sie nicht, und reicht das nicht, liest FORGE von einem gefilterten Replikat oder mit Wasserzeichen.