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.

Chased on the road to hana.jpg

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.

hornbach haus.jpg

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

To report this post you need to login first.

7 Comments

You must be Logged on to comment or reply to a post.

  1. Oliver Jaegle Post author

    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

    (0) 
  2. Christian Lechner

    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:

    • Documentation/Best Practices: We have some very good documentation on the keywords and so on in help.sap.com. That is highly appreciated but what we are missing are guidelines, best practices and do’s and dont’s on the topic. One example is the things you mentioned concerning the usage of consumption views. Until TechEd I was not aware of that concept and It seems to be an adoption of the concept used for HANA Live Views (known there as private, re-use and public views) but this is an essential guideline how to work with these guys. I think here SAP has to deliver the information that they gained with their S/4HANA development so that development at customer/partner site is aligned with that knowledge as there are certainly too many pitfalls that need to be avoided
    • Tooling: I really like text based editors. But cluttering the CDS View with annotations makes life not easier, so even when stacking the views there should be some tooling support to allow different perspectives on the view based on the metadata you want to work on. This also comprises the management of dependencies as you mentioned: there have to be some checks in order to avoid to crash an application by changes on the “DB” CDS layer; well … situation is not that different as when somebody changes a domain of a data element that is heavily used, but I think the tooling should definitely help us here as complexity will rise with the extensive usage of CDS views: according to the TechEd sessions SAP is quite aware of that fact and is working on it – so this is hopefully just a temporary issue.
    • (Unit-)Testing: Within ABAP object we are currently able to do decent unit testing due to ABAP test doubles and test seams. As the logic or at least some parts of the logic are now pushed towards CDS views we should have the same options especially when it comes to stacked views in order to mock out dependent views. Hopefully the test double concepts will be transferred to CDS views too to bridge that gap

    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

    (0) 
    1. Oliver Jaegle Post author

      Hi Christian,

      it’s always good to know one is not alone.

      Some remarks:

      • I’m a fan of CDS in general, I like annotations in order to enrich the semantics of the way the core-entities in the core relate, I don’t like the mixture of annotations and the practice of handling them in the same artifact.

      situation is not that different as when somebody changes a domain of a data element that is heavily used

      • The difference I see is that the meta-model of the data-element captures only the data-element’s responsibility. With a CDS-view having potentially a much wider responsibility, it’s more likely to change without changing with respect to the part which might be relevant to the consumer. The API which propagates changes should not only notify the fact of a change, but also provide information about what has changed, similar to the /BOPF/IF_FRW_CHANGE 😉   (have to ask in Horst Kellers blog for that)
      • About Unit-Testing: Christiaan Edward Swanepoel has given a warholistic-presentation at SAP inside track Frankfurt last year. Unfortunately, the interesting part is missing in the slides: the demo. As far as I remember the prototype presented provided an ABAP API which generated a database-scheme which then could be inserted to. The CDS-view on top of it then used a temporary secondary database connection in order to access them. Looked promising to me.


      Cheers,

      Oliver

      (0) 
  3. Martin Fischer

    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

    (0) 
      1. Martin Fischer

        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 🙂

        (0) 

Leave a Reply