- SAP Managed Tags:
In my blog post Business Configuration in SAP BTP ABAP Environment (1): Overview and BC Maintenance Apps I provided an overview on how to create business configuration maintenance apps in SAP BTP ABAP Environment.
However, business Configuration content is normally not directly maintained in a production environment, but it is created in a content development environment and transported/deployed to the test and production environment. In this blog post, I want to share some details on BC content transport that is available for SAP BTP ABAP Environment.
Before we discuss solutions, let us have a look at typical system/tenant setups for the SAP BTP ABAP Environment. The following figure shows customer tenant landscape, which consists of 3 instances of the SAP BTP ABAP Environment service serving as development, test, and production instance. For simplicity, we call an instance of the SAP BTP ABAP Environment service an ABAP system, because it behaves very similar as an ABAP system that you may know from the on-premise world. In this landscape, you have a “main line” of one tenant (ABAP client) per system, labeled as “100” in the figure. Software is transported along the main line from dev to test and prod. The process is described e.g. in the following help document:
(For larger development projects, a 3-system landscape may be not sufficient, and systems may be added to have a development and a maintenance code line. A typical setup with 5 systems is described here. The principles that I want to discuss are valid for a 3-system landscape or for a 5-system landscape. To keep this blog post simple, I will refer to a 3-system landscape only.)
Transport technology powered by gCTS is used to transports development object between SAP BTP ABAP Environment instances (aka systems). (I have added some link on gCTS in the SAP BTP ABAP Environment at the end of this blog post.) The same technology is used for transporting business configuration. But there is one important difference between development objects and business configuration:
The process of transporting business configuration covers the following aspects:
If business configuration is relevant for transport, it must be recorded on a transport request. The transport request is either managed (determined, created) automatically when business configuration data it saved, or it is selected explicitly by the configuration expert. When a transport requests is released (in the Fiori UI or in the Eclipse UI), the data a pushed into a Git repository. This means that a Git repository must be available (cloned) in a system before you can create transport requests (Exception: you can create a transport requests of type “local” that cannot be released/exported; these requests can be created without cloning of a Git repository.) After the configuration data are pushed to a repository, they can be pulled into subsequent system (test, production, …).
You can use one of the following transport patterns:
1. Isolated tenants – no transports
The tenant is isolated. Business Configuration can be created but is not imported or exported. (Note: All Consumer tenants (>=200) in Steampunk MT systems fall into this category, as Git repos cannot be cloned/pushed/pulled in these clients.)
Procedure:
2. Simple – Transports via SWC of type “Business Configuration” and default transports
Business configuration is transported via a software component of type “Business Configuration”
Procedure:
In exceptional cases (e.g. an urgent pre-import that must be done in parallel to the default request), customers can create a 2nd request of category “MANUAL” using ADT (see below for details). Users that work on the exceptional cases can record their changes on the 2nd request (prerequisite is that the maintenance UI supports transport selection, e.g. Spaces&Pages, custom BCOs).
3. Multiple SWCs/Git Repos– transports via SWCs/Repos of type “Development”
Customer runs multiple separated development projects in parallel at separated timeline and in multiple software components/Git Repos. The configuration shall be transported together with the development via respective SWCs/Repos of type “Development”
Procedure:
* In custom BCOs, customers can autofill the transport request based on the software component of the customizing table.
Exceptional cases (e.g. a preimport): same as under 2.
Software component (Git repository): When a transport request is released (in the Fiori UI or in the Eclipse UI), the data a pushed into a Git repository. The Git repository is 1-to-1-related to a software component, and is managed (created, deleted, cloned, pulled, …) in the Fiori app Manage Software Collection. Therefore, you must create and clone a Git repository in a system before you can create transport requests, see the links on gCTS at the end for details). The Manage Software Collection app support two types of software components: type Development and type Business Configuration. You must decide which type you want to use for transporting business configuration:
Transport requests: If business configuration is relevant for transport, it must be recorded on a transport request. Development objects are recorded on transport requests of type “Workbench”, business configuration is recorded on requests of type “Customizing”. Requests for development objects are created and managed (e.g. released) in the Eclipse-based ABAP development tools (ADT, documentation, ), requests for business configuration are created and managed in the BC maintenance Fiori apps and in the Fiori app “Export Customizing Transports” (documentation).
Note that customizing requests can be also managed using ADT (Transport Organizer). For some expert tasks the ADT tool is the more powerful one.
Figure: Export Customizing Transport Fiori App
Transport request selection: During development, developers are used to create or select a transport request when creating or changing an object. Customers have the following option:
The tutorial provides the implementation guidance for this process.
For application and configuration tables, SAP recommends including the ABAP client in the table structure. This means this table are client-dependent. For client-dependent tables, the content is separated in the different clients. For details, refer to the guideline Development Guideline to Enable Multitenancy of Products Built on the ABAP Environment. If you want to transport table content to all clients of a system, you can use tables without ABAP client of delivery type “S”.
Customers and partners can use multiple clients in the same system. However, business configuration transport into clients <> 100 (“main line”) are not supported yet. This is a limitation SAP is currently working on. For the time being, the options in a system with multiple clients are:
The transport technology of the SAP BTP ABAP Environment (Git based gCTS) is described in the following documents:
However, business Configuration content is normally not directly maintained in a production environment, but it is created in a content development environment and transported/deployed to the test and production environment. In this blog post, I want to share some details on BC content transport that is available for SAP BTP ABAP Environment.
Before we discuss solutions, let us have a look at typical system/tenant setups for the SAP BTP ABAP Environment. The following figure shows customer tenant landscape, which consists of 3 instances of the SAP BTP ABAP Environment service serving as development, test, and production instance. For simplicity, we call an instance of the SAP BTP ABAP Environment service an ABAP system, because it behaves very similar as an ABAP system that you may know from the on-premise world. In this landscape, you have a “main line” of one tenant (ABAP client) per system, labeled as “100” in the figure. Software is transported along the main line from dev to test and prod. The process is described e.g. in the following help document:
(For larger development projects, a 3-system landscape may be not sufficient, and systems may be added to have a development and a maintenance code line. A typical setup with 5 systems is described here. The principles that I want to discuss are valid for a 3-system landscape or for a 5-system landscape. To keep this blog post simple, I will refer to a 3-system landscape only.)
Transport technology powered by gCTS is used to transports development object between SAP BTP ABAP Environment instances (aka systems). (I have added some link on gCTS in the SAP BTP ABAP Environment at the end of this blog post.) The same technology is used for transporting business configuration. But there is one important difference between development objects and business configuration:
- Development objects are client-independent and they are available in the entire system after import.
- Business configuration is client-dependent (same as master or transactional data), and after import, it is only available in the client where the import was executed. This is why in Figure 1, I have depicted a box labeled “100” to show this client behavior. Since some time, ABAP Environment instances can be operated with multiple clients (see Section Business Configuration and Multiple Clients below for details)
Process Overview on Transporting Business Configuration
The process of transporting business configuration covers the following aspects:
If business configuration is relevant for transport, it must be recorded on a transport request. The transport request is either managed (determined, created) automatically when business configuration data it saved, or it is selected explicitly by the configuration expert. When a transport requests is released (in the Fiori UI or in the Eclipse UI), the data a pushed into a Git repository. This means that a Git repository must be available (cloned) in a system before you can create transport requests (Exception: you can create a transport requests of type “local” that cannot be released/exported; these requests can be created without cloning of a Git repository.) After the configuration data are pushed to a repository, they can be pulled into subsequent system (test, production, …).
Transport Patterns
You can use one of the following transport patterns:
1. Isolated tenants – no transports
The tenant is isolated. Business Configuration can be created but is not imported or exported. (Note: All Consumer tenants (>=200) in Steampunk MT systems fall into this category, as Git repos cannot be cloned/pushed/pulled in these clients.)
Procedure:
- No SWC/Git repo is cloned in this tenant
- In the Export Customizing Transport Fiori app, and create a transport request. (The system creates a local request with category “Default”) [role: BPC_EXPERT]
- Configuration is recorded on this request [role: BPC_EXPERT or any other role that has authorization for BC apps]
2. Simple – Transports via SWC of type “Business Configuration” and default transports
Business configuration is transported via a software component of type “Business Configuration”
Procedure:
- In the Manage Software Component Fiori app, create a software component of type “Business Configuration”, clone it to the tenant where business configuration is created [role: ADMINISTRATOR]
- In the Export Customizing Transport Fiori app, and create a transport request. (The system creates a request with transport target hat relates to the SWC/Repo created in the previous step and with category “Default”) [BPC_EXPERT]
- Configuration is recorded on this request [BPC_EXPERT or any other role that has authorization for BC apps]
- In the Export Customizing Transport Fiori app, release the request [BPC_EXPERT]
- Repeat from 2.
In exceptional cases (e.g. an urgent pre-import that must be done in parallel to the default request), customers can create a 2nd request of category “MANUAL” using ADT (see below for details). Users that work on the exceptional cases can record their changes on the 2nd request (prerequisite is that the maintenance UI supports transport selection, e.g. Spaces&Pages, custom BCOs).
3. Multiple SWCs/Git Repos– transports via SWCs/Repos of type “Development”
Customer runs multiple separated development projects in parallel at separated timeline and in multiple software components/Git Repos. The configuration shall be transported together with the development via respective SWCs/Repos of type “Development”
Procedure:
- In Manage Software Component Fiori app, create software components of type “Development”, clone them to the tenant where development and business configuration is created [role: ADMINISTRATOR]
- In the Export Customizing Transport Fiori app, and create a transport request for each software component and assign them to the transport layer that refers to the respective software component/Git Repo) [BPC_EXPERT]
- Users can record their changes on the request that refers to their (prerequisite is that the maintenance UI supports transport selection, e.g. FLP spaces & pages, custom BCOs*).Users that create Configuration is recorded on this request [BPC_EXPERT or any other role that has authorization for BC apps]
- In Export Customizing Transport Fiori app, release the request [BPC_EXPERT]
- Repeat from 2)
* In custom BCOs, customers can autofill the transport request based on the software component of the customizing table.
Exceptional cases (e.g. a preimport): same as under 2.
Process Details
Software component (Git repository): When a transport request is released (in the Fiori UI or in the Eclipse UI), the data a pushed into a Git repository. The Git repository is 1-to-1-related to a software component, and is managed (created, deleted, cloned, pulled, …) in the Fiori app Manage Software Collection. Therefore, you must create and clone a Git repository in a system before you can create transport requests, see the links on gCTS at the end for details). The Manage Software Collection app support two types of software components: type Development and type Business Configuration. You must decide which type you want to use for transporting business configuration:
- You can create a software component of type Business Configuration and transport all your configuration via this software component. This is a very simple way and has advantages that we will reveal when we discuss the transport request handling. Note that there can be only one software component of type Business Configuration in a tenant.
- You can transport the configuration using the software components that you also use for your development objects (typically the same software component for table and table content). This is advisable if you run multiple projects on the same landscape that are well separated and have decoupled time schedules.
Transport requests: If business configuration is relevant for transport, it must be recorded on a transport request. Development objects are recorded on transport requests of type “Workbench”, business configuration is recorded on requests of type “Customizing”. Requests for development objects are created and managed (e.g. released) in the Eclipse-based ABAP development tools (ADT, documentation, ), requests for business configuration are created and managed in the BC maintenance Fiori apps and in the Fiori app “Export Customizing Transports” (documentation).
Note that customizing requests can be also managed using ADT (Transport Organizer). For some expert tasks the ADT tool is the more powerful one.
Figure: Export Customizing Transport Fiori App
Transport request selection: During development, developers are used to create or select a transport request when creating or changing an object. Customers have the following option:
- Explicit selection of the transport request. Option 1 and 2 hide the transport request handling from the business user. If complex business configuration is required, working with multiple parallel transport requests, and thus, a manual selection of the transport request is required. Alternatively, customers can decide that users should explicitly select transport requests using a value selection.
The tutorial provides the implementation guidance for this process.
Business Configuration and Multiple Clients
For application and configuration tables, SAP recommends including the ABAP client in the table structure. This means this table are client-dependent. For client-dependent tables, the content is separated in the different clients. For details, refer to the guideline Development Guideline to Enable Multitenancy of Products Built on the ABAP Environment. If you want to transport table content to all clients of a system, you can use tables without ABAP client of delivery type “S”.
Customers and partners can use multiple clients in the same system. However, business configuration transport into clients <> 100 (“main line”) are not supported yet. This is a limitation SAP is currently working on. For the time being, the options in a system with multiple clients are:
- Use the generic BC file download/upload functionality as introduced in the previous blog post here
- Provide “template content” using client-independent tables (without ABAP client, of delivery type “S”).
Links
The transport technology of the SAP BTP ABAP Environment (Git based gCTS) is described in the following documents:
- Blog post Software Lifecycle Management for SAP Cloud Platform ABAP Environment
- Tutorial Transport a Software Component Between Two ABAP Systems
- Documentation on transport management: https://help.sap.com/viewer/65de2977205c403bbc107264b8eccf4b/Cloud/en-US/5c7b17d68bb7427d93ff2086f01...
11 Comments
