Don’t be that Team – Why CDS Views are the new ABAP Objects

[Thorsten_Franz]

Those of us who have been in the SAP game for a few years will remember the days when object-oriented ABAP was considered exotic. Ten, fifteen years ago, most ABAP developers had been brought up exclusively with procedural programming in ABAP (and often COBOL), and there were only a few younger developers in the SAP world who had grown up with Java and other object-oriented programming languages and to whom the concept of object-orientation in programming was natural.

Demographics of SAP teams

Managers and team leads are typically about least five years more experienced than the average of their team members, and so among managers, the percentage of those with previous exposure to object-oriented programming was even smaller than in the general developer population.
The result? When faced with the question: “Should we adopt object-oriented development,” in most teams about 70% of the team members were against it, and most managers followed the majority and decided against object-oriented development.

Fast-forward to fifteen years later, and ABAP OO is absolute mainstream. One of the main drivers for this is that development in customer projects doesn’t take place on an island.

There is very little development from scratch

• There is very little development from scratch, and most ABAP development is done to extend business processes in the SAP standard modules. What happened in the standard modules?


• New modules that were developed followed a modern, object-oriented paradigm because those tend to be built by newly hired developers who come from a Java etc. background.


• Older modules were slowly and gradually modernized as business functionally was enhanced over the years, and the new developments formed larger and larger islands of object-orientation within the classic modules.


• The underlying NetWeaver platform evolves fast, and because the most tech-savvy developers at SAP work on it, it uses the most modern programming techniques; and this leads to changes in the business applications higher up in the software stack as they consume the functionality provided by the technology stack.


• Some older modules underwent more drastic renovations, leading to disruptive changes with few islands on procedural ABAP remaining.

ABAP Objects is now mainstream

As a result, slowly but steadily ABAP Objects has taken over most of SAP development. Granted, there are still niches and comfort zones for strictly procedural developers even in the S/4 HANA world, but these become smaller and smaller as method calls and object instantiations become more and more inevitable when interacting with the SAP standard codebase. ABAP Objects is now completely mainstream.

Enter CDS views: The next paradigm

Just as soon as development teams are beginning to feel comfortable with ABAP Objects, around the corner comes the next paradigm programming paradigm: CDS views. (Don’t get me wrong, they’re not replacing ABAP Objects, but they’re a new technology at the very core of SAP’s business applications just like ABAP, object-oriented or not.)

In SAP’s recent development, especially in the S/4 HANA space, CDS views are hugely important. CDS views with annotations are the core technology for building anything new along the lines of:

• OData services (replacing Gateway Builder)


• Fiori apps (moving Fiori screen design from Web IDE to UI annotations)


• Business Objects and persistency (BOPF objects from CDS views)


• Analytics (data providers and queries for the Analytic Engine)


• Enterprise Search (also generated from CDS views and integrated into Fiori Search)


• Web Dynpro/FPM applications via SADL and BOPF on top of CDS views


• Authorizations (via DCL)

Paradoxically, CDS views are even crucial for building compatibility of refactored applications with old programs through compatibility views, which replace some transparent tables that used to hold redundant data.

How do development teams feel about the new paradigm?

I often coach development teams who want to learn the new technologies. Those teams where the decision process towards adopting new technologies has already taken place and management has approved the expenses for hiring an outside coach are very enthusiastic and open-minded in adopting new technologies.

Of course, many teams haven’t reached this point yet: They aren’t yet aware of how much SAP’s programming paradigm has changed with S/4 HANA, and expect that they’re going to get along just fine with the skills and knowledge that served them well working with ECC 6.0. Team managers don’t yet realize they need to build new skills in their teams, because everything looks similar to the way it used to.

Customizers and developers are pretty comfortable when they look into what they think are transparent tables via transaction SE16 (even though they do get irritated when they insert a record via ABAP and it doesn’t show up in SE16 or their subsequent OpenSQL SELECT attempt, because both get redirected to a CDS compatibility view instead of accessing the database table into which the record was inserted). Many teams are in denial.

When confronted with and challenged by a lot of new stuff technologically, it may be tempting to close one’s eyes and deny the relevance or urgency of dealing with the technology.

Reasons we’ve heard before

When there is a new technology but you’d prefer not to deal with it, these are some easy ways to deflect it (and justify your denial):

• “We don’t need this, we’ll be able to implement our requirements with the technologies we know.”


• “Our developers don’t know it, and nobody will be able to give them guidance; we shouldn’t force them to use a technology they don’t know or need.”


• “We can’t maintain it: Even if some developers can and want to use it, we shouldn’t let them, because the maintenance team won’t be able to understand the code and fix any bugs.”

Where does this lead?

Where will such an attitude get them? Where did it get the laggard teams from ten, fifteen years ago?

• They created hard-to-maintain legacy code for ten more years than other teams.


• In the past years, they found it increasingly more difficult to connect their extensions with SAP standard code.


• They weren’t able to use SAP standard frameworks, which nowadays all requires good knowledge of object-orientation, for years (at least not with nearly the same efficiency).


• From half-understood tools comes unnecessary complexity; I find that developers who still struggle with object-orientation create the most messy and hard to understand code.

The earlier and especially the most whole-heartedly (i.e. quickly) someone adopts a new paradigm, the sooner they leave the stage behind during which they create very messy code. The more hesitantly and slowly someone adopts a new paradigm, and the longer they drag it out, the longer the stage during which they create messy code, and the more liabilities they create during that stage.

Embracing new paradigms

Following from that, my recommendation is to embrace significant new paradigms head-on and with plenty of energy. Give yourself the time to learn, ideally in a playful way. Use a sandbox system, build prototypes, extend your knowledge, and don’t be afraid to create a big mess, because it’s a learning process.

Training budget is limited – Making choices

But which new developments are “significant”? Clearly, few people are in the luxurious position of being able to learn every new thing. Most of us have to make choices and invest in some skills, while we leave others for later or indeed never.

In the SAP world, when choosing which skills to build and into which knowledge to invest, it’s always wise to look at what SAP is using for its own application development.

Currently, this is clearly the combination of CDS views with annotations, BOPF, and OData. These are the key technologies to understanding what’s even going on in S/4 HANA, and without which developers will simply be unable to figure out what the standard does, how to extend it, and how to troubleshoot it. Don’t let your team be that team.

[joao_sousa2]

When people ask me that, I will just state that the rest of the programming world uses OO programming. It’s everywhere, except at SAP. I do agree OO is required for larger application development which is not always the case in the SAP world, most developments (even the large ones) are small by comparison to fully fledged development projects.

People start to understand the problem when a SAP shop tries to implement a Hybris Commerce project and fails miserably because that’s where the OO concepts become paramount.

The new Clean Code ABAP guidelines will help me a lot because they have clean examples, and I’ll just start to refuse deliverables that break those rules (and yes it will hurt in the short term, but I think people are trying to see the costs of maintenance).

[joao_sousa2]

Many people think the simple migration to HANA brings improvements because that what SAP “sells” the customer. Most of the times it’s just “sales talk” because when you actually get down to it the application is based on something like BOPF which is like the anti-thesis to HANA’s “push code down” philosophy.

When I see that SAP itself keeps using BOPF to develop applications, I become very skeptical of their technical capabilities, with the expection of course of some extremely good individuals that exist in every company.

If you haven't seen me say it already, avoid BOPF for any large scale application that needs performance. Take a look at the code base, the code is garbage, methods with more then 1000 lines with zero comments, and the application itself is based on buffer (pull everything from tables and then process in the application layer). 

[mmcisme1]

I like that answer. Someday, I hope I can answer in the same way.

 

[Florian]

But isn't that in your hand, to make your own way with guidelines.

 

Because of having a broad set of tools and techniques there might be also ways we don't want to go.

Of course, it is a big task to define rules, to write it down (in a manner, that everyone can follow those rules) and even more hard to check, if the defined rules are also respected. I know what I'm talking about 😉

Me personally think, I cannot blame the creator of the toolset, because the thinking is different. You might don't like the opportunity to expose the tables direct. For me, it's something I have waited ages. I'm pretty happy with it.

~Florian

[joao_sousa2]

The problem is when the creator of the toolset is also the creator of “best-practices”. If the “best-practices” say to use Fiori elements with CDS views guess what most developers will do?

Most ABAPers will take the easier road, regarless of code quality and in this case it fundamentally breaks the advantages of encapsulation. Your data model gets exposed with a uncontrollable way.

It may make your personal development easier, but that development just made future changes to the data model impossible without intensive rework. Higher cost of innovation, longer time to market of changes to the model.

That’s why companies who have legacy systems with tons of development can’t innovate. They are stuck, chrystalized. The impact of any tiny change is unpredictable, untestable. 

This is the age of APIs, and SAP is promoting direct database access. Not direct I know, but it still goes around public APIs.

[joachimrees1]

Ver good read, the blog as well as the many comments!