(Glue-2308) Refreshing a System with SNP Glue

Table of Contents:

General Information

SAP System Refresh procedure is used to overwrite an existing Target system with the data from the Source system while preserving Target system configuration.

Assumption #1: The copy is made from production system via database backup/restore procedure.
Assumption #2: SNP Glue and SNP JCO versions are identical in 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.

Export SM_SETUP from Target system

Transaction: /DVD/SM_SETUP > Menu: Tools > SM backup

Choose export file path, select Export data in Actions and Confirm (F8).
Configuration tables included in backup can be shown using button Specify table selection.

Export Glue settings from Target system

Transaction: /DVD/GLUE > Menu: Tools > Glue utilities > Glue backup

Choose export file path, select Export data in Actions and Confirm (F8).
Configuration tables included in backup can be shown using button Specify table selection.

Deactivate Glue Tables in Target System

The goal of this step is to clean up the replication target of 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 target platform, with the exception of File storage types (AWS S3, Azure ADLS, GCP GCS, etc.). In case of File storage types, manual cleanup on target platform is recommended.

Target System Overwrite

List of Glue components which 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 intention of procedure described here is to preserve Glue objects defining the data flows in inactive state, while deleting objects which 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 wrong SM target and start the system.

Deactivate Glue scheduling in 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 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 Source system. Confirm (F8).

Restore Glue settings (optional)

This step only makes sense if Glue settings in Target differ from 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). Following steps are assuming that the schema has already a new name.

Deactivate all Glue objects

Complete deactivation report is dependent on 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

Important part of the deactivation procedure is the correction of database schema name inherited from Source system in Glue metadata related to database triggers (table /DVD/GL_DBTH). This correction ensures that during deactivation of Fetcher objects, related Triggers and Shadow tables can be correctly addressed and deleted from database.

Reconfigure SNP JCO

Similarly to Storage Management setup, the JCO configuration is stored as a table content and still refers to Source system. To adapt it to Target system, you can either re-deploy the Java Connector from scratch, or correct following parameters in transaction /DVD/JCO_MNG:

  • Adapt technical user or SNC setup for Target system (correct authentication)

  • Double check paths to installation directory, configuration files, logs and JRE in /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.