Planning a ZDO project

Objectives

After completing this lesson, you will be able to:

  • Plan a maintenance event with ZDO

Planning Aspects of a ZDO Maintenance Project

This section contains information about recommended execution cycles and further important planning aspects such as rollover to bridge subsystem.

Before performing the upgrade using Zero Downtime Option in the productive system, it is essential to plan and prepare the project. This includes the execution of test upgrade cycles in non-productive systems.

The first upgrade cycle is essential for the overall success of the upgrade project. Based on this, you will determine if ZDO is the right approach to follow in your upgrade project.

Note
The very first upgrade cycle has to be executed in a sandbox environment. It is highly recommended to create a sandbox system based on a recent system copy of the productive SAP S/4HANA system.

Purposes of running the first cycle in a sandbox environment

  • Familiarize with the technical upgrade approach ZDO
  • Understand and set expectations regarding the business downtime
  • Technical and functional validation of the bridge subsystem
  • Performing business validation tests on the bridge subsystem in the sandbox system help to verify that all core business processes are functional when running on the bridge subsystem
  • Analyze potential conflicts and impacts on critical business processes using the Impact Analysis
  • Address technical and functional findings to the responsible teams
  • Start creating an upgrade cookbook
Note
The test effort in the case of ZDO is higher compared to a standard upgrade as the source release should be tested and validated in a non-productive system. This also needs to be considered in terms of project planning.

Exemplary High-Level Project Plan

In general, it is recommended that you follow the same upgrade approach (either standard, nZDM, or ZDO) throughout the complete landscape for all systems. Hence, the following exemplary project plan for a 3-tier landscape that includes all systems from sandbox to production.

Cycle 1 and cycle 2 might be combined into one test cycle that will focus on both the technical validation of the ZDO procedure and the functional validation of the source release when running on a bridge subsystem.

Note
The results of cycles 1 and 2 need to be checked carefully, especially if the results of the Impact Analysis should be interpreted and discussed with the respective functional teams. Based on these findings, a go or no-go decision for the further ZDO project should be taken.

ZDO is used in general for all systems including development and quality assurance test systems. The last cycle before production has to run on a recent copy of production to rehearse to overall upgrade sequence. This ensures that the test shows all potential issues that might occur in production.

Additional Steps for ZDO

In addition to the standard update procedure using SUM, consider the following enhanced steps for ZDO.

Interpreting the results of the Impact Analysis

This part is essential and must not be skipped. By ignoring the results, you can hit severe business impact in production if business-relevant tables that were not checked beforehand are set to read-only.

Functional validation during the bridge runtime on a non-productive system

All business processes that need to be available for day-by-day operations on the bridge subsystem should be tested. This essentially means that the source release must be validated again. Compared to standard upgrades, where typically only the target release is tested, the effort for testing may significantly increases.

Considering load verification

Like the functional validation, a load verification is recommended to be triggered on a non-productive system during the time when users work on the bridge subsystem. From upgrade tool perspective, there is no requirement in having real users on the system. The load can also be generated using any load generation and testing tool.

Testing the Database Replication Setup

Database triggers used by SAP Landscape Transformation (SLT) scenarios require more attention in case of ZDO.

Note
In case SLT is used in the production system, it is strongly recommended that you perform this test as part of the first ZDO upgrade test cycle in the sandbox environment.

The right timing for rollover and rollback

This section deals with the estimation of the correct timing for rollover and rollback.

We recommend that you perform the rollover to the bridge subsystem at off-peak hours. Some steps after the rollover like the smart-switch in phase EU_SWITCH_ZDM need to acquire an exclusive database lock on the table to switch the table on-the-fly. Software Update Manager (SUM) Toolbox offers the feature "DB Table Lock Analyzer" to identify periods of time in which SUM can acquire required database locks. From SUM Toolbox reportRSTBX_LOCK_DATA_COLLECTOR can be scheduled as a regular background job in the production system. The job collects information about database locks that are requested during production operation. The results listing busy tables are available in SUM Toolbox. Optionally, SUM table classification data from any previous SUM run with the same software stack (for example, sandbox system) can be uploaded to narrow down the result.

Analyze the system utilization (dialog and batch load) and the alignment of the rollover to the bridge system in close collaboration with the functional teams. From this time onwards, the read-only restrictions on the read-only tables are active.

Calculate the rollover to the bridge subsystem based on the runtimes from the test cycle.

Assuming, as per the upgrade analysis file (UPGANA.XML), the net-runtime of the bridge subsystem in the dress rehearsal cycle took approximately 19 hours. Then, to calculate the recommended runtime of the bridge subsystem in production, a buffer of 24 hours should be added.

The productive bridge runtime should be calculated as follows:

Note
The buffer of 24 hours is highly recommended to compensate unexpected longer runtimes as well as unforeseen issues.
  • Take the value Bridge Time stated in the upgrade analysis file. In this example, the net-runtime in the dress rehearsal was like 19 hours
  • Recommended runtime of the bridge subsystem in production should be at least 19 hours + 24 hours = 43 hours

Now, by knowing that the recommended minimum runtime of the bridge subsystem in the example above should be approximately 43 hours, the timing for the rollover to bridge can be calculated.

Note
There is no maximum runtime of the bridge subsystem. As long as there are not restrictions for the business, you can extend the bridge runtime to fit your project requirements.

Functional Validation and Load Verification

This section introduces functional validation and load verification as important considerations during project execution to avoid any issues during maintenance of production system(s).

Recommended Testing Activities for Zero-Downtime Upgrades and Updates

In classic procedures like standard or near-Zero Downtime Maintenance, the functional validation of business processes happens after all upgrade activities of Software Update Manager are finished and the system was handed over to the functional teams.

When you are performing a zero-downtime upgrade project, key users of functional teams and test managers should be involved in the entire upgrade project. This starts when you plan the first sandbox system and ends when the productive SAP S/4HANA system has been successfully upgraded.

There are two major topics that should be in focus as part of testing activities:

  • Functional testing of crucial business processes
  • Load verification after the rollover to the bridge subsystem

Testing and verifying the system in different system states (prior, during, and after the ZDO upgrade or update) is essential for a successful zero-downtime project. As we have previously said, the functional teams and test managers should be part of the complete project cycle starting with the first upgrade happening in the sandbox environment. A recommendation on the number of test cycles is given in the lesson, 'Project Planning for Zero-downtime Upgrades' in unit 3.

Note

It is highly recommended that you plan and execute testing activities as part of the first sandbox upgrade. The results of the testing activities will be the foundation for taking a decision if the Zero Downtime Option approach meets the requirements and expectations from the business teams in terms of the availability of crucial business processes.

Concept of Functional Validation

Functional validation include the following activities:

  • Simulation of end-users or real testers like key users
  • Run connected interfaces (inbound and outbound)
  • Run scheduled background jobs (internally and externally scheduled)

Functional validation of crucial business processes ideally happens three times as shown in the illustration above:

(1) Baseline testing of the source release prior the upgrade is started

  • Baseline testing refers to the validation of the processes and specifications on which test cases are designed.
  • This test ensures that all business processes are functional before the ZDO upgrade is started.
  • If the baseline test is skipped but an error is found either during the bridge or after the upgrade, it will be hard to identify the root cause for the issue.
Note
In case a system is newly built up for performing an upgrade test, it is always recommended that you perform baseline testing. This holds true independently of the upgrade approach.

(2) Bridge testing of the source release during the ZDO procedure:

  • This is the most crucial testing activity. All relevant business processes should be tested thoroughly in a non-productive environment.
  • Proving that all business processes triggered by end-users, interfaces, and background jobs are fully available and functional during the bridge runtime is the ultimate goal of testing on the bridge.
  • Performing functional validation on the bridge subsystem helps to identify if crucial business processes would be blocked in case an application table would become read-only but one or more business processes require to change the table. Of course, the Impact Analysis would also identify such tables as long as the provided table statistics file is accurate. For details on the Impact Analysis, see unit 4.
Note
Some applications might be only restricted available during the bridge runtime. SAP Note 2707731 contains a list of known restrictions during the runtime of the bridge subsystem.

(3) Final testing of the target release after the upgrade is finished. Testing the target release after the ZDO upgrade follows the same best practices like in any other upgrade approach.

Functional validation key benefits:

  • Verify the business processes that will run on the bridge subsystem.
  • Proof that read-only restriction found using the Impact Analysis do not block critical business processes.
  • Proof known restrictions to applications listed in SAP Note 2707731.

Concept of Load Verification

The goal of load verification is to simulate production-like load in a non-productive environment. When you are performing load verification, the following activities should be considered - similar to what is shown in the illustration above:

(A) Activation of batch jobs (internally and externally scheduled)

  • Even in a non-productive system, it is highly recommended to simulate all jobs that are scheduled in production.
  • Especially, when rolling over to the bridge subsystem, it should be proven that all active batch jobs are taken over to the bridge subsystem.
  • As long as the batch jobs regularly perform an implicit commit, the rollover of active batch jobs will be done automatically by the reconnect feature which is triggered by the SAP Kernel.

(B) Simulation of end-user load (that is, using test automation tools)

  • In non-productive systems, typically only very few users are operating on the system.
  • Hence, the user load of end-users and interfaces can also be simulated using test automation tools.
Note
Performing a load test becomes especially important in case the productive system constantly shows a significant load. Load verification should be considered from phase REQ_USER_ROLLOVER_PREP until the end of the bridge runtime (phase REQ_USER_ROLLBACK_PREP).

The following upgrade phases should be focused on when performing a load test:

  • BRIDGE_RECONNECT: Reconnection of all users to the bridge subsystem as part of the rollover to bridge.
  • EU_SWITCH_ZDM: Renaming cloned tables during the smart-switch.
  • SQLRUNTASK_FDCT_TRANSFER: Creation of cloned tables.
  • PARCONV_UPG: Execution of DDL statements on cloned and shared tables.

Load verification key benefits:

  • Simulation of load impact to the overall system performance.
  • Proof that load can be handled by SUM replication process when creating cloned tables.
  • Verify that exclusive database locks can be acquired to perform the smart-switch of cloned tables in phase EU_SWITCH_ZDM.

Checklist Preparation Activities

This lesson covers the list of preparatory activities you have to consider prior to starting the ZDO upgrade or update.

1. Graduate the mandatory training on Zero Downtime Option

This learning journey is your first step in getting ready for zero-downtime updates and upgrades.

2. Check and Migrate SAP HANA Repository 1.0 Objects

  • If native SAP HANA objects stored in SAP HANA Repository 1.0 (_SYS_BIC) are used in the SAP S/4HANA system, these objects need to be migrated to HDI before a ZDO project.
  • During the runtime of the bridge subsystem, all objects in SAP HANA Repository 1.0 are not accessible.

3. Check Technical Prerequisites for ZDO

  • Some add-on products are not supported by ZDO. Hence, it is important to check beforehand the list of unsupported add-ons and software components.
  • Additionally, check if the minimum required SAP HANA 2.0 database revision is fulfilled.

More information:

SAP Note 2707731 - Prerequisites and restrictions of Zero Downtime Option of SUM for SAP S/4HANA.

4. Run ZDO Preliminary Checks in SUM Toolbox

As part of the SUM Toolbox, the ZDO preliminary checks are delivered with the focus on the consistency of the following topics:

  • Usage of SAP Business Warehouse
  • Status of Silent Data Migration Infrastructure
  • Consistency check of data dictionary and database
  • Consistency check of SAP HANA content deployment
  • Consistency check of active nametab objects
  • Check ZDO compliance of SLT setup

More information:

5. Check the List of Known Restrictions on Applications

Some applications are only available with restrictions during the bridge runtime.

More information:

SAP Note 2707731 - Prerequisites and restrictions of Zero Downtime Option of SUM for SAP S/4HANA

6. Project Management and Planning

  • In case of a major release upgrade, consider running the SAP Readiness Check for SAP S/4HANA Upgrades.
  • Start creating a project plan according to the requirements for ZDO.
  • Consider that for ZDO there might be more test cycles to be included in the project plan.
  • Involve test management and functional teams in an early stage of the project.
  • Consider functional validation and load verification of the bridge subsystem in the project plan.

More information:

SAP Note 3059197 - SAP Readiness Check for SAP S/4HANA upgrades

7. Request the ZDO Password for the Relevant Systems

Software Update Manager asks for a password if ZDO is selected in the Scenario Strategy dialog.

More information:

SAP Note 2707731 - Prerequisites and restrictions of Zero Downtime Option of SUM for SAP S/4HANA

8. Prepare the Sandbox Environment

  • Build up a sandbox system that is ideally a recent copy of the productive SAP S/4HANA system.
  • If possible, set up the connectivity and interfaces to systems around the SAP S/4HANA system.

9. Prepare the Impact Analysis

  • The Impact Analysis of SUM requires table access statistics from the productive SAP S/4HANA system.
  • Make sure that the export report is available in the productive SAP S/4HANA system.

More information:

  • SAP Note 2471883 - SUM Impact Analysis for ZDO
  • SAP Note 2402270 - Export of Table Statistics for SUM Impact Analysis

10. Get the Latest ZDO Guide and SAP Notes

  • The documentation on Zero Downtime Option is updated regularly.
  • Get the latest ZDO guide as well as the latest version of SAP Notes for Software Update Manager and Zero Downtime Option.

More information:

Software Logistics Toolset landing page in SAP Support Portal: https://support.sap.com/sltoolset

11. Create the Stack File in Maintenance Planner

  • Software Update Manager requires a so-called stack file that lists the target software components.
  • The stack file is generated using Maintenance Planner.
  • It is recommended to create the stack files for all systems at the same time.

More information:

Maintenance Planner landing page in SAP Support Portal: https://support.sap.com/en/alm/solution-manager/processes-72/maintenance-planner.html

12. Start the First Sandbox Iteration

  • When you complete all steps, you should be prepared.
  • Start your first sandbox upgrade or update utilizing Zero Downtime Option.

Log in to track your progress & complete quizzes