Seit dem oxaion open Release 5.1 stellt oxaion ausschließlich kumulative Patches bereit. Diese Anleitung beschreibt, wie ein Patch von oxaion zum Kunden übertragen wird (in der Regel in den staging-Zweig). Ein Merge innerhalb des Kunden (z. B. von staging nach production) ist hingegen hier beschrieben.
Alternativ zu dieser Anleitung kann von erfahrenen Programmierern auch die Checkliste zum Einspielen eines Patches verwendet werden.
Diese Anleitung gilt ab Release 2021. Die Anleitung für das Release 5.1 befindet sich hier.
Manuelle Vorarbeiten
In den Release Notes werden Hinweise zu manuellen Vorarbeiten dokumentiert. Diese müssen vollständig ausgeführt werden. Auch, wenn Patches übersprungen / ausgelassen werden, sind die jeweiligen manuellen Vorarbeiten zwingend auszuführen.
Zum Vermeiden von Kollisionen bei Dokumenten-IDs (OBIDs) muss das Prüfprogramm US30060 mit der Prüfung 10 aufgerufen werden. Dabei muss in der Firmenauswahl nur eine Firma vorgegeben werden.
Mischen der Aktualisierungen in den staging-Zweig
Es wird von einer "sauberen" Entwicklungsumgebung (=IDE) im Ziel-Zweig (in der Regel der staging-Zweig) ausgegangen. (Siehe Grundlagen und Voraussetzungen zu Patches)
Im ersten Schritt muss per Rechtsklick auf dem Projekt die Mischfunktion aufgerufen werden:
Ein Dialog mit den möglichen mischbaren Quellen erscheint.
Die Optionen "No commit (...)" sowie "If a fast-forward, create a merge commit" sind in den folgenden Beispielen ausgewählt, um den Merge-Commit nochmals prüfen und ggf. auch einen eigenen Committext vergeben zu können.
Auswahl der richtigen Quelle
Merge des aktuellen oxaion-Release in die STG-Umgebung
Hier kann einfach der aktuellste Stand des origin/oxaion/release Zweiges ausgewählt werden.
Merge der aktuellen STG-Version in die DEV-Umgebung
(Bei Bedarf) Konflikte lösen
Maschinelles Auflösen per SolveConflicts
Wenn die Umgebung vor Einspielen des Patches auf dem Stand 2021.5301.1 oder älter ist, ist dieser Schritt zwingend erforderlich.
Um automatisierte Konflikte in generierten Sourcen zu bereinigen, ist der Gradle Task "solveConflicts" auszuführen.
Damit werden alle Konflikte aus vollständig maschinell erzeugten Sourcen (Generierte Sourcen ohne Einfügepunkte, FileDescriptions, Textdatenstrukturen, Sprachproperties und XMLs aus dem groups-Ordner) automatisch gelöst. Die betroffenen Programme, Dateien, Properties und XMLs müssen anschließend neu generiert werden (kommt später in dieser Anleitung).
Die verbleibenden Konflikte (z.B. Einfügepunkte, Yamls) müssen manuell gelöst werden.
Manuelles Auflösen der übrigen Konflikte
Sollte beim Mischen weitere Konflikte auftreten, werden diese als rot markierte Einträge im sog. "Unstaged Bereich" (Unstaged Changes) der GIT Staging View sichtbar.
Durch Doppelklick öffnet ein 3-Wege-Vergleich, in dem alle Unterschiede und Konflikte in der jeweiligen Datei sichtbar werden.
Sind die Konflikte beseitigt, und gespeichert, muss die entsprechende Datei per Drag&Drop in den sog. "Staged Bereich" (Staged Changes) der GIT Staging View gezogen werden.
Dies ist für alle konfliktbehafteten Dateien zu wiederholen.
Übernahme der Metadaten
patchMode auf "true" setzen
In der Datei gradle.properties die Variable "patchMode" auf "true" setzen und einen "Refresh Gradle" ausführen.
Damit startet dann temporär der Server in der aktuellsten oxaion-Version, was einen lokalen Build überflüssig macht und dafür sorgt, dass die nachfolgenden Tools in der aktuellsten Version ausgeführt werden. Die Einstellung in der gradle.properties darf aber nicht comittet werden!
Möglicherweise startet der Server nicht und in der Konsole findet sich folgender Eintrag (die Zahlen hinter "line" und "char" können abweichend sein):
Ursache ist dann wahrscheinlich, dass kundenspezifische Dateien hinzugekommen sind. Durch den Start im Modus "patchMode=true" sind diese im Klassenpfad nicht vorhanden, sind aber im Cache aufgeführt und somit versucht der Server, diese zu laden.
Zur Lösung des Problems müssen diese Dateien in der Datei "cache.xml" auskommentiert werden:
Achtung: Nach Abschluss der Patch-Arbeiten muss die Datei "cache.xml" wieder in den ursprünglichen Zustand versetzt werden!
Vor Ausführung der nun folgenden Arbeiten sollten alle asynchronen Jobs gestoppt werden.
Bei alten Patch-Ständen die Fremdsprachen nachinstallieren
Wenn die Umgebung vor Einspielen des Patches auf dem Stand 2021.5301.1 oder älter ist, muss die englische Sprache einmalig installiert werden (siehe Release-Notes oxaion infinite zu Version 2021.5302.1).
Referenzfelder OP70100
Die Referenzfelder werden mittels des Programmes OP70100 "Referenzfeldänderungen einspielen" übernommen. Dazu muss der Client bzw. Client open direct aus der IDE gestartet werden.
In diesem Programm wird angezeigt, welche Referenzfeldänderungen eingespielt werden. Vor Beginn der Übernahme der Änderungen muss die Liste der Änderungen mittels Klick auf den entsprechenden Menüpunkt aktualisiert werden:
Per Rechtsklick auf einen Eintrag der ersten Ebene (=Referenzfeld) können die Änderungen vorab eingesehen und die Referenzfeldmetadaten des betreffenden Feldes importiert werden.
Per Rechtsklick auf einen Eintrag der zweiten Ebene (=betroffene Tabellen) kann die entsprechende Tabelle mittels "Datenbankobjekt erstellen! aktualisiert werden.
Bitte dabei zuerst die Yaml-Datei importieren und danach das Datenbankobjekt erstellen.
- Sollte beim Erstellen des Datenbankobjektes die Meldung "GEN0053" erscheinen, so bedeutet das, dass für die betroffene Datei weitere Änderungen anstehen und dass dadurch das Datenbankobjekt erst zu einem späteren Zeitpunkt erstellt wird. Der Status bleibt auf "rot".
- Mittels "Multiselect" können die genannten Aktionen für mehrere Einträge gleichzeitig ausgeführt werden. Dazu sollten vorher auch die Einträge der zweiten Ebene mittels des Plus-Zeichens in der Symbolleiste ausgeklappt werden.
Sind alle geänderten Referenzfelder importiert und alle Tabellen aktualisiert, sollten alle Status-Icon grün erscheinen und es kann fortgefahren werden mit dem nächsten Punkt.
Datenbank-Tabellen OP70110
Die Änderungen an den Datenbank-Tabellen werden mittels des Programmes OP70110 "Datenbankänderungen einspielen" übernommen.
In diesem Programm werden Datenbank-Änderungen angezeigt
Vor Beginn der Übernahme der Änderungen muss die Liste der Änderungen mittels Klick auf den entsprechenden Menüpunkt aktualisiert werden:
Anschließend werden die Dateien auf zweiter Ebene per Klick auf das "+" eingeblendet.
Per Rechtsklick auf einen Eintrag erster Ebene können die Änderungen eingesehen, die Metadaten des Eintrags importiert oder die Änderung in der Datenbank vorgenommen werden.
Dabei zuerst die Yaml importieren und danach das Datenbankobjekt erstellen.
Möglicherweise erscheint beim Importieren der YAML-Dateien folgende Fehlermeldung:
Dann muss zunächst für die Datei "GFLDNP" das Datenbankobjekt erstellt werden.
Per Rechtsklick auf einen Eintrag der zweiten Ebene (=abhängige Tabellen) kann die entsprechende Tabelle aktualisiert werden (= Create Objects CO).
Hinweise zum Datenbankobjekt erstellen
Der Menüpunkt "Datenbankobjekt erstellen" aktualisiert auch Indizes und var. Sichten der betreffenden Tabelle.
Dies kann bei Tabellen mit sehr vielen Einträgen entsprechend lange dauern und sollte deshalb gut geplant sein.
Ein Zeitpunkt außerhalb der Hauptnutzungszeiten ist zu empfehlen.Ab Version 2021.5209.01 kann das Erstellen der Datenbankobjekte als Job abgesetzt werden:
Dadurch werden die Änderungen im Hintergrund und gleichzeitig über mehrere Dateien ausgeführt.
Die Jobs laufen in der Job-Warteschlange *SYSTEM und somit mit bis zu 10 parallelen Prozessen.- Ab Version 2021.5405.1 werden Datenbank-Aktualisierungen für Archiv-Dateien nicht unmittelbar, sondern erst nach dem nächsten Neustart des Servers ausgeführt.
Wird eine Datenbank-Tabelle mit Archiv-Datei aktualisiert, wird für die Archiv-Datei ein geplanter Job wie nachfolgend angelegt. Bis zur Ausführung des Jobs wird die Archivierung der Journale der physischen Datei ausgesetzt.
Der Job wird standardmäßig nach dem Neustart des SRV01 ausgeführt. Die Ausführung des Jobs kann manuell angepasst (auch inaktiviert und später manuell angestoßen) werden.- Job-Name: *HST-CO-[Name der physischen Datei]
- Job-Queue: *JRNHSTCO (Default werden bis zu 3 Jobs parallel auf SRV01 ausgefüht)
- Programm: ArchivCoJob
Sind alle Tabellen aktualisiert, sollten alle Status-Icon grün erscheinen und es kann fortgefahren werden mit dem nächsten Punkt.
Weitere Metadaten-Änderungen OP70300
Änderungen an den Programmen oder Daten, die via Diff-YAML transportiert werden, werden über Metadaten-Änderungen (OP70300) eingespielt.
Zuerst müssen die aktuellen Änderungen eingelesen werden.
Anschließend können per Rechtsklick 
die Diff-YAML angewandt werden, solange der "Patchausführungs - Status" noch auf "NEW" steht.
Hinweis:
Die Metadaten-Änderungen werden nur ausgeführt
- für Datensätze mit dem Status "NEW"
- für Datensätze in der Umgebung ""
Die Metadaten-Änderungen eines Patches müssen in der korrekten zeitlichen Reihenfolge angewandt werden, um Probleme & Fehler zu vermeiden.
Dafür ist die Anzeige nach dem Erstell-Datum (aufsteigend) zu sortieren (DIYEDT) und zuerst erstellte Datensätze sind zuerst anzuwenden.
Empfehlung:
Ab Version 2021.5405.1 werden über die Funktion 
die Änderungen automatisch eingelesen und in der korrekten Reihenfolge angewandt.
Änderungen an allgemeinen Daten wie Fehlernachrichten, Feldbezeichnungen, TBV-Strukturen usw. werden dabei direkt in die Blank-Umgebung eingespielt.
Änderungen an den Generator-Daten für Programme werden je Umgebung geführt und automatisch beim Server-Neustart nach Blank angewandt.
YAMLs für Generator - Daten für Programme müssen beim Patch daher nicht eingespielt werden (die Funktion kann aber zu Testzwecken genutzt werden).
Sourcen zu gelösten Konflikte generieren
Wenn zuvor die Konflikte mit dem Gradletask "solveConflicts" gelöst wurden, dann müssen die zugehörigen Programme, Dateien usw. generiert werden. Das kann über das Funktionsmenü des Programms OP70300 gemacht werden.
Das Programm generiert alle betroffenen Sourcen neu und erzeugt ein Protokoll über die Verarbeitung.
Lokalen Build ausführen
Um zu prüfen, ob die Konfliktlösung erfolgreich war, ist ein lokaler Build erforderlich. Anleitung: Lokaler Build des Applikationsservers
Commit & Push
Nun kann die Git-Staging-Ansicht der IDE genutzt werden, um die Änderungen an den Quellen zu veröffentlichen. Sind alle Änderungen veröffentlicht wird der Applikationsserver (nicht der in der IDE) diese beim nächtlichen Build verwenden und nach einem Neustart stehen diese dann für Tests bereit.
Wenn die Gradle-Einstellung "patchMode" in den gradle.properties auf "true" gesetzt wurde, ist sie vor dem Commit wieder auf "false" zu setzen.
Wenn die Datei "cache.xml" temporär geändert wurde, ist sie vor dem Commit wieder in den ursprünglichen Zustand zu versetzen.
Manuelle Nacharbeiten
- Falls mit dem Patch neue Felder zu Masken hinzugefügt wurden, die bereits im Design-Modus manuell angepasst wurden,
werden diese neuen Felder nicht automatisch auf die individualisierten Masken aufgenommen, sondern ausgeblendet.
Sollen diese Felder angezeigt und von Anwendern verwendet werden, müssen sie über den Design-Modus manuell eingeblendet werden.
Eine Auflistung der neuen Felder findet sich in den Patch-Details. - In den jeweiligen Release Notes sind alle manuellen Nacharbeiten zum Patch und den vorher (übersprungenen) Patches abzuarbeiten.
- Es sind die Kunden-Release-Notes abzuarbeiten