Introducing the Migration from SAP BW to SAP Datasphere, SAP BW Bridge

Suppose you are a customer who has developed useful models and dataflows in SAP Netweaver BW or SAP BW/4HANA on premise, and you want to keep your data structures, but move them to the cloud. So, you have decided to work with SAP Datasphere and use the Migration and Conversion option for the transition.

Methods and Scenarios

To move the existing models to SAP BW bridge, two conversion methods exist: Remote conversion adds metadata and data. Shell conversion transfers metadata, but no data. Manual creation of BW bridge objects without template is another option. As you can select a specific object or data flow as a scope, you can mix these approaches and use one method for one scope and the other method for the other scope.

There are two sub-scenarios:

After migration, you can discontinue the on-premise BW. Development and modeling then takes place in SAP BW bridge and SAP Datasphere core tenant. This is the SAP Datasphere with SAP BW bridge approach.

Alternatively, you can continue development in the on-premise BW and update the changes to SAP BW bridge by running another migration job (or repeated migration jobs). This job updates (overwrites) the SAP BW bridge objects. This is the SAP Datasphere with SAP BW bridge and SAP BW approach.

Steps of the Migration Approach

Your steps are as follows:

1. Decide which migration option you want to use. Prepare the migration and conversion phase. Tidy up the system to reduce the migration effort.
2. Order the SAP BW bridge tenant from SAP.
3. As prerequisites for the next steps, define source systems in SAP BW bridge, such as SAP S/4HANA or the original BW system. Define transport requests in SAP BW bridge.
4. Perform the migration and conversion.
5. Load historic data from the original system if necessary (especially to be considered after shell migration / conversion). Schedule the load of new records from the sources.
6. Optionally, create additional BW objects in SAP Datasphere, SAP BW bridge.
7. Optionally, integrate the BW bridge models with models that exist in SAP Datasphere core tenant.

For preparing the migration, you must consider the following aspects:

1. Update the sending system

   It is highly recommended to update the sending system to the highest patch level in order to reduce the probability of errors or issues.

2. Check prerequisites for your scenario

   Open SAP Note 3141688 - Conversion from SAP BW or SAP BW/4HANA to SAP Datasphere, SAP BW Bridge. This note contains a .zip file (SAP_Bridge_Transfer_Note_Analyzer_YYYY-MM-DD.zip) with .xml files for each scenario. There are 2 (two) files for the Shell Conversion and 2 (two) files for the Remote Conversion. Of the two files for your method, 1 (one) file is to be used when the sender system is on SAP BW 7.x and the other one is to be used when the sender system is on SAP BW/4HANA. Download the correct file by using the Note Analyzer report (which is provided with SAP Note 3141688, too).

   The imported .xml files contain a list of notes which are required to be implemented to enable the corresponding conversion method. It brings enhancements and corrections in a frequent manner therefore it is important and recommended to always have the latest version implemented.

3. Check potential non-HANA code

   This step is only required when your variables, transformations or global routines may contain ABAP code that runs on a non-HANA database.

4. Get the sending system ready:
   1. In sending system (CIA) transaction SE38, start report RS_B4HANA_RC (Readiness check for remote cloud conversion).
   2. Activate, adjust, delete, or convert objects with issues (if you need them for your scope).

5. Sizing:

   Determine the required size of the SAP Datasphere, SAP BW bridge:

   The report (/SDF/HANA_SAP BW_SIZING) is available from SAP BW 7.3 (on any DB) and you will find any information with regards to the new sizing report in SAP Note 2296290.. Make sure the "SAP Datasphere / SAP BW bridge Sizing", not "SAP BW/4HANA Sizing".

   If you use SAP BW bridge only for specific topics or data flows, you can either list specific InfoAreas, list specific included InfoProviders, or list specific excluded InfoProviders by their technical names.

   Note

   In case of SAP BW Bridge and SAP Datasphere, sizing is not so important because you can easily up- or downsize.

6. Get your SAP BW Bridge tenant.

   Buy capacity units and order an additional SAP BW bridge tenant for your SAP Datasphere tenant.

7. Install backend and frontend tools:
   1. Install Eclipse / SAP HANA Studio in a version that supports cloud projects. (For simplicity, this frontend will be referred to as SAP HANA Studio in this lesson.<f)
   2. On your web browser, facilitate proxy settings.
   3. Install the Cloud Connector.
   4. Apply your licence, log on to the SAP Datasphere, make sure SAP BW Bridge runs technically (you can do a connection test in SAP Datasphere).
   5. In SAP HANA Studio, create a SAP BW Bridge project by applying the key from your SAP BW BRIDGE connection inside the (one and only) SAP BWBRIDGESPACE access key.
   6. Log on to the SAP BWB Bridge project and bookmark the SAP BW Bridge Cockpit link.
   7. In SAP HANA Studio, create a and log on to an ABAP cloud project,
   8. In SAP HANA Studio, create a "classic" SAP BW project for the sending system (CIA).
   9. Log on to SAP GUI with your named users and create users for communication with SAP BW bridge.

8. Prepare the communication framework to all sources:

   

   A communication system is basically an RFC destination. When defining a communication system, you have to define its communication users for both directions (inbound, outbound). The BW bridge Cockpit provides several apps for setting up users and communication systems.

   For specific purposes of connection, for example for a specific migration method or for a specific data exchange method, SAP provides a specific "scenario" that contains the required services,.

   • For shell conversion to SAP BW bridge, you need a scenario "SAP_COM_0691" (Migration Integration).
   • For ODP-based data extraction, you need a scenario "SAP_COM_0692" (ODP RFC Source System Integration).
   • For the write interface via RFC, you need a scenario "SAP_COM_0801" (Write Interface RFC Integration).
   • For the remote conversion, you need a scenario "SAP_COM_0818" (Data Migration Integration) in addition to "SAP_COM_0691".
   

   A communication arrangement consists of a calling and a responding system, the related scenario and the communication users. If you want to migrate a DataSource, you need communication arrangements with corresponding communication scenario for the migration method, the source systems and communication users.

   It is easy to jump from the created source system to the communication arrangements. Use the BW bridge Cockpit apps for the following tasks:
   1. Define users for communication in all systems.
   2. Create source systems and RFC connections between them.
   3. Create / check the communication users on SAP BW Bridge side
   4. Create / check the source systems and communication arrangements. They are set up with RFC protocol, technical users and the required service interfaces.
9. Set up Transport Management in SAP BW Bridge:
   1. In SAP HANA Studio, create an ABAP cloud project for the BW bridge tenant in a similar way as you created the BW bridge project.
   2. In HANA Studio Transport Organizer View (open via Window > Views > Show View) list, create a transport package and request.
   3. Assign the communication user of the migration project.
   4. Make sure that there are no open import queue entries and no other import is planned during conversion time.
   5. Check if manually developed objects exist with technical names that would be used by the conversion/migration.
10. Install missing objects manually:

    Create objects in the receiving system that are required and not available in the sending system or not part of the migration job, such as function modules, ABAP includes, a new BW Source System or new business content objects.

    

    If you want to transfer data from Extractors / DataSources (Service API) of an SAP system to SAP BW bridge, then you can configure a ODP Source System with the "SAP (Extractors) Context". If you have already defined a communication arrangement for the source system scenario, you can easily create the corresponding ODP source system. You can choose a different source system name as in the sending BW, but it would be easier to use the same one. From the maintenance view of a BW source system, you can jump to the maintenance of the communication arrangement and check the communication user assignment.

Launch the following video to see how to add a BW Bridge project, set up the transport request, and create an SAP BW object.

Suppose you have established all prerequisites for the Migration process. You first have decided to use Shell Conversion (without data) and/or Remote Conversion (with data). Let's have a look what happens in detail.

The Conversion Process

Suppose you start from SAP Netweaver BW 7.x or SAP BW on HANA. During migration with either Shell conversion or remote conversion, legacy objects are converted: Cubes and PSA tables are converted to DataStore Object (Advanced). Mutliproviders are converted to CompositeProviders. InfoPackages are replaces with a DTP and a default transformation is generated for the first layer of transformation. DataSources, InfoSources, InfoObjects, and BW Queries remain as they are. Open ODS views are ignored.

The generation of a DataStore Object (advanced) for the PSA table is optional. Use it if you have a complex first transformation step and want to run it in the SAP-HANA-optimized run-time.

If you start from SAP BW/4HANA, the conversion step is not necessary. Then, the objects are just moved to the cloud and updated to the latest SAP BW/4HANA release.

Note

Note that shell migration does not copy the data and neither does it clone a delta queue. It is recommended to extract historic data from the sending BW application and at the same time initialize a new delta process from the source system using the DTP setting that does not transfer any data for the initial DTP.

Running Shell the Conversion

The migration / conversion is started from the sending SAP BW system. Follow the following procedure:

1. Start transaction RSB4HCONV, called the transfer cockpit. Choose SAP BW bridge as the receiver system, Shell Conversion as the conversion method Alternatively, start transaction STC01 and start task list SAP_BW_TRANSFER_CLOUD_SHELL.
2. Select a scope to carve out selected applications (data flows) from your existing SAP BW system.
3. Specify if queries should be included, how PSA tables are treated, and rename the source system and, optionally, other objects (SAP note 2911800).
4. During import into the SAP BW Bridge system, all classic BW objects are converted automatically into the successor objects (e.g. CUBE/ODSO to ADSO, MPRO/ISET to HCPR). (SAP note 2911800).
5. Load the historical data from the original SAP BW system or from the original SAP source. Load new data from relevant source.

The task list SAP_BW_TRANSFER_CLOUD_SHELL consists of 5 steps. provide options to set up parameters. In step 1, choose to add a BW object, such as a dataflow, a BW query, or an InfoProvider, to the scope. After saving your list, the system collects the full scope. In step 2, you can still adjust the proposed list, and enter object names to complete the object mapping.

Depending on the scope, step 3 (adjusing mappings in MultiProviders) and step 4 (adjusting Badi) might not be relevant. There is no automatic handling of Badi. Do it manually and confirm that you did your job by checking the checkboxes. The program believes you. After you set step 4 to "resolved", you can run the next task. During step 5, the transfer tools convert object types and transfer metadata to SAP BW bridge in the background. You can watch what happens if you refresh the Repository in the SAP BW bridge project in HANA studio.

With remote conversion, you have an additional step after metadata transfer for data transfer.

Launch the video to see an example of shell migration.

Remote Migration

The special advantage of the remote migration / conversion is that data is copied and the delta queue of the ODP source system is cloned.

REMOTE conversion works similarly to the SHELL approach, except that data is transferred as well. (Remember, SHELL Migration transfers only the metadata.) Migration functionality relies on the SAP Landscape Transformation (DMIS addon). For this reason. The migration / conversion is started from the sending SAP BW system.

During Remote conversion, the existing data of InfoProviders is transferred to the receiving system, and the source queue is automatically cloned, so that the new target can catch up at the same delta status.

Follow the following procedure:

1. Install DMIS add-on in the sending SAP BW system.

2. Start transaction RSB4HCONV, called the transfer cockpit.

   

   Choose SAP BW bridge as the receiver system, Remote Conversion as the conversion method. Choose or create a package that collects the objects for the migration.

   

   The remote conversion cockpit is opened. It shows the task list for the remote conversion.

3. In the conversion cockpit, select a scope to carve out selected applications (data flows) from your existing SAP BW system.
4. Specify if queries should be included, how PSA tables are treated. It is not possible to change the technical names.
5. During import into the SAP BW Bridge system, all classic BW objects are converted automatically into the successor objects (e.g. CUBE/ODSO to ADSO, MPRO/ISET to HCPR). (SAP note 2911800).
6. Wait until the system clones the delta queue and transfers the historical data from the original SAP source.
7. 

   Check the Result of the Data Transfer

8. Schedule the loading mechanism for the new data from relevant sources.

For details, check the following document: SAP Datasphere, SAP BW bridge - Remote Conversion Runbook.

Note that BW bridge does not support all SAP Netweaver BW or SAP BW/4HANA capabilities. For example, it only supports ODP source systems and the Write Interface for ADSO and InfoObjects. For other source systems, such as SAP HANA, databases, cloud sources, or non-SAP applications, you need to create additional connections in SAP Datasphere core tenant. Therefore, the questions is how you can integrate SAP BW bridge data with data that is accessed using those connections.

For an updated list of limitations, check SAP Note 3117800 (Restrictions Note for SAP Datasphere, SPA BW Bridge) and the roadmap for SAP BW bridge, https://roadmaps.sap.com

Several of the workarounds suggest to model additional layers in SAP Datasphere core tenant. Suppose you have migrated existing models or created several objects in the SAP BW bridge and have already loaded data into the corresponding tables. You now want to integrate this content with data and objects from the SAP Datasphere core tenant and add additional layers. Your next step is to expose the SAP BW bridge objects as remote tables in SAP Datasphere (core tenant), which is called Import in the SAP Datasphere user interface.

After you have activated it, a dedicated BW bridge space exists as part of the SAP Datasphere core tenant. In the BWBRIDGE space, a dedicated connection called BWBRDIGE of type SAP Datasphere, SAP BW bridge is available. This SAP BW bridge connection differs from other connection types, as it can't be created or modified. It is being generated by default by SAP when the SAP BW bridge component is provisioned. The Data Builder main page for the BWBRIDGE space lists only the used BW bridge objects,

Use another, customer-defined space, to create additional connections to other sources, such as files, non-SAP sources, or databases and upload data from them. To integrate objects and data from SAP BW bridge, use the Semantic Onboarding app. When you import a SAP BW bridge object, choose your customer-defined space as a target. Then, pick the SAP BW bridge desired objects. The system will detect dependencies and list all required SAP BW bridge objects. When you start the deployment, a dedicated remote table is created for each of them and shared automatically with the target space. For the top level objects and for several intermediate objects, SQL views are automatically created. This does not replicate its data, but allows access to it via a remote table. However, you are not allowed to generate objects manually in the BW bridge space. The only way to generate objects is via import.

Perform the following tasks to enrich your SAP BW bridge data and make it available for SAP Analytics Cloud (SAC):

1. Import SAP BW bridge objects into SAP Datasphere as Remote Tables and SQL view directly to a target space using the BWBRDIGE connection.
2. Create a graphical view or SQL view to combine the shared object data with other data of the customer space.
3. Create an analytic model to define further filters, key figures, and parameters that should be available in SAP Analytics cloud (SAC).

Watch the following video to learn how the import to SAP BW bridge Space works.

When you use this approach, the data is still located outside of SAP Datasphere core tenant in the SAP Datasphere, SAP BW bridge tenant. Remote table might then be slow for large datasets. To persist harmonize values and/or to improve the run-time performance, you can load values from SAP BW bridge to the SAP Datasphere core tenant using a transformation flow. When the source is a Standard ADSO with change log, the corresponding imported remote table has delta capture capabilities. They can be used for delta logic of the transformation flow. In the transformation flow, you can change records with features of SAP Datasphere core tenant in a graphical editor, or you can use a script to transform the data.

Changes in source data are stored in a change log of a standard ASDO, ideally in Delta update mode for better performance, but even with full upload, only the changes are written to the change log. Metadata import generates a remote table with delta capture in SAP Datasphere core tenant. A transformation flow can read the delta capture information, process it, and fill a local table where the delta capture is reproduced. So, active records in the local table are up to date.