Migrationsskript ausführen

Voraussetzungen

Auf dem Zielsystem sind alle Datenbanken (Cache, Repository und Logging) erfolgreich gestartet.
Die minimalen Hardwareanforderungen sind erfüllt.

Bei der Migration werden fast alle Prozesse, Artefakte und Konfigurationen, die im Quellsystem erzeugt wurden, in das neue System übernommen bzw. dort angepasst:

Systemkonfiguration

Zum Beispiel Integration Server-Konfiguration, Customer-Plug-Ins-Konfiguration, Customer-Bibliotheken, Treiber, Repository, Zertifikate im Key Manager, Watchdog-Prozesse des Connection Managers, Applikationsprofile, Portalserver-bezogene Dateien und Portalserver-Einstellungen
Benutzer

Zum Beispiel Benutzer, Benutzergruppen, Prozessrollen, Diagramme und Module
Betriebszustände

Zum Beispiel Workflow- und System Connector-Aktivierungsstatus, die komplette INUBIT-Monitoring-Datenbank sowie die aktuelle Workflow-ID
Prozesszustände

Migration von INUBIT 6.1/7.1: Workflows im Status Error, Waiting, Retry, Suspended, Queued und Processing werden migriert.
Process-Id-Bereich
Benutzerdaten
Tasks und Tasklisten
Die Versionshistorie benutzerspezifischer Repositorydaten wird erst ab INUBIT 6.0 migriert.

Der Portalordner <inubit-installdir>/server/ibis_root/conf/portal wird während der Sicherung nicht gesichert, da durch das Wiederherstellen dieser Versionen alte Versionen, die mit der installierten Portal-Version nicht kompatibel sind, wiederhergestellt werden können. Dies erfordert zusätzlichen Zeit- und Archivierungsaufwand. Der Portalordner des Zielsystems wird deshalb während der Migration beibehalten.

Welche Komponenten migriert bzw. nicht migriert werden und welche manuellen Schritte erforderlich sind, siehe Überblick.

So gehen Sie vor

Der Aktivierungsstatus der Workflows im Quellsystem wird bei der Migration in das Zielsystem übernommen. Passen Sie ggf. die Aktivierungsstatus der Workflows den Erfordernissen des Zielsystems an.
Stellen Sie sicher, dass die im Quellsystem verwendeten Datenbanktreiber im Verzeichnis <inubit-installdir>/server/process_engine/lib des Zielsystems verfügbar sind.
Optional: Wenn Sie den X.400 SE Connector einsetzen, installieren Sie die Isode-Bibliothek auf den X.400-Clients.
Aktivieren Sie den Wartungsmodus der Process Engine des Zielsystems, damit Sie das Zielsystem nach der Migration schrittweise in Betrieb nehmen können.

Beziehen Sie sich auf die Thirdparty-Komponenten für die Isode-Versionen, die den INUBIT-Server unterstützen.
Stoppen Sie die Process Engine des Quell- und des Zielsystems.
Navigieren Sie im Zielsystem in das Verzeichnis <inubit‑installdir>/bin/migration/ und rufen Sie das Migrationsskript migration.bat bzw. migration.sh auf.

Anwendung

Das Migrationsskript kann mit zwei verschiedenen Eingabequellen ausgeführt werden:

Bereitstellung einer Backup-ZIP-Datei (erstellt mit dem INUBIT Backup Skript oder dem Backup Connector)
```
migration.sh /path/to/backup.zip
```
Angabe des Pfads zu einer vorhandenen INUBIT-Installation (Serververzeichnis):
```
migration.sh /data/old_inubit/server
```
Wenn der Pfad Leerzeichen enthält, müssen Sie den Pfad in einfache Anführungszeichen setzen (unter Windows: doppelte Anführungszeichen), zum Beispiel:
```
migration.bat "C:\old inubit\server"
```

Haben Sie das System-Backup-Archiv manuell erweitert, um auch die EDI-ID-Listen zu migrieren (siehe EDI-Migration), transferieren Sie das angepasste Archiv zum Zielsystem und geben Sie den vollständigen Pfadnamen des Archivs als Aufrufparameter des Migrationsskripts an, zum Beispiel: migration.bat C:\tmp\inubit\backup.zip

Abhängig von der Menge der Moduldaten stellen Sie sicher, dass ausreichend Speicher zur Verfügung steht. Zu diesem Zweck ändern Sie den` -Xmx`-Wert, zu Beispiel auf 20GB (20480M). Darüber hinaus sollten Sie ebenfalls Concurrent Mark Sweep GC aktivieren, bevor Sie das Migrationsskript ausführen. Dazu fügen Sie die Option ‑XX:+UseConcMarkSweepGC im Kommandozeilenaufruf hinzu.

Option zur Begrenzung der Anzahl der zu migrierenden Versionen

Wenn Sie den optionalen Parameter -rv <versions_to_retain> oder -recentVersionToRetain <versions_to_retain> verwenden, legen Sie mit dem numerischen Wert <versions_to_retain> fest, wie viele der letzten Versionen von Workflows und Modulen migriert, also beibehalten werden sollen. Frühere Versionen der Workflows und Module werden dann bei der Migration übersprungen.

Standardmäßig oder wenn <versions_to_retain> gleich 0 oder kleiner ist, werden alle Versionen migriert. Hat ein Workflow oder Modul weniger als <versions_to_retain> Versionen, werden diese alle migriert. Die HEAD-Version wird immer migriert.

Die Nummerierung der Versionen bleibt nach der Migration dieselbe; die Versionserhöhung wird bei der höchsten Versionsnummer fortgesetzt.

Migrationsreport

Während der Ausführung des Migrationsskripts wird im Migrationsverzeichnis /bin/migration/reports ein Migrationsreport als HTML-Datei migrationreport-<timestamp>.html erzeugt. Er enthält die Migrationsergebnisse sowohl im Erfolgsfall als auch im Fehlerfall.

Beispiel: /bin/migration/reports/migrationreport_2019.11.15_11.12.53.html

Wenn Sie die Migration abbrechen, werden bereits durchgeführte Änderungen am Zielsystem nicht zurückgerollt. Sie können die Migration später einfach neu starten.

Stoppt das Migrationsskript unter Windows bei der Erstellung des Backups wegen gesperrter Bibliotheksdateien, führen Sie eine der beiden Optionen aus:

Erstellen Sie ein System-Backup mit dem Backup Connector und verwenden Sie die generierte ZIP-Datei für die Migration.
Entfernen Sie die Bibliotheken (jar-Dateien) manuell aus dem Quellsystem und fügen Sie diese nach der Migration im Zielsystem neu ein.