Explaining the Architecture of Fiori Elements

SAP Fiori elements is a framework that comprises the most commonly used floorplan templates and is designed to:

• Speed up development by reducing the amount of front-end code needed to build SAP Fiori apps
• Ensure stable, optimized UI code out of the box
• Deliver high-quality SAPUI5 applications to end users
• Drive UX consistency and compliance with the latest SAP Fiori design guidelines

App developers can use SAP Fiori elements to create SAP Fiori applications based on OData services and annotations that don't need JavaScript UI coding. The resulting app uses predefined views and controllers that are provided centrally. This means that no application-specific view instances are required. SAPUI5 interprets Metadata and annotations of the underlying OData service and uses the corresponding views for the SAP Fiori app at start up.

SAP Fiori elements can be used in the different modern programming models as a UI technology. We will not discuss these models in this course. However, we already have courses on this topic on our learning platform that we would like to refer to.

• SAP Cloud Application Programming Model: https://learning.sap.com/learning-journey/building-side-by-side-extensions-on-sap-btp

• ABAP RESTful Application Programming Model:https://learning.sap.com/learning-journey/get-started-with-abap-programming-on-sap-btp/introducing-restful-application-programming_e86bbfde-50be-4c7b-8716-53bacc94c5a0

• You should also be familiar with SAP Business Application Studio. For this we can recommend you the following Learning Journey:https://learning.sap.com/learning-journey/discover-sap-business-technology-platform

This video gives you an overview of how SAP Fiori elements is used to create SAP Fiori applications.

Unlike traditional SAPUI5 development, detailed JavaScript knowledge is not mandatory for developing SAP Fiori elements applications. Since JavaScript is a flexible and totally dynamic language, and there is no compile time code check, code written by JavaScript has more chance of runtime error. SAP Fiori elements save a lot of effort within studying, writing, and debugging JavaScript code. This approach of developing SAP Fiori apps can also improve your overall quality, stability, and maintainability of your SAP Fiori apps, especially when you need lots of SAP Fiori apps.

When SAP started building SAP Fiori apps, it became clear early on that SAP needed a way to scale development across the organization.

80% of the Fiori apps that SAP delivers for SAP S/4HANA have been built with SAP Fiori elements.

SAP Fiori elements provide UI logic out of the box.

There is straightforward logic, like navigating between pages or apps, or the ability to search, sort, and filter lists. Additionally, there are more complex functions including editing with draft management, support for translation, and compatibility with mobile devices.

Most scenarios in the enterprise involve a variation of providing an overview on business-relevant data, various types of lists of this data, and managing the data. The SAP Fiori elements page types were developed to cover the majority of these use cases that we see in the ERP context.

Annotations are descriptive information for OData Service.

The OData V2 protocol allows you to add annotations to the metadata document. The purpose of the annotations is to add information and hints to the Entity Data Model elements. This structural metadata makes it easy to understand a service, and human-readable documentation can be directly embedded into the metadata document, helping developers consume an OData service. The added information can be used by the service clients (for example, SAPUI5 application) to better represent the service entities. The annotations are divided into annotation elements and annotation attributes, represented as XML elements and XML attributes, respectively.

With OData V4, you get a reduced amount of data, through a more powerful query language, a revised and optimized JSON protocol and a change in the metadata concept.

Located at the OData service root, the service document lists the top-level resources that are available. The metadata document, on the other hand, describes the structure of all resources in the OData service; the metadata document is located at the address $metadata relative to the OData service root.

The OData protocol defines the concept of the annotations without adding any details concerning the particular names and values, which can or should be used for them. In addition, SAP defines its own specific set of annotations.

Let's look at how annotations work in OData V2 and OData V4.

Vocabulary defines how you can add annotations to an OData service. All annotation files must start from references and give an alias to some vocabularies.

The form of vocabulary is an XML document containing information of Terms and Types.

In an SAP Fiori elements scenario, the most important vocabulary is UI vocabulary, it defines most of the annotations you can use in SAP Fiori elements. Other vocabularies, like Common and Communication, define annotations in specific domains and are used in several scenarios.

Annotations must be grouped by targets. Targets associate a group of annotations to something in OData service. As most annotations are data relevant, they try to target an entity type or property. In some cases, annotations target an Association, a Function Import, or other objects in OData service.

Some annotations are nothing about data, or do not bind with a particular entity type. Those annotations do not have a target, they should be contained in a group of annotations with a blank "" target.

All annotations must have a term. A term determines the meaning of an annotation. For example, term UI.FieldGroup defines a group of fields.

If you have two annotations with the same term for the same target, a qualifier must be added to make your annotation unique.

Terms are defined in a vocabulary. A term definition comprises the following Information:

Most terms are described by a complex type. A complex type can have properties, which are further described by other complex types, or OData built in types ( Edm.*) like string,int32,boolean.

Inheritance of types is supported for better re-usability.

In this example, DataFieldAbstract is an abstract data type ( Abstract = true ) and type DataFieldWithAction has a base type of DataFieldAbstract. This means the latter has properties of the base type with additional properties defined for itself.