Identifying System Landscape

You have already seen that the productive environment for SAP BW Bridge consists of two tenants, SAP Datasphere core and SAP BW Bridge. To avoid having dysfunctional objects in a productive tenant, SAP proposes two additional landscape components: Development and quality assurance. Suppose, you have created some objects in a SAP BW Bridge development tenant and in the corresponding SAP Datasphere Core development tenant. Now, you need the same objects in a productive tenants. How do you transport the objects?

Make sure that you setup your landscape before you provision the SAP Datasphere tenant. A single tier cannot be converted.

Make sure that you first transport the SAP BW Bridge object, then the SAP Datasphere core object that depends on it. Both transport mechanisms are independent. There can be a newer version of the SAP BW Bridge object in git repository, but you can pick an older one that is consistent with the file.

In SAP BW Bridge, transports are carried out using the so-called git-based Change and Transport System (gCTS). gCTS is the evolution of the classical Change and Transport Management System (CTS). It is the recommended approach for transporting objects between cloud-based ABAP systems. First, you use the Software Components app in your SAP Fiori launchpad to generate at least one software component with at least one transport request.

Git is a distributed version-control system, which provides concepts in which development objects and all their versions and metadata are mirrored from a central place to every developer's computer. The developer can switch locally and offline between different versions and change all of them before updating the central originals later.

A transport request records all the changes in your ABAP development system. Once a transport request is released, the changes are pushed into your central Git repository. During the import (pull or checkout) of a version, all the changes between the last imported version and the currently imported version are updated.

gCTS is controlled using the software component. For each software component, a git repository is established. We recommend that you use your company name as part of the software component because otherwise the name may already be used by a different customer. (There is no tenant specific namespace.) Thus, when the software component (for example, all objects belonging to it) is transported again, only new objects and objects with a more recent time stamp (changed objects) are transferred to the target system.

In SAP BW Bridge, it is not possible to assign objects to a local package $TMP. This means that all objects – regardless of whether they are created manually, using content activation, or migrated from a legacy SAP BW system – have to be assigned to an ABAP development package. For this purpose, developers need to create an ABAP package and a transport request for the software component. However, the ABAP package and the transport request are actually not required for the provisioning of changes throughout in the system landscape using gCTS.

Technically it is possible to use more than one software component and more than one transport request in the same landscape. However, in a one-tier landscape, one software component and one transport request will be sufficient in most of the cases.

Step-by-step Guide for provisioning changes in a two tier SAP BW Bridge environment:

Scenario: System A is the SAP BW Bridge development system where objects are created and maintained. System B is the target SAP BW Bridge system; it is the production system into which you want to transport.

1. Prepare system A:

   1. Create a Software Component of type Development. This generates a repository in Git behind the scenes: https://help.sap.com/docs/BTP/65de2977205c403bbc107264b8eccf4b/67e2f2e1fbcf48a4801bad004133e0a7.html?locale=en-US&version=Cloud
   2. Clone the new software component into system A based on Repository Role Source – Allow Pull and Push. This generates a Structured Package for that software component behind the scenes: https://help.sap.com/docs/BTP/65de2977205c403bbc107264b8eccf4b/18564c54f529496ba420d4c83545a2ce.html?locale=en-US
   3. Create a Development Package as sub-package to the Structured Package that was generated for the software component in (b): https://help.sap.com/docs/SAP_DATASPHERE/ecce5bb08ae24ed089497fc00c2320d8/0a748ba743ef4285a1816073f7e32cc4.html
2. Prepare system B:
   1. Clone software component into system B based on Repository Role Target – Allow Only Pull (Disabled Push): https://help.sap.com/docs/BTP/65de2977205c403bbc107264b8eccf4b/18564c54f529496ba420d4c83545a2ce.html?locale=en-US
   2. Optional: In the Settings switch the parameter Rollback Mechanism to 'Disabled – Allow also invalid commits to be imported'. This step is recommended based on current tests and experiences, but it may change in the future. As a consequence, you will not be able to reimport failed imports. Instead the problematic objects have to be collected and imported again.
3. Create or maintain objects in system A:

   Create objects or change existing ones. New objects have to be assigned them to the development package of above (step 1c). You will be prompted for a transport request by default.

4. Transport these objects into system B
   1. In system A, set up an ABAP Cloud project, and go to the Transport Organizer view. There, release all tasks of your transport request and finally the transport itself which pushes all objects of that transport into the Git repository.
   2. Change to system B and pull the software component into System B, which synchronizes all changes since the last pull: https://help.sap.com/docs/BTP/65de2977205c403bbc107264b8eccf4b/90b9b9d5219c4875825be35137d9128f.html?locale=en-US