Transport Management in SAP S/4HANA Cloud 3SL (2): Parallel Implementation and Maintenance

[ThomasSchneider]

In my Blog Transport Management in SAP S/4HANA Cloud Public Edition 3-System Landscape: From Basics to Complex ( Transport Management in SAP S/4HANA Cloud Public E... - SAP Community ) I provided a comprehensive introduction into transport management for SAP S/4HANA Cloud, 3-system landscape. In this blog post, I would like to go into more details. The previous blog is the prerequisite so that you can understand the used terms and basic concepts that are used in this blog.

Managing (parallel) feature development and maintenance in a 3-system landscape, which consists of a development, test, and production system, is a challenging task. In on-premise and private cloud, customers are using additional systems for managing the application management lifecycle (for example additional systems for maintenance, early testing, pre-production testing, etc.). These additional systems are currently not offered in SAP S/4HANA Cloud, public cloud edition. This means that managing parallel feature development and maintenance always comes with certain restrictions.

Sprint-Based Development and Maintenance: The Golden Standard

Sprint-based development and maintenance is the golden standard. It allows to manage development and maintenance in a 3-system landscape. 

In this document, I want to provide a short overview on sprint-based development and maintenance If you want to learn more, you can watch the online training:

• Training: SAP S/4HANA Cloud, Public Edition, 3-System Landscape - Transport Management Fundamentals *Before you can access the link, a one-time registration in the SAP Learning Hub, edition for SAP Enterprise Support, is required. Follow the step-by-step guide to complete your registration here.

The following picture shows the basic principle:

Figure 1: Sprint Schedule – Regular Implementation Flow

A sprint is a short, time-boxed period in which the implementation team works to complete a set amount of work (here: business configuration and extensibility tasks). In Figure 1, sprints are shown in horizontal direction. On the vertical axis the different systems/tenants (CBC, DEV, TST, PRD) are shown.

The picture shows the flow of developments, which are organized by sprints through the systems/tenants. The picture shows 2½ sprints. The beige boxes show the flow of the sprint n, green boxes show sprint n+1, and grey boxes sprint n+2. To give one example, you can think of a sprint of a week timeframe. But you can define sprint times flexibly according to your needs.

Let us investigate the flow of one sprint. The implementation starts in CBC. Once configuration is ready there, the respective milestone is deployed into the development system. In parallel, SAP content updates are automatically applied on the already deployed content and the delta is also deployed to the development system.

In the development system the business configuration and extensibility implementation continues. In one sprint, you may have one or more transports for CBC, BC, key user extensibility, and developer extensibility. At the end of a sprint, these transports are released and imported into TST.

In the second period, the development of the sprint n is tested in the test system. During this time, corrections can be made in DEV and individually imported to TST. At the end of the period, the transports are forwarded and imported into production.

Notes

• You can define sprint length according to your needs: 1 week, 2 weeks, variable, …  You can also define development and correction sprints.
  • The time points shown in the picture are examples, you can define them according to your needs.
  • Importing and forwarding activities can be scheduled/automated, for details see my preceding blog.
• Once your production system is live, you must must keep the TST system close to the PRD system so that you can apply corrections. Thus, only if an implementation task is ready to go to production, it shall be released and imported to TST for final testing. Exceptions are new and independent implementations, which are not yet in production.
• Release decision in TST: At the end of the test phase, a release decision is required:
  • If tests are passed successfully, forward to PRD.
  • If tests fail, skip the sprint delivery (no forward to PRD).
  • Normally the release decision is “all or nothing”. This means, you should forward either all transports or nothing.
    • Exceptions are new developments, which are not yet in production.
    • If you want to exclude single transports from the release decision, you must ensure that this has no impact on the  part of the sprint development that is transported to production.

The following picture shows the correction process:

Figure 2: Sprint Schedule – Corrections

Corrections are changes due to defects that are found either during test or in production. Corrections can be classified as:

• Regular (r): corrections that can be shipped with the sprint that is currently in development.
• Urgent (u): corrections that can be shipped with the sprint that is currently in test.
• Immediate (i): corrections that must be shipped before the next regular sprint delivery.

Corrections are created in DEV in parallel to the implementation of new features in dedicated transport requests (for regular corrections you can also use existing open transport requests). Regular corrections are released together with the other transport requests of the  current sprint and are tested, forwarded, and imported to PRD.

Urgent and immediate corrections are released  as soon as they are ready, imported into TST. Urgent corrections are tested, forwarded, and imported to PRD together with the current sprint in test. Immediate corrections are forwarded and imported into PRD immediately after test and approval.

Creation and transport of corrections must be possible any time, this means, it must have priority over new feature implementation (this is stopped if a correction is required). An approval process for correction is required.

The delivery of a correction requires considerations:

• Object locking must be considered:
  • Development objects can be in one transport request only (“locked”). If an object to be corrected is locked on a development request, it must be removed and added to the correction transport request
  • is not locked – they can be part of multiple transport requests (use the “Transport” feature in customizing UIs to add them to a correction transport request)
• Dependencies between objects must be mitigated:
  • Individual solution required, e.g. for customizing objects, “open” dependencies must be added to the correction transport request
  • Corrections of the same objects need to be imported in the correct sequence
  • Tools can help to manage dependencies, but in the end a decision by an approver is required, if a correction is applied to production.

Further details are discussed in the next section.

Parallel Development and Corrections: Details

If you do not want to follow the sprint-based development and maintenance methodology and you want to manage release, import, and forward of transports individually, you must understand the dependencies between the different objects.

In the next sections, I will discuss the specific dependency management for CBC, BC, key user and developer extensibility transports.

CBC Transports

Figure 3 shows the flow for CBC transports through a system landscape.

Figure 3: Transport of CBC Transports

Figure 3 shows 3 CBC deployments and the resulting transports. The first transport contains a scope or organizational change. The change is deployed into DEV, released, imported to TST, tested, forwarded, and finally imported to PRD. Transports 2 and 3 are SAP content updates which are consumed in the same way.

CBC transports must be moved through the landscape in strict sequence. This means a transport from a later deployment (technically with higher number) must be moved later or together with an earlier transport. Overtaking is not possible.

Conclusion:

Strict sequencing of CBC transports prevents parallel development and maintenance. To overcome this restriction, parallel project lines will be provided for SAP S/4HANA Cloud. They are not yet generally available (for details see my preceding blog).

BC Transports

Figure 4 shows the flow for BC transports through a system landscape.

Figure 4: Transport of BC Transports 

Figure 4 shows 3 transports. Transport #1 is the first transport that is released and imported to test. But then, transports #2 and #3 are getting released and imported. Once they are successfully tested and approved, they can be forwarded and imported to PRD, “overtaking” transport #1. Prerequisite is that transports #2 and #3 have no dependency on #1. In our example, objects in #3 have dependency on objects in #2. Thus transport #3 cannot overtake #2.

One example for dependencies in business configuration are modelled foreign key relations. For example, condition types (configuration activity Define Condition Types in Conditions and Account Determination) and condition groups are linked by a foreign key relation. The condition group depends on the condition type and must be transported in the same transport with the condition type or in a subsequent transport.

If a dependency is detected, the system blocks the release, import, or forward of a BC transport and enforces the correct  sequence.

If you have a transport with dependency that must urgently overtake a previous transport, you have two options:

• Add the referenced configuration redundantly to make the blocked transport self-contained. Configuration content can be part of multiple transport requests.  You can use the “Transport” feature in customizing UIs to add them to a (second) transport request.
• Move the referenced configuration to the blocked transport. This is done by deleting an entry from the source transport (in app Export Customizing Transports) and add it to the target transport in the respective customizing UI.

If you have two transports with cyclic dependency you must merge the transports.

When designing your business configuration transports, you should consider:

• For different projects (for example the implementation of Country 1 and Country 2) or features, create dedicated BC transports to keep the configuration separate.
• When working in sprints, create one transport per project or feature and sprint.
• Create as many BC transports as necessary but as few as possible. A large number of BC transports will lead to cluttered projects.

Conclusion:

Parallel feature development and maintenance for configuration activities is possible if the features are independent. Dependency checks are executed by the system during release, import and forward. But please consider that business configuration has also semantic dependencies, which are not checked by the system. Thus, judgement by implementation experts is required when transports are moved independently through the landscape.

For larger implementation/change projects that require CBC and BC changes, parallel project lines will be provided for SAP S/4HANA Cloud. They are not yet generally available (for details see my preceding blog).

Key User Extensibility Transports

Key user extensibility uses software collections and their versions for transport of extensibility items. A software collection is a set of extensibility items. An extensibility item (for example a custom field or a custom business object) consists of several ABAP development objects, which are managed by the respective key user tool. The collection management ensures that key user items are managed consistently through  the complete lifecycle.

In contrast to a transport, a software collection has an infinite lifetime by default. You can use software collections to collect objects that belong together.

When you export a collection, a new version is created. The version includes by default all new, changed, or deleted items of the collection. (Technically, the export of a collection version results in a transport.)

Figure 5 shows the flow for key user extensibility through a system landscape.

Figure 5: Transport of Key User Extensibility

Figure 5 shows two software collections. First, collection #1 is being exported (as version 1) and imported to TST. Then, collection #2 is being exported (as version 1 of collection #2) and imported to TST. The items in collections #1 and #2 are independent, and so version 1 of collection #2 can be forwarded and imported into PRD, overtaking version 1 of collection #1.

Then, version 2 of collection #1 is being exported, imported to TST and forwarded . A higher version of the same software collection cannot overtake a lower version. This means that version 2 must be imported at the same time (as shown on figure 5) or after version 1.

When exporting a software collection, the items are handled as follows:

• By default, all new, changed, or deleted items of the collection are added to the new version.
• You can choose the option to add all items. Using this option may be required to solve an error situation in the import.
• You can pick dedicated objects to be added to the new version. This option is required for corrections, when not all changed items shall be put to the new version.

When designing your software collections and adding items to it, you must consider:

• Items with dependencies must be in the same software collection. This ensures that different software collections are independent and can be transported through the landscape independently.
• Versions of a software collection must be transported in sequence. This means, a higher version a software collection cannot overtake a lower version.
• To achieve maximum flexibility during transport, assign independent sets of items to separate collections.
  • One standard recommendation is to create (an) own software collection(s) for business roles together with their spaces and pages.
  • For different projects (for example the implementation of Country 1 and Country 2), use dedicated software collections and keep the extensibility items independent if possible.

Conclusion:

Parallel feature development and maintenance for key user items is possible if the features are independent and assigned to dedicated software collections. Within a collection a strict sequencing of versions is enforced. 

In comparison to developer extensibility, key user extensibility has a much higher “safety net”. For example, key user tools check if extensibility items are changed, analyze the impact on dependent items and take respective measures. Together with the transport handling for software collections, the risk for import errors is significantly lower than for developer extensibility, where development and transports provide more flexibility and thus more responsibility to the users. 

Regarding the planned feature of parallel project lines, key user items can be divided into two groups:

• Key user items that are shared between tenants of the same system. These  objects are created in the main line and shared between main line, development, and project line. Parallel development in project line is not possible.
• Key user items that are not shared between tenants of the same system. There objects can be implemented in main line and in project line in parallel.

Developer Extensibility Transports

Figure 6 shows the flow for developer extensibility through a system landscape.

Figure 6: Transport of Developer Extensibility

Figure 6 shows three developer extensibility transports. The flow is very similar to business configuration.  Transport #1 is the first transport that is released and imported to test. But then, transports #2 and #3 are getting released and imported. Once they are successfully tested and approved, they can be forwarded and imported to PRD, “overtaking” transport #1. Prerequisite is that transports #2 and #3 have no dependency on #1. In our example, objects in #3 have dependency on objects in #2. Thus transport #3 cannot overtake #2.

Dependencies between ABAP development objects are tracked by the ABAP development tools and are presented to the developer as “where-used” in the development environment. When a transport request is released, the dependencies are evaluated. If a dependency is detected, the system blocks the release, import, or forward of a developer extensibility transport and enforces the right sequence.

If you have a transport with dependency that must urgently overtake a previous transport, you have two options:

• Move the referenced development object to the blocked transport in the Transport Organizer tool.
• Please note that a development object can only be assigned to one open transport at a time (this is called the object is locked on a transport request).

If you have two transports with cyclic dependency you must merge the transports.

When designing your developer extensibility transports, you must consider:

• For different projects (for example the implementation of Country 1 and Country 2) or features, create dedicated transport requests to keep the development separate.
• When working in sprints, create one transport request per project or feature and sprint.
• Create as many transport requests as necessary but as few as possible. A large number of transports will lead to cluttered projects.

Conclusion:

Parallel feature development and maintenance for developer extensibility is possible if the features are independent. Dependency checks are executed by the system during release, import and forward. But consider that incompatible changes of dependent objects do not always lead to a blocking of the release, import or forward. If an object is changed in an incompatible way, the developer must analyze the impact on dependent objects using the respective tools in ABAP development tools. Thus, a final judgement by developers is required when transports are moved independently through the landscape.

Regarding the planned feature of parallel project lines, development objects are created in the development tenant and shared between main line, development, and project line. Parallel development in project line is not possible.

Dependencies Between Different Transport Types

Dependencies occur not only between transports of one type, but also between transports of different types:

• BC to CBC: dependencies from BC transports to CBC transports occur frequently, because configuration activities often use the predefined configuration from CBC.
• CBC to BC: dependencies from BC transports to CBC transports are rather exceptional cases.
• BC to key user extensibility: dependencies from BC transports to key user extensibility transports occur when key user items are used in configuration. For example, as a first step you create a new form template in the Form Templates key user tool. Second, you use the form template in the configuration of output determination (e.g. use the form in specific country, for a specific customer group, etc.). Here, the output determination configuration (BC) depends on the form template (key user extensibility item).
• BC to developer extensibility: dependencies from BC transports to developer extensibility transports occur when you create your own business configuration object with developer extensibility and then create and transport content for it.
• Developer extensibility and key user extensibility: dependencies from developer extensibility transports to key user extensibility transports and vice versa occur when you use key user extensibility items (for example custom fields) in development objects (for example CDS views) and vice versa.

A project, sprint, or feature development contains often  all 4 types of transports. Even if the objects in the transports are not technically linked, they often build a semantic unit that must be transported together through the landscape.

If your implementation project reaches a certain volume, you need a concept on how to manage your implementation and maintenance. As mentioned before, managing your implementation in sprints is good method. Defining project milestones for implementation, test and import to production is another option of organization that may fit to your needs.

Additional Information and Links

Please refer to my blog Transport Management in SAP S/4HANA Cloud Public Edition 3-System Landscape: From Basics to Complex ( Transport Management in SAP S/4HANA Cloud Public E... - SAP Community ) for additional information and links.