Versionsabhängige Patch-Schritte

Um auf die gewünschte Version zu aktualisieren, müssen Sie aus der folgenden Liste alle zutreffenden Patch-Schritte ausführen, deren Patch-Level höher als das aktuelle Patch-Level und niedriger oder gleich der Zielversion ist.

Möchten Sie z.B. auf die Zielversion 8.0.18 aktualisieren und ihre aktuelle Version ist 8.0.3, müssen Sie alle Schritte von der Patch-Version 8.0.4 bis einschließlich zur Patch-Version 8.0.18 ausführen.

Falls ein Patch-Schritt mehrfach auftaucht, müssen Sie diesen nur einmalig ausführen (z.B. Tomcat-Updates).

Aufbau der Liste

  • Patch Version

    Patch-Version, der eine manuelle Aktion zum Patchen benötigt. Patchen ist notwendig, wenn Sie von einer niedrigeren Version zur angegebenen oder einer höheren Version patchen.

  • Voraussetzungen

    Bedingungen, die gegeben sein müssen, damit Sie den Patch-Schritt manuell ausführen müssen.

  • Aktion/So gehen Sie vor

    Aktion(en), die ausgeführt werden muss/müssen.

8.1.0

Es sind nur Standard Patch-Schritte erforderlich.

8.1.1

Es sind nur Standard Patch-Schritte erforderlich.

8.1.2

HTTPs TLSv1.3 standardmäßig aktivieren

Aktion

Aktuell als sicher eingestuft werden nur die Version TLSv1.2 und TLSv1.3. Um die neueste TLS-Version sowohl auf der Server- als auch auf der Clientseite zu aktivieren, konfigurieren Sie die Einstellungen so, dass nur noch TLS 1.2 und TLS 1.3 unterstützt werden.

Gehen Sie wie folgt vor

  • Die Werte für -Dhttps.protocols=…​ angepasst:

    • Neuer (empfohlener) Wert: -Dhttps.protocols=TLSv1.2,TLSv1.3

    • ABER: Damit funktionieren gegebenenfalls HTTPs-Verbindungen zwischen der Process Engine und anderen Servern nicht mehr, diese auf ältere TLS-Versionen angewiesen sind.

  • Die Werte für -Djdk.tls.client.protocols=…​ angepasst:

    • Neuer (empfohlener) Wert: -Djdk.tls.client.protocols=TLSv1.2,TLSv1.3

  • Prüfen Sie die Werte in den folgenden Dateien und passen Sie sie entsprechend an:

    <inubit-installdir>/inubit/server/process_engine/bin/setenv.[bat|sh]
    <inubit-installdir>/inubit/bin/start_workbench.[bat|sh]
    <inubit-installdir>/inubit/server/process_engine/bin/startcli.[bat|sh]
    <workbench-installdir>/inubit/client/bin/start_workbench.[bat|sh]
    <workbench-installdir>/inubit/client/bin/startcli.[bat|sh]
  • Nutzen Sie auch die durch den Patch-Installer angelegten Dateien mit dem Suffix _patch.[bat|sh], um auf den von der Virtimo AG empfohlenen Dateiinhalt zuzugreifen.

Nach Abschluss der obigen Schritte starten Sie die Process Engine und Workbench neu.

Betrifft:

  • Application - Process Engine

  • Application - Workbench

8.1.3

Keycloak auf Version 26.0.x aktualisieren

Voraussetzungen

Sie verwenden Keycloak bereits als Identitätsanbieter für INUBIT.

Aktion

Keycloak und die entsprechende Client-Bibliothek in INUBIT auf Version 26.0.1 aktualisieren Das Keycloak-Upgrade ist nicht abwärtskompatibel und daher müssen sowohl die Keycloak-Anwendung als auch die in der Datenbank gespeicherten Daten migriert werden.

Gehen Sie wie folgt vor

  1. Lesen Sie Keycloak Migration Guide, um mehr über die neuesten Migrationsänderungen zu erfahren.

  2. Stoppen Sie den Keycloak-Server, falls er ausgeführt wird.

  3. Lesen Sie Preparing for upgrading und befolgen Sie die Vorbereitungsschritte.

  4. Führen Sie das Patch-Installationsprogramm der Virtimo Digitalization Suite aus und aktualisieren Sie auf Ihrem Computer auf die neueste Keycloak-Version.

  5. Lesen Sie Migrating the database und befolgen Sie die Schritte zur Datenbankmigration.

  6. Lesen Sie die restlichen Abschnitte wie Migrating themes und befolgen Sie die Anweisungen.

  7. Starten Sie den Keycloak-Server.

  8. Melden Sie sich bei der Keycloak-Administratorkonsole an, navigieren Sie zu Realm Settings und ändern Sie den Wert von „Unmanaged attribute“ auf "Enabled".

  9. Navigieren Sie zu Authentication und dann zur Registerkarte "Required Actions".

  10. Ändern Sie den Wert von "Verify Profile" auf "off".

Betrifft:

8.1.4

AS4-Protokolldateipfad

Um die Datei as4gateway.log unter <inubit-installdir>/inubit/server/ibis_root/log zu platzieren.

Aktion

  1. Stoppen Sie die Process Engine

  2. Ändern Sie den folgenden Eintrag in <inubit-installdir>/inubit/server/ibis_root/conf/as4/log4j2.properties und geben Sie den absoluten Pfad zum Zielordner an, in dem die Datei as4gateway.log erstellt werden soll:

    # Log ins <inubit-installdir>/inubit/server/ibis_root/log
    property.basePath=${env:CATALINA_BASE}/../ibis_root/log
  3. Speichern Sie alle Änderungen

  4. Starten Sie die Process Engine

Betrifft:

Konfiguration des Log Cleanup Services unter Windows

Voraussetzungen

Die Patch-Installation wurde durchgeführt.

Gehen Sie wie folgt vor

  1. Erforderlichen Skripte einrichten

    1. Sichern Sie die Skriptdatei ibis_nt_service_nssm_install.cmd.

    2. Benennen Sie die Datei ibis_nt_service_nssm_install_patch.cmd in ibis_nt_service_nssm_install.cmd um.

    3. Sichern Sie die Skriptdatei ibis_nt_service_nssm_uninstall.cmd.

    4. Benennen Sie die Datei ibis_nt_service_nssm_uninstall_patch.cmd in ibis_nt_service_nssm_uninstall.cmd um.

  2. Dienst installieren

    1. Führen Sie das Skript ibis_nt_service_nssm_install.cmd aus, um den Dienst zu installieren.

      Bei der Installation der INUBIT Process Engine als Dienst über das Skript ibis_nt_service_nssm_install.cmd wird zusätzlich ein neuer Dienst namens LogCleanupService installiert und automatisch gestartet. Dieser Dienst ist so konfiguriert, dass er das Skript log_cleanup.cmd ausführt, das die Logik für die Protokollbereinigung enthält.

      Das Skript log_cleanup.cmd ruft die Konfigurationsdatei pe_log_cleanup_conf.bat auf, die die folgenden Variablen definiert:

      • MAX_FILE_COUNT: Gibt die maximale Anzahl der aufzubewahrenden Protokolldateien an. Standardmäßig auf 10 eingestellt.

      • MAX_AGE_DAYS: Gibt die maximale Anzahl von Tagen an, für die die Protokolldateien aufbewahrt werden sollen. Standardmäßig auf 7 Tage eingestellt. Wenn beide Werte angegeben sind, hat MAX_FILE_COUNT Vorrang.

        Achtung: Um die Altersbeschränkung nutzen zu können, muss Powershell auf dem Windows-System installiert sein.

      • LOG_DIR: Definiert das Verzeichnis, in dem sich die Protokolldateien befinden.

      • INTERVAL_MINUTES: Legt das Intervall fest, in dem die Bereinigung ausgeführt werden soll. Standardmäßig auf 60 Minuten eingestellt.

      • LOG_PATTERNS: Definiert die Protokolldateimuster, nach denen das Skript sucht. Geben Sie mehrere Muster durch Leerzeichen getrennt an (z. B. stderr stdout).

    2. Stellen Sie sicher, dass alle notwendigen Dienste gestartet sind.

      Wenn Sie Werte in der Konfigurationsdatei pe_log_cleanup_conf.bat im Ordner <inubit-installdir>\server\process_engine\bin\ anpassen, dann müssen Sie den Dienst LogCleanupService neu starten.

Betrifft:

  • Application - Process Engine

Virtimo Cluster Manager aktualisieren

Mit dieser Version erfolgt ein Update des Virtimo Cluster Managers (Version: 2.0). Der neue Cluster Manager arbeitet technisch auf der JGroups Bibliothek.

Alte und neue Cluster Manager Version sind daher nicht kompatibel.

Vor der Ausführung des Patches muss sichergestellt werden, dass es zu keinen ungewollten Problemen kommt.

Diese Anleitung hilft Ihnen, die möglicherweise auftretenden Szenarien zu bewerten und geeignete Lösungstrategien einzuplanen.

Voraussetzungen

Sie verwenden bereits den Virtimo Cluster Manager mit INUBIT.

Konfiguration des neuen Virtimo Cluster Managers

So gehen Sie vor:

  1. Durch die Ausführung des Patch-Installers wird das folgende Verzeichnis neu angelagt: <inubit-installdir>/inubit/server/ibis_root/conf/clustermanager.

  2. Starten Sie den gepatchten INUBIT-Knoten.

Während des Starts der Process Engine wird die Konfigurationsdatei virtimo_cluster_manager.xml automatisch aus einer vorhandenen clusterManagerConfig.xml erstellt. Sobald der INUBIT-Knoten gestartet ist, verfügt der neue Cluster-Manager über einen aktiven Leader-Knoten.

Verhalten des Clusters nach Einspielen des Patches

Standardmäßig werden Cluster-Knoten einzeln aus einem laufendem Cluster herausgenommen, gepatcht und im Anschluss dem Cluster wieder hinzugefügt. Dabei meldet sicher der Knoten zunächst aus dem Cluster ab und nach dem Patchen beim Cluster wieder an.

Durch Einspielen dieses Patches formen die gepatchten Knoten einen neuen Cluster und melden sich nicht wieder am vorherigen Cluster an.

Mögliche Probleme

Es entstehen 2 separater Cluster, die nicht mit einander agieren und keine Kenntnis voneinander haben (Split Brain). Beide Cluster wählen einen Leader-Knoten, der exklusive Arbeiten durchführt, z.B. Scheduler ausführt. Existieren zur geplanten Zeit des Schedulers 2 Cluster, werden die entsprechenden Workflows auch von beiden Clustern ausgeführt. Dies kann zu fachlichen Fehler führen.

Lösungszenarien ohne Downtime

  1. Ein komplettes Herunterfahren des gesamten Clusters ist betrieblich nicht realisierbar. Mindestens ein Cluster-Knoten muss jederzeit verfügbar sein. Während der Zeit des Patchens werden keine exklusiven Workflows ausgeführt.

    So gehen Sie vor

    • Sichern Sie die bisherige Konfiguration

    • Fahren Sie einen Knoten des Clusters herunter

    • Patchen Sie den Knoten mit dem Patch-Installer

    • Konfigurieren Sie den neuen Cluster-Knoten

    • Fahren Sie die gepatchten Knoten wieder hoch. Bei Problemen stoppen Sie den gerade hochgefahrenen Knoten.

    • Wiederholen Sie den Vorgang für alle Cluster-Knoten

    Es formt sich ein zweiter Cluster. Da keine exklusiven Arbeiten ausgeführt werden, sind fachliche Fehler nicht zu erwarten.

  2. Während der Zeit des Patchens werden exklusive Workflows ausgeführt.

    So gehen Sie vor

    • Greifen Sie manuell in die Workflows ein und unterbinden Sie die Ausführung der exklusiven Arbeiten, z.B. Deaktivierung der Scheduler

    • Fahren Sie einen Knoten des Clusters herunter

    • Patchen Sie den Knoten mit dem Patch-Installer

    • Konfigurieren Sie den neuen Cluster Manager

    • Fahren Sie die gepatchten Knoten wieder hoch.

      Bei Problemen stoppen Sie den gerade hochgefahrenen Knoten.

    • Wiederholen Sie den Vorgang für alle Cluster-Knoten

    Es formt sich ein zweiter Cluster. Da keine exklusiven Arbeiten ausgeführt werden, sind fachliche Fehler nicht zu erwarten.

Lösungsszenario mit Downtime

Ein komplettes Herunterfahren des gesamten Clusters ist betrieblich realisierbar.

So gehen Sie vor

  • Fahren Sie den gesamten Cluster herunter

  • Sichern Sie die bisherige Konfiguration

  • Patchen Sie alle Knoten mit dem Patch-Installer

  • Konfigurieren Sie den neuen Cluster Manager

  • Fahren Sie die gepatchten Knoten wieder hoch.

Bei Problemen stoppen Sie den gerade hochgefahrenen Knoten.

Betrifft:

8.1.5

Es sind nur Standard Patch-Schritte erforderlich.

8.1.6

X12 Metadaten-Datei im Repository aktualisieren

Aktion

In der im Auslieferungsumfang enthaltene Datei "X12-ENVELOPER.xml" wurde der maximale Längenwert des Feldes "GS05" (Zeitbeschreibung) von 4 auf 8 korrigiert. Um diese Änderungen in das Repository zu übernehmen, muss das entsprechende Repository-Verzeichnis manuell aktualisiert werden.

Alle Dateien im Verzeichnis Global > EDI Specification > Rule Metadata werden aktualisiert. Jede aktualisierte Datei wird mit einer neuen Version im Repository abgelegt.

Wenn Sie bereits Änderungen an Dateien in dem Repository-Verzeichnis Global > EDI Specification > Rule Metadata vorgenommen haben oder eine angepasste Version verwendet haben, können Sie Ihren letzten Stand aus der entsprechenden Versionshistorie wiederherstellen.

Voraussetzungen

Die Patch-Installation wurde ausgeführt.

Vorgehensweise

  • Navigieren Sie zum Reiter "Repository"

  • Klicken Sie mit der rechten Maustaste auf das Verzeichnis "Global > EDI Specification > Rule Metadata"

  • Wählen Sie im Kontextmenü die Option "Verzeichnis aktualisieren"

Betrifft:

8.1.7

Es sind nur Standard Patch-Schritte erforderlich.

8.1.8

Unterstützung für aggregierte E-Mails

Dieser Patchschritt ist zwingend erforderlich und muss vor dem Start der Process Engine durchgeführt werden.

Voraussetzungen

Für die neu eingeführte Funktion des aggregierten Fehlerberichts ist eine neue Datenbanktabelle erforderlich, die der aktuell verwendeten Datei logsDBConfig.xml in der Process Engine hinzugefügt werden muss.

Die Änderung muss angewendet werden.

Gehen Sie wie folgt vor:

  1. Beenden Sie die Process Engine (falls noch nicht geschehen).

  2. Öffnen Sie die Datei logsDBConfig.xml.

  3. Fügen Sie abhängig von Ihrer verwendeten Datenbank den folgenden Abschnitt unterhalb des <tables>-Elements hinzu:

    • MySQL

    • Oracle

    • Postgres

    • DB2

    • H2

    • MariaDB

    • MSSQL

    <workFlowErrorData tableName="inubitWorkflowErrorData">
        <statements>
            <createTable>CREATE TABLE inubitWorkflowErrorData(is_id BIGINT NOT NULL
                AUTO_INCREMENT,is_server VARCHAR(256),is_serverId VARCHAR(256),is_dateTime
                BIGINT,is_workflowName VARCHAR(256),is_moduleName VARCHAR(256),is_IsErrorKey
                VARCHAR(256),is_IsErrorString VARCHAR(1024),is_errorMailContent
                VARCHAR(1024),is_processId VARCHAR(255),PRIMARY KEY(is_id))
            </createTable>
        </statements>
    </workFlowErrorData>
    <workFlowErrorData tableName="inubitWorkflowErrorData">
        <statements>
            <createTable>CREATE TABLE inubitWorkflowErrorData(is_id NUMBER GENERATED BY DEFAULT AS
                IDENTITY PRIMARY KEY,is_server VARCHAR2(50),is_serverId VARCHAR2(255),is_dateTime
                NUMBER(19),is_workflowName VARCHAR2(255),is_moduleName VARCHAR2(255),is_IsErrorKey
                VARCHAR2(255),is_IsErrorString VARCHAR2(1024),is_errorMailContent
                VARCHAR2(1024),is_processId VARCHAR2(255))
            </createTable>
        </statements>
    </workFlowErrorData>
    <workFlowErrorData tableName="inubitWorkflowErrorData">
        <statements>
            <createTable>CREATE TABLE inubitWorkflowErrorData (is_id SERIAL PRIMARY KEY, is_server
                varchar(50), is_serverId varchar(255), is_dateTime BIGINT, is_workflowName varchar(255),
                is_moduleName varchar(255), is_IsErrorKey varchar(255), is_IsErrorString
                varchar(1024),is_errorMailContent varchar(1024),is_processId varchar(255))
            </createTable>
        </statements>
    </workFlowErrorData>
    <workFlowErrorData tableName="inubitWorkflowErrorData">
        <statements>
            <createTable>CREATE TABLE inubitWorkflowErrorData (is_id BIGINT NOT NULL GENERATED ALWAYS AS
                IDENTITY (START WITH 1 INCREMENT BY 1), is_server VARCHAR(256), is_serverId
                VARCHAR(256), is_dateTime BIGINT, is_workflowName VARCHAR(256), is_moduleName
                VARCHAR(256), is_IsErrorKey VARCHAR(256), is_IsErrorString
                VARCHAR(1024),is_errorMailContent VARCHAR(1024),is_processId VARCHAR(255), PRIMARY KEY
                (is_id))
            </createTable>
        </statements>
    </workFlowErrorData>
    <workFlowErrorData tableName="inubitWorkflowErrorData">
        <statements>
            <createTable>CREATE TABLE inubitWorkflowErrorData (is_id BIGINT AUTO_INCREMENT PRIMARY KEY,
                is_server VARCHAR(256), is_serverId VARCHAR(256), is_dateTime BIGINT, is_workflowName
                VARCHAR(256), is_moduleName VARCHAR(256), is_IsErrorKey VARCHAR(256), is_IsErrorString
                VARCHAR(1024),is_errorMailContent VARCHAR(1024),is_processId VARCHAR(255))
            </createTable>
        </statements>
    </workFlowErrorData>
    <workFlowErrorData tableName="inubitWorkflowErrorData">
        <statements>
            <createTable>CREATE TABLE inubitWorkflowErrorData (is_id BIGINT NOT NULL AUTO_INCREMENT,
                is_server VARCHAR(256), is_serverId VARCHAR(256), is_dateTime BIGINT, is_workflowName
                VARCHAR(256), is_moduleName VARCHAR(256), is_IsErrorKey VARCHAR(256), is_IsErrorString
                VARCHAR(1024),is_errorMailContent VARCHAR(1024),is_processId VARCHAR(255), PRIMARY KEY
                (is_id))
            </createTable>
        </statements>
    </workFlowErrorData>
    <workFlowErrorData tableName="inubitWorkflowErrorData">
        <statements>
            <createTable>CREATE TABLE inubitWorkflowErrorData (is_id BIGINT NOT NULL IDENTITY(1,1),
                is_server VARCHAR(256), is_serverId VARCHAR(256), is_dateTime BIGINT, is_workflowName
                VARCHAR(256), is_moduleName VARCHAR(256), is_IsErrorKey VARCHAR(256), is_IsErrorString
                VARCHAR(1024),is_errorMailContent VARCHAR(1024),is_processId VARCHAR(255), PRIMARY KEY
                (is_id))
            </createTable>
        </statements>
    </workFlowErrorData>
  4. Speichern Sie die Änderungen in der Datei logsDBConfig.xml.

  5. Starten Sie die Process Engine

Betrifft:

Verändertes Verhalten bei Nutzung der generischen Konvertierung

Problem

Mit INUBIT 8.0.45 bzw 8.1.8 ändert sich das Verhalten des JSON Adapter. Per Default wird jetzt die Domain-Konvertierung durchgeführt und nicht wie bisher die generische Konvertierung. Dadurch schlägt die Ausführung an Modulen fehl, wo nur das Modul-Property "json.domain.Type" gesetzt ist.

Ab INUBIT 8.0.46 bzw. 8.1.11 ist das ursprüngliche Verhalten wiederhergestellt.

Workaround

Bearbeiten Sie das Modul und pubizieren Sie es erneut mit dem Typ „Generisch“.

Betrifft:

8.1.9

Es sind nur Standard Patch-Schritte erforderlich.

8.1.10

Es sind nur Standard Patch-Schritte erforderlich.

8.1.11

Es sind nur Standard Patch-Schritte erforderlich.

8.1.12

Es sind nur Standard Patch-Schritte erforderlich.