Adopting the S/4HANA Programming Model
Motivated by the blog post Performance Considerations Using ABAP Core Data Services anyDB and the experiences gathered in some projects, I would like to share some thoughts about the usage on ABAP CDS Views and some pitfalls especially from the point of vie of customer and partner development.
In general, ABAP CDS Views are the central pillar of the S/4HANA programming model. This is a matter of fact and SAP TechEd 2016 proved that they are the way to go when you adopt to the S/4HANA development model.
However, the CDS technology itself is part of the SAP NetWeaver since 7.40 SP05 and has been evolving since then with SAP NetWeaver 7.50 and 7.51 where the long awaited Testdouble Framework (Introduction CDS Test Double Framework – Write Unit Tests ABAP CDS Entities) was introduced. As a consequence, whenever this NetWeaver is available CDS views can be used, no matter if it is a S/4HANA system, a Business Suite or a bare NetWeaver and no matter what database is underneath. CDS views can be used on anyDB.
As we want to deliver future-proof solutions for our customers, the logical consequence is to make use of the CDS views (and consequently the code pushdown) when the NetWeaver systems allows it. This way the customer gets a state-of-the-art solution adopting the S/4 programming model as far as possible even not (yet) being on a S/4HANA system (and as a consequence hopefully making the transition at least from a technical point of view smooth). That’s the idea. However, this goal is noble, but mother nature (and in this case non-HANA databases) can be brutal to the noble ones.
Potential Problems with ABAP CDS Views on anyDB
So what is can be a problem with this approach? Let us take a step back and think what we are doing when putting complex logic into CDS views: We create complex SQL statements (eventually including SQL functions) that have to be executed on DB level. Now if we would have implemented complex SQL in the days before the advent of CDS views and SAP HANA, we wouldn’t have expected that this code is running on every database in the blink of an eye and without any issues. The execution of complex SQL was and is dependent on the database and how it processes it. So using complex SQL and executing it on different DBs might lead to some “surprises” especially when it comes to performance. The same holds if you put that complex logic into a CDS view (at the end it is SQL) – no magic here.
The next valid question is: Why do these CDS views then perform quite well on SAP HANA? The simple reason is, that SAP HANA was built with the intention to exactly make this possible, i. e. to enable the application to push data-intensive logic down to the SAP HANA and let SAP HANA (due to its architecture) do the trick.
Another important point to keep in mind is, that SAP heavily focuses on S/4HANA and its programming model, so the testing and the consequent optimization of CDS views together with SAP HANA is far beyond the testing on other databases. One can debate about that, but this will not really help you when the CDS view on anyDB is not performing in your project.
ABAP CDS Views – To use or not to use?
What does this mean for us as developers and architects? The answer to that one is not a single truth, but you have to take into account your constraints in your project. I would distinguish the following options:
- If we are on a system with SAP HANA underneath you can and should use CDS views and go for the code pushdown. There is no guarantee that no problem will arise and everything is pink unicorns and rainbows, but the likeliness is lower/not that high. If a problem occurs, SAP will probably find a fix as SAP HANA with CDS views is the programming model they also stick to. Nevertheless, it has to be clear especially to the customer that moving away from SAP HANA is then not that easy anymore, as sticking to CDS is not really DB agnostic (especially when it comes to performance)
- If you are developing on a customer system with a non-HANA DB underneath CDS views are not the preferred choice. If the customer is likely to switch to SAP HANA or S/4HANA soon, it might make sense to think about applying them. Nevertheless, you have to test the things very accurately and in case the performance (or something else) fails a plan B is needed. Be aware that the tests have to be done on the same database type as on the productive system – otherwise, maybe there is a big surprise after go-live.
If the customer has no plans to move to SAP HANA, I would not recommend making use of them. The potential problems that can arise are not worth it.
- If you develop products/add-ons as a partner that have to run on anyDB, the choice is simple: do not use them!
Except that you are capable and willing to test the stuff on every DB system it is released for – not a realistic scenario I would say
(Side Remark: Perhaps you find a spot in your product where the code pushdown makes sense and the customers on SAP HANA might really benefit from – well then it is time for a code split for HANA optimized code with all its consequences.)
- Another point to think about for the product developers out there: If you already have done a code split (let’s say a S/4HANA line and a Business Suite line of your product) and you want to do some back-porting of innovations from the S/4 to the Suite line and you used no strictly HANA specific code (like AMDPs) it is easy as cake … right? Well, you might also want to take a closer look if some CDS views (or let’s be more generic : some code pushdown) potentially come along with the backport and then you should rethink your decision on the backport.
Bottom line – ABAP CDS Views vs. anyDB
If you are on SAP HANA the usage of CDS views is quite safe and you should go for it to provide a future proof development. If you are not, you really have to think about the usage of CDS views and as a rough guide I would propose “if in doubt, don’t use them”.
For product/add-on development the situation is even more relevant as in contrast to custom-specific development the anyDB aspect really comes into play and you will really run into trouble.