Explaining the Architecture of Fiori

Elements

Objectives

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

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.

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

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

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.

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 a 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. This means 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.
Explaining Templates for Fiori Elements

Objectives

After completing this lesson, you will be able to:

 Identify the different templates of SAP Fiori Elements

Templates of SAP Fiori Elements

The current templates for SAP Fiori elements are as follows:

 List Report
 Object Page
 Analytic List Page
 Overview Page
 Worklist Page
Let's look at each of these templates more closely.

List Report

With a list report, users can view and work with a large set of items. This floorplan offers
powerful features for finding and acting on relevant items. It is often used as an entry
point for navigating to the item details, which are usually shown on an Object Page .

Use the list report floorplan if:

  Users need to find and act on relevant items within a large set of items by
searching, filtering, sorting, and grouping.
 You want to let users display the whole dataset using different visualizations (for
example, as a table or as a chart), but no interactions are required between
these visualizations. An example use case might be reporting.
 Users need to work with multiple views of the same content, for example on
items that are "Open", "In Process", or "Completed". You want to let users switch
views using tabs, segmented buttons, or a select control.
 Drilldown is rarely or never used, or is only available via navigation to another
page, and not as free or flexible drilldown within the page itself.
 Users work on different kinds of items.
Do not use the list page floorplan if: Use instead:
Object page
Users need to see or edit one item with all its details.
floorplan
Worklist
Users need to work through a comparably small set of items.
floorplan
Users need to extract knowledge or insights from data, either to better
understand the current situation, or to identify the root cause for a certain
value.

Charts are not only used for visualization. Users need to switch between
Analytical list
integrated chart and table views (hybrid view).
page
Users need to see the impact of their action on a KPI.

Users need to see not only the result, but also the impact of their filter settings
directly in a chart representation
From that, we can use the List Report as replacement of ALV in SAP GUI. Lots of ABAP
queries created by SQVI and ALV-based ABAP reports can be replaced by List Report.

Object Page

The object page floorplan is used to display and categorize all relevant information
about an object. Categorized content can be accessed quickly using anchor or tab
navigation, and users can switch from display to edit mode to change the content. To
create a new object, users can switch to create mode.

The object page floorplan comes with a flexible, responsive layout and a dynamic page
header that can be adapted to display simple and complex business objects. This
allows you to adjust the layout to a wide range of use cases.
Use the object page floorplan if:

 Users need to display, create, or edit an object.

 Users need to get an overview of an object and interact with different parts of the
object.
Do not use the object page floorplan if: Use instead:
 Users need to edit several items at the same time.
List report
 Users need to find relevant items without knowing the exact item
floorplan
details.
 Users need to be guided through a series of steps when a new object is
created. Wizard
 The creation process for a new object is not linear, but can have floorplan
different paths, depending on the information selected.
 Users need a way to analyze data step by step from different
perspectives. They need to drill down to investigate a root cause and act
Analytical list
on transactional content within one page.
page
 Users need to interact with interdependent chart and table views (rather
than using charts for visualization only).

Overview Page

The overview page (OVP) is a data-driven SAP Fiori app type and floorplan that
provides all of the information a user needs in a single page, based on the user’s
specific domain or role. It allows the user to focus on the most important tasks, and
view, filter, and react to information quickly.

Each task or topic is represented by a card (or content container). The overview page
acts as a UI framework for organizing multiple cards on a single page.
The Overview page is based on SAP Fiori elements technology and uses annotated
views of app data, meaning that the app content can be tailored to the domain or role.
Different types of cards allow you to visualize information in an attractive and efficient
way.

An Overview page is a data-driven SAP Fiori application built using SAPUI5 technology,
OData services, and annotations for organizing large amounts of information.

Use the overview page if:

 You want to provide an entry-level view of content related to a specific domain or

role.
 Users need to filter and react to information from at least two different
applications to complete their role-specific tasks.
 You want to offer different information formats (such as charts, lists, and tables)
on a single page.
 You plan to have at least three cards. These cards should not all be of the same
type.
Do not use the overview page floorplan if: Use instead:
A high-level or birds-eye view of application content is
sufficient
SAP Fiori launchpad home
You just want the user to launch an application
page
You want to show information about one object only.
Object page floorplan
You just represent one application and less than three cards.
Analytical List Page

The analytical list page (ALP) offers a unique way to analyze data step by step from
different perspectives, to investigate a root cause through drilldown, and to act on
transactional content. All of this can be done seamlessly within one page. The purpose
of the analytical list page is to identify interesting areas within datasets or significant
single instances using data visualization and business intelligence.

Visualizations help users to recognize facts and situations, and reduce the number of
interaction steps needed to gain insights or to identify significant single instances. Chart
visualization increases the joy of use, and enables users to spot relevant data quickly.

The main target group are users who work on transactional content. They benefit from
fully transparent business object data and direct access to business actions. In addition,
they have access to analytical views and functions without having to switch between
systems. These include KPIs, a visual filter where filter values are enriched by
measures and visualizations, and a combined table/chart view with drill-in capabilities
(hybrid view). Users can interact with the chart to dig deep into the data. The
visualization enables users to identify spikes, deviations, and abnormalities faster, and
allows them to take appropriate action right away.

Use the analytical list page if:

 Users need to extract key information to understand the current situation or

identify a root cause. The way the data is presented is crucial for giving them the
insights they need to take the right action.
  Users need a way to analyze data step by step from different perspectives,
investigate a root cause through drilldown, and act on transactional content
within one page.
 In addition to the filtered dataset, users need to see the impact of their filter
settings in a chart (visual filter).
 Users need to switch between integrated chart and table views (hybrid view).
 Users need to see the impact of their action on a global key performance
indicator (KPI).
 Users need to find and act on relevant items out of a large set of items by
searching, filtering, sorting, grouping, drilling down, and slicing and dicing
Do not use the analytical list page floorplan if: Use instead:
 Drilldown is rarely used, not used at all, or is only needed after navigating
to another page, rather than as free or flexible drilldown within the page
itself..
 Users need different visualizations for the entire dataset (for example, as a
table or chart), but don’t need to work with both visualizations on the
same page (for example, in a reporting scenario).
 Users need to find and act on relevant items from within a large set of
List report
items by searching, filtering, sorting, and grouping, without using
floorplan
drilldown or "slice and dice".
 Users need to work with multiple views of the same content, for example,
on items that are "Open", "In Process", or "Completed". They want to be
able to switch views using tabs, segmented buttons, or a select control. In
this case, consider using a list report.
 Users have a trivial use case that does require the use of a chart, but that
do not involve identifying a root cause, analyzing data, or drilldown.
 Users need to find a specific item, and the item or an identifying data
point is known to the user (such as a code). In this case, use the initial
Initial Page
page floorplan.
floorplan
 The creation process for a new object is not linear, but can have different
paths, depending on the information selected.
 Users need to work through a comparably small set of items, one by one.
Worklist
 Users need to interact with interdependent chart and table views (rather
floorplan
than using charts for visualization only).

Worklist Page

A worklist displays a collection of items a user needs to process. Working through the
list usually involves reviewing details of the items and taking action. In most cases, the
user has to either complete a work item or delegate it.

The worklist is a versatile floorplan that offers three main variants: a simple worklist
(plain page with a table), a worklist with tabs, and a worklist with one or more KPI tags.
These variants are based on different user needs and use cases.
Use the worklist floorplan if:

 Users have numerous work items and need to decide which ones to process first.
 You want to give users a direct entry point for taking action on work items.
 Users need to work with multiple views of the same content (for example, items
that are "Open", "In Process", or "Completed"). You want to offer tabs for
switching between views.
Do not use the worklist page floorplan if: Use instead:
The items you are showing are not work items.
You want to show large item lists, or combine different data visualizations
(charts or tables).
List report
floorplan
Users need to find and act on relevant items from within a large set of items
by searching, filtering, sorting, and grouping.

Exploring the Basic Process of Building

Fiori Elements Application
Objectives

After completing this lesson, you will be able to:

 List the basic process steps of building SAP Fiori Elements applications

Building SAP Fiori Elements Applications Process

Navigate through this activity to learn the basic process steps for building a SAP Fiori
elements application.

Note
The process is not 100% the same for all templates. Here, we only take List Report as
an example. Processes for other templates will be discussed in later units.

To Create an SAP Fiori Elements Application

Steps

1. Create an SAP Fiori elements application.

2. Choose an OData service.
3. Create an annotation file and writing annotation.
4. Modify the configuration file.
5. Translate resource bundles.
6. Deploy your SAP Fiori elements application.
7. Configure SAP Fiori launchpad.
8. Authorize user to access the SAP Fiori application.
9. Log on to SAP Fiori launchpad and add the tile to the SAP Fiori launchpad.

Using the Core Data Services (CDS)

View
Objectives

After completing this lesson, you will be able to:

 Describe the usage of CDS view

The Core Data Services (CDS) View

The ABAP Core Data Services (ABAP CDS) are the platform-independent
implementation of the general CDS concept for AS ABAP. The ABAP CDS makes it
possible to define semantic data models on the standard AS ABAP database. Unlike the
SAP HANA-specific variant HANA CDS, the ABAP CDS are independent of the
database system.

The entities of the models defined in ABAP CDS provide enhanced access functions
compared with existing database tables and views defined in ABAP Dictionary, making
it possible to optimize Open SQL-based applications. This is particularly clear when an
AS ABAP uses an SAP HANA database, since its in-memory characteristics can be
implemented in an optimum manner.

Note
The purpose of this lesson is to let you gain a basic understand of CDS.

For detailed knowledge of CDS, please refer to course S4D430.

Basic Syntax of CDS

A basic CDS defines a view. The definition of CDS uses SQL like syntax.

Annotations for CDS Views

In the figure below, we use ABAP annotations and UI annotations. As an example, the
ABAP annotations @OData.publish:true ensures that an OData service is created when
the CDS view is activated. The annotations @UI.lineItem ensures that a column is
created.

CDS annotations are extra information to describe the data. They let the consumer of
the CDS view know how to use data from the CDS view.

Annotations are grouped according to usage. The figure above shows the most relevant
groups of association for SAP Fiori elements.

To have full knowledge of CDS annotations, you can access the CDS annotation
document. Search for ABAP Programming Model for SAP Fiori on the Sap Help
Portal.
Follow these steps:

1. Go to SAP Help.
2. Search "ABAP Programming Model for SAP Fiori" and press Enter.
3. Choose the correct result according your Kernel version.
4. Click "Reference" on left bottom of the screen.

Annotation Syntax: Structure Type

If an annotation term represents a structure, two options are available for writing the
annotation.

Let's explore!

Both syntax have same meaning and can be used in combination, such as
@UI.headerInfo.title: { value: 'SalesOrderID' }

If an annotation term represents an array, the only option is to use a JSON array.

Annotation Syntax: Array Type

Key features of this syntax are:

 "{ }" represent a structure.

 "[ ]" represent an array.
 Use ":" to separate property name and its value.
  Use "," to separate properties.
 In most cases, each line should have a property called "qualifier" to identify it.

In some cases, a term is an array type, but most of its usage only has single line of
record.

In this situation, you can use object style to simplify the input.

CDS Associations

A CDS view can define some associations. An association is a declaration of the

relationship of views which can be consumed by itself or by the consumer of this CDS
view.

Usually, you need to define some reusable CDS views, which define associations as a
representation of the business entity. Then you can write a consumption CDS view,
which uses the interface view as its data source, to consume the data and associations.

In the figure, Interface View 1 has two associations connected to Interface View 3 and
Interface View 2.

When Consumption View 1 accesses the data of interface View 1, it can do the
following:
  Access fields of Interface View 1.
 Access fields of Interface View 2 through association 1 of interface View 1.
 Expose Association 2 of Interface View 1 again, to let the consumer of this view
have the ability to access fields of Interface View 3.
There are three main areas of an association. Let's look at each of them.
Using the Service Adaption Definition
Language (SADL)

Objectives

After completing this lesson, you will be able to:

 Explain the usage of SADL for publishing CDS views to an Odata service

Service Adaptation Definition Language (SADL)

This video provides an overview of the relationship between CDS View and OData
Service.

All SAP Fiori elements related annotations are translated to OData annotations. In this
way, you can combine your business logic, OData service development, and annotation
into one CDS view.

CDS as an OData Service

If a CDS view has the annotation "@Odata.Publish:true", an OData service is generated

automatically in your back end system. The only thing you need to do is to activate it in
your front end system.

Each OData service, no matter how it was developed, must be activated in

transaction/IWFND/MAINT_SERVICE so that it can be queried externally.

The CDS view you are working on is transformed to an EntitySet with a name identical
to the generated OData service.
All CDS views associated to this view are also transformed to an EntitySet. The
association relationship is transformed to the Association and Navigation Property in the
OData service.

Creating an OData Service by Referencing a CDS

In SAP Gateway Service Builder, you can reference an existing CDS view. Then, you
can add associated CDS views selectively. Even associations of associated views can
be added to your OData Service.

You can then override MPC or DPC standard implementation to add write support and
advanced OData features for the OData Service.

Relationship Between CDS Annotation and OData Annotation

In the figure below, we see on the left side the CDS UI annotations @Ui.lineItem to
create columns. @UI.identification represents an ordered collection of specific data
fields that together with headerInfo identifies an entity to an end user.
@UI.selectionField annotation allows filtering a list of data. This annotation is usually
used in an initial page floorplan as filter bar. On the right side we see the transformation
of the CDS annotations into OData annotations.
Like OData Annotations, CDS Annotations can apply on an EntitySet or a data field.

In most cases, there is a 1:1 relationship between an OData annotation term and a CDS
annotation with a similar name.

CDS Annotations are grouped by target. Annotations with the same target stay together.

OData Annotations do not have a fixed position. It is usually grouped by terms.

When translated to an OData annotation, the sequence of CDS annotations belonging

to one term is determined by a position property.
Explaining Metadata Extension

Objectives

After completing this lesson, you will be able to:

 List the steps for implementing a metadata extension

Metadata Extension
The syntax of CDS will grow if complex annotations are needed. That may reduce the
readability of CDS.

A metadata extension separates annotation from business logic.

Perform the following steps to implement a metadata extension:

1. Add an annotation of @metadata.allExtensions:true to the CDS view.

2. Create a Metadata extension and write annotations for the view and its fields.
3. Use ";" to separate fields.

Note
Metadata extensions only allow annotation of JSON style.
Some annotations relevant to the activation of CDS, like @odata.publish,
@AbapCatalog.sqlViewName are not supported in a metadata extension.
 Note
If there is more than one metadata extension annotation for the same CDS, refer
to https://help.sap.com/doc/abapdocu_752_index_htm/7.52/en-US/abencds_meta_data
_extension_eval.htm to know how to determine which metadata extension is used.

Learning Scenarios of Fiori Elements

Implementation
Objectives

After completing this lesson, you will be able to:

 List the scenarios for SAP Fiori Elements implementation

Scenarios
System Requirements for SAP Fiori Elements Development with SADL

To use SAP Fiori elements in SAP NetWeaver AS ABAP, the minimum version of SAP
NetWeaver is 7.50 SP01, otherwise the SADL will not work.

Many new annotations are added in each upgrade of SAP NetWeaver. Hence, SAP
Fiori elements will be more powerful if you choose the newest version of SAP
NetWeaver.

In general, CDS works on any database, but SAP HANA is recommended when good
performance is needed, due to CDS push down the calculation to the DB layer.

System Requirements for SAP Fiori Elements Development with Local

Annotation

When writing annotation as a local file using SAP WebIDE, SAP Fiori elements works
with any OData service, even from non-SAP back end.

If SAPUI5 runs on a non-ABAP platform like SAP CP, or you're using OpenUI5, SAP
Fiori elements only requires the version of SAPUI5/OpenUI5.
If SAPUI5 runs on ABAP platform, SAP Fiori elements require version of SAP_UI.

SADL vs Local Annotation