- SAP Managed Tags
Introduction
Did you ever need to manage the (parallel) implementation and maintenance of key user extensibility in SAP S/4HANA Cloud, 3-system landscape?
If the answer is ‘Yes’ you might have recognized that the Export Software Collection and Import Collection apps have some restrictions, which make it difficult to separate corrections from new development in the transport management process.
In his blog post Transport Management in SAP S/4HANA Cloud 3SL (2): Parallel Implementation and Maintenance Thomas Schneider described the basic principles of parallel implementation and maintenance. In the following I will dive deeper into the process and highlight how new features in release 2502 help to overcome the restrictions for key user extensibility.
Working with Software Collections in SAP S/4HANA Cloud, 3-System Landscape
With the introduction of the 3-system landscape, the process of transporting software collections for key user extensibility has changed significantly due to the introduction of the test system. But let’s look back at the 2-system landscape first, where key user extensions are created and tested in the quality system. After successful testing, they are exported with the next software collection version. After the export, the software collection version is ready for import into the production system.
Figure 1: Transport Process in 2-System Landscape
The example in Figure 1 shows two versions of the same software collection that were exported from the quality system after the release decision. They were imported to the production system afterwards. The ‘Changed (and Deleted) Items’ option is used first to export the newly developed Item 1 and Item 2. After that the ‘Hotfix’ option was used for the correction Item 1’ without exporting the changed Item 2’. This process is sufficient to manage parallel corrections and development in the 2-system landscape.
Let’s look at the 3-system landscape now. In that landscape, key user extensions are created and tested in the development system. After that, they are exported to the test system for integration testing. The release decision on whether a version is ready for production is now made in the test system using the Import Collection app. However, the same rules for exporting and importing software collections are applied:
- Dependencies are checked during the export of software collections. During the export, the Export Software collection app will always check the dependencies between key user items. With that all changes that are needed in production are contained in the same version or have been exported beforehand.
- A higher version of the same software collection can’t overtake a lower version. The Import Collection app will make sure that the import happens in the same sequence as the export.
The combination of both helps to reduce the risk of issues in production to a minimum. However, when doing parallel development and maintenance this leads to restrictions that are displayed in Figure 2 and Figure 3.
Figure 2: Hotfix must include unwanted item
Figure 2 shows an example where the hotfix was forced to include new development on Item 2’ because the corrected Item 1’ declares a dependency on it. Hence, new development Item 2’ would be imported to production with the hotfix.
Figure 3: Rejected release decision blocks correction
As shown in Figure 3, hotfixes can’t bypass lower versions containing new development. The release decision of the second ‘Changed (and Deleted) Items’ export has been declined. Hence, it blocks the immediate delivery of the subsequent hotfix.
Both restrictions have been addressed by new features in release 2502 which will be described below starting with the dependency checks for the hotfix export.
Dependency Checks for Hotfix Export
Due to the dependency checks performed by the Export Software Collection app hotfixes often need to include content that isn’t part of the actual correction.
Until to the 2408 release, the app checked which key user extensibility items are used by items contained in the hotfix. If the used items had the status ‘New’, ‘Changed’ or ‘Deleted’ they needed to be added to the hotfix. Otherwise, the export checks failed.
In a 3-system landscape however, this led to an unwanted side effect when performing corrections and new development in parallel. If the item to be corrected used other items that were changed by new development, the app enforced the inclusion of these items into the hotfix. However, the new development might not have been ready for production, yet.
With 2502 the checks for exporting software collection hotfixes have been reduced significantly. The dependency check for the hotfix export option has been changed in the 3-system landscape.
Figure 4: Hotfix with relaxed dependency check
As you can see in Figure 4 it’s no longer mandatory to include the used item 2’. The hotfix leaves Item 2 unchanged in test and production system.
With that, it can be decided whether the change to a used item shall be contained in the hotfix or be exported in a later version. The Export Software collection app still helps to identify such dependencies. The check hasn’t been fully removed, but its severity has been reduced to a warning for items with the status ‘Changed’ or ‘Deleted’. However, it is still mandatory to include items with status ‘New’. Since new items have never been exported before, using such an item would cause import issues. Hence, they must still be included.
Discarding Extensibility Collection Versions
After exporting a hotfix and importing it to the test system, users encounter the next restriction in the 3-system landscape. The hotfix can’t be forwarded and imported to production until the same is done for all previous versions of the same software collection.
This rule is part of the safety net for the key user extensibility transport process and prevents the production system from becoming inconsistent due to incorrect transport sequence. Until now, there was no possibility to ‘clear the way’ for corrections to the production system for key user extensibility.
With 2502 key user extensibility collection versions can be discarded in the Import Collection app.
Figure 5: Discarding software collections in test system
As you can see in Figure 5 the ‘Discard’ action has been used after the declined release decision. The information about the discarded version was sent to the production system. After that it was possible to forward the hotfix and import it.
The ‘Discard’ action has been available for other collection types (e.g., developer extensibility) already. The action changes the status of the collection version to ‘Discarded’ and prevents further actions. The result depends on the previous state of the collection version:
- Ready for Import: The collection version can’t be imported into the current system, nor can it be forwarded for import into a subsequent system. A discarded collection version is automatically transported to all subsequent systems (with status ‘Discarded’) so that any dependencies on the current version no longer exist.
- Imported (in test system only): The collection version can’t be imported into a subsequent system. A discarded collection version is automatically transported to all subsequent systems so that any dependencies on the current version no longer exist.
With that, software collection versions that block delivery of a correction to the production system can be ‘moved out the way’. However, this also means that the discarded collection versions can’t be forwarded to the production system later. The extensibility items on these versions need to be exported in a higher version of the same software collection to be consolidated to production later.
Figure 6: Consolidating a discarded item
In Figure 6 a software collection version was discarded to enable the hotfix for Item 1’’. However, the changed Item 2’ was not forwarded to production due to that. Another hotfix for the, now unchanged, Item 2’ was needed to consolidate it to the production system.
The consolidation of discarded items can either be done with another hotfix for or during continued development, e.g. with another changed Item 2’’. However, there is the risk of missing some of the items that have been discarded. To counter that, the safety net for key user extensibility has been enhanced.
Figure 7: Consolidating an unchanged item
As can be seen in Figure 7, Item 2 has never been consolidated to production system. During the next export of ‘Changed and Deleted Items’ Item 2 was included automatically.
The Export Software Collection app checks the status of exported items in the production system. If a certain version of an item hasn’t reached the production system yet, the item is included in the next export when using the option ‘Changed and Deleted Items’, even when the items status is ‘Unchanged’.
Conclusion
To manage corrections and new development occurring in parallel, the export option ‘Changed and Deleted Items’ should be used for new development, while corrections should be delivered via hotfixes. The relaxed export checks for hotfixes make it easier to separate corrections from new development, keeping the hotfix small. This ensures it can be imported to production without any side effects.
The option to discard allows previous versions of the same software collection to be moved out of the way. However, the discarded collections can’t be imported to production later. Another version of the software collection will need to be exported to consolidate the discarded items, eventually. To ensure discarded items aren’t forgotten, the next export with ‘Changed and Deleted Items’ will automatically include those items, even if they are ‘Unchanged’.
With these new features it becomes easier to manage parallel correction and development within a single software collection in the SAP S/4HANA Cloud 3-system landscape beginning with release 2502. Please keep in mind that these features don’t apply to the SAP S/4HANA Cloud 2-system landscape.
Additional Information and Links
SAP S/4HANA Cloud Public Edition, Three-System Landscape | SAP Community
Transport Management in SAP S/4HANA Cloud Public E... - SAP Community
Transport Management in SAP S/4HANA Cloud 3SL (2):... - SAP Community
Export Software Collection - Hotfix
