This section introduces the options for SLT replication during a Zero Downtime Option (ZDO) maintenance event.
When you are updating or upgrading an SAP S/4HANA system using ZDO, the replication of changes using SAP Landscape Transformation Replication Server (SLT) is supported. SLT replication can also be used as part of SAP Data Intelligence and Operational Data Provisioning. From SLT perspective, the system that is upgraded using ZDO can be either a source or target system. However, the replication type is important to be checked:
Note
Only RFC-based replication is supported by ZDO. Replication using native database connections cannot be determined by SUM. Further information on the different SLT replication types can be found in SAP Note 1605140.There are four cases that have to be distinguished:
- SUM with active SLT replication: SLT is used in production. The current system has the same SLT setup like production. SLT should be functional during the bridge runtime.
- SUM with deactivated SLT replication: SLT is used in production. The current system has the same SLT setup like production. However, SLT should be deactivated during the bridge runtime.
- SUM without SLT replication: SLT is used in production. The current system that is being upgraded (for example, sandbox) do not have an SLT setup. In that case, there is no special handling of SUM in the current system. However, the Impact Analysis outlines the tables that will be cloned but, as per the used table statistics file from production, SLT triggers are linked to a particular table. For details, see the section 'Results of the Impact Analysis' in unit 4.
- No SLT replication: SLT is not used.
When SUM is launched and ZDO is selected as downtime-optimization approach, the phase SUMASK_RFC_2_SLT_SERVER
in Configuration automatically determines if the system currently being upgraded uses SLT replication based on SLT triggers found in the system. This applies for the described cases 1 and 2.
![](/service/media/topic/f6374373-15ba-4f5d-bde0-0c0a186289d1/ADM330_23_en-US_media/ADM330_23_en-US_images/U3L2C1_SLT_SUM_UI_Image.png)
Case 1: SUM with active SLT replication
The checkbox "Yes, run ZDO with active SLT triggers" in phase SUMASK_RFC_2_SLT_SERVER
is checked. To keep the SLT replication active during the bridge runtime, an RFC destination for each of the connected SAP Landscape Transformation Replication servers has to be provided to SUM.
The RFC destination has to be of type ABAP. The user provided to the SLT server has to have at least the following user roles:
- SAP_IUUC_REPL_ADMIN
- SAP_IUUC_REPL_REMOTE
- SAP_MWB_PROJECT_MANAGER
Further details on how to create the RFC destination can be found in the latest ZDO guide.
Note
Depending on the source system and SLT server configuration, there are two different technologies used by SLT replication. Database triggers having the prefix /1LT/ are using the legacy change data capture mechanism. The subscription-based change data capture mechanism is used by triggers having the prefix /1DH/. This is possible from SAP S/4HANA 2020 onwards.These RFC destinations are used to prepare the database triggers needed during the bridge runtime. This is only relevant if SLT triggers from legacy change data capture mechanism with the prefix /1LT/ are used and determined by SUM.
Additional prerequisites and restrictions are as follows:
- At least SAP HANA revision 2.0.00.42.
- After phase
SUMASK_RFC_2_SLT_SERVER
, it is not allowed to start or stop SLT replication for a particular table as this can lead to inconsistencies. - Various SAP Notes that have to be applied in the source system.
- Various SAP Notes that have to be applied in the central SLT server.
Note
The list of SAP Notes is volatile and still gets extended. Hence, make sure that you always have the latest SLT-related corrections applied before starting the ZDO upgrade. For this, the so-called Note Analyzer is provided (for details, see SAP Notes 2596411 and 3016862). In addition, the SLT Release Information Notes listed in SAP Note 2572945 provide the full list of relevant SAP Notes.![](/service/media/topic/f6374373-15ba-4f5d-bde0-0c0a186289d1/ADM330_23_en-US_media/ADM330_23_en-US_images/U3L2C1_SUM_SLT_active_Image.png)
- In phase
RUN_ZDO_SLT_IMPANA_CONSISTENCY
SUM checks the number of SLT triggers on tables as reported in the statistics fileZDIMPANA.ZIP
and a number of SLT triggers in the current system. A mismatch might indicate a different setup of the system where statistical data is exported from (typically production system) and the current system. If only one of the systems has SLT triggers, SUM will stop. If the mismatch is intentional, the error can be ignored. - When the decision on phase
SUMASK_RFC_2_SLT_SERVER
was made that SLT replication should be kept active, the RFC destinations to the SLT servers has to be provided. - As part of the ZDO consistency check in phase
PARRUN_ZDO_CONSISTENCY_CHECK
SUM verifies if the SLT setup is valid. - The Impact Analysis outlines the tables having SLT triggers but have to be cloned by ZDO. This helps to elaborate the amount of tables that have to be re-initialized after the ZDO upgrade.
- Shortly before the end-users are transitioned to the bridge subsystem, phase
RUN_CHECK_SLT_TRIGGER_ZDM_BRI_ROLL_PRE
informs about tables that are handled in a special way but have SLT triggers. The phase is equipped with an ignore option. The triggers can be kept until the next SLT check phase runs.Note
These tables are handled by an application-defined procedure (XCLA class) and needs to be treated in a special way by SUM to prevent the table of being set to read-only. This special handling leads to a necessity to drop the trigger for these XCLA tables. However, this is a very rare case. Additionally, such changes are mostly delivered by silent data migration classes rather than using an XCLA implementation. - After the rollover to bridge, phase
RUN_CHECK_SLT_TRIGGER_ZDM_BRI_ROLL_AFT
runs the same check like the previous SLT check phase. However, now the triggers on the tables listed have to be dropped in order to proceed. - At the end of the bridge runtime, phase
REQ_DEL_RFC_2_SLT_SERVER
reminds to delete the RFC destination created manually in phaseSUMASK_RFC_2_SLT_SERVER
. Of course, it is not mandatory to delete the RFC destination but, for security reasons, it might be required. - When the system is restarted, as part of the ramp up activities, an initial load is needed for all switch, clone, and XCLA tables having SLT triggers. Tables handled as shared by SUM, are not affected.
Note
In general, all of these tables were having two different versions during the ZDO upgrade. Only the source version of the tables was equipped with the SLT trigger. The new version of the tables that belong to the target release, do no longer have SLT triggers. Hence, it is mandatory to perform an initial load for such tables in the SLT cockpit.Case 2: SUM with deactivated SLT replication
If the checkbox "Yes, run ZDO with active SLT triggers" in phase SUMASK_RFC_2_SLT_SERVER
is unchecked, the SLT replication has to be paused or suspended before rolling over to the bridge subsystem.
![](/service/media/topic/f6374373-15ba-4f5d-bde0-0c0a186289d1/ADM330_23_en-US_media/ADM330_23_en-US_images/U3L2C1_SUM_SLT_deactiv_Image.png)
- In phase
RUN_ZDO_SLT_IMPANA_CONSISTENCY
SUM checks the number of SLT triggers on tables as reported in the statistics fileZDIMPANA.ZIP
and a number of SLT triggers in the current system. A mismatch might indicate a different setup of the system where statistical data is exported from (typically production system) and the current system. If only one of the systems has SLT triggers, SUM will stop. If the mismatch is intentional the error can be ignored. - SUM detected that the systems uses SLT replication. However, in phase
SUMASK_RFC_2_SLT_SERVER
the decision was taken that SLT replication should be deactivated during the bridge runtime. - The Impact Analysis outlines the tables that have SLT triggers but have to be cloned by ZDO. This helps to elaborate the amount of tables that have to be re-initialized after the ZDO upgrade.
- The first SLT check in phase
RUN_CHECK_SLT_TRIGGER_ZDM_BRI_ROLL_PRE
lists the tables for which the SLT triggers have to be dropped. This phase is equipped with an ignore option. The triggers can be kept until the next SLT check phase runs. - Shortly after starting the rollover to bridge, the SLT check phase
RUN_CHECK_SLT_TRIGGER_ZDM_BRI_ROLL_AFT
runs. Here, the triggers for the tables listed have to be dropped in order to proceed. - Before the rollover to the bridge happens, the SLT replication has to be suspended in the SLT cockpit.
- When the system was restarted, as part of the ramp-up activities, an initial load is needed for all switch, clone, and XCLA tables having SLT triggers. Tables handled as shared by SUM, are not affected.
Note
In general, all of these tables have two different versions during the ZDO upgrade. Only the source version of the tables are equipped with the SLT trigger. The new version of the tables that belong to the target release no longer have SLT triggers. Hence, it is mandatory to perform an initial load for such tables in the SLT cockpit.Further Information
- SAP Note 1605140 - SAP Landscape Transformation Replication Server (SLT)
- SAP Note 2572945 - DMIS compatibility with S/4HANA
- SAP Note 2596411 - Note Analyzer for ABAP-based Migration and Replication Technology […]
- SAP Note 3016862 - Note Analyzers with separated scenarios for ABAP-based Migration and Replication Technology […]