Gatewaystandard OCT 2.0

Namenskonventionen

• 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 Lösung

Versionierung

• jedes Release erhält eine Versionsnummer nach Semantic Versioning Regeln

• jedes Release, welches gepublisht wird erhält im Relaselog die Liste der Änderungen zum letzten Release

• Semantic Versioning https://semver.org/ defineren wir so:

  • Major: (Regeln müssen noch definiert werden)

  • Minor:

  • Patch

• Gateway Konnektor Versionierung? Abhängigkeiten von Gateway Version usw.

Gateway übergreifende Regeln

• 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)”

Globale Komponenten

• 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 schreib Kennzahl in eine Monitoringtabellen

  • Größe der DB

  • Zeilenzahl

  • ein Emailstep am Ende sendet eine Email, 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 %

Regeln für das einzelne Gateway

• 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-prem durch mehrere Stepvarianten.

• Notwendig Parameter für Scripte werden in einer config Datei abgelegt, nicht hart in das Script codiert

• Die config Datei wird vom Script 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öfftlicht neben den zu einem Script konkatinierten Datenbankobjekten auch die Einzelkomponenten

Konnektoren für Gateways

• PipelineID = Kurz_ID_[Zielmodell] - z.B. GWDC_REWE

• Steps erhalten auch diese ID mit laufender Nummer.

Fachmodellregeln

• 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.

Paketregeln

• 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).