Lesen, was Sie ohnehin betreiben. Und nichts davon verändern.

Das Verbinden gilt in den meisten Integrationsprojekten als gelöst, und genau dort entstehen die meisten Integrationsschulden. Beetl liest aus Ihren Systemen, ohne in sie zu schreiben, und behält eine Kopie dessen, was die Quelle tatsächlich geliefert hat, bevor irgendetwas transformiert wird.

Was passiert, wenn eine Quelle dazukommt

Vier Dinge, in dieser Reihenfolge.

Der Zugriff wird eingegrenzt, bevor irgendetwas läuft

Sie richten lesenden Zugriff auf eine festgelegte Menge von Tabellen ein. Nicht auf das Schema, nicht auf die Datenbank, sondern auf genau die Tabellen, die der Datenfluss braucht.

Cloud-Systeme werden über die API des jeweiligen Herstellers angebunden. Systeme, die von außerhalb Ihres Netzwerks nicht erreichbar sind, laufen über einen Connector innerhalb Ihres Perimeters, der einen ausgehenden Tunnel öffnet. Keine eingehenden Firewall-Regeln, keine offenen Ports.

Das Schema wird gelesen, nicht angenommen

Beetl liest die Quelle aus und zeigt Ihnen, was gefunden wurde: Tabellen, Spalten, Typen. Gegen dieses Inventar wird die Pipeline geschrieben.

Hier kommt auch die undokumentierte Wirklichkeit ans Licht. Felder, die immer leer sind, Spalten, deren Name schon vor Jahren aufgehört hat zum Inhalt zu passen, und die zwei Tabellen, die eigentlich eine hätten sein sollen.

Eine quellgetreue Kopie bleibt erhalten

Was die Quelle geliefert hat, wird gespeichert, bevor eines Ihrer Mappings greift, mit stabilen Kennungen, Extraktionszeitstempeln und Cursorn.

Das ist die eine Entscheidung, die alles Weitere wiederherstellbar macht. Wird eine Zahl sechs Wochen später infrage gestellt, liegt der ursprüngliche Datensatz noch vor. Die Antwort ist dann ein Nachschlagen und keine Untersuchung.

Inkrementelles Verhalten wird zum Problem der Plattform

Cursor, Watermarks und die Frage, was als geändert gilt, liegen bei Beetl, statt aus irgendeiner Zeitstempel-Spalte abgeleitet zu werden, die jemand einmal ausgewählt hat.

Verpasste Aktualisierungen und verpasste Löschungen sind zwei der neun Wege, auf denen Integrationsschulden entstehen. Hier hören sie auf.

Datenlandschaft

Jede Verbindung, jeder Datensatz, jede Pipeline, die daran hängt.

Verbindungen sind keine Liste. Sie sind ein Graph, denn was Sie üblicherweise wissen müssen, ist: Was geht kaputt, wenn sich diese Quelle ändert?

1Verbindungen links, jeweils mit Typ und letzter Aktivität.
2Eingelesene Datensätze in ihrer quellgetreuen Form, versioniert.
3Pipelines, mit der Anzahl der Quellen, von denen jede abhängt.
4Validierte Ausgaben, und das ist, was der Rest des Unternehmens liest.
Beetls Ansicht der Datenlandschaft: ein Graph, der Dateiverbindungen mit Bronze-Datensätzen, mit Pipelines und mit Gold-Datensätzen verknüpft.
Datenlandschaft. Verbindungen, Datensätze und die Pipelines dazwischen.

Was wir heute anbinden

Sieben Systemtypen, und uns ist eine genaue Aufzählung lieber, als alles zu behaupten:

  • Datenbanken. Nur lesend, über eine eingegrenzte Verbindung.
  • ERP-Systeme. Darunter SAP Business One und Microsoft Dynamics 365 Business Central.
  • Dateien und Tabellen. Das Format, in dem die operative Wahrheit tatsächlich meistens liegt.
  • HTTP-Feeds. Strukturierte Feeds mit benanntem Ausgabevertrag.
  • Webhooks. Mit Verbindungstyp, geprüftem Medientyp und erzwungenem Schema beim Einlesen.
  • Lokale operative Systeme, erreicht über einen Connector innerhalb Ihres Netzwerks.
  • Object Storage und Staging-Ablagen, die Sie ohnehin betreiben.

Eine breitere ERP-Abdeckung ist in aktiver Entwicklung. Generische Connectoren für beliebige Drittanbieter-APIs bieten wir heute nicht an, und das sagen wir lieber hier, als es Sie im Scoping-Gespräch herausfinden zu lassen.

Beginnen Sie mit der Quelle, die Ihnen am meisten Sorgen macht.

Sagen Sie uns, worum es sich handelt und was herauskommen muss. Wir sagen Ihnen, ob wir sie heute lesen können.