Explaining the Architecture of Fiori Elements

Objectives
After completing this lesson, you will be able to:

After completing this lesson, you will be able to:

  • Describe the advantages of using SAP Fiori Elements for SAP Fiori app development
  • Describe the concept of adding annotations to OData services
  • Define smart controls

Introduction to Fiori Elements

Getting Started with 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 frontend 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 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.

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 will save you lots of effort of 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.

Evolution of Fiori Elements

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

We are very proud to say that 80% of the Fiori apps that SAP delivers for SAP S/4HANA has 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.

SAP Fiori Elements Page Types

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 for OData Services

OData is a standard protocol for creating and consuming data by using simple HTTP and REST APIs for create, read, update, delete (CRUD) operations. This also enables the integration of data from a wide variety of sources - users can consume their data securely and quickly at any time and from anywhere. OData is the default way to communicate with an SAP back-end, be it for an SAPUI5 front-end or any other integration scenario.

An important thing to know is that SAP Fiori elements generates the application at runtime by combining three fundamental building blocks: OData services, OData annotations and SAP Fiori element page types.

Curious to learn more? Watch this video.

In the SAP world, the only OData versions that are relevant are V2 and V4. The V4 version was released in 2014.

Refer to the figure below for additional information on OData V4.

Annotations in OData V2 and OData V4

Annotations are descriptive information for OData Service.

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, and 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

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 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.

Target

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 particular entity type. Those annotations do not have a target, they should be contained in a group of annotations with a blank "" target.

Term and Qualifier

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.

Type Inheritance

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, so the latter has properties of the base type, with additional properties defined for itself.

Smart Controls

Smart controls are a specific category of SAPUI5 controls that have some special features in addition to the standard SAPUI5 features. This makes it easier to use the control in certain scenarios.

A primary example of such a feature is OData support: Typically, a smart control interprets OData metadata. In some cases, a smart control even persists an adapted version of the user interface that the user has defined for later usage.

Save progress to your learning plan by logging in or creating an account