Skip to Content
Technical Articles
Author's profile photo Andre Hilden

Remote SAP BW/4HANA Meta data conversion in detail

Remote Conversions from BW 7.3/7.4 to SAP BW/4HANA are a new tool in the toolbox adding to the In-Place conversion option.

In this blog post I will focus on our firsthand experience with remote conversions and point out the steps needed for a successful migration. A remote conversion consists of 2 Steps. Step 1 the Meta data conversion is being described in this blog post. Step 2 the Data Conversion is not discussed in this blog post.

Prerequisite to Remote Conversions

With an In-place conversion the customer first needs to upgrade its BW system to BW 7.5 compatibility mode. For a client that is currently on BW 7.4 this requirement will add a step to navigate on their route from earlier versions of BW to SAP BW/4HANA For many customers, the Remote Conversion offers a way to avoid the initial upgrade to BW 7.5.  Remote conversions can originate out of BW systems from BW7.3 and up. In addition, the sender system does not need to be on a Hana data base while an in place conversion requires to have a Hana DB as a starting point.

Variations of Remote Conversions

 Shell Conversion

In a Shell conversion only the meta data is migrated from the old BW sender system to the new SAP BW/4HANA receiver system. All Info Providers, Data flows, Process chains etc. are migrated but the data is not migrated over to the receiver system.

This is a simpler form of Remote Conversion since many issues in a classic  Remote Conversion originate in the data transfer phase.

 

In a Shell Conversion only the structures are migrated, and the data will be loaded from SAP S/4HANA/ECC


Classic Remote Conversion

In a  Classic Remote Conversion both the Meta data and the data are migrated from a legacy BW sender system to the new SAP BW/4HANA system.

This conversion is the more complicated than the Shell Conversion, but it will create an exact copy of the clients existing BW system under the new SAP BW/4HANA landscape.

This is a good approach if SAP S/4HANA / ECC does not have all the data the client needs, and the reporting consumers are expecting the full historical data volume.

 

In a  Remote Conversion  both data and structures are migrated


Carve Out  

The Carve Out is a variation of both Remote and Shell Conversions. In a carve out the client will choose data flows to be converted. Only flows that you want to continue to use will be converted.

During the carve out the conversion algorithm will check on the inter dependencies of the chosen structures with the rest of the system. The conversion will fail if any needed dependency is missing. Once carved out objects cannot be re-integrated into the conversion. Therefore, a carve out option only applies in cases in which the client is sure that the carved-out structures are not needed anywhere else.

The carve out can be done either with data ( Classic remote) or no data ( Shell Conversion)

 

Early Preparations

Early preparation should start well ahead of the actual migration. The Prep is an optional exercise and can be done by the client. This exercise will cut down on Project Timeline and staffing resource costs during the migration.

 

Request Reductions

Note 1431315 and the instruction in transaction “RSREQREDUCE should be carefully studied and implemented well in advance. No Info-provider can have more than 1000 request.  Request reduction can have hidden issues that need time for resolutions. Lessons Learned (old 3X data-flows had hidden not fully promoted request and inconsistent tables which stopped reduction.)

 

Virtual Info Cubes

Are not supported in SAP BW/4HANA and would need to be redesigned before conversion.

 

Fix all Multi-provider Compounding Issues

Note 1045683 – Compounding problem (CMP problem)

 

3x Queries with “Calculation before Aggregation” setting

Replace with supported exception Aggregation.

 

3x data flow clean up

The conversion will not allow any 3x data-flow objects to be present in the system.

Often clients still have 3x data-flow used in master data load scenarios. In addition, the automatic conversion of 3 x data-flows does not delete the transfer structures. Even if the client has completed the 3x conversion in the past a considerable amount of work is needed to clean up the old transfer structures. These old transfer structures also will be associated to old requests which will cause issues with request reduction and structure deletion. Lessons learned : Do not think you are done with 3x flow clean up if you did a flow conversion in the past.

Code Analysis

When executed Code analyzer returns  a report.

All Objects Marked in red need to be addressed.

Since this is a first very early run not all the code changes need to be made at this point. Its good practice to get familiar with the issues and to address anything that can be done without causing issues in the old environment. Some code changes will have to wait for the actual Migration Prep.

 

 

Typical Code changes ( some must happen after migration)

  • Abap functions being called that do not exist in BW4.
  • Program Includes used that do not exist in BW4
  • Look-Ups against tables that changed names e.g active table for DSO has different naming convention  than active table in Adso.
  • Automatic Master Data Look-up in Transformation does not work because in BW4 the full key is needed to access aDSO
  • Changes to Info Object Length (e.g. 0material)
  • Types and Classes do not exist anymore

Reporting Analysis

Questions to be asked during Analysis.

  • Which reports are based on Info Sets? (its is possible that they are not needed since most of the time Info Set based reports are abandoned due to performance issues. Info set conversion could be de-prioritized.
  • Which reports are still pointing directly at Cubes or DSO’s ? These will have to be copied over to the Multi-provider and tested before migration.
  • Which reports are depending on APD’s ? APD’s will have to be rebuild and reports may be impacted.
  • Which reports are based on data-flows that are based on de-commissioned data sources ?     Later a detail analysis is needed to make sure all field are still available.
  • Any Reports on Virtual Info Providers ( not supported in SAP BW/4HANA)

 

APD Rebuild

Transaction RSB4HAPD is providing SAP migration tool for APD’s

SAP is currently not providing a fully operational conversion tool for APD’s. The existing tool works only for the simplest APD’s.  Most APD’s have to be rebuild.

APD’s can be rebuild before the migration. The functionality needs to be built into End- or Expert- routines using transformations. In addition, DTP’s with filter functions can be used. The workflow being used in the APD will need to be rebuild using a Process chain. Lessons Learned (do not trust the APD conversion tool. Start early to build out APD replacements)

Data source Analysis

All data sources will need to be ODP compliant.

Almost all Data sources commonly used in a BW implementations are whitelisted for use in ODP as well.

SAP Note 2232584 contains the updated list of data sources that are released for ODP.

Checking the ODP whitelist against the list of utilized data sources is an important first step and can start early.

If the transactional system remains to be SAP ECC its is important to check that your release supports ODP data sources. For SAP BW/4HANA the SAP ECC source system should have the following minimum release (picture source SAP)

Team training

Start to train the team early. Below a list of the most important SAP classes

  • HA100 – SAP HANA – 360° Introduction
  • BW410 – SAP BW/4HANA Data Warehousing
  • BW430 – SAP BW/4HANA Modeling
  • BW450 – SAP BW/4HANA Data Acquisition
  • BW462 – SAP BW/4HANA
  • BW405 – SAP BW/4HANA Query Design and Analysis

 

Migration Steps Option 1

 System Copy Approach

  •  Advantage: Less reliance of SAP involvement through reduction of the remote migration complexity. Currently SAP team must assist in ending phase of Meta data and throughout the data conversion due to missing SAP documentation.
  • Disadvantage:  Only works if SAP S/4HANA/ECC environments have roughly the same data volume. Data catch up needs additional data quality testing

In this option the actual conversion is only done once.

  1. System copy of BW 740 Production System to create Remote Conversion Sender System
  2. Application of all needed Notes and all needed prep to Sender system
  3. Standing Up of the SAP BW/4HANA System and application of all needed notes
  4. Application of all needed notes to SAP BW/4HANA System
  5. Meta Data conversion using conversion cockpit  and transport of copies to to SAP BW/4HANA receiver System.
  6. Data conversion into SAP BW/4HANA receiver system
  7. System Copy’s of the SAP BW/4HANA receiver system to SAP BW/4HANA- Dev,QA and Prd.
  8. Data catch up from S/4HANA/ECC sources for all three systems.

 

Migration Steps Option 2

Classic SAP Conversion approach

In this option the conversion is done for each System using one Task list

  1. Stand Up SAP BW/4HANA- Dev, QA and Prd System and install all necessary notes to Dev.
  2. Application of all needed Notes and all needed Prep to BW 740 Sender system
  3. Remote Conversion from Old BW 740 Dev system to new SAP BW/4HANA- Dev system
  4. Transport of Notes and task list from BW 740 Dev to BW 740 QA. The task list log will also be transported
  5. Transport prep from SAP BW/4HANA Dev to SAP BW/4HANA QA
  6. Remote conversion Old BW 740 QA system to new SAP BW/4HANA QA system
  7. Transport of Notes and task list from BW 740 QA to BW 740 Prd. The task list log will also be transported
  8. Transport Prep from SAP BW/4HANA QA to SAP BW/4HANA Prd
  9. Remote conversion Old BW 740 Production system to new SAP BW/4HANA Production system

Prep at Beginning of Migration Project

Initial Note implementation

Many Notes need to be applied in BW sender 7.X system and SAP BW/4HANA receiver system

In a first step read Note 2541557 which will allow you to download the note analyzer. Install the program in both sender and receiver systems. run the analyzer throughout the project. Running the downloaded program and using the xml file for remote conversion  will provide you with the list of notes that need to be installed in prep of the migration

 

Here is a list of Notes ( which is constantly changing and just an example )

 

At this point you will find yourselves in a transport freeze if you choose the classic SAP Migration Approach ( Option 2) .If you choose Option 1 you will have to first make a system copy of your production BW system to create the migration Sender System. The existing BW Landscape will remain untouched when using Option 1 ( system copy approach).

From here on all additional Prep will be done either in the BW development 7.X system ( Option 2 ) or in the System Copy of the BW.7x Production System (Option 1)

 

2nd round of code resolution

Now we can do all code resolutions that would have interrupted the old system

  • Replacing functionality of missing System functions or includes
  • Changing  any fields routine logic  that still refers to transfer structures
  • Changing custom functions called out by code scan
  • Clean up Process Chains with deprecated functions like PSA delete , Change log delete, cube compression, cube index deletion.
  • For look ups instead of the select statements, use the API (cl_rsda_infoprov_query=>select) to get that data.

 

ODP Data Source migration in Transactional System (SAP S/4HANA/ECC)

ODP capable Data sources need to be converted to ODP in the  SAP ECC or  S/4HANA system prior to conversion. Non ODP capable Data sources need to be replaced. SAP Note 2232584 describes the process in detail.

To enable use of ODP data replication you must first implement the Support Packages or SAP Notes described in the following SAP Notes in your system:

– SAP Note 1521883 (ODP Replication API 1.0 ) for SAP_BASIS < 730

– SAP Note 1931427 (ODP Replication API 2.0 ) for SAP_BASIS >= 730

Run program  BS_ANLY_DS_RELEASE_ODP in the SAP source system to release all Business Content extractors.

Run program  RODPS_OS_EXPOSE  in the SAP source system to release all custom extractors to ODP.

System Landscape before conversion

SAP S/4HANA/ECC system needs to be connected to Sender- and Receiver BW Systems

Last Steps for both conversion options

  • Making sure that all objects in the system are active
  • Making sure that all delta queues are healthy
  • Making sure all delta requests  that have already been received are  fully promoted to all Info providers
  • No Info Provider has more than 1000 request
  • All change logs are purged
  • We know what to carve out
  • Sender and Receiver system are connected to same SAP S/4HANA/ECC System
  • Change all Data sources to ODP if transactional system is not SAP S/4HANA
  • Min of 20 percent of the database size available in Sender System

Additional Steps for Option 2 Conversions

  • Block all users in Sender System in Sender System
  • Stop V3 update jobs in SAP S/4HANA/ECC

Migration

Scope Collection and Meta Data Import to Receiver System

In Scope Collection phase several tasks need to be performed

  • Carve Out any not needed Objects ( Be careful. Once these Objects are carved-out, they can not be re-introduced within the same package)
  • Collect additional data sources that are not automatically connected ( e.g., all Asset Accounting data sources )
  • Name the write optimized aDSO’s that will replace PSA’s
  • Assign transport packages to all entries
  • Makes sure everything is flagged for conversion
  • Tip: Do not plan to use several smaller packages. Everything needs to go together in one BIG-BANG Package. Lessons Learned ( Verify with Team that nothing in here is missing and obtain sigh off)

In Scope Collection error list

  • Scope Collection Step will return a list of issues that will have to be performed to migrate the scope. Here you must fix what was missed during Prep.
  • There are 2 iteration. In a first one the scope collection will complain if something larger is missing. ( Missing Transport package assignments, Missing aDSO names for PSA replacements, Missing datsources, )
  • In the 2nd finer one the scope collection has completed but the transports are not yet released yet. Here the errors can be numerous. Inactive objects, corrupt info packages, process chain variants that do not have assignments, missing objects that have been carved out by accident

Transport of copy request generation

  • At the conclusion of the Scope Phase Transport of Copy requests will be created
  • In a next step these requests need to be imported into the receiver system
  • At the end of this phase the receiver system should contain all selected data-flows in a converted SAP BW/4HANA format
  • Verify the objects and make sure that all new objects in the receiver system are active .

The Task List has a manual confirmation step before data migration can start, This confirmation has to happen after the team has confirmed the successful import of the Migration transports into the receiver system. After this confirmation the Data Transfer Phase can start.

Conclusion

Remote Conversions of  legacy BW systems are a larger project but make sense if the client likes the existing BW solution and has many years of development invested. It is important to start early and Prep the system before the actual migration project starts. The migration tool has proven to be a stable and bug free solution. Throughout the project SAP needed to assist many times but in almost all cases the issues were related to missing information in the Implementation guide.

 

 

Reference

Conversion Guide for SAP BW/4HANA2.0

https://help.sap.com/doc/999ae5f8c578402dab1fea94fa4599f9/2.0/en-US/SAP_BW4HANA_20_Conversion_Guide.pdf

 

Assigned tags

      2 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Sudhanshu Surma
      Sudhanshu Surma

      Thanks for sharing your experience and insights Andre!

      Author's profile photo Thorsten Lüdtke
      Thorsten Lüdtke

      Hi Andre,

      I'd like to add another option as shown in my latest book (see https://bit.ly/3gu8X1k): We use our external tool to first extract a copy of your BW metadata, convert and remodel it offline, and then push it to your development, QA, and production systems. An added benefit is that we can keep various versions of your metadata as a backup, apply a consistent naming convention, or discuss any remodeling issues with your stakeholders before actually deploying it.

      Best,

      Thorsten