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.

SAP Reporting, Modeling and Data Acquisition with SAP BW/4HANA Certification Preparation Guide

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.

System copy of BW 740 Production System to create Remote Conversion Sender System
Application of all needed Notes and all needed prep to Sender system
Standing Up of the SAP BW/4HANA System and application of all needed notes
Application of all needed notes to SAP BW/4HANA System
Meta Data conversion using conversion cockpit and transport of copies to to SAP BW/4HANA receiver System.
Data conversion into SAP BW/4HANA receiver system
System Copy’s of the SAP BW/4HANA receiver system to SAP BW/4HANA- Dev,QA and Prd.
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

Stand Up SAP BW/4HANA- Dev, QA and Prd System and install all necessary notes to Dev.
Application of all needed Notes and all needed Prep to BW 740 Sender system
Remote Conversion from Old BW 740 Dev system to new SAP BW/4HANA- Dev system
Transport of Notes and task list from BW 740 Dev to BW 740 QA. The task list log will also be transported
Transport prep from SAP BW/4HANA Dev to SAP BW/4HANA QA
Remote conversion Old BW 740 QA system to new SAP BW/4HANA QA system
Transport of Notes and task list from BW 740 QA to BW 740 Prd. The task list log will also be transported
Transport Prep from SAP BW/4HANA QA to SAP BW/4HANA Prd
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.

Rating: 0 / 5 (0 votes)