Since I first got to know the complexities of the SAP data landscape, which is more years ago than I care to mention, not a lot really changed on a year on year basis.
The principal receptacle of the SAP metadata landscape was the SAP Data Dictionary – a set of database tables within the SAP application that had a set of data definitions, describing how the large and complex SAP data model worked and was described.
The ABAP Workbench provides tools to maintain and view this Data Dictionary and is an integral part of the SAP development environment, and its where we go to get the metadata that our product Safyr for SAP uses.
And so it was for many years. However, this started to change with the introduction of SAP’s HANA database. HANA – standing for High performance, ANalytics Appliance) is SAP’s in-memory database. HANA promises dramatic increases in performance in comparison to a more conventional RDBMS like Oracle or Microsoft SQL Server.
SAP has pinned a lot of its future product direction and commercial success on HANA, introducing new versions of its flag-ship products that only run on the HANA RDBMS, in particular, S4/HANA, C4/HANA and BW/4HANA. These products have been optimised to take advantage of the speed and analytical power of HANA.
Whereas earlier releases of SAP were largely ‘RDBMS-agnostic’ – running the same on DB2 as on, say, SQL Server, applications like S4/HANA will only run on HANA. And SAP’s direction is to have the application take advantage of the powerful features of the HANA RDBMS. This is a significant change compared to that of a few years ago. By going to S4/HANA, customers are not only making a significant investment in an application that will run key aspects of their business, but also a significant investment in HANA itself – the ‘persistence layer’ that will store the valuable business data collected by the SAP application.
A customer using SAP on Oracle can switch the application to another RDBMS like SQL Server without any real change in the Application logic. It is not a simple task, but because pre-HANA versions of SAP treated the RDBMS as a relatively dumb ‘bucket’ for the storage of data, moving from one to another was probably not a career-threatening decision.
Much of SAP’s future technical direction is about further exploitation of HANA’s features. SAP’s aim is to push processing that is currently performed by the application layer down into the HANA database layer.
This approach takes advantage of the speed of HANA, and puts more of the processing ‘near’ to the database, rather than having the data processed by the application layer and then written back to the database.
The increasing level of capabilities at the HANA RDBMS level has brought about a plethora of new SAP capabilities to support the creation of objects at the HANA database level. And it’s a very complex story to keep track of.
The main elements of this are:
There is more to this than ‘Calculation Views’ – there are other View types as well, but the principle here is to provide a series of richly featured views that give a layer for reporting on the SAP tables.
SAP have provided a set of pre-built Calculation Views for their applications that provide ‘out of the box’ reporting for a wide range of business areas in the SAP system (this is sometimes called ‘HANA Live’).
CDS (Core Data Services) is SAP’s SQL-based layer for extending the standard definition capabilities of the SAP ABAP Data Dictionary to allow a richer set of features than have been traditionally offered by ‘Classic’ ABAP.
This overlaps a little with the HANA Calculation Views, as a much richer set of View features are available now via CDS then the relatively simple database Views supported by the non-CDS versions of ABAP. Our understanding of the suggested future direction from SAP is to use CDS rather than Calculation Views. Why? Well by using CDS the full definition of the data is in one place, rather than some being in ABAP and some in the HANA RDBMS. Of course, this is not possible when HANA is being used as a standalone ‘appliance’, separate to the SAP ERP or BW system itself (this is sometimes known as HANA Sidecar).
Once again, SAP developers have had ABAP as the primary development environment for SAP, using the venerable ABAP Workbench, an integral part of the SAP ABAP environment, for years.
In the new HANA world this has all changed. ABAP is still there, but now there is an Eclipse based development environment too. The HANA Studio uses an Eclipse concept called a ‘Perspective’ to provide different experiences to different types of user. There is a HANA Administration Perspective, providing the kinds of RDBMS level features that you might see in something like Microsoft SQL Server Management Studio.
Then there is a SAP BW Perspective that is used to build the BW modelling objects and maintain the BW system from HANA studio rather than logging into BW system separately.
And there is the ABAP Perspective. This perspective is used to build, debug and execute the ABAP programs and other objects, as an alternative to doing it in eth ABAP workbench.
Of course, I haven’t touched on the other elements of the SAP world that were not around in the days of SAP R/3 – things like Fiori and Lumira. Please look elsewhere for this – we only do metadata!
And it’s our lifeblood to ensure that we keep up with this changing world – as well as the other environments we work with like Salesforce, Microsoft Dynamics and the Oracle applications – to better support our customers and partners, so keep an eye open for new developments and product announcements to our SAP capabilities.