How to Transport in an SAP BW Bridge System Landscape

[Dominik_Graus]

Have you recently provisioned SAP BW bridge tenants? This blog helps you prepare the tenants and transport objects from one tenant to another.

You are still in the planning phase and looking for guidance on the system landscape? See the short blog How to Plan and Provision an SAP BW Bridge System Landscape for more information.

Transporting in SAP BW Bridge

In many aspects transporting in SAP BW bridge works like transporting in SAP NetWeaver BW or SAP BW/4HANA, but there are also significant differences.

Transporting objects in SAP BW bridge is done via gCTS, the git-enabled Change and Transport System. To transport objects between tenants, they are stored in a central git repository that is provided and maintained by SAP.

Releasing a transport request pushes the objects of that transport request into the git repository. Pulling the changes from the git repository into a target system synchronizes the changed objects between the git repository and that target system.

The pull operation is done for a so-called software component. A software component is comparable to a repository in git. You can access the repository and perform pull operations via the app Manage Software Components in the SAP BW Bridge Cockpit.

Creating a software component triggers the creation of a top-level ABAP package of type structure that has the same name as the software component. You cannot create BW bridge objects or ABAP development objects in that structure package though. They must be stored on a package of type development which must be created as a sub-package of the generated structure package.

In SAP NetWeaver BW or SAP BW/4HANA, new objects are typically created on the temporary package $TMP in the first place. Only later, before transporting objects from an on-premise development system to a target system, the objects are reassigned to a development package. This is not possible in SAP BW bridge. $TMP does not even exist in SAP BTP, ABAP environment. It is the software component ZLOCAL which serves a similar role like $TMP in an on-premise system. In SAP BW bridge, new objects must be assigned to an appropriate transportable development package right during creation.

Moving objects from a development package to another is not supported. For very limited scenarios, it is planned to support moving objects created on a local development package (i.e., on a development package without transport target) to a transportable development package. This blog will be updated when the feature is made available. Moving objects from a local development package to a development package with transport target can then be done using the view 'Manage Transport Objects' in BW Modeling Tools. Objects assigned to a local development package cannot be transported, and until further notice, they can't be moved to a transportable development package. That's why you should carefully plan your software components, packages, and transports.

In contrast to on-premise, changes of local objects are always recorded in local transport requests and it is not possible to create local objects in productive tenants with setting 'Enable system for development' unchecked (false).

Preparing the Tenants for Transporting

Let's assume tenant D is the development system where objects are developed (with setting 'Enable system for development' = true) and tenant P is the target system into which you want to transport (with setting 'Enable system for development' = false).

A few one-time steps are needed to prepare your tenants for transporting:

• You create a software component. This triggers the creation of a git repository.
• You clone that software component into both tenants. This generates structure packages that have the same name as the software component in both tenants.
• In the development tenant, you create a development package for the new software component. This development package can be used when creating BW bridge or ABAP objects.

Let's have a look at the details.

Preparing the Development Tenant D

Step 1:

In the Development Tenant D, logon to the BW Bridge Cockpit and open the app Manage Software Component. Press Create to create a new software component of type Development. In the dialog New Software Component, enter a name and description and press Create. Behind the scenes, this generates a git repository. See FAQ below for customer or partner namespaces.


Figure 1: Create a New Software Component

Step 2:

Press Clone to clone the remote git repository into your local BW bridge development tenant. In the Clone dialog, choose Source – Allow Pull and Push as Repository Role. Cloning the software component generates a structured package ZMYCOMPANY_BRIDGE in tenant D.

Note: At this point, the repository is empty. In other scenarios - particularly when cloning a repository containing many objects - it may be advisable to disable the rollback mechanism. The rollback setting in this dialog is only relevant in cases where errors occur during cloning and does not apply to pull operations.

Figure 2: Clone the New Software Component into the Development Tenant

Step 3:

In tenant D, open the ABAP cloud project in BW Modeling Tools and right-click on the ABAP cloud project to create a new ABAP package. Choose a meaningful name, e.g., the name of the software component followed by a suffix '_P', here ZMYCOMPANY_BRIDGE_P, and select the generated structure package ZMYCOMPANY_BRIDGE as super-package.

Figure 3: Create an ABAP Development Package

Step 4:

Create a new transport request by simply entering a Request Description and write the new development package to this transport.

Figure 4: Create a Transport Request

The result is a generated structure package with a development sub-package in your development tenant. The development package is recorded on a modifiable transport. It will only be pushed into the software component resp. the git repository when the transport is released. That's why the software component is still empty at this point.

Figure 5: Structure Package with Development Sub-Package

see also Getting Started With SAP Datasphere, SAP BW Bridge | Create Software Components 

Preparing the Productive Tenant P

Step 5:

In the Productive Tenant P, logon to the BW Bridge Cockpit, open the app Manage Software Component and click on the software component you have created in step 1.

Step 6:

Press Clone to clone the new (empty) software component into System P. In the Clone dialog, choose Target – Allow Only Pull (Disabled Push) as Repository Role. Cloning the software component creates a structure package ZMYCOMPANY_BWBRIDGE in tenant P.

Note: At this point, the repository is empty. In other scenarios - particularly when cloning a repository containing many objects - it may be advisable to disable the rollback mechanism. The rollback setting in this dialog is only relevant in cases where errors occur during cloning and does not apply to pull operations.

Figure 6: Clone the Software Component into the Productive Tenant

Step 7:

After successful completion of the cloning operation, click on Settings and change Rollback Mechanism to Disabled (see FAQ below). 

The rollback mechanism can be configured separately and independently from each other:
a) for the clone process only (see figure 6), and
b) for all pull operations on the software component (see figure 7).

The rollback setting in this dialog (figure 7) applies to pull operations.

Figure 7: Disable Rollback Mechanism

Start Developing Objects in the Development Tenant D

You can now create BW bridge objects in tenant D, e.g., an InfoArea. Choose ZMYCOMPANY_BRIDGE_P as Package:

Figure 8: Create BW Bridge and ABAP Objects

You can write this object to the same transport you have created earlier for the development package.

Browsing the development package can be laborious. To use the new development package as default package for new BW bridge objects, go to Window > Preferences > BW Modeling and set a default package. You can either set it globally for all BW bridge projects or individually per BW bridge project.

Figure 9: Set Default Package in BW Modeling Tools

Push your Developments from the Development Tenant to the Remote Git Repository

Once your developments are ready for production, you must push them to the remote git repository. This is done by simply releasing the transport(s) in the development tenant D. 

Step 8:

In the Development Tenant D, in your ABAP Cloud project in BW Modeling Tools, go to the Transport Organizer view and locate the modifiable transport request you have created in step 4. If the Transport Organizer view is not visible, go to Window > Show View > Other… and select Transport Organizer in the ABAP folder.

Figure 10: Transport Organizer

Step 9:

Release all tasks of the transport. Subsequently, release the transport request. To release a task or transport, right-click on the respective line in the Transport Organizer view and press Release. Releasing a transport pushes all objects/changes of that transport into the git repository. In the rare case of errors, you can check the transport log by opening the released transport request. The content of the tab Transport Logs may look familiar if you are used to transporting in ABAP-based on-premise systems. Press Ctrl+click to show more detailed logs for the steps highlighted in blue.

Figure 11: Transport Logs

Pull your Developments from the Remote Git Repository into the Productive Tenant P

Step 10:

In the final step, you pull the changes into your productive tenant. To do so, logon to the BW Bridge Cockpit in the Productive Tenant P, open the app Manage Software Component and click on the software component you cloned earlier in step 6. In History Recent Actions, the earlier clone operation is shown. In Branching, you can see a delta for the main branch: a delta between the remote git repository and the local (productive) tenant since the last pull (here: a delta since the initial clone). Note: After releasing the transport in tenant D, you may have to wait a few minutes for the delta to appear in tenant P.

Figure 12: Software Component with Delta Between Local Tenant and Repository

Step 11:

Press Pull to synchronize the delta. In the Pull dialog, confirm that you want to pull the latest state. All changes since the last pull are then imported into the productive tenant (see SAP Help for more details). The running pull operation is listed in History Recent Actions. Once completed successfully, you can see the new objects, i.e., the development package and the InfoArea, in the productive tenant.

In case of errors, you can check the import log by selecting the pull operation in History Recent Actions. In the Log Overview, you can view details of the import, e.g., potential errors in the after-import phase. The protocol of the after-import phase can be quite long for larger transports. For better readability, you can export the protocol as Excel file.

Figure 13: Log Overview for Pull Operation

If you are interested in more details regarding gCTS, I can recommend the blog SAP BTP Platform ABAP Environment – Lifecycle Management – Introduction of my colleague andre.fischer.

FAQ on Transporting in SAP BW Bridge

The FAQ below takes up again some of the aspects discussed above and lists a few additional questions.

How many software components should be created?

SAP Note 3130759 recommends creating just one software component. This is probably reasonable for most SAP BW bridge projects.

Is it possible to transport only the changes of a specific transport request to a target system?

By default, pulling a software component always synchronizes all changed objects of that software component into the target system. Optionally, you can pull only those changes up to and including the commit of a specific transport request. This will, however, also synchronize all changes of transport requests that had been released prior to that specific transport request.

Can I change the assignment of objects in SAP BW bridge from one development package to another?

Changing the assignment of objects from one development package to another is not recommended and (currently) not supported. Instead, you should carefully design the software components (and its associated structure and development packages) before you start creating, installing, or transferring your data models to SAP BW bridge.

Why should the rollback mechanism be disabled after cloning the software component into the productive tenant?

The rollback mechanism controls whether the repository is automatically rolled back to the last valid commit in case of errors when pulling changes. Enabling the rollback mechanism can be beneficial in many scenarios. However, for SAP BW bridge, errors typically occur in the after-import phase. In some cases, it may not be possible to consistently roll back all changes of the erroneous pull operation. Instead of rolling back all changes, it is better to just fix the root cause of the issue and repeat the import of the (few) failed object(s). That's why we recommend disabling the rollback mechanism.

Note that with deactivated rollback mechanism, you cannot pull an erroneous transport once again. Instead, you must perform a "dummy" change to those objects that ended up with errors, write them to a new transport request, release that transport, and pull the changes into the target tenant. You can also use the Mass Activation view in BW Modeling Tools to activate inactive objects after a failed pull operation.

The rollback mechanism can be enabled or disabled in the settings of the software component at any time.

Does BW bridge support conversion of logical system names for source systems?

DataSources are source-system dependent objects. The technical names of DataSources include the technical name of the source system. During transports in on-premise systems, for example from a development BW/4HANA system to a productive BW/4HANA system, the after-import transport handling adapts the technical name of the DataSource to reflect that it points from the productive BW/4HANA system to the respective productive S/4HANA source system in the landscape after the transport. This was done according to mapping table RSLOGSYSMAP. See SAP Help for details.

This source system mapping in the after-import transport handling is not done in SAP BW bridge. SAP Help explains the impact of this approach on best practices for naming conventions of source systems in BW bridge.

Is it possible to use customer or partner namespaces in SAP BW bridge?

Yes, you can use customer or partner namespaces. Please log an incident on component DS-BWB and provide the information as documented in SAP Note 3298985.

I can't see (and clone) a software component in one of the SAP BW bridge tenants – why?

Software components should be visible in all SAP BW bridge tenants of a customer (defined by the customer number at SAP). Please log an incident on component DS-BWB if you can't see a software component that should be visible.

Is it possible to transport remote tables in SAP Datasphere that have been created in the SAP BW bridge space via 'Import Entities' feature in Data Builder?

Remote tables are "imported" (=created) in the SAP BW bridge space in Data Builder in SAP Datasphere via 'Import Entities Table' feature. You may wonder whether these remote tables must be "imported" (=created) in the SAP BW bridge space in Data Builder in each and every SAP Datasphere tenant. This is not necessary. Remote tables in the SAP BW bridge space can be collected as dependent objects of an artefact in SAP Datasphere which is using these remote tables. And you can export/import remote tables into a target tenant in SAP Datasphere.

Why does the system generate all these local transport requests?

ABAP coding embedded in InfoObject transfer routines or in routines of transformations and DTP filters is maintained by users in the so-called M-class ZCL<GUID>_M (modified version of the code). Internally, the routine coding is stored as part of the respective TLOGO object (IOBJ, TRFN, DTPA). When activating such an object, either manually or in the after-import phase of a transport, the code is transferred to the so-called A-class ZCL<GUID>_A (active version of the code). Both classes are created as local objects. Changes to these classes are therefore recorded on local transport requests. A typical description of such a transport could be 'Transformation: Generated Class ZCL<GUID>_M'. There is no need to care for these local transport requests. They are created (and released) automatically.

What's the difference between gCTS and abapGit?

gCTS and abapGit are two independent solutions. gCTS is developed and provided by SAP whereas abapGit is a project of the open source community (with contribution by SAP). gCTS is an enhancement of the well-known Change and Transport Management System (CTS). In tenants based on SAP BTP ABAP Environment like SAP BW bridge, it is essential to transport objects. In context of SAP BW bridge, abapGit can be used to transfer your ABAP custom code that is not(!) directly embedded into transformations into the cloud. See the tutorial Use abapGit to Transfer Your On-Premise ABAP Source Code to the Cloud for further details.

 

Conclusion

This blog explained how to transport objects from an SAP BW bridge tenant to another and answered some of the frequently asked questions around that topic.

Many thanks to my colleagues Dirk, konstantinos.stergios, and thomas.baer for their valuable contribution to this blog post.