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.
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 usually 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. Instead, new objects must be assigned to an appropriate development package right during creation. Once an object is assigned to a development package, you cannot move it to another development package. That's why you should carefully plan your software components, packages, and transports.
$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. Note that objects assigned to the software component ZLOCAL cannot be transported or moved to your custom software component.
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).
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:
Let's have a look at the details.
see also Getting Started With SAP Datasphere, SAP BW Bridge | Create Software Components
You can now create BW bridge objects in tenant D, e.g., an InfoArea. Choose ZMYCOMPANY_BRIDGE_P as Package:
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.
Once your developments are ready for production, you must push them to the git repository. This is done by simply releasing the transport(s). To do so, open the Transport Organizer view in your ABAP Cloud project in BW Modeling Tools. If this view is not visible, go to Window > Show View > Other… and select Transport Organizer in the ABAP folder.
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.
The FAQ below takes up again some of the aspects discussed above and lists a few additional questions.
SAP Note 3130759 recommends creating just one software component. This is probably reasonable for most SAP BW bridge projects.
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.
At the time of writing, it is not possible to change the assignment of objects from one development package to another. 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.
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.
If you cloned the software component with rollback mechanism Enabled, you can still change it to Disabled in the settings of the software component.
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.
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.
Remote tables are "imported" (=created) in the SAP BW bridge space in Data Builder in SAP Datasphere via 'Import Remote 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.
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.
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.
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.
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 usually 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. Instead, new objects must be assigned to an appropriate development package right during creation. Once an object is assigned to a development package, you cannot move it to another development package. That's why you should carefully plan your software components, packages, and transports.
$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. Note that objects assigned to the software component ZLOCAL cannot be transported or moved to your custom software component.
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
- In 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
Note: At the time of writing, the names of software components must be unique across all SAP BW bridge tenants, globally. Therefore, as a best practice, include an identifier in the name of a software component that is likely to be unique, e.g., your company and project name. In this blog, we use the name ZMYCOMPANY_BRIDGE.
- In the Clone dialog, choose Source – Allow Pull and Push as Repository Role and set Rollback Mechanism to Disabled (see FAQ below). Cloning the software component generates a structured package ZMYCOMPANY_BRIDGE in tenant D.
Figure 2: Clone the New Software Component into the Development Tenant
- 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
- In the next step, 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
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
- In 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.
- 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 and set Rollback Mechanism to Disabled (see FAQ below). Cloning the software component creates a structure package ZMYCOMPANY_BWBRIDGE in tenant P.
Figure 6: Clone the Software Component into the Productive Tenant
Start Developing Objects
You can now create BW bridge objects in tenant D, e.g., an InfoArea. Choose ZMYCOMPANY_BRIDGE_P as Package:
Figure 7: 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 8: Set Default Package in BW Modeling Tools
How to Transport
Once your developments are ready for production, you must push them to the git repository. This is done by simply releasing the transport(s). To do so, open the Transport Organizer view in your ABAP Cloud project in BW Modeling Tools. If this view is not visible, go to Window > Show View > Other… and select Transport Organizer in the ABAP folder.
- In the Transport Organizer view in BW Modeling Tools, locate the modifiable transport request you have created in step 3.
Figure 9: Transport Organizer
- 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 10: Transport Logs
Figure 11: Software Component with Delta Between Local Tenant and Repository
- 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 12: 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?
At the time of writing, it is not possible to change the assignment of objects from one development package to another. 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 when cloning the software component?
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.
If you cloned the software component with rollback mechanism Enabled, you can still change it to Disabled in the settings of the software component.
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 Remote Tables' feature in Data Builder?
Remote tables are "imported" (=created) in the SAP BW bridge space in Data Builder in SAP Datasphere via 'Import Remote 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.
- SAP Managed Tags:
4 Comments
