OCT-Module
OCT-Module
Breadcrumbs

Gatewaystandard OCT 2.0

Namenskonventionen

  • Build → Release: ein Build 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

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 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 (Tabellengröße, Pipelineauswertung) befinden.

Globale Komponenten

  • Übersicht der Größe aller Tabellen der Datenbank

  • Übersicht der Größe der Datenbank

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.

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

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