Don’t be that Team – Why CDS Views are the new ABAP Objects
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.
What a pleasure it is to read one of your blogs again. Coincidentally, last Friday found me punching the air and doing a lap of celebration around my small apartment (télétravail day) after completing my first CDS extension view. Oh the joy!
The big news, as anyone on an S4 conversion project will know, is that you have to recreate your append structures (for tables such as MARC) for all tables changed ('disappeared') by the new S4 data model. This is done by creating an extension on the CDS proxy view.
So development teams will have to get involved with CDS, and of course ADT (my struggles with this deserve a blog on their own). And if I can do it, anyone can 😀
Yes! Yes! Yes! I wholeheartedly agree. CDS is a must have skill. Um... So that means I actually have to use Eclipse and not just have it on my computer? I'm going back and fourth right now Eclipse/SE80.
As far as training - I would suggest SAP Teched. It would be a bit of a wait, but finding out a little at a time is nice. It will also give some nice examples to use. opensap.com is a great place to learn the basics too. That way you can get a feel for what your organization is using.
Sadly - timing is everything. My current training is searches, blogs, and anything I can find on the Web. SAP books - I've been buying them like crazy.
So yes, adapt it. Use it. And be like me and love it.
Thank you for a very nice blog,
This may be dependent on the release of ADT or on your Netweaver release, but I have found I can open a SAP GUI window (including SE80) from within Eclipse / ADT.
It is not as comfortable as running SAP GUI in its own window (which is a good thing for forcing yourself to use ADT functionality). It actually uses the SAP GUI, so don't go uninstalling it., but maybe remove the SAP GUI icon from your desktop or taskbar ?
Yes, I can open a GUI window from Eclipse. It's just easier from the GUI. I also did test my applications in the GUI. That wasn't a good idea. Sometimes I missed some issues in the FIORI version. So at least I'm slowly moving in the right direction. I did of course, make the command bar open. Still attached to some of my transaction codes. Interesting because some of them shouldn't be used.
Anyway - yes, I'm moving toward Eclipse. Maybe I'll try to remove the GUI icon. That would force me to do things correctly. I'll try that after our we add another division of our company. 😉
Thank you for the suggestion.
I use both Eclipse and SAPGui in parallel.
Any coding gets done in Eclipse, but it's convenient to have a number of SAPGui windows open at once, and in Eclipse that can get kind of crowded. Even if you stretch across a number of physical monitors, Eclipse isn't as straightforward for arranging windows as, .e.g Windows 10.
But a little tip. /o0 from an embedded in Eclipse SAPGui session will open a connected SAPGui, but in a stand-alone window. Optionally, if from that you open a Eclipse managed object, focus shifts to Eclipse.
/x closes only the stand-alone SAPGui windows.
When it comes to training, I recommend the (virtual) classroom trainings S4DEV and S4D430:
Ah... And you assume that all companies have a training budget. 🙂 This suggestion is really a nice one. Sometimes it's interesting to pick courses. Some are too easy and don't help much. That is unless you have a great instructor who will answer harder questions after class. Some have prereqs, then I don't know if I should be in them. Yes, I do normally go for the harder one. If I need to catch up, I have the material for later.
However, I am an interesting case. I buy a ton of books. I gather information via blogs. I try free training. Then of course there is always trial and error.
If there is a training budget, I would rather go to SAP Teched. Why? Because I get a good overview of everything and what to dive into. Then I start digging.
It's not the best way to do things, but it does work to an extent. I am usually a step behind everyone else. Which sometimes works to my advantage.
Again thank you for the suggestion!
Very insightful and good comparisons to prior experience. It’s scary to see how many developers are still struggling with abap oo at times.
Developers need to get off their abap stack Island as mentioned by Matt Harding
CDS ? what's that ?
I have customers on Netweaver 7.40 and 7.50 (and even S4) that haven't even implemented ADT. Some of them are like a retirement home for all the 3.1H ABAPers from the 90's.
Ouch - I resemble that. And actually it was 1997 3.1H.
Retire? I have quite a few year left. I'm not being serious. I do know what you mean. Learning new things, sometimes isn't an easy thing to do.
For me - so much to learn - so little time.
You can start CDS Development already on 7.40 and create OData Services using SEGW and the mapped data source Approach and in 750 you can even use Referenced Data Sources.
So your customers can already leverage CDS views now.
Fast-forward to fifteen years later, and ABAP OO is absolute mainstream
No it is not.
I wish it was, but it is not. I would be willing to bet that on this day 14/02/2019 over 50% of the new ABAP code being written is procedural. I actually think the percentage would come out even higher.
For some years now I have been writing blogs exploring the benefits of OO programming, and from the feedback I would say that "Team Procedural" is still a dominant player in the ABAP world.
As one example from last year:-
ABAP Objets cane in with 4.6C and though 19 years on it's use is much more common the day when it is mainstream is still some distance into the future. I always use OO myself now, and some of my colleagues at work do, but we are the minority.
At work last week I considered creating a CDS view but in the end I did not as only a few of the 20 odd programmers here would actually know what a CDS view was, and once again I am up against the "do not implement anything new, no-one else will be able to support it" problem.
Don't get me wrong - I like CDS views and think they are the way forward. I just think realistically that it will be 10-15 years until they are anywhere near "mainstream" in the ABAP world.
Agreed - ABAP OO is not mainstream, but I didn't want to be the one to say it.
My way of moving forward, is just not to mention what I did. At least that's what I did when I was in a bigger pool of developers.
I'm a happy person now!!!! Some people will never like my world, but I do. I'm in a company with only a few developers. So moving forward is not a an issue - yet. We all have to learn to do things "the new way".
It's interesting though, you would need less support if you used some of those objects from SAP or even your own. That could be a good argument. Sometimes, you even write a program in about 30 lines that would have been 1000 pulling all your own tables. Personally I'd like less support. That means I get to play with the fun stuff.
exactly what's in my mind. CDS is the hurdle afterwards. And those folks talking about OO using pure static methods I have to say .... no, that is not OO. That is still procedural
Maybe they think it's classy. ?
I have to agree. We are forcing ourself to do as much as possible in OO style but there are some things that are simply not possible (dynpro programming is one of the best examples). And yes, dynpro is still very common. Among our customers nearly noone even uses WebDynpro. Not talking about Fiori. It isn't even configured.And why should they? All of their modules are completely built on dynpros.
Considering those maintaining and extending banking applications. You are not getting around dynpro. I think that is one major point why ADT hasn't spread very much. Why should someone? Of course, CDS, Fiori, etc. isn't usable bot noone needs it. I'd really like to know where this statement of OO distribution in SAP modules comes from. For sure not the smaller Banking modules (BCA: no, CML: no, TRM: yes, most of our customers have the first 2).
They're not even using HASHED and SORTED tables - never mind Objects...
I think it is extremely likely that there are many many training centres around the world that are teaching 31H standard coding. It seems few newbies know anything about Objects. It can't be for lack of ability - Java coders from the same location seem to manage.
Thank you for this blog post.
Sometimes it is hard to find experienced ABAPers who really know how to use OOP. Few ABAPers know the "Gang of Four" design patterns for example, but most Java programmers do.
Part of the problem is that OOP tends to show its real value in bigger projects. Most ABAP projects involve a lot of SAP-related complexity but relatively little coding complexity (compared to Java projects.) So ABAPers have much less incentive to become OOP experts than Java programmers.
😉 I am asked a lot of times to prove OOP is the better option.
It's an easy thing to do - download ABAP2XLS. But all those small projects will eventually end up being replicated. Ah then use functions. LOL Functions are easier for structured type programming. But they lack the flexibility of OOP.
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).
I like that answer. Someday, I hope I can answer in the same way.
Paul - I really appreciate your thoughts be it your analysis on editable SALV or this one.
Do not implement anything new, no-one else will be able to support it - This is what I also faced many a time. But on an honest precept we need to change our team.
That linked blog post looks "somewhat" familiar! ?
Since writing it not quite a year ago, I've at least taken some baby steps towards ABAP OO, but it's still a struggle and not a "walk in the park" for me. But then, I don't really do much coding myself these days and it's usually enough for me to have some kind of passive knowledge about ABAP OO in order to get the gist of what others developed. As I'm doing some QA-work and maintain our development guidelines I need to be able to separate the wheat from the chaff and posts like Thorsten's help me do that. So thanks a lot for writing it, Thorsten!
I would just like to stress I am not forcing you to go down the OO path just because myself and other people say it is "good/cool" or whatever.
I just want you to take the same journey I did, looking at how to solve the same problems procedurally or via the OO equivalent. I came to the conclusion that OO, done well, made the programs easier to understand and maintain .. but if done badly it can make things a million times worse.
The good thing is that you have an open mind about this. I would be very interested to hear your opinion in another few years as to whether the OO light bulb went on for you, or if you decided it was not worth it, and the reasoning behind your eventual decision.
Either way I think we can agree that OO is not "mainstream" as of March 2019....
It's certainly not that I don't want to understand ABAP OO (I really want to come to grips with it), but that whenever I try and dig a bit deeper I run into what's most likely a kind of "mental block"! It's comparable - I think - to what happens when I read scientific articles about climate change which very often obviously include complex formulas: I just go cross-eyed and skip them as they could just as well have been written in a foreign and cryptic language.
And yes, to your concluding sentence, which certainly holds true for what I'm involved with day to day.
Told you so already in 2015 at #sitFRA 😉
Good read and Eye opening
Great article, thank you. I see some people disputing that OO is mainstream which was a bit of a shock. I wonder if there is a way to find out? It would be useful to have some numbers in that area. I agree that CDS Views are the future but sometimes in companies that use SAP the future is very far away. I think someone who has new skills and keeps up to speed will get opportunities in companies that like to be at the leading edge and that could be quite exciting and fun.
thanks a lot for sharing. I absolutely agree with you and your ideas in the end of the blog, where to focus on to be prepared for the future.
I think, the point “if ABAP-OO is mainstream or not” cannot be answered with a simple yes or no. There are a lot of different teams/scenarios where we reside with different boundary conditions.
If I would ask in my office, if ABAP-OO is mainstream, they would laugh at me and tell me that ABAP CDS, BOPF, SAP Gateway and even SAPUI5 is our daily bread for a few years. ABAP-OO is done without noticing that it is "something special".
If I go down a few floors and ask the same question to the team there, I will for sure get a different answer, as they are working in a < 7.40 maintenance project with a lot of very old legacy code, tightly coupled to applications or modules which do not use ABAP-OO at all.
However for younger colleagues, which are just starting their ABAP journey (most coming with a Java background from school or university), I would say that ABAP-OO is used intuitively and most of them don’t even know/recognize, that there was a time having ABAP without ABAP-OO.
Nevertheless I think that there are a lot of developers, who think that they use ABAP-OO (just because they are using classes and methods), but in fact they do a procedural style by only defining static methods without using any further common concepts of object orientation.
However for younger colleagues, which are just starting their ABAP journey (most coming with a Java background from school or university), I would say that ABAP-OO is used intuitively and most of them don’t even know/recognize, that there was a time having ABAP without ABAP-OO.
I work with a couple of large outsourced resources from big providers. Maybe they're hiding all their OO programmers. The newbies seem to be firmly stuck in 31H.
If you read the questions in the ABAP Development tag, this will also be confirmed. People still use the FMs for ALV, or FOR ALL ENTRIES instead of JOINs. Or READ ... BINARY SEARCH.
Read the blogs that have sample code, using FORMS. When I was mod, I'd politely ask for a rewrite into Objects. But the perception remains that OO is not for beginners. Which is of course tosh, since many developers start on e.g. Java.
thanks for your reply.
My sentence is mainly based on the colleagues I faced personally in my company. Maybe this is just the "special case", if you compare it with the whole community...
I personally think that "correct onboarding" of new colleagues probably is a key factor. If you tell a skilled, but old-fashioned developer (with no motivation to learn new stuff or to use ABAP-OO), that he should explain the young colleague how he should use ABAP - probably he will directly start implementing FORM routines despite his Java background, as he won't be aware of all the possibilities.
Just my opinion...
I think this is down to training institutes. Anyone who is a trainer (as opposed to old hand on-boarding newbies) has a duty to teach best practice. I've no evidence except the sheer quantity of newbies who use 20 year old ABAP techniques.
And those consultants that go to a firmly procedural company. That company may not want the OOP on their system. Thus the new consultant needs to know both ways of doing things. How confusing is that?
The new consultant at that same shop as above will only ever learn the old ways to do things thus making it more of an issue.
Again new technologies will improve upon our programming skills and how we do things. I just learned ODP and BRF+ as a default. Those both rely heavily on OOP.
ODP is how we are now doing most of our printing.
You can do BRF+ within a strictly procedural framework - just as you can CL_SALV_TABLE.
When you start passing object references around and use polymorphism (inheritance, interfaces), then I'd say you (me!) are beginning to do OOP. I've been doing it (allegedly) since 2000. But as I learn more, I begin to think what I did before wasn't really OOPs! 🙂
In the projects I work on, ABAP CDS is rarely used - not because nobody wants to or isn't skilled, but it's not relevant to the work. First it's not HANA S/4, second database access is fairly minimal. We do do considerable work directly in HANA however.
I've done some of the courses, so I'm ABAP CDS aware. But no chance to use it in the near future.
Are you on the cloud? We use it because we are on-premise. It's amazing how fast it makes things. Replacing the build of a Z* table with a straight SAP lookup. Most the time what I want is already there.
Work directly in HANA? What are you doing? Do you have a blog? I probably would have missed it. Lately I've been so heads down learning and developing programs at the same time.
Am I on the cloud? No. (I suspect a cloud wouldn't bear my weight anyway).
HANA through AMDP, ADBC and developing HANA objects, and XS.
Ha! The could is this massive thing. It's one main purpose is to change everything around and create Havoc.
So it wants everyone there. Yes, it is an entity all on it's own. Love the acronym's above.
Havoc. (n). A means by which a consultant can make money. qv. outsourcing.
Great article! Totally agree. In addition to adapting to the new paradigm, I also see a clear niche in performance improvement (very clearly related). Many people think that the simple migration to HANA brings obvious performance improvements and, if you simply adjust the code to keep it working, nothing is further from reality.
Now that there is so much talk about digital transformation, companies with legacy code have one of the main points that they should undertake.
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).
I enjoyed reading your blog. In section “Enter CDS views: The next paradigm” your list of CDS use cases can be enriched with ABAP applications on SAP Cloud Platform
Best regards, Bertram
P.S.: there is a typo in in your blog: it’s “SAP S/4HANA” not “SAP S/4 HANA”.
Dear Thorsten, This is a most excellent blog and as someone who has worked daily with SAP S/4HANA customers over the last 2 years and still going, this is one of the core messages we give to the developers in the project.
In fact based on my experiences I would consider it more important in SAP S/4HANA to learn at least the basics of CDS Views before they get too deep into Fiori – after all with Fiori elements, a lot of Fiori elements are largely generated from the ABAP CDS View.
I would add Fiori elements as the next topic after this, given the growing number of apps that use these floorplans.
However as always first and foremost, the most important thing for anyone working in newer technologies and solutions is mindset. And that’s where this blog of yours absolutely shines!
I would very much appreciate if you would add the SAP tags SAP S/4HANA and SAP Fiori for SAP S/4HANA to your blog to make it more discoverable by such teams.
A little late to the party but I've had problems dealing with Fiori apps that directly access CDS views as they will ignore any logic that I add on top of those views in a business layer (only concerns larger applications).
The fact that Fiori Elements use the annotations coupled with the fact it's no easy to generate the oData layer, kinda breaks encapsulation of code.
You can create OData Services manually, and use the CDS purely as a repository layer, but it's so much harder compared to auto-generate, I'm seeing an increasing number of developer go this easy (but in my view anti-pattern) way of doing things.
Nice post. Thank you Thorsten.
I found CDS to be something in what ABAP developers could get involved without the need of learning something totally new. At the end, as developers we have enough SQL knowledge which is highly needed (of course) while developing CDS views.
Currently I’m facing a problem, I have customers frozen in Netweaver versions before 7.4 (the first version CDS is supported from). They are not eager to level up Support Packages because “They don’t need it.”
I fear, in my case, until then, when SAP tells to customers “you need to move to S4/HANA”, CDS will remain as a “nice have” more than a “must have” skill.
I’m totally new in CDS and like it a lot. As you correctly point, it is the foundation of all new stuff to come, kind of.
Excellent blog.and excellent points raised by various people, especially Matthew Billingham
In 2006 when we got our new SAP system we had the same thing happen – people who were developers did what they knew as opposed to doing it the OO way.
Many of them didn’t use joins. SAP’s hottest new thing at the time was the new ALV grid and no one knew it except me because I accidently got put into the first class for it they ever had and all I had was BC-400 before that two weeks earlier. It took three months to agree that unless the manager of development agreed that only the new ALV grid would be used in report programs.
Here are my suggestions for companies when they first get their SAP systems and before they hire a single contractor to do anything.
1 – Bring in a very experienced SAP developer resource directly from SAP and someone who is a very experienced project dev manager, also directly from SAP. Do not bring in anyone at this point from any contracting firm because their bias will be what they can get as developers, not what makes sense for you.
2 – Have those people and the future SAP developers internal to your company come up with standards for everything that is code and the methodologies you will use. This includes …
2A) What version of ABAP you will use
2B) What things in ABAP you won’t allow
2C) Coding style ( OO vs. procedural )
2D) What technologies you will use ( CDS views, what type of forms, what front end languages, etc. )
3) Document this in a formal document that are coding standards and appoint a sr. developer to be the code reviewer. Reject anything that doesn’t match your standards and practices
4) Document your entire development methodology and build several template programs to Illustrate what is allowed and what is not allowed. Also set up the code inspector and demand it’s use prior to turning over code to code review.
5) Your dev process should have a formal code review state and empower the reviewer to be able to reject things that go against the standard no matter how badly its needed.
If you build the software infrastructure up front, you then can dictate terms to your contracting firm and tell them “these skills are mandatory for our project and this is how we do things” and insist it’s in the contract up front.
6) review resumes of all developers and interview them and ask them where their skills came from and what experience they have. Reject those who don’t have the necessary skills.
7) Hire people who have a track record of being able to learn and re-invent themselves.
Why are you hiding your identity, “former member”?
New? I enforced its use when I joined a company as Head of Development - in 2002. I'm pretty sure I'd been using it since 2000.
Cheaper and just as (if not more) useful, will be to bring in a knowledgeable independent contractor. I was so hired back in 1999 so that the client had someone to gainsay the consultancy partner's recommendations. Which challenge I took up gleefully.
6) is tempting, but not alway the best approach. If someone has 7) then they may well turn out better than someone who has the right skills. This is especially true for a permanent resource - obviously not so much for a contractor.
I'd add point 8). If you have a consultancy partner, have veto over the resources they provide. Better yet, at least for developers on a smaller project, take the time to recruit your own freelancers/contractor.
I fully agree with your other points.
Thanks for this timely blog post. I'm currently in a project where recently the question came up whether to use a traditional ABAP SQL query (SELECT) against a table or join of tables, or rather encapsulate the query in a CDS view and then select against the CDS view.
I'm an "old-timer" (R/3 1.0), a big ABAP-OO fan, and am certainly in favor of using CDS views if it makes sense. However, in our specific example I was wondering if it would really make sense to use CDS views. The queries are rather simple, mostly single-table selects and a few simple joins. I don't think there would be any significant performance advantage of using CDS views. The CDS view would be purely in the technical domain, no mapping to "nice" field names for the CDS consumers. No annotations, as there is no other use than selecting data for internal consumption.
What are your thoughts and recommendations? From the perspective of good programming practice, when is it OK to use traditional ABAP SQL vs CDS views?
Interesting question. I know Thorsten will answer. Probably differently than me. Ask 1000 developers the same question and you could get 1000 different answers.
From my point of view - I use CDS where it makes sense. Meaning if you are only selecting from one table. What are you doing with the data? Does it need to be aggregated? Is it something that you could limit the movement of data from the data server to the application server? Large amount or small amount of data?
Can you tell my real answer - for me it just depends. 😉
A pleasure to read !
As we know, CDS is the best way to get boost from SAP HANA DB and I am wondering about the percentage of SAP standard CDS compared to the Open SQL usage.
For my personal experiance, in 1809 the percentage of CDS is still pretty low and I am looking for a way to count SQL operations generated by CDS and those by OpenSQL in ABAP.
You say that CDS Views don't replace ABAP Objects but their coexistence is not peaceful, especially if you use the oData funcionality to expose data directly to frontends (like Fiori).
I came to this situation recently where for reports the CDS view guys had made oData available to the outsite Fiori apps. This is great and easy to do, except when you have an application layer on top of the database made up of ABAP Objects.
Suddenly I have this data being exposed with no regard for business logic, and all the encapsulation I achieved in the ABAP Objects code is destroyed. I wanted to replace the persistence of a particular segment of the application but I couldn't because all the tables were directly exposed.
Worse is that Fiori best practices seem to foster this direct CDS access for reports which completly breaks encapsulation.
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.
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.
Ver good read, the blog as well as the many comments!