Datenquellen, Quellsysteme und Module

Dieser Artikel liefert eine Beschreibung über das Zusammenspiel von Quellsystemen und Modulen und wie diese in Pipelines bzw. Steps verwendet werden können. Dieses KnowHow ist z.B. bei der Erstellung, Kopie oder Anpassung von Modulen wichtig & interessant.

Version: Dieser Artikel ist mindestens gültig ab der Version 5.6.

1. Voraussetzungen

• Zugriff auf das Verzeichnis “C:\ProgramData\”

• OCT-Installation

2. Verwendungsanleitung

2.1. Datenquellen

In OCT können Datenquellen definiert werden. Diese Datenquellen sind immer von einem bestimmten Typ. Bei der Einrichtung einer neuen Datenquelle öffnet sich eine Auflistung aller verfügbaren Quellsysteme & deren Quellsystemtypen.
Dabei gibt es sowohl “Build-In”-Konnektoren (z.B. SAP_DIRECT (SAP_DIRECT)) und Konnektoren, welche man herunterladen muss (z.B. NAVISION (MSSQL)):

In der oben gezeigten Auswahlliste “Quellsystem auswählen” wird immer der folgende Syntax verwendet:

QUELLSYSTEM (DATENQUELLENTYP)

In dieser Auswahlliste repräsentiert…

• … das QUELLSYSTEM die Bezeichnung des ERP Systems (z.B. Datev, Navision, SAP).

• … der DATENQUELLENTYP die Art des technischen Zugriffs auf die Daten des ERP Systems (z.B. MSSQL, ORACLE, API, FILE).
  

Es gibt Datenquellentypen, welche immer in OCT verfügbar sind (= “Build-in”) - diese haben keine zu erfüllenden Vorbedingungen:

• GENERIC (GENERIC) - erfordert die manuelle Angabe eines JDBC ConnectionStrings.

• SAP_DIRECT (SAP_DIRECT) - für den direkten Zugriff auf SAP ERP / SAP HANA.

• DATEV (DATEV) - für den direkten Zugriff auf DATEV (über die Schnittstelle KREXPORT).
  

Alle weiteren Quellsysteme und die passenden Datenquellentypen stehen nach dem Download des jeweiligen Konnektors in der Auswahlliste zur Verfügung.

Wenn für ein “Build-In”-System nochmal ein Konnektor heruntergeladen wird, dann führt dies zu einer Kollision. In der Datenquellenauswahl erscheint dieses Quellsystem dann doppelt. Der Konnektor kann sich nicht anderes benennen, da das Modul im Step passend zur Datenquelle gesucht und ansonsten nicht gefunden wird.

2.2. Datenquellen in Steps (Basics)

Viele Steps erlauben die Auswahl einer Datenquelle, wobei die Auflistung nicht immer alle theoretisch verfügbaren Datenquellen darstellt. Es werden nur die Datenquellen angezeigt, welche vom Datenquellentyp her zum Step passen. Beispielsweise unterstützt der Step SQL-Transfer nur den Datenquelltyp “MSSQL”. Die Steps treffen die Auswahl mit dem folgenden Prozess:

• Der Step sucht im Pfad “C:\ProgramData\Saxess Software\<service_name>\<server>\<db>\Repository\Integration” nach einem Ordner mit dem passenden Quellsystem.

• Innerhalb des Quellsystemordner wird nach Dateien “package-metadata.json” gesucht.

• Entspricht der dort definierte Datenquellentyp dem der gewählten Datenquelle, so wird der gesetzte Modulname (in der “package-metadata.json”) als Modul angezeigt (siehe Bild):

3. Zusätzliche Hinweise

• Kopiert man den Ordner eines Moduls, so wird auch die “package-metadata.json”-Datei mit kopiert.

  • Folge: Das Modul erscheint in der Anzeige doppelt.

  • Lösungsansatz: Änderung des Modulnamens in dieser Datei.

4. Expertenbereich

Hier werden Inhalte mit tiefergehendem Wissen, Berechtigungen und Zugriffen beschrieben.

4.1. Datenquellen in Steps (Details)

Grundsätzlich gibt es verschiedene Steps (z.B. Extraktionen) in denen neben einer Datenquelle die dazugehörigen “Integrationspakete für Modul” aufgelistet sind. Im folgenden wird erklärt wie diese Auflistung zustande kommt:

4.1.1. Allgemeines Konzept

• Jedes verfügbare Quellsystem wird direkt aus dem lokalen Dateiscan des folgenden Verzeichnisses entnommen: “C:\ProgramData\Saxess Software<service_name><server><db>\Repository\Integration”.

• Es wird eine Sammlung von Quellsystemen mit unterschiedlichen Quellsystemtypen (MSSQL, FILE, KREXPORT etc.) erzeugt.

  • z.B. befinden sich innerhalb des Ordners “DATEV” (Quellsystem) die Unterordner “FILE” und “KREXPORT” - diese werden als unterschiedliche Quellsysteme behandelt.

• Jedes dieser Quellsysteme enthält einen Ordner und wird als ein separates Modul behandelt.

• Jeder dieser Ordner besitzt eine eigene “metadata.json”-Datei, welche Informationen über das Modul enthält.

• Die Werte der Auswahlliste werden auf der Grundlage eines Quellsystems erstellt, welches für die ausgewählte Datenquelle gültig ist. Es wird dabei die Gültigkeit über den folgenden Vergleich festgestellt:

  • SourceSystem ShortName muss mit DataSource.SourceSystem übereinstimmen (DATEV, NAVISON, etc…). Das entspricht dem Namen des Ordners im Basis-Suchverzeichnis (siehe oben).

  • SourceSystem SourceType (MSSQL, FILE, KREXPORT, etc…) muss mit DataSource.SourceType übereinstimmen. Das entspricht dem Unterordner im ShortName-Ordner.

• Wenn der Check dann ein passendes Quellsystem findet, sollte es alle verfügbaren Module innerhalb dieses Quellsystems lesen und anzeigen.

  • Alle so dargestellten Module werden direkt aus der “package-metadata.json”-Datei entnommen.

4.1.2. Beispiel für die Verknüpfung von Ordnerstruktur & resultierender GUI

Am unteren Beispiel werden Ordnerstruktur und die daraus resultierenden, angezeigten Module für das passenden Quellsystem dargestellt:

• Die beiden Ordner heißen “DEBCRED” und “DEBCRED_Renamed_Manually”, weil dort z.B. kleinere Änderungen vorgenommen wurden. Die Bezeichnung “DEBCRED” in der GUI von OCT (Bild 3) wird jedoch nicht aus der Ordnernamensstruktur, sondern aus den “package-metadata.json”-Dateien befüllt und diese enthalten beide unter “module” = “DEBCRED”.

• Die “package-metadata.json” des FIN-Moduls enthält zum Beispiel “module” = “FIN”:

• Somit setzt sich die Auflistung in der GUI wie folgt zusammen: