Relocation of the central system
1 General
This chapter describes the relocation of existing Conigma central system to another system.
All of the objects (change requests, releases, customizing, etc.) will be transferred.
The sequence of the steps must be followed, because it can cause to a complete loss of all Conigma data (in the worst case)!
A backup of database tables of the old central system, starting with "/GAL/" is highly recommended!
2 Infrastructure Setup
2.1 Create new Infrastructure
Loopback connection to new central system (connection of the new central system to itself).
RFC connections from the satellite systems to the new central system.
RFC connections from the new central system to all satellite systems.
If the same connection names will be used like for the old central system to the satellite systems, it will save a few steps later on.
2.2 Configuration of Central System
These actions must be performed locally on the new central system!
Run report /GAL/CCM_ADMTOOLS_CONFIG_RESET
Set/mark both flags
As the RFC connection, specify the loopback connection to the new central system
2.3 Data Migration
These actions must be performed locally on the old central system!
Create Workbench transport which can be used in the report (see number 1 in the screenshot below) and manually transferred in the queue of the new central system.
To generate the transport relevant Conigma data, use the Conigma report /GAL/CCM_REPOSITORY_EXPORT on the old central system.
In the selection screen of this report you can decide to export the current data together with the historical data or to export the current data in a first step and export the historical data in a second step.
We recommend to do it in two steps to minimize the downtime for Conigma when moving the data.
First move the current data only, so that you are ready to work again with Conigma.
The historical data could be moved in a second step.
Even if the export is very fast, the import of the historical data blocks the whole process, because the historical data are alphabetically somewhere in between and you can continue with Conigma after the complete import is finished.
Please don’t forget to select the repository you want to relocate (see number 2)
Normally we go through this report in a conference call to discuss the different options.
Subsequently, the transport request must be released and imported into the new central system.
To get a feeling how long the export will take you can run tests for current and historical data without harming Conigma. Please note that most of the time will be consumed by releasing the transport (The runtime of the report itself is very fast).
Once you run this report for production purpose don’t forget to restrict Conigma for Conigma administrators only or at least informing Conigma users that you are moving Conigma.
It should be clear that after starting the export, changes to existing Conigma objects or new objects or deleted objects cannot be taken into account.
To allow Conigma for Conigma administrators only and informing Conigma users that you are moving Conigma we recommend to use the ‘System message’ feature under ‘Edit global settings’ with an according message (see example below).
Note on the separate export of current and historical data. If you have chosen this path and the central system has already been moved in step 1, you will receive a corresponding warning for step 2 that you are not running the report on the central system. In this constellation, the warning can then be ignored. In case of doubt, please always consult with Conigma support.
2.4 Create Connection to all other systems
These actions must be performed locally on the new central system!
2.4.1 Change the connection of the new central system to the satellite systems.
Please note: This is only necessary if the connection names are not identical to those of the old central system.
Expand the list of systems in the repository browser
Open each system for editing
In tab “SAP” enter the RFC-connection of the new central system to the corresponding satellite systems
Perform the same step for all clients registered in Conigma
2.4.2 Change the connection of the satellite systems to the new central system
Expand the list of systems in the Conigma repository browser
Open each system for editing
Enter in tab "
System specific settings" for the parameter "RFC route to central system" the RFC connection name from the satellite system to the new central system.
Alternative: Run the Configuration Wizard on all satellite systems and change these parameters by resetting the RFC route.
2.4.3 Verify your configuration changes
To verify your configuration changes please run ‘Check configuration’ and check the output for error messages.
2.5 Data Migration of Customer Specific Tables
Please do not forget to adopt custom specific tables, like for interfaces, etc.
The standard number ranges are already migrated. Here we have to cover the customer specific objects only.
3 Known Issues
3.1 Conigma does not start
Issue: At the start of Conigma, the following message appears:
Solution: Call transaction SM59 and maintain the new IP address in all RFC connections from and to the new central system
3.2 Systems are displayed as "offline" in Conigma
Issue: Following error message occurs in transaction SM59
Solution: Ensure that following services at operating system are known.
in Windows-based systems the services file is usually under: "C:\WINDOWS\system32\drivers\etc\services"
in UNIX-based systems under:
"/ etc/services"
Required services:
sapdpNN | 32NN/tcp |
sapgwNN | 33NN/tcp |
sapmsSID | 36NN/tcp |
sapgwNNs | 38NN/tcp |
Replace: NN: by instance number
SID: by system ID