SAP BW/4HANA Migration – Discover / Prepare Phase – Part 3
This is a follow-on article (part 3) from the following articles
In SAP BW/4HANA Migration – Discover / Prepare Phase – Part 2 article I covered the detailed explanation of the first half of the log generated for the pre-check in transaction RSB4HCONV for the Discover / Prepare Phase of a migration to SAP BW/4HANA. The following are the remaining items for the generated log in the pre-check in transaction RSB4HCONV.
Explanation of the Pre-check log (RSB4HCONV) – continued
When migrating to BW/4HANA there will be automatically adjustments and deletions to certain objects.
When executing the switch to “B4H Mode“ the following happens:
InfoObject Catalogs are not available in SAP BW/4HANA. InfoObject Catalogs have been replaced by InfoAreas (AREA). InfoObjects will be adjusted automatically from InfoObject catalogs to InfoAreas
DSO Personalization data will be copied from three DSO’s to tables RSPERS_BOD, RSPERS_VAR and RSPERS_WTE.
Attribute change runs, APD executions, DB statistic updates, data change process types, index creation and deletion, aggregate roll ups, ODS activation, PSA deletion and cube compression & deletion will be removed automatically from the process chains.
The system will check and generate all BW queries in 3.x format. Queries in 3.x format will be automatically adjusted to 7.x format.
The following objects will be deleted when executing the switch to “B4H Mode“ the following happens:
Infoobject Catalog (migrated to Infoareas)
3.x Web Items
Source Systems that are not supported on BW4/HANA
3. Deletion of SAP delivered technical content.
All delivered BW technical content – 0TCT* and 0BWTC* objects (for example Front-End and OLAP Statistics) will be deleted when executing the switch to “B4H Mode“.
BW Object Type (Manual Redesign)
Certain BW object types can’t be convert automatically via the transfer tool (RSB4HTRF) and must be manually redesigned:
1. BW Object Type (Manual Redesign) -Infoset
The SAP BW InfoSet is not available in SAP BW/4HANA. It can be converted to a CompositeProvider via the BW4 Transfer Tool but is not possible if one of the following is applicable for the infoset (hence manual redesign is required):
InfoSets with “Most Recent Reporting for InfoObjects” are not supported by the BW4 Transfer Tool
InfoSets with “Left Outer: Add Filter Value On-Condition” are not supported by the BW4 Transfer Tool
InfoSets without “Additional Grouping Before Join” and without “Join Is Time-Dependent” are not supported by the BW4 Transfer Tool
InfoSets with only one PartProvider are not supported by the BW4 Transfer Tool
InfoSets which use navigational attributes from an InfoCube in combination with a temporal join are not supported by the BW4 Transfer Tool.
InfoSets with fields based on InfoObjects compounded to referenced key figures are not supported by the BW4 Transfer Tool
2. BW Object Type (Manual Redesign) -Infopackage
The persistent staging area service (PSA) and InfoPackages are not available in SAP BW/4HANA. Therefore, it is no longer possible to load data via a InfoPackage.
The Transfer Tool will allow you to either skip the InfoPackage and create the DTP directly on the DataSource, or transfer the PSA to an ADSO and replace the InfoPackage by a DTP.
The following InfoPackages cannot be handled by the Transfer Tool (hence manual redesign is required):
InfoPackages for 3.x DataSources – Migrate the 3.x DataSources and InfoPackage to 7.x DataSources (using transaction RSMIGRATE)
InfoPackages for Real-time Data Acquisition
Push InfoPackage for Web Service Source Systems
Multiple Delta InfoPackages for File Source Systems which read different files for same DataSource (or have different routines to determine the filename
3. BW Object Type (Manual Redesign) – Multiprovider
The SAP BW MultiProvider is not available in SAP BW/4HANA. It can be converted to a CompositeProvider using the SAP BW/4HANA Transfer Tool.
In the following cases, it is not possible to convert a MultiProvider to a Composite Provider:
The setting “Accept Inconsistency During Compounding” is set to true.
Navigation attributes from InfoObjects based on HANA Model are mapped in a way, that they cannot be used as navigation attributes anymore (see explanation below).
4. BW Object Type (Manual Redesign) – Process Chain & Process Variants
With SAP BW/4HANA, a number of process types are no longer available or have to be adjusted (for example infocube compression with zero elimination).
The process chains as such are still fully supported, but if a process must be deleted, then the corresponding process chain must be adjusted accordingly, i.e. the process must be removed from the chain, and the gap between the preceding and subsequent processes must be closed. In some cases, a process type must be replaced by the corresponding new process type. Here, the process chain also must be adjusted accordingly.
5. BW Object Type (Manual Redesign) – DTP
List’s DTP’s that are inactive due to a source or target object been deleted from the system – these need to be manually deleted. Also, it lists real time data acquisition (Type REMT) DTP’s which are not supported on BW/4HANA.
6. BW Object Type (Manual Redesign) – Open Hub Destination
This highlights the following Open Hubs destination types
• 3.x destinations (InfoSpokes)
• Third Party Tool
These must be deleted or replaced by features available in SAP BW/4HANA like SAP HANA smart data integration.
7. BW Object Type (Manual Redesign) – Infocube
The following infocubes can’t be converted using the transfer tool.
InfoCubes of type VirtualProvider or HybridProvider cannot be converted.
InfoCubes on SAP HANA that are not HANA-optimized cannot be converted. HANA-optimized these InfoCubes using transaction RSMIGRHANADB.
InfoCubes with an audit dimension, i.e. InfoCubes for which the checkbox ‘Auditable’ flag has been checked, cannot be converted at present. In order to convert them, the flag ‘Auditable’ has to be removed.
8. BW Object Type (Manual Redesign) – Aggregation Levels
Planning scenarios with aggregation levels (BW Integrated Planning or BPC embedded), which are created on top of a plannable InfoCube or on top of an DataStore object directly (i.e. without a MultiProvider or CompositeProvider in between), cannot be converted automatically into a SAP BW/4HANA compatible object.
BEX (objects will be automatically deleted) (Manual Redesign)
The report output highlights the BEX objects that will automatically get deleted.
To allow customers a parallel approach to complete the conversion project, SAP supports the temporary use of the existing BEx Web Applications through a dedicated pilot program for a limited time until end of 2022. This temporary functionality is exclusively available with the In-Place Conversion to SAP BW/4HANA.
The following are the steps from OSS note 2496706 (BEx Web Application Add-on for SAP BW4HANA) to be added to the pilot project.
Open OSS message on component BW-B4H-CNV with the string “WAD4BW4_PILOT” in the short text.
You’ll then be given a pilot note.
This pilot note contains a code change to allow the usage of the WAD and BEX Web functionality in a SAP BW system with the SAP BW/4HANA Starter Add-On installed and in a SAP BW/4HANA system.
See OSS note 2496706 (BEx Web Application Add-on for SAP BW4HANA) for more information.
Datasources (Manual Redesign)
The datasources for the following source systems are not supported on BW/4HANA
UD Connect source systems have to be replaced manually with source systems of type “SAP HANA”.
Source systems of type “SAP Data Services” or “External System (Partner ETL)” are not available in SAP BW/4HANA. There is no direct replacement for SAP Data Services Source Systems in SAP BW/4HANA. Instead, SAP recommend to use SAP Data Services (or external systems) to write to a native SAP HANA database table and then use a SAP HANA Source System with connection type “Local SAP HANA Database Schema” to bring the data into SAP BW/4HANA.
A SAP System (Service-API DataSources / Extractors), SAP BW or SAP BW/4HANA (source system) to a SAP BW or SAP BW/4HANA (target system) that the system level of source and/or target system does not meet the prerequisites for ODP based data extraction.
Check Service API target systems (Manual Redesign)
The following datasources need to be manually changed:
Export DataSources (8*) within SAP BW/4HANA is not supported. Data Transfer out of InfoProviders in SAP BW/4HANA (SAP BW/4HANA as source system) to other Consumers (target systems) such as BW systems or ETL Tools is only possible using ODP-BW. When InfoCubes and classic DataStore Objects get converted to Advanced DataStore Objects (ADSO), the resulting ADSO will not have an Export DataSource.
InfoObjects in a SAP BW/4HANA source system will get extracted to target systems using the ODP-BW context.
Service API DataSource within SAP BW/4HANA is not supported. This means that no Generic DataSources can be maintained in Transaction RSO2.
No Technical Content DataSources (0TCT* DataSources) can be activated in SAP BW/4HANA. Hence, SAP BW/4HANA can’t serve as source system to other SAP BW or SAP BW/4HANA system via the Service API Interface.
Delete Data for Open Hub Destination (Manual Redesign)
This highlights the open hub destination of type “database table” with “Technical Key“ selected.
Database table Open Hub Destinations with “Technical Key” store data by Request ID. However, SAP BW/4HANA uses a new Request Transaction Sequence Number for storing such data. Therefore, the existing data must be manually deleted from the target database table.
If the target database table is in the same database schema as SAP BW/4HANA (i.e. SAP<SID> schema), then the conversion will be performed automatically when switching from “Compatibility Mode” to “B4H Mode”. Since this conversion can take some time especially for larger data volumes, it’s recommended to truncate these target database tables before switching modes.
If the target database table is in another database schema, then the table must be truncated before switching modes (or the switch will fail with a corresponding error message).
User Exits (Manual Redesign)
With SAP BW/4HANA, the implementation of using the function module EXIT_SAPLRRS0_001 is no longer supported.
SAP recommend that in the conversion to the enhancement spots, that you classify the customer enhancements, for example, according to different application areas, and you create separate BAdI implementations.
Archive (Manual Redesign)
There is no tool for migrating existing archiving objects to the new archiving process concept.
The following are the manual steps required:
Reload all archived data to the InfoProviders
Convert the InfoProviders to DataStore objects (advanced).
Archive data again using the new concept, use near-line storage, or data tiering features available in SAP BW/4HANA.
Integrated Planning (BW Planning)
Integrated planning objects are allowed on BW/4HANA but require the BPC (Version 11 or greater) to be installed.
Please note, SAP BPC, version for SAP BW/4HANA is a completely new release of SAP BPC (it is not a successor to the pervious BPC version for SAP).
Since it’s BW/4HANA platform which leverages the SAP HANA database, BW-IP is no longer supported, and the BPC Standard model requires the SAP HANA platform.
BW-BPS (BW Planning)
SAP BW Business Planning & Simulation (BW-BPS) applications are not available in SAP BW/4HANA.
A conversion of BPS applications is not available. To set the system to Ready-for-Conversion status, which is a prerequisite for an in-place conversion to SAP BW/4HANA, it is necessary to manually migrated all BPS objects to to the BPC embedded model and delete all BPS applications.
In transaction BPS01, it is only possible to delete one application at a time.
To simplify the deletion, you can use the program (attached to OSS note 2468702). The program deletes all BPS applications (planning areas and dependent levels, packages, etc.). There’s no option to select any subset of the applications. InfoCubes and InfoObjects will not be deleted.
This article (part 3) along with the follow-on article (part 2) provides a detailed explanation of the pre-checker log generated by transaction RSB4HCONV.
Even if you’re not considering migrating to BW/4HANA now, it’s extremely important to start to review this conversion now due to the following factors
Simplification: Two objects (ADSO & Composite provider) for all LSA++ layers. Number of Modelling object types reduced from 10 to 4 (60% less)
Performance: ODP extraction performance benefits – for example the extraction reduction of a delta execution of the 0FI_GL_14 ODP is from 74% to 86% in PRD – (ODP—Performance-improvements-and-benefits)
BI Schedule: Parallel data loads to and from an ADSO is possible without any locking restrictions which will reduce the overall execution time of the BI schedules.
Innovations: All future SAP development innovations will take place on SAP BW/4HANA compatible objects.
BW/4HANA: The BW/4HANA is a new solution, it’s not an upgrade of BW 7.5.
BW 7.6: There is no BW 7.6. The last version of BW is 7.5.
Future Innovations: All future SAP development innovations will take place on SAP BW/4HANA.
BW 7.5 Support: The support maintenance on BW 7.5 will end on 31.12.2024.
BW/4HANA Ready: Getting ready for the actual migration to BW/4HANA in a controlled and organised approach. This phase of work is a substantial piece of work and needs to be completed in full before the actual migration of the system to BW/4HANA can happen.
Reporting: Report at any layer of the Data Warehouse with speed and flexibility including virtually combining data across layers.
Flexibility: Composite providers allow Info Providers to be combined using the JOIN operation allowing us to create new scenarios not possible before or if possible in the past would have very poor performance with standard techniques via Multiprovider or InfoSet
LSA++: Transition your LSA (Layered Scalable Architecture) to LSA++.
Reduce LSA/LSA++ Layer: Potentially remove the reporting layer and the existing transformation layer becomes the reporting Layer.
Reduction of objects and DB Size: By removing the reporting layer, the number of objects to support is reduced along with DB storage size.
Finally, it’s extremely important to understand that the conversion process of the objects does not mean that you must transition the BW system onto BW/4HANA. The conversion process can be executed on a standard BW system (For example BW 7.5 SP 11) without committing to move to BW/4HANA but must be executed in each BW system!!
Hi Donal , thanks for the detail information.
Is it possible for you to share known issues?
Currently I am facing issues while doing the inplace conversion meaning in the first step itself system throwing errors , i have selected very small flow which consists one cube and odso but system throwing errors which are not relavant to the above said flow.
Could you please help us on this issue?
Please send more information on the issue.
When we using the migration tool(RSB4HTRF ) which convert BW classical object to BW4/HANA compatible object, we have recognized a behavior which causes issue on our side.
We just wanted to migrate certain part of whole system but the Migration tool seems to check all data flows if they are still on a 3.x version .
We know that in our scenario there are some object which we will upgrade (3.x to 7.x) before start of Migration using (RSB4HTRF), but we would like to avoid to upgrade all 3.x object to 7.x object.
Is there any option available to suppress this or to deflag one we do not want.?
I would like to convert to Certain Part of whole system to BW4HANA compatabilty like Multiprovider to composit provier , Cube into ADSO and SPO's into ADSO, Complete flow.
We do not want to change mode to B4H.
so is it required to convert 3.x flow to 7.x for above requirement?