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.
1. 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.
2. Kopieren Sie ihr Daten-Verzeichnis (INSTALLATIONSVERZEICHNIS/elasticsearch/data) in die neue Elasticsearchinstallation (INSTALLATIONSVERZEICHNIS/elasticsearch-7.10.2/data)
3. 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.

Bitte beachten Sie auch die Breaking Changes im Changelog. Dabei sind alle Einträge zwischen ihrer aktuellen Version und der Zielversion zu beachten. Dies kann bedeuten, dass Sie Changelog mehrerer Versionen beachten müssen.

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. Dort httpproxy durch backendconnection ersetzen.
Wenn über unsere API Endpunkte (oder direkt in OpenSearch) Backend Connections angelegt werden, auch dort ist dann httpproxy durch backendconnection 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 durch backendconnection 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.

Keywords: