Skip to Content

With this blog series I hope to dig into Fiori Elements and describe what they are and how we, as developers, can leverage them to build robust applications that follow their opinionated design. In this first entry I will provide a brief introduction to these application building blocks and the annotations that help mold them.

What are Fiori Elements?

Fiori Elements (formerly Smart Templates) are essentially an aggregation of Smart Controls and other SAPUI5 controls that have been weaved together into what is described as a “floorplan” with an abstraction of code that can introspect annotation-based data and adapt layout and behavior accordingly. These “annotations” are an extension of a service’s metadata (EDMX) model and can act to enhance the service’s entity and property semantics, the service’s capabilities and potentially define how a user interface that consumes the service should behave. In other words, the service’s interface is being extended with syntax that goes beyond the scope of normal entity and association definitions with the addition of machine-readable declarations that are accessible by client-side frameworks like that of SAPUI5.

Outside of annotations dictating behavior within a Fiori Element application, you are also provided the standard paths to extension with SAPUI5 along with some extension APIs that are baked into the framework.

What is the point of all of this and why would we want to incorporate Fiori Elements into our application development process? I could spend time explaining but much more adept authors like Jocelyn Dart have already put in the effort.

A Brief Explanation of SAP-Specific and Vocabulary-Based Annotations

OData services generated within the Gateway Service Builder (transaction SEGW) before 7.50 were based on version 2.0 of the OData protocol. This version predates the concept of service annotations and, thus, compromises were to be made to integrate this form of semantic enrichment into the metadata model. This gave rise to SAP-specific annotations that commonly use the XML namespace prefix of, you guessed it, “sap”. Although these annotations will most likely be disregarded by non-SAP client-side frameworks and libraries, SAP technologies like that of SAPUI5 can make use of them and benefit from the extra semantic and functional service data.

SAP Annotation Example with a Service’s Metadata (EDMX)

Based on the OData documentation for the use of vocabularies annotations, the intent is to provide for a method of defining extensibility points in OData. These extensions can be applied to the metadata to annotate a service, entity, function import or other general element or to that of a specific instance of a collection that is returned from a service akin to field control and assigning a property of a specific instance as read-only.

Outside of those OData 4.0 base vocabulary components, you may create your own to fill any gaps or to facilitate any custom functionality. This is exactly what SAP did in the creation of their complementary vocabulary components which have a great impact on shaping the behavior of applications built with Fiori Elements. One OData 4.0 vocabulary that will be heavily leveraged is that of SAP UI and SAP Common.

Vocabulary Annotation Example from a Local Annotation File

Going forward with OData 4.0, SAP will be able to translate SAP-specific annotations into that of the new standard and be rid of these non-standard annotations. For the examples in this article, we will be leveraging both vocabulary-based and SAP-specific annotations to achieve targeted user interface behaviors within our Fiori Element application.

To learn more about the progression of enriching the metadata model for OData services, please refer to this blog entry by Ralf Handl of SAP.

In the next two installments we will walk through leveraging annotations to configuring the Smart Filter Bar in a Fiori Elements List Report Floorplan.

For other articles in this series, please refer to the list below:

Some Resources to Consider

To report this post you need to login first.

9 Comments

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

  1. Vivek Tiwari

    Hi, Thanks for the post.

    I have a question regarding the UI annotations from o-data and other sources.

    Regarding the other SAP.UI and SAP.common “complimentary annotations”.  I see these under the <Annotations> tag in the $metadata.  But in any FIORI launchpad application, I see annotations are also supplied from

    (i) – CATALOG SERVICE Url’s -> URLs are something like this
    “*/sap/opu/odata/IWFND/CATALOGSERVICE;v=2/Annotations(TechnicalName=’SOME_NAME’,Version=’0001′,SAP__Origin=’LOCAL’)/$value”;”
    ii) – annotations.xml -> application specific annotations provided by javascript app developer.

    SAP UI5 somehow merges all the annotations from these resources and produce the UI.

    I am interested to know how is this done? Algorithm? Is there any documentation on this topic i.e. on these UI <Annotations>, their sources and merging?

    I have to understand this logic and extract this final set of annotations in JAVA and I am looking for some library (o-lingo doesn’t understand <Annotations> and does not talk with other sources of annotations) – I am exploring XScript and other xml parsers but I would really help to understand the algorithm that javascript uses to merge and understand these annotations.

    Any clue/direction will be greatly appreciated.

    Thanks,

    Vivek

     

    (1) 
    1. Joe Rupert Post author

      Hi Vivek,

      Yes, you can leverage a local annotation, have an independent vocabulary service or nest your vocabulary annotations within your service’s metadata model and Fiori Elements does merge them with some limitations. As to what is going on under the covers, I have not researched this enough but may do so for a future blog post.

      I’m sorry I cannot be of assistance at this time but your objective is something I’m toying around with in other stacks. The concept of enriching the metadata model to dictate UI behavior is quite interesting and I’m sure could be carried out in a number of ways (following vocabulary standards).

      Good luck with your work,

      Joe

      (1) 
      1. Vivek Tiwari

        Hi Joe,

        Thanks for the reply.  It’s good to know that other people are interested in this area.  I will be following your blogs and hope you will have to share more n this topic in near future.

         

        Best Regards,

        Vivek

        (1) 
  2. Jocelyn Dart

    Hi Joe

    Firstly it’s fantastic to have another voice blogging on the topic and thanks for the shout out!

    If I may return the compliment you are blogging at a level many developers I know will appreciate & that is enormously helpful for those who like to understand how the OData paradigm & other nuts & bolts support this option.

    Appreciate it if you would also add your blog to our Fiori elements wiki https://wiki.scn.sap.com/wiki/display/Fiori/Fiori+Elements along with any resources you have found that I may have missed.

    Keep going!

    Jocelyn

    (1) 
    1. Joe Rupert Post author

      Hi Jocelyn,

      You are too kind, thank you!

      I will see where this series fits in your wiki and add it very soon.

      Thank you again!

      Joe

      (1) 
  3. Syam Babu

    Hi Joe,

     Excellent blog on Annotations 😀 

    I have quick questions here.

    Is that annotations are feteching from the backend/Frontend system based on this URL : “*/sap/opu/odata/IWFND/CATALOGSERVICE;v=2/Annotations(TechnicalName=’SOME_NAME’,Version=’0001′,SAP__Origin=’LOCAL’)/$value”

    Thanks,

    Syam

    (1) 
    1. Joe Rupert Post author

      I hope I am understanding your question but the resource you are providing is a catalog service URL and represents a standalone annotations. Refer to the following blog: https://blogs.sap.com/2014/08/16/create-standalone-annotation-using-sap-gateway-service-builder/

      Take care,

      Joe

      (0) 

Leave a Reply