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, thomasfiedler
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
- SAP Managed Tags:
8 Comments
