Thoughts on hybrid development with BW/4HANA and SAP Hana Calculation Views as generally valid solution pattern looking at a mid-term time horizon and SAP Datasphere

[PhilMad]

Note: Adjusting SAP DWC to SAP Datasphere with the presentation of SAP Datasphere today.

 

Repeatedly in recent years I have been confronted with the question of how to evaluate "hybrid" development" in BW, i.e. creating virtual models with SAP HANA native Calculation Views built on BW-generated HANA Calculation Views, often with the subsequent use of the custom developments in BW composite providers of the same system. For the following, it is of importance to be aware that BW-generated SAP HANA calculation views are generated in the repository of the “SAP HANA extended application services, classic model”.

 

I will first list a few references to SAP notes which seem of importance to me in relation with the discussed topic.

 

• SAP Note 2463312 - "Support of HDI Calculation Views with SAP BW on HANA and SAP BW/4HANA", latest version 9 as per today. This note basically says that
  
  
  
  • BW/4HANA can consume HDI-based Calculation Views and
  
  
  • That BW/4HANA for the moment decided not to support the deployment of BW-generated HANA Calculation Views into HDI containers
  
  
  
  

 

• SAP Note 2465027 - "Deprecation of SAP HANA extended application services, classic model and SAP HANA Repository", latest version 13 as per today. You find in this note
  
  
  
  • The strong recommendation to plan the transition of existing content and applications from the “SAP HANA extended application services, classic model” to the “SAP HANA extended application services, advanced model”, which uses the HDI infrastructure.
  
  
  • That SAP plans to remove the SAP HANA extended application services, classic model with the next major product version. Actually there is no more “classic model” in SAP HANA Cloud. If you connect to a SAP HANA Cloud instance via e.g. the SAP HANA Python ML client return or access the SAP HANA Cockpit the SAP HANA Database version number is 4.00.
  
  
  
  

 

• SAP Note 2729983 - "Support status of combining modeling views created in HANA Studio and in Web IDE during temporary migration phase", latest version 5 as per today.
  Summing up its content, the reader will learn that
  
  
  
  • SAP recommends to move all views to the new “advanced model”.
  
  
  • It is supported to use BW-generated views being available in the “classic repository” to be consumed by HDI-based SAP HANA calculation views, but that, due to the fact that different technical users are involved in the execution of such mixed models, not all optimizations might be possible to be applied, longer execution times can occur and problems in the meta data replication can occur.
  
  
  
  

 

 

The note 2723506 - External SAP HANA SQL View with SAP BW/4HANA 2.0 introduces the “new” “External SAP HANA SQL view”  (in short the “8-view”, watch out for using the exact terminology) and describes the functionality with more detail and thus solves the issue of a lack of support as described in 1682131 - SAP BW tables in SAP HANA Information Views and ABAP CDS Views not supported which declares that building SAP HANA Calculation views and CDS Views directly on top of BW-generated objects is “unsupported”, even it might be technically possible.

 

One additional aspects is, as there is no 8-view for another other persistency apart of ADSO objects, there is the question of what to do with BW characteristics in virtual modelling outside of BW, if one wants to be formally correct.

And some more details about the 8-view: The definition of the 8-view doesn’t include the joins to the master data objects as it was included in the BW-generated SAP HANA views for ADSOs or other objects. Furthermore, no BW authorizations are checked when being accessed.

 

Further addition: At the moment I don't know of any extension of the functionality of TX SCTS_HTA for transporting HDI objects out of ABAP AS, which was for some an acceptable solution to integrate SAP HANA classic native developments in the existing ALM procedures. For HDI containers looks different and one might probably want to have to look for an integration between ABAP AS CTS, Git and HDI here. At this point, please take note of the “ABAP-managed HDI container, which is described here (link from the SAP HANA Development User guide):

https://help.sap.com/docs/ABAP_PLATFORM_NEW/6811c09434084fd1bc4f40e66913ce11/ec1eb6b328bc4219ad907f4...

Another options could be gCTS, which can create compatibilities with the git approach for HDI-based developments.

 

With the above, I think it becomes apparent that consistent, large-scale hybrid development in BW can be suffer both technical and support effects that should be addressed early or maybe even avoided.

 

Some reasons and precautionary measures are:

 

1. Technical aspects described above by the notes and the conclusions when putting them into a conext to each other under the hood of SAP BW/4HANA.


2. Testing of the design on productive data volumes at an early stage of development, possibly even on a data volume projected into the future. Virtual models can still have reasonable runtimes at the beginning of their lifetime with a productive data volume. However, this may become unacceptable as the volume increases because, among other things, there are several operations that have non-linear runtime behaviour.


3. Metadata breakage: the change from the BW metadata repository to a native HDI repository is not mapped by standard procedures. "Where-used" lists therefore do not work circumferentially. For small amounts of objects this may still be practicable, but for a large amount, poor documentation and changing developer groups, the logic can become very difficult to follow.


4. When Calculation Views, which are based on BW-generated Calculation Views, are returned to Composite Providers of the same BW, the DB user of the ABAP AS must have the sum of all authorizations of all potential (ABAP) BW users. Therefore, it is imperative to ensure that the correct info objects or other suitable BW authorizations are reapplied to the composite provider.

5. The creation of views is in many cases an easy process to initiate and lacks needs of integration in other aspects like controlled data flows, e.g. by process chains. Hence they might be too inviting and in case of missing governance and distributed teams the temptation can easily arise that each participant creates his own set of Calculation Views, although content wise identical or very similar views already exist. This can then lead to siloed data models or what I call the "view jungle". As a reminder, siloed data models were one of the main reasons why LSA came into existence and still have their raison d'être today, "++" or not, even in a world of virtual modeling.


6. The composite provider has received a significant functional update in BW/4HANA 2.0 SP4 and might address many modelling problems that were not resolvable with earlier versions.  These enhancements reduce the potential need for HANA native modelling within the area of BW. For the ones not yet familiar with these changes, a jump point to these new features can be the following URL: https://help.sap.com/docs/SAP_BW4HANA/b3701cd3826440618ef938d74dc93c51/d8b12ec099e04e6aa77a312be687d...

 

With the above I came to the conclusion that a consistent creation of virtual and/or partial and/or distributed virtual data models is only given in SAP Datasphere. However, this requires a different knowledge of modeling, deeper understanding of native SAP HANA core and integration technologies as well as performance monitoring and tuning. It is of great importance to know your data sources and integration technologies in detail, if you want to model in data storage and compute optimized virtual way.

For BW/4HANA I personally would initially tend to resolve everything with BW means. Developers can address in HANA transformations a lot of HANA native functionality including HANA native SQL and SQL functions. You might reduce persistencies in the middle but having a solid persistency close to the end users will guarantee you for most cases good and stable response times.

PS:

If you are using the external SQL view, please have a look at SAP Note 3198229 - "ADSO: Unnecessary CASTs in external SQL view", too.