As the name implies, SAP BW/4HANA or SAP S/4HANA are fully integrated with the underlying SAP HANA platform. This also means, that the physical data model changed compared to their predecessor products (for example in FICO area). Some tables are removed, changed or consolidated which makes a lot of sense to leverage the full power of the columnar in-memory concepts of SAP HANA.
In order to facilitate customers´ transformations, SAP has introduced so-called compatibility views to keep some core interfaces running. If a compatibility view is in place for an obsolete table, requests to access that table are redirected to newly introduced table(s) by the help and logic provided in the compatibility view.
This blog post will share some insights regarding these compatibility views in both worlds: SAP BW/4HANA Data Warehousing and SAP S/4HANA ERP. Both worlds make use of this concept, but they implement it quite differently.
SAP Business Warehouse
In SAP BW, compatibility views are relevant only for a conversion to SAP BW/4HANA. They are required to keep customer coding (e.g. lookups in Transformations) running although the data model changes with SAP BW/4HANA. This means, the major purpose is reducing the mandatory migration and cleanup tasks for customers which are running such conversion projects; SAP standard components do not require or use these compatibility views.
Please consider btw, that new customer coding should refer to the new SAP BW/4HANA-compliant structures and in the ideally the legacy references should also be migrated at some point of time. Also take into account, that although common practice at many customers, the direct usage of tables or views from the SAP BW database schema (SAP<SID>) in customer coding, HANA Views or CDS artifacts is not supported (see notes 1682131, 2723506).
In SAP BW, compatibility views are generated automatically only for objects which are transferred into BW/4HANA-compatible successor objects based on the provided SAP transfer tools. This means they are created in the original BW 7.5 system during an in-place conversion approach or during import into the new SAP BW/4HANA system in a shell or remote conversion approach. However, a compatibility view is not always generated: It is created only for classic DataStore objects (TLOGO=ODSO), but not for other TLOGOs, like InfoCubes for example.
In SAP BW, this compatibility view is a simple SQL view which does nothing more than redirecting the old ODSO structure to the new ADSOs structure. But there is no additional logic implemented there.
Example: Classic ODSO ZSAPDSO type Standard is transferred into an ADSO. The data model behind this new ADSO consists of two new compatibility views which refer to the new table of active data and the new inbound table. Both views consist of the exact same fields as the ADSO definition without any additional filters or joins.
This concept was introduced based on feedback SAP received from early customers who did conversion projects in 2017/18. To be precise it was introduced generally by SAP BW 7.50 SP11 (03/2018) or by SAP note 2539205 and corrected by SAP BW 7.50 SP14 (03/2019) or by SAP note 2684642.
So which compatibility views are created exactly?
ODSO type Standard transferred into ADSO type Standard with “Write Changelog” = ON
◉ View /BIC/A…00 referring to the ADSO active table /BIC/A…2
◉ View /BIC/A…40 referring to the ADSO inbound table /BIC/A…1
ODSO type Write-optimized transferred into ADSO type Staging
◉ View /BIC/A…00 referring to the ADSO inbound table /BIC/A..1
ODSO type Direct Update transferred into ADSO type Direct Update
◉ View /BIC/A…00 referring to the ADSO active table /BIC/A…2
InfoCube transferred into ADSO type Data Mart
◉ No Compatibility Views generated
Note 1: Take into account that compatibility views for following two scenarios have been provided only with SAP BW 7.50 SP20 (03/2021) or SAP note 2949015:
◉ ODSO type Direct Update with Planning Mode = ON
◉ ODSOs of all types in a customer namespace (unequal to /BIC/ or /BI0/ )
Note 2: Be aware, that the compatibility views might disappear if you change the modeling behavior of the resulting ADSO of an ODSO transfer. E.g. if you remove the flag “Write Change Log” for an ADSO of type Standard, then both views will be removed.
SAP S/4HANA
Remark: Unless stated explicitly, the term “SAP S/4HANA” refers to all deployment options (on premise, private cloud and public cloud).
SAP S/4HANA provides some compatibility views out of the box. They are not generated by any customer interaction; they are part of the SAP S/4HANA core and come out of the box.
The main purpose was always to keep some core legacy processes (transactions, reports, APIs) running. From a BW perspective, compatibility views play a key role for extraction: In SAP S/4HANA on premise most SAP Standard extractors can still be used, because they leverage these compatibility views to read to the data from the new source tables.
SAP note 2595627 provides a good summary of important compatibility views available:
If you are not sure whether a DDIC object is DB-table of SAP S/4HANA or just a compatibility view, you can easily check that in Tr. SE16N:
The line called Proxy Object provides reference to the compatibility view. In the example below, DDIC object “COEP” is actually the compatibility view called “V_COEP”.
As opposed to SAP BW, the compatibility view is not a simple 1:1 reference to another table! Much more logic is required to redirect the request towards an old ERP interface to the new S/4HANA data model. For this reason, there is complex logic required behind these objects in SAP S/4HANA. This logic is implemented as ABAP Core Data Services, and SAP S/4HANA compatibility views are actually CDS views. The above transaction provides a reference to the CDS data definition.
Another helpful option to understand the relations of compatibility view to the new SAP S/4HANA data model is the
Dependency Analyzer provided in the ABAP Development Tools (ADT) for Eclipse. This helps to get a good understanding about which SAP S/4HANA tables are really accessed.
In our example this is mainly our well-known ACDOCA table with additional details read from PRPS (WBS element), TKA01 (controlling area) and FINSC_CMP_VERSND (ledger version).
As table replication from SAP sources is a quite popular scenario, SAP Landscape Transformation Replication Server (SLT) has received innovation to be able make use of these SAP S/4HANA compatibility views as well. This means, SLT is now capable of identifying the tables associated with compatibility views and adds these tables to the replication process. In addition, SLT is able to analyze the compatibility view logic and create the same logic in the target system.
No comments:
Post a Comment