Gatewaystandard OCT 2.0

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

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.

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.

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