In this blog, I wish to discuss the high-level technical details on ZDO upgrades/updates that can be performed by any basis expert who has completed the learning journey and assessment ADM330.
If you want to have a quick overview on what this assessment is about, do check out my other blog =>"Why should a basis admin pass ADM330(ZDO for S/4HANA updates and upgrades) assessment"
https://blogs.sap.com/2022/12/26/why-should-a-basis-admin-pass-adm330zdo-for-s-4hana-updates-and-upg...
NOTE: This blog must be used to attain high-level knowledge of ZDO upgrades. Basis experts must complete the ADM330 course to attain complete details in this regard.
1. What is a ZDO upgrade/update and how does this attain Zero technical downtime?
ZDO revolves around the concept of running an update/upgrade without technical downtime along with minimal business downtime. This is attained with the help of the bridge subsystem. The technical downtime only involves restarting the application server without a need to restart the database. Usually, the restart takes approximately 5 to 15 minutes based on the number of application servers involved. Both original and bridge subsystems will be running on the same database.
SAP has enabled ZDO upgrades starting from S/4HANA2020. This upgrade does not need a separate license. The basis expert must have cleared the assessment ADM330 and must hold an SAP-generated password for the specific SID.
2. What is a bridge subsystem?
In my own words, this is a clone-like version of the original source system and will be running on the source version where business users get reconnected to continue their task when the original system gets into technical downtime for an upgrade to the target version by SUM2.0.
The reason behind calling this a clone-like instead of the clone is due to the fact that this bridge subsystem only has the views that are pointing to the tables in the original system. However, the original system will have shared tables that could be shared between the original and bridge system or might have a clone of the table with 2 different versions(one pointing to the source version=>to be accessed by business users in the bridge subsystem) and the other pointing to the target version=>to be accessed by SUM)). These table clone requirements are determined based on the type of change the upgrade is going to bring into this table and SUM uses the process called Impact Analysis to arrive at the specified table classification.
Refer to question "7. How does SUM arrive at the above classification? " for more details in this blog.
3. How does ZDO operates together with the original and bridge subsystem to attain zero technical downtime during upgrades?
Reference: Page 12 for public guide below. https://help.sap.com/doc/b4e092bbef2a48db867e5b0095a6559a/zdosum20.16/en-US/zdo_sum20_s4hana.pdf
Business users will work on the original system in release 1 which is the actual source release. In the same system, SUM processing will be started. After the uptime processing in the original system, SUM will perform rollover of the business users to the bridge subsystem which will be in source release as the target version is yet to be finalized. Transitioning of the users to the bridge subsystem happens in a controlled manner, thus enabling the business users to continue their work in the bridge system seamlessly. While the business continues to operate in the bridge subsystem, the target release is finalized in parallel by SUM. At the end of the maintenance event, target release must be activated.
The cut-over and activation of the target release include the following steps:
After the restart and ramp-up of the system, users will work on release 2 which represents the target release
One must understand the bridge subsystem runs in the same database as the original system, but with a dedicated schema .ie, both releases, source(bridge subsystem) and target are stored in the same database but the access happens via different database schema. All business transactions of the applications that are enabled for ZDO are fully available during the upgrade via the bridge subsystem to end users.
However, not all applications are enabled for ZDO usage. Applications that aren't fully available during the bridge runtime are listed accordingly in SAP Note 2707731. Also note that in S/4HANA, among the BW operational modes that can be activated ( Embedded BW, Data Warehouse, and Embedded Analytics) only Embedded Analytics is supported by ZDO.
4. What are the different subsystems involved with ZDO upgrades?
5. How does the bridge subsystem operate with a list of views that are pointing to different versions of the same table in the original system?
The views of bridge subsystems point to different tables in an original system based on the SUM's phase.
a.At the beginning of the SUM’s phases, bridge schema(SAPABAP1SHD) gets created and has views for all the source system tables as depicted below. At this point in time, only one version of the tables (V1) exists, which represents the source release. The original schema continues to be used productively.
Reference: Page 13 of SUM ZDO public guide
https://help.sap.com/doc/b4e092bbef2a48db867e5b0095a6559a/zdosum20.16/en-US/zdo_sum20_s4hana.pdf
b. When the rollover to the bridge subsystem is initiated in phase REQ_USER_ROLLOVER_PREP , all work processes are automatically reconnected to the bridge schema in phase BRIDGE_RECONNECT. After all the users have been transferred to the bridge subsystem, the default database schema of the production system is renamed by appending SHD to its name. For example, the SAPABAP1 database schema is renamed to SAPABAP1SHD. The upgrade subsystem with which the upgrade is performed is still connected with the original database schema (SAPABAP1 in the example).
c.While the upgrade is being performed on the target release tables (V2 tables), the generated views (view 1 in the example illustration) continue to point to the source release tables (tab1 V1 in the example). As a result, the productive use can continue on the bridge subsystem. If no adjustment of the table structure is required during the upgrade, no additional V2 table is created (in the example, tab 2 V1=V2), and the generated view (in the example, view 2) still points to this table.
Reference:https://help.sap.com/viewer/c4ebc2b5d928446180d9ad2667f11faa/1.0/en-US/9a9abc84fd3e48118ff81bf6ff5cb...
PAGE 12
6.What are the available table classifications during ZDO run?
Below is the high-level overview of table classification that happens during the ZDO procedure and as of how they are handled in the bridge subsystem.
Reference: Page 28 of SUM ZDO public guide
https://help.sap.com/doc/b4e092bbef2a48db867e5b0095a6559a/zdosum20.16/en-US/zdo_sum20_s4hana.pdf
7.How does SUM arrive at the above classification?
Tables are classified based on the type of changes that they will receive due to the upgrade of the source system. To determine these changes ZDO uses a process called Impact Analysis. This is a process of identifying the impact of the upgrade on the source system. Ie, This helps in answering the question “What would happen if the defined upgrade scope is applied in a production environment?”
This can be executed via SUM or t-code SUMTOOLBOX after passing the phase RUN_RSPTBFIL_ZDM_CLASSIFY (The initial shipment of SUM toolbox was released in Dec 2021 via TCI sap note. This is also included as apart of SAP_BASIS component in recent releases)
The input required for Impact Analysis is
The impacts below are checked by Impact Analysis for ZDO:
The output of Impact Analysis is the table classification as Shared, Clone, Clone Read-only.
Below are the high-level steps involved
8. How to download the table statistics for SUM Impact Analysis from the production environment?
This can be downloaded with the help of the t-code SUMTOOLBOX in a production environment. To enable this t-code to be capable enough to capture the statistics, the below pre-equisites must be met.
For more information refer to the OSS note: 2402270 - Export of Table Statistics for SUM Impact Analysis
9. What are the preliminary ZDO readiness process that must be executed in a S/4HANA system?
ZDO readiness process consists of a list of 5 steps.These steps are more of guidelines that must be followed by a software vendor, SAP as well as 3rd party add-on vendor.
One must understand that the below ZDO readiness process is not related to SAP Readiness Check that is used for S/4HANA. This involves ,
10. How is SLT-enabled S/4HANA systems handled during ZDO upgrades?
During an ZDO upgrade of S/4HANA, replication of changes using SLT is supported. There are 4 different use cases involved.
For more details, refer ZDO guide.
11. How does ZDO perform application data migration? How is this approach different from a normal standard upgrade?
One of the key concepts of ZDO is SDMI (Silent Data Migration Infrastructure). The Silent Data Migration Infrastructure (SDMI) is a framework that enables automatic application data migration during system uptime. In a non-ZDO upgrade, migration of application data happens during the downtime by XPRA program or XCLA classed in phase XPRAS_AMMMRG.
However, with ZDO, these programs are executed during the uptime.ie, The migration of application data does not happen during the SUM upgrade but is triggered after the upgrade is completed during regular business operations.
For more information refer ZDO guide and ADM330 learning path documentation.
12.How is the reset procedure handled in ZDO?
If a reset is required before the SUM has rolled over to the bridge subsystem and until the phase REQ_USER_ROLLOVER_PREP has not been reached, a reset can be performed during uptime processing like in standard SUM procedure.
If a reset is required during the bridge runtime, we can still use the SUM UI for Reset.
However, If a reset of the procedure is required post bridge runtime, ie post REQ_USER_ROLLBACK_PREP, the switch to the target would have already happened. Hence a complete restore is required in order to use the reset option of SUM.
13. What does it takes to execute a ZDO in a landscape until production?
Below is a high-level project plan for a system landscape with 3 levels including all systems from sandbox to production. It is highly recommended to use the same update approach (that is, standard update, nZDM, or ZDO) across the system landscape.
Reference: Public ZDO guide in sltoolset, PAGE 19
https://help.sap.com/doc/b4e092bbef2a48db867e5b0095a6559a/zdosum20.16/en-US/zdo_sum20_s4hana.pdf
14.How is ZDO different from nZDM and the standard approach?
Reference PAGE11 of public ZDO guide :https://help.sap.com/doc/b4e092bbef2a48db867e5b0095a6559a/zdosum20.latest/en-US/zdo_sum20_s4hana.pdf
Reference, ZDO public guide PAGE12 :https://help.sap.com/doc/b4e092bbef2a48db867e5b0095a6559a/zdosum20.latest/en-US/zdo_sum20_s4hana.pdf
Thanks for reading!
All the best for performing a ZDO upgrade successfully in your customer landscape.
NOTE: Below blog has been written based on the Public reference from SAP:
Reference:https://help.sap.com/doc/b4e092bbef2a48db867e5b0095a6559a/zdosum20.latest/en-US/zdo_sum20_s4hana.pdf
If you want to have a quick overview on what this assessment is about, do check out my other blog =>"Why should a basis admin pass ADM330(ZDO for S/4HANA updates and upgrades) assessment"
https://blogs.sap.com/2022/12/26/why-should-a-basis-admin-pass-adm330zdo-for-s-4hana-updates-and-upg...
NOTE: This blog must be used to attain high-level knowledge of ZDO upgrades. Basis experts must complete the ADM330 course to attain complete details in this regard.
This blog is targeted to answer the below questions.
1. What is a ZDO upgrade/update and how does this attain Zero technical downtime?
2. What is a bridge subsystem?
3. How does ZDO operates together with the original and bridge subsystem to attain zero technical downtime during upgrades?
4. What are the different subsystems involved with ZDO upgrades?
5. How does the bridge subsystem operate with a list of views that are pointing to different versions of the same table in the original system?
6. What are the available table classifications during ZDO run?
7. How does SUM arrive at the above classification?
8. How to download the table statistics for SUM Impact Analysis from the production environment?
9. What are the preliminary ZDO readiness process that must be executed in a S/4HANA system?
10.How is SLT-enabled S/4HANA systems handled during ZDO upgrades?
11.How does ZDO perform application data migration? How is this approach different from a normal standard upgrade?
12.How is the reset procedure handled in ZDO?
13.What does it takes to execute a ZDO in a landscape until production?
14.How is ZDO different from nZDM and the standard approach?
1. What is a ZDO upgrade/update and how does this attain Zero technical downtime?
ZDO revolves around the concept of running an update/upgrade without technical downtime along with minimal business downtime. This is attained with the help of the bridge subsystem. The technical downtime only involves restarting the application server without a need to restart the database. Usually, the restart takes approximately 5 to 15 minutes based on the number of application servers involved. Both original and bridge subsystems will be running on the same database.
SAP has enabled ZDO upgrades starting from S/4HANA2020. This upgrade does not need a separate license. The basis expert must have cleared the assessment ADM330 and must hold an SAP-generated password for the specific SID.
2. What is a bridge subsystem?
In my own words, this is a clone-like version of the original source system and will be running on the source version where business users get reconnected to continue their task when the original system gets into technical downtime for an upgrade to the target version by SUM2.0.
The reason behind calling this a clone-like instead of the clone is due to the fact that this bridge subsystem only has the views that are pointing to the tables in the original system. However, the original system will have shared tables that could be shared between the original and bridge system or might have a clone of the table with 2 different versions(one pointing to the source version=>to be accessed by business users in the bridge subsystem) and the other pointing to the target version=>to be accessed by SUM)). These table clone requirements are determined based on the type of change the upgrade is going to bring into this table and SUM uses the process called Impact Analysis to arrive at the specified table classification.
Refer to question "7. How does SUM arrive at the above classification? " for more details in this blog.
3. How does ZDO operates together with the original and bridge subsystem to attain zero technical downtime during upgrades?
Reference: Page 12 for public guide below. https://help.sap.com/doc/b4e092bbef2a48db867e5b0095a6559a/zdosum20.16/en-US/zdo_sum20_s4hana.pdf
Business users will work on the original system in release 1 which is the actual source release. In the same system, SUM processing will be started. After the uptime processing in the original system, SUM will perform rollover of the business users to the bridge subsystem which will be in source release as the target version is yet to be finalized. Transitioning of the users to the bridge subsystem happens in a controlled manner, thus enabling the business users to continue their work in the bridge system seamlessly. While the business continues to operate in the bridge subsystem, the target release is finalized in parallel by SUM. At the end of the maintenance event, target release must be activated.
The cut-over and activation of the target release include the following steps:
- Ramp-down release 1 typically includes tasks like log off users, lock users, de-schedule batch jobs, cleanup queues, and cleaning erroneous update processes.
- A parallelized restart of all application servers by SUM. The database is not restarted.
- The ramp-up of release 2 typically includes tasks like import of transports, functional validation, unlock users, and re-schedule batch jobs.
After the restart and ramp-up of the system, users will work on release 2 which represents the target release
One must understand the bridge subsystem runs in the same database as the original system, but with a dedicated schema .ie, both releases, source(bridge subsystem) and target are stored in the same database but the access happens via different database schema. All business transactions of the applications that are enabled for ZDO are fully available during the upgrade via the bridge subsystem to end users.
However, not all applications are enabled for ZDO usage. Applications that aren't fully available during the bridge runtime are listed accordingly in SAP Note 2707731. Also note that in S/4HANA, among the BW operational modes that can be activated ( Embedded BW, Data Warehouse, and Embedded Analytics) only Embedded Analytics is supported by ZDO.
4. What are the different subsystems involved with ZDO upgrades?
- Original system:
- Before the upgrade=>Source release (version 1) ; After the upgrade: Target release (version 2)
- Original schema (like SAPHANADB)
- The original system represents the state of the system before and after SUM execution. Business Users are also operating on the original system during the pre-processing phases when the shadow system runs in parallel.
- Shadow system:
- Target release (versio2)
- Shadow schema (like SAPHANADBSHD)
- The shadow system is used to prepare the repository and dictionary objects of the target release in the shadow database schema
- Bridge subsystem:
- Source release (version 1)
- Bridge schema (like SAPHANADBSHD)
- The state of the system when all existing application servers are reconnected to the bridge database schema. From a technical perspective, the bridge database schema reuses the shadow database schema
- Upgrade subsystem:
- Target release (version 2)
- Original schema (like SAPHANADB)
- Finalization of the target release repository. The upgrade subsystem operates on the original database schema.
5. How does the bridge subsystem operate with a list of views that are pointing to different versions of the same table in the original system?
The views of bridge subsystems point to different tables in an original system based on the SUM's phase.
a.At the beginning of the SUM’s phases, bridge schema(SAPABAP1SHD) gets created and has views for all the source system tables as depicted below. At this point in time, only one version of the tables (V1) exists, which represents the source release. The original schema continues to be used productively.
Reference: Page 13 of SUM ZDO public guide
https://help.sap.com/doc/b4e092bbef2a48db867e5b0095a6559a/zdosum20.16/en-US/zdo_sum20_s4hana.pdf
b. When the rollover to the bridge subsystem is initiated in phase REQ_USER_ROLLOVER_PREP , all work processes are automatically reconnected to the bridge schema in phase BRIDGE_RECONNECT. After all the users have been transferred to the bridge subsystem, the default database schema of the production system is renamed by appending SHD to its name. For example, the SAPABAP1 database schema is renamed to SAPABAP1SHD. The upgrade subsystem with which the upgrade is performed is still connected with the original database schema (SAPABAP1 in the example).
c.While the upgrade is being performed on the target release tables (V2 tables), the generated views (view 1 in the example illustration) continue to point to the source release tables (tab1 V1 in the example). As a result, the productive use can continue on the bridge subsystem. If no adjustment of the table structure is required during the upgrade, no additional V2 table is created (in the example, tab 2 V1=V2), and the generated view (in the example, view 2) still points to this table.
Reference:https://help.sap.com/viewer/c4ebc2b5d928446180d9ad2667f11faa/1.0/en-US/9a9abc84fd3e48118ff81bf6ff5cb...
PAGE 12
6.What are the available table classifications during ZDO run?
The tables will be classified as
a. Shared between the original system and bridge system (Tables under this classification are not changed by the upgrade except for a few cases where a new non-key field gets added without any default value)
b. Cloned between the original system and bridge system with read/write access.( Tables under this classification undergo changes through upgrade using simple DDL changes or new content or customization)
c. Cloned and will be in read-only for bridge subsystem. (Tables that are classified under this category receive complex structural changes through the upgrade. These tables will be read-only for business users while working on the bridge subsystem). Also if SLT is enabled in the original system, then triggers will have to be dropped and tables must be reloaded post-upgrade if these tables fall under the clone classification.
Below is the high-level overview of table classification that happens during the ZDO procedure and as of how they are handled in the bridge subsystem.
Reference: Page 28 of SUM ZDO public guide
https://help.sap.com/doc/b4e092bbef2a48db867e5b0095a6559a/zdosum20.16/en-US/zdo_sum20_s4hana.pdf
7.How does SUM arrive at the above classification?
Tables are classified based on the type of changes that they will receive due to the upgrade of the source system. To determine these changes ZDO uses a process called Impact Analysis. This is a process of identifying the impact of the upgrade on the source system. Ie, This helps in answering the question “What would happen if the defined upgrade scope is applied in a production environment?”
This can be executed via SUM or t-code SUMTOOLBOX after passing the phase RUN_RSPTBFIL_ZDM_CLASSIFY (The initial shipment of SUM toolbox was released in Dec 2021 via TCI sap note. This is also included as apart of SAP_BASIS component in recent releases)
The input required for Impact Analysis is
1. Table usage statistics from the production environment (can be downloaded by SUMTOOLBOX) which must be a representation of the tasks that will be operated during a business runtime in the bridge subsystem. This can be exported using the t-code SUMTOOLBOX. The output must be stored in the specified naming convention => “ZDIMPANA.ZIP” and must be stored in /SUM/abap/save directory in case of running Impact Analysis in batch mode via SUM.
2. Target version of the upgrade.
The impacts below are checked by Impact Analysis for ZDO:
a.What are the tables that will be marked as read-only in the bridge subsystem, thus preventing the business users from the bridge to perform changes into these tables, resulting in blocking of the involved business process.
b.What are the database triggers that might have to be deleted from certain tables for which a reload is required post upgrade
c.Additional database space that is required for clone tables during ZDO
d.Tables that will be smart-switched( table rename ) as they fall under cloned tables but with a very high number of changes
Refer to OSS notes below for more information.
SAP Note 2402270 - Export of Table Statistics for SUM Impact Analysis
SAP Note 2471883 - SUM Impact Analysis for ZDO
SAP Note 3092738 - Software Update Manager Toolbox - Central SAP Note
The output of Impact Analysis is the table classification as Shared, Clone, Clone Read-only.
Below are the high-level steps involved
- In production, Export the table statistics via SUM toolbox using t-code SUMTOOLBOX. The output thus obtained is "ZDIMPANA.ZIP"
- In Sandbox, we must the table classification via SUM Toolbox using t-code SUMTOOLBOX. The output thus obtained is "PUTTB_SHD.ZIP"
- For instance, in DEV, The output of 1 and 2 must be supplied to t-code SUMTOOLBOX to run the impact analysis.
8. How to download the table statistics for SUM Impact Analysis from the production environment?
This can be downloaded with the help of the t-code SUMTOOLBOX in a production environment. To enable this t-code to be capable enough to capture the statistics, the below pre-equisites must be met.
- SAP_BASIS 740 only: make sure that the SAP Note 2187612 is implemented in your production system.
- Make sure that the standard job SAP_COLLECTOR_FOR_PERFMONITOR is scheduled hourly, and the corresponding control table TCOLL has been maintained via transaction ST03 in such a way that report RSSTAT90 is executed four times a day (see SAP Note 966309).
- In transaction ST03, expand subtree Collector and Performance DB -> Performance Database -> Monitoring Database -> Reorganization.
- Adjust the retention time settings to retain the aggregate values for updates, deletes and inserts as long as desired, and wait long enough for the aggregates to be collected.
- Recommendation: avoid importing transports in the evaluation period from which you will export the table statistics. Importing transport will also change tables which eventually can lead to false-positive results in the Impact Analysis.
- Make sure that the database statistics are up to date. Outdated database statistics may result in inaccurate table size statistics.
- Make sure that you've applied the latest version of SUM Toolbox (SAP Note 3092738) which introduces the tool "Export data for Impact Analysis" to export table statistics used by the Impact Analysis.
- SUM Toolbox has to be available in the production system as the export of statistics will be carried out in the production system only.
For more information refer to the OSS note: 2402270 - Export of Table Statistics for SUM Impact Analysis
9. What are the preliminary ZDO readiness process that must be executed in a S/4HANA system?
ZDO readiness process consists of a list of 5 steps.These steps are more of guidelines that must be followed by a software vendor, SAP as well as 3rd party add-on vendor.
One must understand that the below ZDO readiness process is not related to SAP Readiness Check that is used for S/4HANA. This involves ,
- Content migration for SAP HANA
- ZDO compliance and enablement
- ZDO table classification
- Impact Analysis of SUM
- Silent Data Migration
A.Content migration for SAP HANA
In HANA1.0, native HANA artifacts like calculation views etc were created in the repository 1.0 under the technical database schema name _SYS_BIC. The objects under these schemas are not ZDO compliant. In the recent HANA releases, the native artifacts are getting shipped via HDI containers which are ZDO compliant.
Hence as a part of ZDO preparation, the native HANA artifacts(if any) under singleton schema _SYS_BIC must be migrated to HDI containers.ie, To prepare an SAP S/4HANA system for updates with ZDO, all objects stored in _SYS_BIC must be migrated to new containers that are based on HTA for HDI technology. HTA for HDI means SAP HANA Transport for ABAP (HTA) for SAP HANA Deployment Infrastructure (HDI). For more information, see the below link.
NOTE: During the runtime under the bridge subsystem, the HANA repository 1.0 are not accessible.
Along with objects stored in _SYS_BIC, custom objects that are used by business processes must also be migrated. Use the SAP HANA XS Advanced Migration Assistant for the migration of customer objects. For more information, see the SAP HANA XS Advanced Migration Guide =>
B.ZDO compliance and enablement.
All the objects that are developed in S/4HANA must be enabled to be maintained under ZDO. All software changes that are planned to be released to the customer will run against the ATC checks with focus on ZDO compliance.
C.ZDO table classification
The ZDO table classification is an automated process triggered by SUM in phase RUN_RSPTBFIL_ZDM_CLASSIFY. The result of this classification is the way tables are handled during the upgrade procedure.
As specified earlier, the output of this will be
1. Shared tables: These sets of tables will be shared between the bridge subsystem and the upgrade system with both the systems having a read/write enabled to these shared tables.
2. Cloned tables: These sets of tables will be cloned in the bridge subsystem and both the upgrade system and bridge system will have read/write access to these tables. However, these changes will be synchronized on both sides using trigger-based synchronous replication
3. Cloned read-only: These sets of tables will be cloned in the bridge subsystem with a restriction that, the bridge system has read-only access to these sets of tables. Only the upgrade system has access to write into these tables.
D.Impact Analysis of SUM2
Running a ZDO upgrade will have a certain impact on the ongoing business operations when the users will be connecting to the bridge subsystem. Eg, Some of the tables that get classified as read-only will not be available for edits in the bridge system and hence this might have an impact on the business processes that are linked to this table. Hence a thorough understanding of ZDO impact must be performed in advance.
This can be achieved by exporting table statistics from the production system and providing them to the SUM.
E.Silent Data Migration (SDM)
Starting with S/4HANA 1909,SAP has introduced a new framework to deliver the simplification of datamodel such that they are compliant with ZDO. With SDM infrastructure, the application developers decouple the data model change from the functional change of a business application. For more information refer to the question "How does ZDO perform application data migration ? How is this approach different from the normal standard upgrade?" in this blog.
10. How is SLT-enabled S/4HANA systems handled during ZDO upgrades?
During an ZDO upgrade of S/4HANA, replication of changes using SLT is supported. There are 4 different use cases involved.
a.SUM with active SLT replication.
For this use case , HANA version in the source must at least be HANA2.0 rev42. During this use case, to keep the SLT replication active during the bridge runtime, an RFC destination for each of the connected SLT has to be provided to SUM. These RFCs are used to prepare the database triggers needed during the bridge runtime.
Any SLT tables that are classified as Clone, Switch and XCLA must be reloaded / re-initialized post ZDO upgrade.
NOTE:None of the SLT tables must be classified as Clone read-only, as it will make this table to be read-only in the bridge subsystem. These tables must be handled using a special application-defined procedure(XCLA class). This will ensure that SUM does not mark it as clone read only.
b.SUM with deactivated SLT replication
c.SUM without SLT replication
d.No SLT replication
For more details, refer ZDO guide.
11. How does ZDO perform application data migration? How is this approach different from a normal standard upgrade?
One of the key concepts of ZDO is SDMI (Silent Data Migration Infrastructure). The Silent Data Migration Infrastructure (SDMI) is a framework that enables automatic application data migration during system uptime. In a non-ZDO upgrade, migration of application data happens during the downtime by XPRA program or XCLA classed in phase XPRAS_AMMMRG.
However, with ZDO, these programs are executed during the uptime.ie, The migration of application data does not happen during the SUM upgrade but is triggered after the upgrade is completed during regular business operations.
For more information refer ZDO guide and ADM330 learning path documentation.
12.How is the reset procedure handled in ZDO?
If a reset is required before the SUM has rolled over to the bridge subsystem and until the phase REQ_USER_ROLLOVER_PREP has not been reached, a reset can be performed during uptime processing like in standard SUM procedure.
If a reset is required during the bridge runtime, we can still use the SUM UI for Reset.
However, If a reset of the procedure is required post bridge runtime, ie post REQ_USER_ROLLBACK_PREP, the switch to the target would have already happened. Hence a complete restore is required in order to use the reset option of SUM.
13. What does it takes to execute a ZDO in a landscape until production?
Below is a high-level project plan for a system landscape with 3 levels including all systems from sandbox to production. It is highly recommended to use the same update approach (that is, standard update, nZDM, or ZDO) across the system landscape.
Reference: Public ZDO guide in sltoolset, PAGE 19
https://help.sap.com/doc/b4e092bbef2a48db867e5b0095a6559a/zdosum20.16/en-US/zdo_sum20_s4hana.pdf
14.How is ZDO different from nZDM and the standard approach?
Reference PAGE11 of public ZDO guide :https://help.sap.com/doc/b4e092bbef2a48db867e5b0095a6559a/zdosum20.latest/en-US/zdo_sum20_s4hana.pdf
Reference, ZDO public guide PAGE12 :https://help.sap.com/doc/b4e092bbef2a48db867e5b0095a6559a/zdosum20.latest/en-US/zdo_sum20_s4hana.pdf
Thanks for reading!
All the best for performing a ZDO upgrade successfully in your customer landscape.
- SAP Managed Tags:
1 Comment
