Back in May 2013, SAP made Business Suite powered by Hana available to its customers. They benefited from generally improved performance and from Fiori applications that simplified business processes.
In addition, Hana Level, newly-introduced at that time, made strong performance possible in assessing available data directly in the Hana database – the operational reporting.
At that time, some news media were already enthusiastically taking about an SAP R/4.
Yet considering the solution in detail, it quickly became clear that it was not a fundamental renewal of the Business Suite. Both the data model and also what were, in part, outdated functions were retained in order to be able to retain backward-compatibility.
This enabled established Business Suite customers to migrate to the new product, without needing to abandon their own in-house developments.
With S/4 Hana, SAP dared to take a bigger step, also making its break with burdens from the past in the Business Suite that were no longer needed. Thus, among other things, for reasons of performance SAP dispensed with tables that contained pre-aggregated data.
This data is no longer necessary with S/4 Hana, because the platform commands sufficient performance to calculate the items of information straightaway. It is certainly justified to talk of a next-generation Business Suite.
Customers migrating to S/4 Hana need to be aware of this because, without further inputs, parts of their in-house development cannot continue to be used in S/4 Hana.
Hana Live Under S/4 Hana
Using an SAP System powered by Hana, customers automatically acquire free-of-charge access to Hana-live content. Operational-reporting solutions implemented on this basis bring together a Hana-based virtual data-model with a SAP-UI5-based user interface for assessing fundamental KPIs from various application areas.
Similar to the BI content, the items of content made available by SAP also serve as a basis for customer-specific extensions. The virtual data model and user-interface can have new KPIs or characteristics added to them; the calculation logic of existing key figures can also be adapted on an individual basis.
Yet caution should be the key-word when migrating to S/4 Hana. Its operational reporting is based on Embedded Analytics, not on Hana Live. Embedded Analytics offers the same flexibility but works on a different technical basis.
Whereas the virtual data model of Business Suite on Hana is implemented exclusively by use of data-base resources (Hana Information Views), the operational reporting of S/4 Hana is based on CDS-Views (Core Data Services), which are defined in the application server.
Because of the reworked data model in S/4 Hana, Hana Live developments cannot continue to be used. It is not planned to rework Hana Live for S/4 Hana. These are two different operational-reporting solutions for two different SAP products.
Alternative One: Integration Instead of Migration
Nevertheless it is also conceivable and possible to continue using Hana Live in S/4 Hana. The necessary adaptations of the virtual data model can be carried out by the customers making the extensions themselves; this can prove worthwhile if Hana Live was already massively extended by means of in-house developments by customers.
As an alternative, SAP is considering the possibility of manual adaptation of Hana Live Views by the customer. However, this requires a thorough examination of the changes to the data model in the individual instance.
The Simplification List for S/4 Hana (https://help.sap.com/s4hana_op_1511), compiled by SAP for this purpose, offers a good foundation for this.
An example: In the Business Suite, the VBBS table receives daily-updated, aggregated values for sales requirements (set of totals for sales-requirements).
Adhering to the principle of not forming any more aggregates, S/4 Hana now directly accesses the individual transaction receipts in the VBBE table (individual data-sets for sales-requirements).
However, acting in this way is configurable and reversible. The VBBS table is retained in S/4 Hana but, in the normal scheme of things, it no longer contains any data.
Because the table still exists, Hana Information Views thinks that accessing this data is still permissible even if no results are indicated anymore. Another example is tables producing totals and index tables in the FI-CO area.
These tables were deleted in S/4 Hana. However, access to the data in the same structure remains possible through Abap Views of the same name. The SAP Note 1976487 explains this case and other cases for data-model changes; it also contains instructions.
However, any changes to Hana Information Views that may be needed are not explained.
Likewise, at the level of the individual transaction receipts or of the core data – the preferred data sources for Hana Information Views – there are data-model changes.
For instance, in Controlling: The ‘Universal Journal’ (ACDOCA table) summarises numerous tables for individual items, used for operational reporting and planning.
Booking-headers associated with this are placed in the BKPF table. However, this does not apply to Controlling. Controlling’s booking-headers are temporarily still located in the COBK table; this is to be changed in future S/4 Hana releases.
These examples show that precise knowledge of the data sources is needed for an application user’s own Hana Information Views and planned changes in S/4 Hana, if the operational reporting in S/4 Hana is also to continue to use Hana Live.
Moreover, for each update any data-model changes made need to be checked in terms of their consequences.
Alternative Two: Hana Live on Embedded Analytics
In technical terms, reciprocal access is also possible between Hana and CDS Views. A user wishing to continue using their own developments in the Hana Live area can make avail of this possibility.
Already, CDS Views cover a large share of the data model in S/4 Hana; in this regard, they are by no means restricted to the data usable for analytical purposes.
As a general principle, for each CDS View a corresponding database view is set-up. This database view can be used as a source for a Hana calculation-view (see Illustration 1 – left).
The virtual data model of Hana Live enriches the data from the table by using metadata (e.g. allocating fields of currencies and of currencies, quantity of digits after the decimal point, rules for aggregation, etc.).
In the approach described, this data gets lost completely and needs to be defined anew – yet this is not the case for calculated key figures or for the already-implemented unified elements and joined elements of the tables forming the basis for this.
It must also be remembered that CDS Views, like Hana Information Views, has a hierarchical structure. Views on the lowest level are based directly on individual tables; however, these could become obsolete in future releases.
This is why it is recommended to use superordinate views as the basis (e.g. so-called CDS Cubes). Even after data-model changes, these will continue to exist under the same name and will have similar and compatible content at their disposal.
Alternative Three: Embedded Analytics on Hana Live
One criticism levelled at Hana Live is the need to develop the authorisation concept anew. The solution, based exclusively on the database, requires a new implementation of the authorisations, based on Analytic Privileges.
By contrast, use of Abap CDS Views in S/4 Hana permits the use of the application server’s authorisation objects.
A customer wanting to make use of this converts their table-access and data processing via Hana Information Views, as before, and then uses a CDS View to access the data that has been processed and is ready.
In this scenario also, metadata are completely lost but can be newly defined on the CDS level.
Like many databases, Hana has a special SQL set of orders available, with Hana-specific commands. This so-called ‘native SQL’ also permits access to Hana Information Views.
This is not possible in normal Abap code, because at the application servers’ level only a reduced standard set of orders is used (Open SQL). It is possible to get around this by using an ‘Abap Managed Database Procedure’ (AMDP).
This enables native SQL orders to be executed on Hana; their results can continue to be used. This AMDP can then be defined as ‘Table Function for CDS-Views’ and can accordingly be used as a data source for a CDS View.
Ultimately this means that a CDS View obtains its data not from a table but rather (via native SQL) directly from a Hana View.
This approach can also used in another way: it is little known that Hana Live can also be operated in a sidecar scenario. That is the term used for a system landscape in which Hana functionalities are used by means of the relevant data from a system (based on AnyDB) initially being replicated onto a separate Hana database.
As a result it is possible to allow data from another system’s Hana Live content to flow into the reporting, based on CDS Views in S/4 Hana.
Incidentally, this means that the best of both technologies is used: key figures are calculated on the basis of strong performance, exclusively on the database, and nevertheless CDS Views guarantee regular access via the Abap authorisation concept and users in the SAP system.
SAP offers two solutions for operational reporting. Hana Live is available for systems operated on SAP Hana and is based on Hana Information Views.
For S/4 Hana, Embedded Analytics is offered instead of this: this is based on Abap CDS Views. Customers using the standard Hana Live content up to now can usually make a problem-free switch to Embedded Analytics.
However, if customer extensions for the Hana Live content were produced on the system hitherto used, migration is not possible without further inputs.
The alternatives presented in this article demand knowledge of the SAP data model, of Hana Information Views and CDS Views. Using them correctly, they can guarantee a faster migration of the operational reporting if a switch to S/4 Hana is being made.
Depending on the method used, the performance resulting from this can even be better than that of the SAP standards of S/4 Hana, because to a greater degree the calculations are shifted over onto the database.