Migration von BPC 3.* nach BPC 4
Auf dieser Seite wird beschrieben, wie man eine bestehende BPC 3 Installation auf BPC 4 migriert.
Installation BPC 4
-
Stoppen Sie Ihre BPC 3 Installation
-
Folgen Sie der regulären Installationsanleitung bis zu Installation von Elasticsearch
-
Kopieren Sie das Daten-Verzeichnis (falls nicht anders Konfiguriert
ELASTICSEARCH/data
) aus der BPC 3 Installation in die neue Elasticsearch Installation.Das Daten-Verzeichnis in der BPC 4 Installation wird von Elasticsearch 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, falls Sie die neue Elasticsearch Installation auf das gleiche Verzeichnis zeigen lassen wollen.
-
Fahren Sie mit der Installationsanleitung fort
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 Elasticsearch) 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.