Migration von BPC 3.* nach BPC 4.1
Auf dieser Seite wird beschrieben, wie man eine bestehende BPC 3-Installation auf BPC 4.1 migriert. Dafür müssen die Elasticsearch-Daten in den Zustand einer BPC 4.0 Installation überführt werden.
Haben Sie bereits BPC 4.0 installiert, nutzen Sie die Anleitung Migration von BPC 4.0 nach BPC 4.1
Migration
-
Stoppen Sie Ihre BPC 3 Installation
-
Folgen Sie der regulären Installationsanleitung bis zu Installation von OpenSearch
-
In diesem Schritt wird eine Zwischenmigration der Daten durchgeführt, um diese in OpenSearch überführen zu können.
-
Laden Sie das zu BPC 4.0 gehörende Elasticsearch herunter (z.B. aus https://files.virtimo.net/bpc/latest/support/4.0.x/release/) und entpacken Sie dieses nach
INSTALLATIONSVERZEICHNIS
. -
Kopieren Sie ihr Daten-Verzeichnis (
INSTALLATIONSVERZEICHNIS/elasticsearch/data
) in die neue Elasticsearchinstallation (INSTALLATIONSVERZEICHNIS/elasticsearch-7.10.2/data
) -
Starten Sie die neue Elasticsearch Installation und verfolgen Sie die Logs (
INSTALLATIONSVERZEICHNIS/elasticsearch-7.10.2/logs
). Die Daten werden nun automatisch auf die neue Elasticsearch Version angepasst, die auch für den Umstieg auf OpenSearch nötig ist. Je nach Umfang der Daten sollten Sie nach einer gewissen Zeit in den Logs sehen können, dass alle Indices bereit sind.
-
-
Nun sind Ihre Daten für die weitere Migration nach BPC 4.1 vorbereitet. Sie können nun mit der Migrationsanleitung fortführen.
Das Daten-Verzeichnis in der BPC 4 Installation wird automatisch migriert. Dieses kann anschließend nicht zurück in eine BPC 3 Installation übernommen werden. Daher sollten Sie das alte Daten-Verzeichnis kopieren oder sichern.
-
Ist die Migration abgeschlossen, können Sie die beiden alten Elasticsearch Installationen entfernen.
BPC 4.1 ist weiterhin Java 11 kompatibel. Jedoch ist der Support für Java 11 im Jahr 2023 augelaufen. Ein Umstieg auf Java 17 wird empfohlen. Siehe Update Guide - Java |
Wichtige Änderungen
Im Folgenden sind wichtige Änderungen zwischen BPC 3 und 4 aufgeführt. Bitte lesen Sie diese Abschnitte sorgfältig, unter Umständen müssen Sie selbstständig Änderungen durchführen.
Interne Modul ID der Backend Connections wurde umbenannt
Die interne ID des "Backend Connections" Moduls war historisch bedingt httpproxy
.
Dies wurde zu backendconnection
umbenannt.
Beim ersten Start des BPC 4 werden die Konfigurationen automatisch angepasst.
Das Recht loadModule_httpproxy
muss ebenfalls in loadModule_backendconnection
geändert werden.
Bei Eigenentwicklungen müssen evtl. Codestellen angepasst werden. Dies kann zum Beispiel folgende Fälle betreffen:
-
Setting Definitionen vom Typ
linkedModuleInstance
bei denen auf eine Backend Connection (_linkedModuleId
) verwiesen wird. Dorthttpproxy
durchbackendconnection
ersetzen. -
Wenn über unsere API Endpunkte (oder direkt in OpenSearch) Backend Connections angelegt werden, auch dort ist dann
httpproxy
durchbackendconnection
zu ersetzen. -
Zugriff auf das Backend Connection Modul:
getModuleManager().getModule("httpproxy")
→getModuleManager().getModule("backendconnection")
-
Wenn Modul Instanzen abgefragt werden um zum Beispiel nach einer Data Source oder INUBIT-Verbindungen zu filtern. Dort dann die moduleId Prüfung auf
httpproxy
durchbackendconnection
ersetzen.
'Deployment Targets' wurden umbenannt
Die Backend Connections vom Typ deployment_target
wurden beim Deployment für die Auswahl der Quelle (Source) und Ziel (Target) verwendet.
Da dies verwirrend war, wurden diese zu deployment_system
umbenannt.
Beim ersten Start des BPC 4 werden bestehende Konfigurationen automatisch angepasst.
Automatisch angelegtes Deployment System 'dt_local' wurde umbenannt
Für das lokale BPC wird automatisch ein Deployment System angelegt. Bisher hatte dies die ID 'dt_local' (dt = deployment target). Dies wird nun mit der ID 'ds_local' (ds = deployment system) angelegt.
Beim ersten Start des BPC 4 wird es automatisch umbenannt.
Benutzername & Passwort Authentifizierung wurde bei der Deployment System Konfiguration entfernt
Bei der Deployment System Konfiguration wurde die Authentifizierung per Benutzername und Passwort entfernt. Auf die Deployment Systeme kann nur noch per API Key zugegriffen werden. Es muss ggfs. auf dem angesprochenen Deployment System zuerst ein API Key angelegt und dieser dann bei der Deployment System Konfiguration hinterlegt werden.
Deployment API Endpunkt wurde umbenannt
Der API Endpunkt zur Abfrage der konfigurierten Deployment Systeme wurde von /cxf/bpc-deployment/deployment/targets
nach /cxf/bpc-deployment/deployment/systems
umbenannt.
Data Source Name bei Datenbankverbindungen wurde ersetzt
Bei den Datenbankverbindungen (Backend Connections vom Typ "data_source") wurde bis zur BPC 3 das extra Feld dataSourceName
für den Namen der Data Source verwendet und von verschiedenen Stellen aus referenziert.
In der BPC 4 wurde dieses durch die Instanz ID der Backend Connection vom Typ "data_source" ersetzt.
Beim ersten Start des BPC 4 werden existierende Datenbankverbindungen mit dem bisherigen dataSourceName
als neue Instanz ID angelegt und das extra Feld gelöscht.
Da der bisherige Name der 'dataSourceName' nicht 1:1 übernommen werden kann (nicht alle Zeichen sind bei IDs erlaubt), werden bei den Replikation-Jobs, Log Services und JAAS DB basierten Identity Provider die Referenzen entsprechend angepasst.
Gültigkeitsende der API Keys
Das Gültigkeitsende der ausgestellten API Keys wurde bisher relativ im Feld expiresIn
(z.B. als 360 days
oder 1 year
) angegeben.
Dies wurde durch ein absolutes Datum im Feld expiresOn
(z.B. 2026-06-19T11:30:00.000Z
) ersetzt.
Beim ersten Start des BPC 4 werden die relativen Werte durch absolute Daten ersetzt.