Planning a ZDO project

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.

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.

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

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.

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.

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.

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

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.

• 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.

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.

• 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.

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

(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.

(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.

(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.

• 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.

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.

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.

• 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.