SAP Learning Journey

Deciding on the Handling of SLT Triggers during a ZDO Maintenance Event

Objectives
After completing this lesson, you will be able to:

After completing this lesson, you will be able to:

  • Decide on SLT Trigger Handling during ZDO execution

SLT Database Trigger Handling in ZDO

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.

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.

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.
  • In phase RUN_ZDO_SLT_IMPANA_CONSISTENCY SUM checks the number of SLT triggers on tables as reported in the statistics file ZDIMPANA.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 phase SUMASK_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.

  • In phase RUN_ZDO_SLT_IMPANA_CONSISTENCY SUM checks the number of SLT triggers on tables as reported in the statistics file ZDIMPANA.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

Set Up the Connectivity to the SLT server

Select Start Exercise to start the simulation.

ExerciseStart Exercise

Steps

  1. Check the SUM UI dialog in phase SUMASK_RFC_2_SLT_SERVER

    1. Select the check box Yes, run ZDO with active SLT triggers to switch off the SLT trigger handling in SUM. The text box for the RFC destination name will disappear.

      Note

      If you resume SUM now, with the unchecked option, the complete outbound SLT replication from this source system would be paused or suspended during the uptime on the bridge subsystem.

    2. Select the check box Yes, run ZDO with active SLT triggers again. The text box for the RFC destination name will appear again.

      Note

      For this demo, we want to keep the SLT replication active during the uptime on the bridge subsystem.

      The RFC destination UPG_ZDO_SLTSRV can be overwritten. In this exercise, keep the default name as set by SUM.

      In case multiple SLT servers are connected to the system, more than one RFC destination can be added to the list by adding more line items using the + icon.

  2. Log on to the productive SAP S/4HANA 2020 system.

    1. Log on to the system with user DDIC_DEV. The password is already pre-filled.

  3. Create the RFC destination to the remote SAP Landscape Transformation Replication server.

    1. Enter transaction code SM59 in the transaction box.

    2. Choose ABAP Connections in the navigation tree.

    3. Create a new RFC destination of type 3 (ABAP Connections).

    4. Enter UPG_ZDO_SLTSRV as name of the RFC destination.

    5. In the Description 1 field, enter From SAP S/4HANA.

    6. In the Description 2 field, enter To SLT server.

    7. Select the radio button Host in section Save to Database as. This will save the hostname in the database rather than the resolved IP Address.

    8. Enter the hostname sltserverhost in the Target Host field.

    9. Enter the instance number 00.

    10. Switch to the Logon & Security tab to enter the user credentials for the SLT server.

    11. Set the Language field to EN.

    12. In the Client field, enter 000.

    13. In the User field, enter SLT_REMOTE. The password is already pre-filled.

    14. After entering all parameters, save the RFC destination.

    15. Perform a Connection Test to check if the host is reachable.

    16. In order to go back, choose the Cancel button in the menu bar.

  4. Logon to the SLT server using the newly created RFC destination.

    1. To logon, choose the Remote Logon button in the menu bar.

    2. Enter transaction code SU01D in the transaction box.

    3. In the User field, enter the username: SLT_REMOTE.

    4. Display the user by selecting the button in the menu bar.

    5. Navigate to the Roles tab.

      Note
      The user needs to have at least the three user roles shown in the UI. For details, check the latest guide for Zero Downtime Option in the SAP Support Portal.

    6. To leave the screen, choose the Exit button in the menu bar.

  5. In the SUM UI, choose Next to resume the SUM procedure.

Save progress to your learning plan by logging in or creating an account

Login or Register