Skip to Content
Technical Articles

CDS View Annotations “Scope” and “Propagation”

Target Audience & Links

This blog is for those who has a basic level of understanding in ABAP Programming model for Fiori or the CDS View annotations. If not there are a lot blogs out there and most importantly the SAP help.

https://help.sap.com/viewer/cc0c305d2fab47bd808adcad3ca7ee9d/7.5.4/en-US/3b77569ca8ee4226bdab4fcebd6f6ea6.html

Note: This blog is based of my experience and shouldn't be considered as the standard.

Scope/Propagation of Annotations

If we are creating the CDS views with annotations, you might have observed that sometimes we will have to write the same annotations multiple times in the different CDS views(parent & child) and sometimes we will write them at only the child view(transactional or basic) and not at the consumption view (or vice versa).

For example:

The Object model annotations like “CreateEnabled”, “DraftEnabled” will be written at the Transactional View(BOPF) and the consumption view(OData) as well. It is because the scope of those annotation are restricted to the View level.

But the annotations like value help, label, foreign key, lineitem, selectionfield etc.., will only be maintained at only one CDS view and will be propagated to parent CDS views.

This is because every annotation will have a scope. So how will we know the scope of the annotations? Simple, just go to the help where it gives the scope description for the annotations.

 

Element annotations will be propagated from child to the parent. We usually maintain these annotations at the columns level

View/Association annotations are specific to the view and will not be propagated to the parent CDS view. These usually be maintained at the header level.

 

Or we can simple say that the annotations that are maintained at the elements level(columns) will be propagated and the annotations that are maintained at the header will not be propagated (correct me if I am wrong πŸ™‚ )

 

It reduces a lot of rewriting head ache right? Now there will be an another scenario where we don’t need the annotations to be propagated and you might want to rewrite those annotations in case of reusing the CDS views. To do that we need to use the below annotation

@Metadata.ignorePropagatedAnnotations: true

If we use it in the parent CDS view, the annotations from the child view will not be propagated to the parent.

Note: BTW there are more than 2 scopes that I’ve discussed and please check in the below comments for more information.

 

Thanks,

Mahesh

13 Comments
You must be Logged on to comment or reply to a post.
  • Hi Mahesh,

    just checking.. whats the source of this definition for scope. I thought scope only defines at what level a particular annotation could be applied. Last I remember there were 6 or 7 scopes. For example, there is a scope for parameters and it simply outlines the annotations that could be used against a parameter.

    The annotation propagation seemed to be beyond the scope thing. Would be good to have ur source reference to further my understanding.

    Regards,

    Sitakant

    • Hi Sitakant,

      You are right, there are more than the 2 scopes that I’ve discussed in this blog. I only mentioned Element & View scope because they are the most used annotations for Fiori elements & ABAP Programming model for Fiori and the only official help I found is for them only. I think should’ve mentioned it to begin with, now I will do that, better late than never πŸ˜€ .

      Now coming to the question, I actually searched a lot to know more about the propagation of the annotations. But the only place where I’ve found the help about is at below

      https://help.sap.com/viewer/cc0c305d2fab47bd808adcad3ca7ee9d/7.52.3/en-US/a77d28ccaa114c009a17d7313075f86e.html

      They didn’t mention about the propagation directly there but I think from the above description we can safely assume that VIEW scope annotations will not be propagated so we need to double maintain them in the consumption view.

      I actually debugged quite a bit and understood that there are mainly 3 tables which stores the data

      1. DDHEADANNO For header annotations are stored
      2. DDFIELDANNO Where all the field level annotations are store
      3. DDPARAMETERANNO For Parameter annotations

      DDLA_RT_ANNOS for definitions including the scopes

       

      Class : CL_DDIC_ANNOTATIONS_PROVIDER which reads the annotations from db

      Class: CL_DD_DDL_HANDLER for saving the annotations to the db.

      And again you are right, from my debugging the above classes I saw that Scope is not the thing that is affecting the propagation. I think it’s just based on the header and columns. Header annotations (View,Table function, EXTeND_VIEW etc.., scopes) are not propagated while only the columns (Element scope not sure what that association means tho from the help) are being propagated.

      I guess SAP mentioned scope just to differentiate between various types of annotations and where to use them at header or item and whether we need to double maintain them or not.

      Let me know If my understanding is correct or not πŸ™‚ . Thanks πŸ™‚ πŸ™‚

      Mahesh

      • Hi Mahesh,

        sorry about the delay in responding. You know what, I feel envious as I miss having access to a system to play with πŸ™‚

        The note was a good pointer but the below statement on the same page created a bit of confusion

        @ObjectModel.transactionalProcessingDelegated: trueΒ annotation indicates that transaction requests to the consumption view are delegated to the underlying business object view.

        Need to dig a bit further on this. Will ping u back if I find stuff on this.

        Regards,

        Sitakant

        • I think that annotation is in case of multiple(or none) CDs views between consumption and transactional processing enabled CDs views and forΒ  the system to drill down to the correct transactional processing enabled CDs view for identifying the bopf object for cud operations I guess.

          No probs, I already debugged it before posting this blog πŸ˜€πŸ˜€πŸ˜€ but again I had to debug once before responding to u, to be extra careful πŸ˜‹ and I love Ur comments, which make me think in a different direction πŸ˜€, which is good.Β  Btw regarding The system, would you follow me here on the community so I can direct message you?

          BR

          Mahesh

  • As always great stuff. Did not know this scope stuff. This is interesting. Adding my comments after i think about scope more. This sounds so familiar. All these annotation scope, extension resonate so much with class and its attributes then being inherited on one hand or something like in program we have global variable and local variables.Β 

    Looks like annotations fundamentally are designed keeping the basic programming principles only.

    • Thanks Nabheet for the encouraging comments πŸ™‚ .. From my understanding, the scope concept that SAP talks about is not the one actually affecting the propagation (from debugging that std.code). It’s actually the items(columns) annotations that gets propagated and header will stay with the defined cds view only, (the same I’ve mentioned in the blog).

      But in the help we can see SAP specifically says that annotations with the view scope has to be double maintained(not propagated). Kind of confusing in the helpΒ  πŸ˜€Β  But again Element scope annotations can never be used at the header level So I think Element scope means they are talking about column level annotation. I think now I might be confusing you πŸ˜€ πŸ˜€

      • I understand what you are trying to say. What i am trying to do is draw parallel with imagine something propagating back( should be forward but still okay) as protected attribute and something not accessible as like private one but you need to declare again in child to make it work. Kind of seeing some similarity in the patterns.