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:
- 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, …).
Software component (Git repository): When a transport requests 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. For business configuration, which is maintained by business experts, the explicit selection of transport request may be considered as a cumbersome task. Therefore, if possible, transport request handling can be automated, so that the business user does not have to deal with it. Customers have the following option:
- Automatic selection of a transport request:
- If the configuration is transported using a software component of type Business Configuration, the system can automatically select or create a transport request for this software component. There can only be one open customizing request for this software component in the tenant. Once the configuration is ready for transport, the request can be released (exported) the Fiori app “Export Customizing Transports”.
- If the configuration is transported using the software components that you also use for your development objects, the system can automatically select or create a customizing transport request for this software component. There can only be one open customizing request for this software component in the tenant.
- 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 a step-by-step implementation guidance for all three cases.
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:
The transport technology of the SAP BTP ABAP Environment (Git based gCTS) is described in the following documents: