In my last insight, already dated back from 2013, I discussed the optimizations for HANA in version SAP BW 7.3 . At the end I discussed the fact that we will be seeing a move towards in-memory data warehouses. Today, this is happening, and the migration towards BW/4HANA provides an opportunity to not only convert your current dataflows, but also remodel these dataflows in order to modernize your BW architecture and reap the full benefits.
This article will not give an overview of the functionality of BW/4HANA, as this is already comprehensively discussed in the insight of my colleague Adrien Constant, “SAP BW/4HANA: The Next-Generation Business Warehouse”. It will discuss the migration journey to BW/4HANA, and the opportunities it brings for remodelling.
From a technical point of view, a migration to BW/4HANA implies multiple changes in the database and the application layer. SAP offers the possibility to perform an in place migration , which will convert and move your current info providers and ETL into BW/4HANA. In the background , multiple changes happen automatically :
- No SAP NetWeaver stack, the underlying platform is SAP HANA and the ABAP application server
- More than 5 million lines of SAP BW code have been deleted. Customer code is not automatically converted, and if obsolete ABAP interfaces have been used, manual changes are necessary.
- Minor changes to official interfaces (RSNDI, RSDRI)
- Deletion of obsolete customer exits (CMOD) and BAdi methods
- Switch to new request management for all staging/load processes
- SAP HANA-generated views are calculation views only
The new BW/4HANA code is redesigned to comply with the new “code to data” paradigm.
Depending on your current version of SAP BW, the migration path will be different :
- You are currently running a SAP BW version (7.31 à 7.5) on HANA
- Migration to BW/4HANA provides an opportunity for remodeling of the ETL
- Migrations Options : In-Place / Remote / Shell (this is discussed here-after)
- You are currently running a SAP BW version (7.0 à 7.5) on any database
- Migration to BW/4HANA should cause an improved reporting performance from running on HANA
- Also when as-is migration is performed without remodeling
- Options :
- In-Place : technical migration to HANA database is included
- Remote from version 7.3 / Shell is generally available
- Migration to BW/4HANA should cause an improved reporting performance from running on HANA
The below picture gives an overview of the current status of SAP’s offerings for BW/4HANA conversion :
Later in 2019, a direct conversion to BW/4HANA 2.0 will be available.
An in-place conversion is a full system conversion of an existing SAP BW installation towards BW/4HANA, keeping the same system SID. In order to start this conversion with SAP’s conversion tools, an upgrade of your system is required if you are not running SAP BW 7.5 yet. Also in the case you are already running on BW 7.5, a list of SAP notes or an upgrade to the latest support pack is required along with the installation of the SAP BW/4HANA Starter Add-On, in order to have the conversion tools available.
You also need to plan for a migration of your database, if your BW is still not running on HANA. Database migration is required prior to starting the migration to BW/4HANA.
The conversion tools will allow selection of objects to be converted, this also includes an automated data transfer to the BW/4HANA counterpart (details on object mapping in the BW/4HANA insight). No obsolete objects should be available in the system before the full system conversion is started.
The SAP BW/4HANA Starter Add-On allows to switch your system into different states :
These modes can be used to to help you plan the migration in a phased matter. It allows you to have control over the creation of unsupported object types, while obsolete dataflows can still run and be transported to production. In parallel these dataflows can be converted to BW/4HANA.
Remote or shell conversion allows you to convert your BW dataflows to a remote BW/4HANA installation. Remote conversion also foresees the transfer of data, while shell conversion will only convert the metadata. As an alternative, data can be reloaded in SAP BW/4HANA and historical data can be loaded by connecting SAP BW with BW/4, only if SAP BW is released for ODP provisioning – see more info on ODP in the BW/4HANA insight.
As with the in-place conversion, the conversion tools allow you to select the objects to be converted, and now also a transport will be generated for import into BW/4HANA. In case of a remote conversion, the scope (=selection of objects) can be read from development when re-running the conversion in production, in order to transfer the productive data. In case of a shell conversion, running this conversion in production is not necessary, as the new BW/4 objects can be transported also from development into production.
The advantage of running a remote or shell conversion, is that both BW systems can run in parallel. In order to have this running smoothly , SAP foresees delta queue cloning and synchronizing. This is interesting in the case of a remote conversion; while for a shell conversion, the data can be re-initialized from the source systems as the old delta queue and the ODP delta queue can exist together.
Opportunity for remodeling
As discussed before, the conversion tools of SAP foresee the possibility to migrate your dataflows as-is to BW/4. When executing this process, there is still a need for manual intervention because not all objects settings can be automatically migrated. Also in the case of extensive use of custom ABAP programming, small adjustments might be necessary in order to work with new BAPI interfaces and table names (for the advanced dso’s). However, as BW/4 still utilizes an ABAP application server, your current dataflows will still run smoothly inside BW/4.
This does not mean that the performance will be automatically increased, as your transformation that use ABAP logic will still run in the application server, and thus are not following the ‘code to data’ paradigm. This leads to an oversizing of the application server. The goal of BW/4 is to keep your application layer small, and let your HANA database layer do the work. Datawarehousing is all about high-volume data processing, and this is the area in which HANA excels !
You might be surprised, but also the HANA database will be oversized when your dataflows are migrated as-is. This is because you will have a lot of redundant layers in your models, which are not required in BW/4. In an ideal situation you will only have a data acquisition layer where you data is persistent, and the intermediate ETL and storage is replaced with virtual data models by means of a :
- Compositeprovider : unioning or joining different datasets
- Calculation View : Use in compositeprovider if specific calculations are necessary
- Transformations using SQL script : If data storage in data marts in still required for performance reasons, logic can be coded in SQL script within end/start/expert routine to store final result in an advanced dso. Also a calculation view can be called from within this routine.
In general, it is always recommended to re-model your dataflows. In the long run you will benefit from your modernized datawarehouse in many ways :
- Lower hardware cost
- Clear architecture à Efficiency gain
- Lower implementation cost of future changes
- Faster access to information
- Future information requirements will be met faster à adapt to change easily
The road to your modern datawarehouse, will be discussed in the next section.
As the recommendation is to always choose for a remodeling approach, there is no need to engage in a huge project if you have a lot of functionality in BW. A project can be planned to ensure a fast decommissioning of your current BW server, and then plan for a phased remodelling approach. Take into mind that an as-is migration comes with a testing phase, which might be a sunk expenditure if you are planning for a new BW/4 datamodel. An advantage of the as-is migration is that you will have your current dataflows ready in BW/4, which can be utilized later to facilitate testing of the new datamodels.
In the analysis phase of the project you will decide which dataflows will be remodeled, and which will be migrated as-is. Then a subsequent phased plan should be constructed to have your BW/4 full y remodeled by a certain deadline. You will also run pre-checks on your BW system, to see which objects need manual intervention during the migration process.
The conversion process of existing BW objects can be run in parallel with the design & build of the new BW/4 models. After the conversion, manual developments on existing objects can be executed. Unit tests can be automated in case of a remote/shell conversion, using smart data access connecting SAP BW database to BW/4 HANA database. Use HANA queries to compare the content of the BW cubes with new Composite providers. It is equally important to execute performance tests during this phase, especially if you are engaging in a large remodeling project. In case performance of calculation views does not suffice for direct reporting, these can be further tuned or you can opt for persistence of data. In the latter case, effort to build the calculation view is not lost, as you can re-use the output in the transformation to your persistent ADSO.
When your BW/4 objects and models are in place, loaded and tested, the UAT phase can kick off. The focus will be mainly on acceptance of the performance of reporting on BW/4HANA, and it is important to manage expectations here. Data quality issues should already be handled thoroughly during unit testing.
After deploying to BW/4HANA production, a parallel run can be executed if a shell or remote conversion was executed. This is a good approach if a very large user base exist in BW reporting.
As discussed in this insight, a migration to BW/4HANA should not be seen as a pure migration project, as remodeling of the BW dataflows is necessary to capture the full benefits a modern datawarehouse. In the path to BW/4HANA an as-is migration is a legitimite scenario, serving to deliver a temporary state before engaging in a full remodeling journey.
The time has come to leave the burden of complex ETL processing with multiple intermediate layers, daily load monitoring and long projects for small changes. Create a real in-memory datawarehouse by virtualizing your business logic using state-of-the-art HANA technology !