OCT-Module
OCT-Module
Breadcrumbs

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