SAP Fiori Elements and its Architecture

SAP Fiori Elements is a framework comprising of templates for commonly used application patterns, for example List Report, Worklist, Object Page, Overview Page and Analytical list page.

Predefined templates combined with OData service and annotations generates SAP Fiori application at startup.

Benefits of creating application with SAP Fiori Element

• No JavaScript UI coding
• Apps are based on centrally provided templates (views and controllers), so no application-specific view instances are required.
• Ensures consistent UI across similar apps
• The metadata-driven development model eliminates front-code code effort, so the developer can focus on the business logic.

Annotations Concept

Descriptions added to OData metadata document is known as OData Annotation.

For SAP OData version 2.0, annotation is stored in XML tag of OData metadata. All SAP specified annotation are started with ‘sap:’.

In OData version 4.0, annotations are separated from the main part of the OData metadata document, either as a separate part in OData metadata document or stored in a separate file.

Annotations Vocabulary

The most commonly used vocabulary for Fiori Elements is UI vocabulary. Vocabulary defines how you can add annotations to an OData service.

Annotation Target

It is good practice to group annotation by targets. Targets associate a group of annotations to something in OData service. Generally, target of annotations will be an entity type or property or even association, function import or other objects in OData service.

Some annotations are nothing about data, or do not bind with particular entity type, those annotation do not have a target. Group of annotations that do not have a target should be contained in a group with a blank “” target.

Annotation Term and Qualifier

Target + Term + Qualifier is the unique identifier for an annotation. Qualifier can be omitted if Target + Term is unique.

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.

Annotation Term Definition in Vocabulary

Terms are defined in a vocabulary. The following Information is part of a term definition:

• Term Name: Then name of the term
• Data Type: If there is only one record in the term, write the name of the type. If the term may have multiple records, the Type attribute needs to be ‘Collection(<Data Type>)’
• Applied To: Defines which kinds of elements in OData service can be target of this term.
• Nullable: Default is true. Most annotations are nullable.
• Annotations to this term, user for development tools.

Annotations Complex type

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.

Annotation Type Inheritance

For better re-usability, inheritance of types is supported.

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

Data Type DataField* Series

A collection of data types starting with DataField are the foundation of UI annotations. Most terms and complex types have relationships with those datatypes since data fields are what end user sees, click and search. All types are inherit from DataFieldAbstract.

List of DataField* types

• DataFieldAbstract
• DataField
• DataFieldForAnnotation
• DataFieldWithAction
• DataFieldForAction
• DataFieldWithNavigationPath
• DataFieldWithURL
• DataFieldWithIntentBasedNavigation
• DataFieldForIntentBasedNavigation