Gatewaystandard OCT 2.0

Entwicklungcode → Build → Release: ein Buildprozess erstellt eine lauffähige Lösungsversion, diese wird (bei Erfolg) als Release gespeichert.
Paketierung: Die Paketierung setzt aus Releases ein größeres Lösungspaket zusammen.
Publish: Bereitstellung zum öffentlichen Download
Deployment: Auslieferung an einen Kunden durch Erzeugung einer verwendbaren Instanz der Lösung

Versionierung des Gateways als Gesamtpaket
- Jedes Release eines Gateways erhält eine Versionsnummer gemäß den Regeln des Semantic Versioning oder alternativ des Calendar Versioning.
- Die jeweilige Versionsnummer ist im Setup-Ordner in der Datei „version.txt“ hinterlegt.
- Für jedes Gateway wird ein Releaselog im öffentlichen Helpcenter geführt.
- Jedes veröffentlichte Release enthält im Releaselog eine Übersicht der Änderungen gegenüber der vorherigen Version, unterteilt in Features, Fixes und Modifikationen.
Versionierung interner Komponenten
- Das Gateway wird zusammen mit einer Konfigurationsdatei („config.json“) verwendet. Bei Updates wird diese Datei in der Regel übernommen.
- Um die Kompatibilität sicherzustellen, prüft das Gateway, ob die verwendete Konfigurationsdatei zur jeweiligen Version passt.
- Zu diesem Zweck enthält die „config.json“ eine Property „config_version“, in der die Version des Gateways als String gespeichert ist.

Jedes Gateway loggt seinen Output für die Ausgabe nach OCT (Konsolehander) ggf. auch für die Ausgabe als Datei (Dateihandler) wie hier beschrieben Logging in Gateways ab OCT Version 2026.02.

Jede Gateway besitzt eine ID in Kurzform und Langform - z.B. bei DATEVconnnect
- KurzID = GWDC
- LangID = DATEVCONNECT
Mehrere Gateways sollen sich ohne Konflikte in eine einzige OCT Datenbank einspielen lassen.
Jedes Gateway legt seine Datenbankobjekte im Schema staging ab.
Jedes Gateway nutzt seine LangID, welches es allen Datenbankobjekten im Namen voranstellt, z.B. staging.tDATEVCONNECT_xxx.
Es soll in der Datenbank eine einzige Pipeline “TRUNCATE - OCT Datenbank leeren” geben, in welche jedes Gateway die TRUNCATE Befehle für seine Tabellen als ein Step einfügt.
Es soll in der Datenbank eine einzige Pipeline “ATR - Alter Table Rebuild” geben. Diese löst für alle Tabellen des Gateways ein ALTER TABLE Rebuild aus.
Das Gateway legt sich globale Parameter mit der KurzID als Präfix an, z.B. “GWDC_DatenquellenID”.
Struktur der Datenerfassung:
- eine Factory “Validierung Gateways (VGW)” existiert
- in dieser Factory legt jedes Gateway eine eigene Productline mit seiner KurzID an, z.B. “Validierung Gateway DATEVconnect (GWDC)” für die technische Validierung seiner Daten an
- eine Factory “Datenanalyse Gateways (DAG)” existiert
- in der Factory legt sich jedes Gateway eine Productline mit seiner KurzID an, “Datenanalyse Gateway DATEVconnect (GWDC)”

In der Datenbank gibt es eine Factory “Technische Validierung (VT)”, in der sich global funktionsfähige Validierungsübersichten befinden.
- Größe der Datenbank insgesamt und Zeilenzahl insgesamt → globale Kennzahl “Durchschnittlicher Speicherplatz pro Tabellenzeile in der Datenbank”
- Größe und Zeilenzahl jeder Tabelle der Datenbank → Tabellenkennzahl “Durchschnittlicher Speicherplatz pro Zeile” für jede Tabelle
- Parameterprodukt “Warnindikatoren”
  - Datenbankgröße
Eine Pipeline “DBMONITOR” vermisst täglich die Datenbank und schreibt die Kennzahl in eine Monitoringtabelle.
- Größe der DB
- Zeilenzahl
- Ein E-Mail-Step am Ende sendet eine E-Mail, falls ein Wert über einem Warnindikator liegt.
Eine Auswertung berechnet Kennzahlen und visualisiert diese.
- Datenbankgröße
- Zeilenzahl
- Wachstumsrate der Tabellengröße in %
- Wachstumsrate der Zeilenzahl in %

IDs für Pipelines - jedes Gateway erstellt eine Pipeline mit seiner KurzID (somit werden keine zufällig vergebenen Nummern für Pipelines genutzt).
Steps in der Pipeline erhalten die ID “KurzID[Nr]”
In der globalen Pipeline TRUNCATE wird ein Step für das Gateway mit der KurzID des Gateways eingefügt.
Farbcodes für die Pipelines - Pipelines erhalten Farbcode
- grün für Pipelines, welche üblicherweise periodisch und ohne Nebenwirkungen ausgeführt werden (#089944)
- orange für Management Pipelines (#f5b916)
- rot für gefährliche Pipelines, bspw. die TRUNCATE Pipeline (#f23f23)
Das Gateway unterstützt die Ausführung über Container oder on-premises durch mehrere Stepvarianten.
Notwendige Parameter für Skripte werden in einer config Datei abgelegt, nicht hart in das Skript codiert.
Die config Datei wird vom Skript validiert, ob die dortigen Parameterwerte zusammenpassen (gültige URL, WinAuth 0/1 passend zu User / Passwort etc.)
Kombinationsfähigkeit
- Das Gateway soll in einen Fachmodelprozess eingebaut werden können - dieser umfasst meist Gateway - Konnektor - Fachmodell.
- Man soll Gateway - Konnektor - Fachmodell einzeln oder als Komplettpaket einspielen können.
- Alle Gatewaykomponenten (insbesondere Productlines / Pipelines / Steps) müssen daher eindeutig adressierbar sein.
Ein Release veröffentlicht neben den zu einem Skript konkatinierten Datenbankobjekten auch die Einzelkomponenten.

Jedes Fachmodell legt sich eine Factory mit seiner KurzID an, z.B. “Fachmodell REWE (REWE)”. Diese besitzt eine vom Fachmodell definierte Productlinestruktur.
Jedes Fachmodell legt sich Pipelines mit seiner KurzID an.

Ein Paket aus Gateway - Konnektor - Fachmodell unterscheidet sich im Bereich der Datenerfassung nicht von einzeln eingespielten Komponenten.
Das Paket erstellt eine kombinierte Pipeline aus den Einzelpipelines der Komponenten mit dem Namen “RUNME” - sofern mehrere Pakete in einer Datenbank laufen, wird diese Pipeline auf eine andere ID verschoben (via Export / Import, da momentan noch nicht direkt möglich).