Table of Contents:
General Information
The SAP System Refresh procedure is used to overwrite an existing Target system with the data from the Source system while preserving the Target system configuration.
Assumption #1: The copy is made from the production system via the database backup/restore procedure.
Assumption #2: SNP Glue and SNP JCO versions are identical in the Source and Target systems.
Before the Refresh
Export Configuration of Target System
Similarly to other SAP system configuration tables, an export of Glue component settings is needed before the refresh.
Set Master Key in SM_SETUP
All passwords are stored in encrypted format. There is a Master key used for encryption.
To be able to correctly re-import the SM configuration after the refresh, a custom Master key needs to be set before the configuration export.
You can skip this step if the Master key has already been set and its value is known.
Transaction: /DVD/SM_SETUP > Toolbar: Manage Master key
Type in the Master key and Continue
Export SM_SETUP from the Target system
Transaction: /DVD/SM_SETUP > Menu: Tools > SM backup
Choose the export file path, select Export data in Actions, and Confirm (F8).
Configuration tables included in the backup can be shown using the button Specify table selection. If tables /DVD/SM_STORAGE and /DVD/SM_STORPAR are in the selection, it’s necessary to keep the order. Table /DVD/SM_STORPAR uses fields from /DVD/SM_STORAGE as foreign keys.
The prerequisite for backing up the tables is to set up the system master key in the Storage management.
A popup that requires the master key is shown after clicking on the run button. The inserted key has to be the same as the master key set up on the system.
Export Glue settings from the Target system
Transaction: /DVD/GLUE > Menu: Tools > Glue utilities > Glue backup
Choose the export file path, select Export data in Actions, and Confirm (F8).
Configuration tables included in the backup can be shown using the button Specify table selection.
Deactivate Glue Tables in the Target System
The goal of this step is to clean up the replication target of the Target system. The reason is to ensure there will be no conflicts during Glue object activation attempts after the Refresh procedure is completed.
By deactivating Glue tables they will be effectively dropped from the target platform, except File storage types (AWS S3, Azure ADLS, GCP GCS, etc.). In the case of File storage types, manual cleanup on the target platform is recommended.
Target System Overwrite
List of Glue components that refer to the Source system configuration at this point and need to be corrected:
Storage Management
SNP Java Connector
Glue Tables
Database schema in Triggers' Header table (/DVD/GL_DBTH)
Database Triggers and related Shadow tables
Glue Fetchers, Queues (and by derived relation Consumers and Extraction Processes)
The procedure described here intends to preserve Glue objects defining the data flows in an inactive state while deleting objects that are no longer relevant (database triggers and their shadow tables).
Post-processing before Background Process Activation
Deactivate background work processes to avoid accidental replication to the wrong SM target and start the system.
Deactivate Glue scheduling in the Target system
It is expected that there will be released Glue jobs or Glue scheduling active. These need to be deactivated to prevent unwanted replication execution.
Restore Storage Management Configuration
Import /DVD/SM_SETUP configuration from the exported file.
Transaction: /DVD/SM_SETUP > Menu: Tools > SM backup
Choose the backup file path, select Import data in Actions, and mark Cleanup before import option, which will delete connections inherited from the Source system. Confirm (F8).
There are two ways how to import the configuration of storages.
With keys in storages: This option requires setting up the master key in the system with the same value as on the source system. The same key has to be inserted in a popup after clicking on the run button.
Without keys in storages: The master key is not required, but no keys will be inserted into storage options.
Restore Glue settings (optional)
This step only makes sense if the Glue settings in Target differ from the Source system.
Similarly to the step above, import /DVD/GLUE settings from the backup file.
Transaction: /DVD/GLUE > Menu: Tools > Glue utilities > Glue backup
Post Processing after Background Process Activation
At one point in the System refresh post-processing steps there may be a database schema rename (depending on the DB type). The following steps assume that the schema has already a new name.
Deactivate all Glue objects
The complete deactivation report is dependent on the Glue 2308 version and can be downloaded from
https://files.datavard.com/index.php/s/ArDGGGFgsbidPaQ
Password: mcHaa2cj
The program is executed via:
/DVD/GLUE > Menu: Tools > Mass Operations > Object Act/Deact
An important part of the deactivation procedure is the correction of the database schema name inherited from the Source system in Glue metadata related to database triggers (table /DVD/GL_DBTH). This correction ensures that during the deactivation of Fetcher objects, related Triggers, and Shadow tables can be correctly addressed and deleted from the database.
Reconfigure SNP JCO
Similarly to the Storage Management setup, the JCO configuration is stored as table content and still refers to the Source system. To adapt it to the Target system, you can either re-deploy the Java Connector from scratch or correct the following parameters in transaction /DVD/JCO_MNG:
Adapt technical user or SNC setup for Target system (correct authentication)
Double-check paths to the installation directory, configuration files, logs, and JRE in the /Config\ and /Advanced\ tabs (correct paths)
Restart SNP JCO
Having the JCO running and SM configuration restored, execute storage checks in /DVD/SM_SETUP.
Once the checks are successful, Glue objects can be activated again.