Migration from BPC 3.* to BPC 4.1

This page describes how to migrate an existing BPC 3 installation to BPC 4.1. To do this, the Elasticsearch data must be transferred to the state of a BPC 4.0 installation.

If you have already installed BPC 4.0, use the instructions Migration from BPC 4.0 to BPC 4.1

Migration

  1. Stop your BPC 3 installation

  2. Follow the regular Installation instructions up to the installation of OpenSearch

  3. In this step, an intermediate migration of the data is carried out in order to be able to transfer it to OpenSearch.

    1. Download the Elasticsearch belonging to BPC 4.0 (e.g. from https://files.virtimo.net/bpc/latest/support/4.0.x/release/) and unzip it to INSTALLATIONSVERZEICHNIS.

    2. Copy your data directory (INSTALLATIONSVERZEICHNIS/elasticsearch/data) to the new Elasticsearch installation (INSTALLATIONSVERZEICHNIS/elasticsearch-7.10.2/data)

    3. Start the new Elasticsearch installation and track the logs (INSTALLATIONSVERZEICHNIS/elasticsearch-7.10.2/logs). The data is now automatically adapted to the new Elasticsearch version, which is also required for the migration to OpenSearch. Depending on the size of the data, you should be able to see in the logs after a certain time that all indices are ready.

  4. Your data is now prepared for further migration to BPC 4.1. You can now continue with the Continue with the migration instructions.

    The data directory in the BPC 4 installation is migrated automatically. This cannot then be transferred back to a BPC 3 installation. You should therefore copy or back up the old data directory.

  5. Once the migration is complete, you can remove the two old Elasticsearch installations.

BPC 4.1 is still Java 11 compatible. However, support for Java 11 will expire in 2023. Switching to Java 17 is recommended. See Update Guide - Java

Important changes

Important changes between BPC 3 and 4 are listed below. Please read these sections carefully, you may need to make changes yourself.

Internal module ID of Backend Connections has been renamed

The internal ID of the "Backend Connections" module was historically httpproxy. This has been renamed to backendconnection.

When BPC 4 is started for the first time, the configurations are automatically adjusted.

The loadModule_httpproxy right must also be changed to loadModule_backendconnection.

For in-house developments, code may need to be adjusted. This can affect the following cases, for example:

  • Setting definitions of type linkedModuleInstance where reference is made to a Backend Connection (_linkedModuleId). Replace httpproxy with backendconnection.

  • If backend Connections are created via our API endpoints (or directly in OpenSearch), httpproxy must also be replaced with backendconnection there.

  • Access to the Backend Connection module: getModuleManager().getModule("httpproxy") → getModuleManager().getModule("backendconnection")

  • If module instances are queried, for example to filter for a data source or INUBIT connections. Then replace the moduleId check on httpproxy with backendconnection.

'Deployment Targets' have been renamed

The Backend Connections of type deployment_target were used during deployment to select the source and target. As this was confusing, they have been renamed to deployment_system.

Existing configurations are automatically adjusted when BPC 4 is started for the first time.

Automatically created deployment system 'dt_local' has been renamed

A deployment system is automatically created for the local BPC. Previously this had the ID 'dt_local' (dt = deployment target). This is now created with the ID 'ds_local' (ds = deployment system).

It is automatically renamed when BPC 4 is started for the first time.

User name & password authentication has been removed from the deployment system configuration

Authentication by user name and password has been removed from the deployment system configuration. The deployment systems can now only be accessed via API key. If necessary, an API key must first be created on the addressed deployment system and then stored in the deployment system configuration.

Deployment API endpoint has been renamed

The API endpoint for querying the configured deployment systems has been renamed from /cxf/bpc-deployment/deployment/targets to /cxf/bpc-deployment/deployment/systems.

Data source name for database connections has been replaced

For database connections (backend Connections of type "data_source"), the extra field dataSourceName was used for the name of the data source up to BPC 3 and referenced from various places. In BPC 4, this was replaced by the instance ID of the backend Connection of type "data_source".

When BPC 4 is started for the first time, existing database connections with the previous dataSourceName are created as a new instance ID and the extra field is deleted. As the previous name of the 'dataSourceName' cannot be adopted 1:1 (not all characters are allowed for IDs), the references are adapted accordingly for replication jobs, Log Services and JAAS DB-based identity providers.

End of validity of the API keys

The end of validity of the issued API keys was previously specified relatively in the field expiresIn (e.g. as 360 days or 1 year). This has been replaced by an absolute date in the field expiresOn (e.g. 2026-06-19T11:30:00.000Z).

When BPC 4 is started for the first time, the relative values are replaced by absolute dates.

Keywords:
Press Esc to exit full screen
Modal image placeholder
Press Esc to exit full screen