How Accurate are SAP’s Arguments on Code Pushdown and CDS?
Executive Summary
- SAP has made bizarre proposals regarding code pushdown (aka stored procedures) and Core Data Services.
- As with Oracle, SAP uses CDSs to restrict its customers’ options to better lock them into buying SAP.
Video Introduction: How Truthful is SAP on Code Pushdown?
Text Introduction (Skip if You Watched the Video)
SAP has made a lot of noise about its code pushdown (aka stored procedures) in sAP HANA. However, an issue that has begun to arise on HANA implementations is how SAP has started to use the term to describe things that do not code pushdown. SAP renamed code push down to make themselves and make HANA seem more innovative than HANA really is. To a great degree, SAP has simply reinvented the wheel. You will learn what is true regarding code pushdown versus what SAP says about code pushdown.
Our References for This Article
If you want to see our references for this article and other related Brightwork articles, see this link.
Notice of Lack of Financial Bias: We have no financial ties to SAP or any other entity mentioned in this article.
What is Code Pushdown?
The first place to begin, of course, is “what is code pushdown.”
Code pushdown is an SAP term for putting previously in the application layer into the database layer.
How SAP is Now Using the Term
As stated by a colleague.
“Code that was pushed down to the database becomes even more pushed down by “filter push down”, “limit push down” and “aggregation push down” This is plain old basic “anyDb” SQL wisdom. Reduce the amount of data as early as possible, especially before you join subqueries, that is at the “most inner” or “lowest” level of your SQL. “Filter push down”: filter each result set to be joined BEFORE you join them, do not join large sets and filter afterwards. I learned this in an “anyDb” administration and performance course about 15 years ago, and even then it wasn’t new.”
Multilevel Pushdown?
The first question that should arise when reading this is how code has to be pushed down multiple levels in the database?
If the code is “pushed,” it is removed from the application layer and inserted into a table. Is there a level below a table? What is this quantum physics?
What SAP means is simply the reduction of data, not pushing code.
SAP on Core Data Services
SAP has published a document on ABAP Core Data Services of CDSs that can be found at this link.
But some of the things written in the document are required further elaboration.
For example, it states that Fiori apps are easy to create.
“Based on the OData exposure of CDS described above, it is then rather straightforward to create an SAP Fiori app using the development framework SAP WEB IDE (either locally or within SAP Cloud Platform). As depicted in Figure 4 the SAP Fiori User Interface connects to SAP Gateway using the OData services.”
The idea being the Fiori app will connect to the CDS view. The CDS is a database view with stored database functions that enable the retrieval of data. The idea is to improve on the limited ABAP dictionary views versus anyDB views have had for decades.
But instead of presenting CDSs as “catching up” with competing offerings, SAP decided to provide a deceptive explanation for CDSs’ logic. This is taken from the document ABAP Core Data Services on AnyDB.
“The CDS framework was introduced to leverage the computational power of HANA DB. Nevertheless, it can also be used with all other databases that support SAP NetWeaver (called anyDB in the following). This guide gives hands-on information on how to implement, run and optimize CDS based applications on anyDB.”
What is Core Data Service?
A core data service is an enhancement to SQL, which is a new data modeling infrastructure. This means the data models are defined and consumed in the database rather than the application.
How HANA Pushes Down CDS
However, there are those with considerable database expertise that suggest that HANA driven CDS enabled functionality pushed down to HANA will likely not end well in the longer term. This is not at all now. Oracle Retail used PL-SQL functionality to push down code into the database from the application. Similar to HANA, the logic was for performance reasons.
SAP IS Retail largely sustained a more precise separation of duties between the SAP application, NetWeaver, and RDBMS tiers, which also enabled AnyDB choices. The issue with the Retek/Oracle approach, which tightly linked together with the application code as that any client facing customizations, and the application/database versions, made **future upgrades very complex and costly**.
Essentially vs. SAP, they became effectively “re-implementations” vs. supporting technology upgrades that were possible with SAP NetWeaver and SAP IS Retail. And then comes the issue of lock-in.
The Lock In To HANA
One of these database experts stated the following about HANA’s CDS.
I’m personally nervous where the whole HANA driven application to database functional push down will take clients in the long term, for sure they become firmly locked into HANA and any aligned commercial terms.
Reinventing the Wheel?
That makes it sound like SAP brings something that did not exist before — both for HANA and AnyDB. The clear statement here is that other DBs can benefit from CDSs — making it appear as if CDSs are an innovation, not that they are bringing HANA to par (or attempting to do so) with AnyDB libraries.
That is one problem. The second is the phrasing.
“CDSs were designed to leverage the computation power of HANA, but nevertheless they can be used for other databases.”
This implies that other databases do not have HANA’s computational power. But let us leave that to the side for now.
We are emphasizing the presentation by SAP of CDSs as if other databases do not already have what CDSs offer. It will take years for CDSs to reach parity with anyDatabaseViews.
Cost to Create Fiori Apps
Usually, Fiori apps are costly to create, even pointed out in the Forrester study that SAP paid for. Forrester states that Fiori apps should be used standard. We addressed this in the article What is Actually in the Fiori Box?
And we have numerous stories of the costs of making custom Fiori apps. This is not happening on projects to any significant degree. Customers that are sufficiently misinformed to customize Fiori apps normally soon run out of money. But these are custom Fiori apps with some complexity. Other Fiori apps are much easier to create than others, as observed by our colleague.
“A simple Fiori app consisting of a drill-down table (filterable, sortable, groupable) and navigation to a detail form is quite easy to build as long as you do not need anything extra. Fiori provides “SmartTables” and “SmartForms” widgets, their behavior can be controlled by annotations/properties in the metadata of OData services (e.g. filterable, sortable, label). These annotations can be defined at the level of the CDS View already (@Filterable, @Sortable, @Label) and are propagated to the OData service that can be generated from CDS Views by some SAP magic. This works quite well for Fiori Apps with almost no UI logic (especially drill down tables with detail views, no edit) that are built once and never touched again. However if you modify the data model you usually are best of when you rebuild your Fiori App from scratch.”
Laying Out Intelligent Fiori Usage
So if Fiori is laid out in terms of usage, it is:
- Use the standard Fiori apps, although those Fiori apps are quite limited (See the article, Strange Changes to the Number of Fiori Apps to find out how SAP has exploded and exaggerated the number of Fiori apps.
- Potentially use the SmartTable or SmartForm Fiori widgets to develop reporting apps.
- Do not customize any Fiori apps with any complexity, so business logic, data complexity, etc.
The vision being pitched is to use the CDS and then do what you want in Fiori. There is a big question as to whether that will happen. If SAP was happy with customers using an efficient non-SAP app development environment, then maybe, but then, SAP will dissuade that from happening.
Secondly, another observation about the CDSs is from a colleague.
“This way offers you a clean layered application and the chance to write unit tests without database persistence. SAP are throwing away accepted architecture paradigms. CDS are OK to look at and analyze (join, aggregate, partly filter) data. That’s it. CDS is a framework, not new technology.”
This brings up the topic of whether CDS will ever really catch on or if they will end up being just another item that SAP introduces that just falls to the wayside.
The Benefit to Stored Procedures / Code Pushdown
CDSs, as with stored procedures, are a form of code pushdown. However, overall, we are still lost as to why SPs are a good thing when SPs’ discussion is really about tradeoffs. This topic is actively debated among those with expertise in the area, and there is no one clear answer. We keep pointing out that HANA is not addressing the hardware it runs on very well. So if you aren’t even addressing the hardware correctly, why are we worried about SPs? Furthermore, SP’s bring up more portability overhead for different DBs. If SP/CDSs are so effective, why won’t SAP publish any benchmarks on S/4HANA on ECC?
This gets into the topic of how most of SAP’s proposals, particularly since the introduction of HANA, where SAP took an abrupt turn from Netweaver as their primary marketing tentpole and transitioned to HANA, have been focused on making architecture arguments around performance. This is incongruous, as the performance was never an SAP selling point. Today, most SAP software performs worse in terms of speed and usability of that speed versus competing applications.
Previous points of emphasis on SAP were reliability and business process/functionality coverage. But first, with Netweaver (which focused on integration) and then with HANA, SAP fundamentally changed its historical message and value proposition.
Oracle on SAP’s Code Push Down
In Oracle’s August 2019 paper Oracle for SAP Database Update, Oracle has the following to say on SAP’s innovation claim regarding code pushdown.
SAP used to think of a database as a dumb data store. Whenever a user wants to do something useful with the data, it must be transferred, because the intelligence sits in the SAP Application Server. The disadvantages of this approach are obvious: If the sum of 1 million values needs to be calculated and if those values represent money in different currencies, 1 million individual values are transferred from the database server to the application server – only to be thrown away after the calculation has been done. As a response to this insight, SAP developed the..
„Push down“ strategy: push down code that requires data-intensive computations from the application layer to the database layer. They developed a completely new programming model that allows ABAP code to (implicitly or explicitly) call procedures stored in the database. And they defined a library of standard procedures, called SAP NetWeaver Core Data Services (CDS).
20 years earlier, Oracle had already had the same idea and made the same decision. Since version 7 Oracle Database allows developers to create procedures and functions that can be stored and run within the database.(emphasis added) It was, therefore, possible to make CDS available for Oracle Database as well, and today SAP application developers can make use of it.
How can code pushdown be innovative if Oracle had been doing it 20 years before SAP?
Restricting Stored Procedures for Competitive Reasons
SAP restricting SPs of S/4HANA is the primary limitation of being able to port S/4HANA to AnyDB. SAP is allowing the CDSs to be ported, but not other SPs.
Code that was taken from the ECC application layer and was pushed into the SPs used to belong to the customer when they purchased the ECC license. But with S/4HANA, that code did not transition to the customer. It was taken from the ECC application layer and was pushed into the SPs used to belong to the customer when they purchased the ECC license. But with S/4HANA, that code did not transition to the customer.
SAP has proposed that this is all new code, but it could not be. Else, how did ECC do these things before?
No one seems to be asking why SAP has control over code that was previously in the application layer but was migrated to the DB layer as a stored procedure. These are codes that SAP supposes to deliver for their customers who paid for their software. This is code that the customer should be able to use as they wish under the license. They should not be restricted by code that is in SPs that SAP controls how it is run.
The Proposed Logic of the Importance of the Code Pushdown
Now let us switch from one type of code pushdown (SPs) back to another type of code pushdown (CDSs)
Let’s look at SAP’s logic for the CDSs. Here was a recent argument made in favor of CDSs.
“Without CDS (labeled as “Classic Approach” in Figure 1), intensive calculations are done on the application layer avoiding costly computations in the database. This results in rather simple SQL queries between application and database layer. The drawback is however that lots of data need to be transferred back and forth between those two layers. Often, this is very time-consuming. “
Is it? With 2018 hardware? (or 2014 hardware as not all hardware is new).
What does SAP think its applications do? SAP does not compete in high-performance computing applications. These are not scientific applications, massively parallel scientific processing, or even Big Data.
If there is a problem with transferring data between the two layers, the entire application should be put in the database. Or most of it in the database. Is that such a good idea? We have software that performs much better than SAP on smaller hardware. They do it with the standard division with application logic in the application layer and just storing data in the database.
SAP’s Arguments for CDSs
SAP has been communicating to customers that they should use HANA CDSs as a primary way to access SAP HANA data. And that CDS views are the way SAP will go forward in the future, which are available through the OData interface.
Our Analysis
- The OData interface is both problematic and not as flexible as SQL.
- SAP should not be defining how you consume or view the data. SAP offers CDSs. Customers can use them or not use them depending upon whether they find they fit their needs.
- Business logic cannot be published to the CDSs.
Conclusion
SAP needs to police its use of the term pushdown or cease to have any meaning.
The evidence is how HANA has so vastly underperformed its performance hype, as is covered in the article HANA as a Mismatch for S/4HANA and ERP.
SAP is not focused on performance; it is using performance to push out other database vendors. What SAP cares about is using the idea of performance to push customers down the rat maze in a way that benefits SAP the most. SAP can use performance arguments to make them accept the logic of the lack of S/4HANA portability to different databases because SAP’s help restricts that portability. That is at least to the laymen — if SAP wanted, they could share the S/4HANA SPs with Oracle, IBM, and Microsoft, and all of these companies would pay the cost of performing the porting of the SPs to their respective databases. But they do not want to do this. They want to block out other vendors and restrict choice. And they are doing it retroactively because the previous versions of their ERP system were portable to different databases, which was the assumption under which it was purchased.
Core Data Services is a mechanism of lock-in presented as a positive functionality for SAP customers. SAP calls them Core Data Services because they are trying to maintain the illusion that they are doing something very different and innovative from other database vendors. Usually, this functionality is called a stored procedure. Stored procedures are how Oracle increases the difficulty for companies in moving away from the Oracle database and reducing portability between applications and databases.
But SAP still will not release the SPs because they don’t want S/4HANA ported. After all, they want to use S/4HANA as a wedge to get database sales that they would not otherwise get in an open competition. We cover SAP’s unwillingness to benchmark S/4HANA on HANA in the article The Hidden Issue with the SD HANA Benchmark.