A note on SAPs annotation-notion
I’m an ABAP fanboy. Writing that, this implies that I do not only like the programming-language itself, but also the tools surrounding it. To me, all of them are necessary in order to implement an application which runs in the AS-ABAP, you can’t just look at the language itself: The DDIC-elements editor (se11), the classbuilder (se24), the program editor (se38), the authorization object modeler (su21), the business object builder (bobx) and so on and on and on… Ok, I don’t like all of them. Some are ugly, unusable, follow inconsistent patterns and so on and on and on.
The ABAP workbench (se80) is a blessing harmonizing at least navigation, personalization and so on. I call it an IDE, although it’s more an integrating development environment, connecting previously separated tools.
Now there’s eclipse. And the need to provide new tools which seamlessly integrate into a new, really integrated development environment for the next generation ABAP programming.
And now there’s HANA, with a need for new types of artifacts and of course new tools for implementing them. What a coincidence and what a brilliant chance to also limit the zoo of tools supported: You want to implement a classic ERP enhancement: use The SAPGUI-based tools and processes. You’d like to implement some funky new S/4 or HANA based thing? We’ve got a new suite of tools tailored for that based on eclipse, there you go.
Source code rules
In the before-ABAP-days, basically during my studies, I was developing in JAVA and some Web-technologies scripts (HTML, XML, Javascript). My first look at the “brand new ABAP workbench” made my eyes water. “This is the way you define a class? You need a mouse for using that ridiculous (sorry, Thomas Fiedler) class builder! Why can’t I just type the definition? This form does not even properly scale to my screen’s resolution…” I was used to source code based tools. Eclipse was just in the wild with this brilliant context-based code-completion and implementing a system with tools like these looked impossible to me.
After I while I got used to it and even found some benefits of a graphical / form based environment: It felt less error-prone, more guided, task-oriented. I used the source-code-based ABAP class editor sometimes, but honestly: Whenever something was getting more complex, I reverted to the form-based view as it felt more manageable to me.
With the first new, central artifact of SAP HANS, the CDS view, SAP shifted the paradigm: It provided the editor exclusively on eclipse and with only a textual representation.
“Why not?”, I said to myself. Not only that code completion and instant syntax-check are things feeling very casual today, but there are other good reasons for providing a textual representation: There is already a language in place providing similar features (SQL) and the complexity of the CDS view’s metamodel is not fearsome. I was positive not to get lost in a CDS view.
But now, this has changed. They arrived. Annotations. In masses. Run while you can.
Figure 1: Developer running down the road to hana (Hawaii) being chased by annotations
No, let’s (try to) be serious again. Here’s a real sample from an annotated model (read in a TechEd slide and enriched a bit based on the ABAP Help):
define view Product … {
@UI: {
lineItem: {position: 30, importance: #HIGH},
selectionField: {position: 20},
}
@EndUserText.label: ‘Price’
@EndUserText.quickInfo: ‘Price per unit’
@Semantics.amount.currencyCode: ‘Currency’
Price,
@ObjectModel: {
mandatory: true,
foreignKey.association: ‘_Currency’
}
@Semantics.currencyCode: true
Currency,
…
}
I can see the source of a CDS view definition incorporates multiple other aspects than the actual structural definition with the annotations made. To me, this has many drawbacks:
Readability
One obvious problem which is particularly obvious if you don’t read the code within an IDE is the length of the source. I guess that using the outline view in eclipse this is much better. Nevertheless, if I’m interested in understanding a definition of a view, my eyes get much distracted reading all this additional information.
One composite meta-model
In the times of the DDIC, there were a lot of models, each with an own meta-model: A structure was defined to have a name, a description and an unlimited number of fields, each referring to a data-element. Each field may optionally refer to a value help and define bindings for it. A data element carries some labels and refers to either a domain or is directly typed. You get the idea.
Parts of these meta-models are now moving into the annotations of a CDS-view: The currency-code-binding from the structure, the label from the data element and so on.
One could argue that the annotations, each level grouped with the full stops (.), are models on their own. But as the artifact which is edited, locked and transported is the CDS view source, I see all those meta-models clubbed into one.
Figure 2: Multiple meta-models clubbed into one. Pictured a house model following this universal meta-model? Source: Hornbach
The aspect driving me as a developer crazy even thinking about it (I did not code CDS yet): Either SAP has to include all the aspects of the incorporated meta-models into the universal CDS-definition or there will be redundancy. If this is the case (which I am sure of): Which entity is the leading one? Are the annotations in the lower-level-layers only defaults? What Do I have to change when doing maintenance?
Layer-mixture
I always thought of CDS as the core of data definitions, the lowest layer, the foundation of it all. But the annotations in this very same source contain instructions for consuming layers, such as the UI or reporting. I can’t see how this should work. It is absolutely common that there are multiple consumers in the same layer which prepare the information of the lower layers in a different way. It can even be pictured on the simplest of all samples, a field- label: On a mobile-UI, I want to use an abbreviation while on the desktop-version I want to use the complete written word. The annotation on the lower-level artifact can’t be more than a default.
But there are other drawbacks of this approach to me: When implementing a consumer, I might need to change the base model (e. g. add an annotation to a view element for a position on the UI). In a bigger project with different developers, this raises the question who may be allowed to change which model at which point in time. At least in some projects I know, the UI-development was separated from the backend-development. And some backend-developers being responsible for the object model would not have been delighted to have some UI-devs twiddle with their models. This might also imply changes to the core-models until very late in the development process. And even when adding an annotation, you can destroy the base source (e. g. by accidentally deleting a line) and destabilize other parts of the application. It’s the same source!
Reuse
By combining multiple meta-models, you might reduce the ability to reuse information. In the DDIC view definition, you refer to data-elements carrying the labels. If you changed the label in the process of your development, all the views with fields referring to those data elements got automatically “updated”. As the meta-models are getting de-normalized, you’d have to do this change in multiple sources.
More questions
The longer I think about it, the more questions form in my brain, though I can’t properly place them now: What about extensibility of annotations, multi-language-support for values, distribution of annotations across systems (e. g. have BI-related annotations should be added to a CDS view in another system), what happens if an annotation changes and consumers need to react (does the activation of a CDS-view in future trigger a build of the complete system), and so on and on and on.
Ideas
I’m desperate. I really don’t see how this could really work out in the long run; nightmares of maintainability are waiting for me. Is there anyone to help me out on that?
Some ideas came to my mind which would at least alleviate pain:
- Different sources for different first-level-annotation-groups: If I could have a separate file decorating the CDS-definition with annotations for a particular usecase (e. g. UI, BI, Forms, …), this would improve readability and allow to limit the scope of changes. If the repository provided a special view which augments all annotation-extensions into one source, this would also satisfy the “holistic developers”.
- Rich editors: Of course, text representation is amazing. But only comfortable if it comes with all the bells and whistles like pretty-printing, excellent highlighting (maybe based on annotation names even), code completion, syntax checking (also for annotations) and so on. In some cases, though, a graphical representation might be easier to consume. I have not tried out the existing editor (due to a missing dev. System), so some of that might already exist.
DB view vs. UI consumption view
I recently learned by Bjoern Goerke himself that there shall be a differentiation between DB and UI/consumption view. To me, this sounds like using the same metamodel in different layers and multiple artifacts. While this sounds similar compared to my first idea to separate the sources for annotations, this raises more questions: Assuming I remove a field from an underlying DB-view which I had exposed on the UI, it will cause syntax-errors in the consuming sources. Of course, this is similar to any structural change (also if you remove a field from a DDIC-structure, you have to adapt the UI-components). However, I believe it’s a lot of redundancy in layered CDS-views as you don’t just add the upper layer’s metadata as annotations, but also repeat the complete field-definition.
What’s you impression on this? Are my fears exaggerated? Do you have any experience in developing in CDS with annotations?
I’m really looking forward to reading from you, community. And if you feel the same, please comment as well. Then at least, I don’t feel alone
Just to make one aspect clear: I don't think that annotations as such are a bad idea!
In general, I believe that having a strong metamodel is beneficial in general. And to me, annotations are just a textual representation of metadata.
I just believe they've got serious disadvantages compared to structured metadata separated from the core-definition (like having a "domain" being responsible for typing with additional metadata for field-based represenation in a data-element).
I'd be delighted if someone showed me why I'm wrong π
Or is my writing not understandable at all?
Cheers,
oliver
Hi Oliver,
you are not alone π
First of all, I have no experience in building, using and maintaining CDS views in a project aka real life. I played around with them and prepared internal trainings based on NW 740 (not so many annotations). I was somehow looking forward to the annotations to come with NW 750 (nourished by some sneak peeks on DSAG etc.). And here they are ... a lot of annotations tackling several aspects (semantics, UI, "BI"-like features, OData exposition). Now back from TechEd I also gained some more knowledge on CDS views and the programming model of S/4 in general where CDS views represent is one essential pillar.
I absolutely can understand each and every doubt you have on the CDS topic. Nevertheless, I see the CDS concept settled for future development of ABAP applications (together with BOPF). This "clear" programing model is imho a big step forward compared to prior developments with tons of different frameworks and concepts used even within in one module. In order to make decent use of these concepts some essential ingredients are currently missing in my very personal opinion:
As long as these constraints are not given the development with CDS views is to some extent an adventure which is just a matter of fact as the technologies are fresh and that is okay that not everything is perfectly in place right from the start, but one has to be aware of that when deciding to use the technology in projects.
Cheers
Christian
Hi Christian,
it's always good to know one is not alone.
Some remarks:
Cheers,
Oliver
Here's the blog where I try to explain what annotations are from the CDS language point of view ...
Hi Christian, hi Oliver,
I also see big advantages of the new programming model with CDS and BOPF. I looks like there will be "the one way" of developing applications with S4. But I also share your doubts.
I also think that there is no big difference between changes in CDS views and changes in DDIC nowadays. If you change things on that layer you always should be aware of the consequences. I'm not worried about defining a UI annotation for a label in a CDS view. But defining the position of field or if it's mandotory or not on DB layer, I don't like that.
About the tooling: I would like to have a visualation of the model I define in a CDS view. Reading all the associations as a text doesn't help my brain to understand how the model looks like.
I strongly agree with Christians point about documentation and best practices. help.sap.com is great and I saw already a lot of improvements in the last 15 years on that. I know that there are some development guides around on SCN. But unfortunately the majority of developers at customer’s site are still not using this source of information. Adding documents like guidelines with help.sap.com would give those documents a bit more the touch of being official. These documents should be available from the beginning, before customers started to mess up their systems. I don’t want to tell how many messed up applications I saw because of wrong understanding of object oriented architecture and clear separation of layers.
Cheers Martin
Hello Martin,
regarding your wish to have a graphical visualization option for CDS views. Starting with NW 7.50 and ADT 2.51 you have that option (at least in a read-only mode) with the new graphical viewer for CDS.
Details: Representing Core Data Services Concept in Graphical Form
BR,
Florian
Thanks Florian, in the meantime I read that blog post. For me, that's already the right direction. But before I can comment on that further, I should get my hands on it π
With regard to readability in Eclipse it is possible to hide the annotations (Ctrl + Alt + F6) and comments (Ctrl + Alt + F7) for a CDS View:
https://help.sap.com/viewer/f2e545608079437ab165c105649b89db/1709.000/en-US/1dcecfeabf204b10868e1988e904251f.html