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. Dort httpproxy durch backendconnection ersetzen.
Wenn über unsere API Endpunkte (oder direkt in Elasticsearch) 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: