Dear all,
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, 2317197[Q22]😞 "BW tables or views are not a public interface. SAP can change the structure, logic and semantic of these objects without any documentation. Also SAP cannot consider any request to change/enhance the internal tables and views to improve customer scenarios built upon them."
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 by default. 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).
However, keep in mind that these compatibility views provide a kind of workaround, but it is not best practice nor can the same functionality or performance guaranteed if you rely on them. So instead of adjusting the new SAP data model in S/4HANA to old and obsolete processes, interfaces or APIs, we recommend a serious redesign to leverage the new data model directly. One suitable example is the valuation of stocks in material management: Here SAP note 2713495 states the following:
In SAP S/4HANA, the stock data model has been changed fundamentally. For compatibility reasons, SAP introduced several different approaches (...). The introduced Compatibility Views are providing the same business functionality as it was in ERP - but due to the new stock data model, it cannot be compared 1:1 in performance.
One example from one of my customers: Using the same SAP ERP BW custom extractor to read stock valuation data from SAP S/4HANA did result in a huge performance degradation - generated by the complexity of the compatibility views. It works - but due to the runtime of 24+ hours, a complete redesign was required for this scenario.
SAP Landscape Transformation Replication Server (SLT)
As table replication from SAP sources is a quite popular scenario, 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. For more details refer to this user guide:
Compatibility Views and SAP Landscape Transformation Replication Server
Summary
Compatibility views are likely to play a key role in your transformation to SAP BW/4HANA and/or SAP S/4HANA. In both worlds, the overall purpose is the same, however the implementation is quite different:
- In SAP BW, compatibility views are generated by customers while in SAP S/4HANA they are part of the core installation.
- In SAP BW they are simple DB-views with a 1:1 reference to another table, while in SAP S/4HANA CDS views containing complex are applied.
Although they do their job, it is recommended to minimize their usage to a minimum and seriously think about redesign instead. Unless you risk to not fully leverage the value-added of the new streamlined SAP S/4HANA data model.
Helpful SAP notes
- 2595627 - Some well known tables and their compatibility views
- 2206980 - Data Model Changes in SAP S/4HANA MM Inventory Management (Stock)
- 2337368 - Data Model Changes in SAP S/4HANA MM Inventory Management (Valuation)
- 2713495 - Performance issues when using the obsolete MM-IM data model in S/4HANA
- 2270404 - Data Model Changes in SAP S/4HANA Controlling CO
- 2185026 - Compatibility views COSP, COSS, COEP, COVP: How do you optimize their use?
- 2270333 - Data Model Changes in SAP S/4HANA Finance FI
- 2349297 - Reporting and Analytics in SAP S/4HANA FICO
Thanks to Èva, Markus, and Andreas for providing essential details.
- SAP Managed Tags:
4 Comments
