Development Basics

SAPUI5 is the SAP user interface development toolkit for HTML5. Let's try to better understand SAPUI5.

Besides SAPUI5, SAP also provides OpenUI5 as a delivery of the UI development toolkit. The core containing all central functionality and the most commonly used control libraries are identical in both deliveries. Although very closely related, they have their differences:

OpenUI5

OpenUI5 is open source, free to use, released under the Apache 2.0 license. OpenUI5 provides all the important features needed to build feature-rich Web applications. The source is available on https://github.com/SAP/openui5/.

If you find a bug or have an idea for a new feature, you can propose a GitHub issue or a change. Please read the guidelines first: https://github.com/SAP/openui5/blob/master/CONTRIBUTING.md.

For more information, please visit https://openui5.org/.

SAPUI5

SAPUI5 is not a separate SAP product with a separate license. It is integrated in many SAP products. The first one was the AS ABAP 7.4, which included SAPUI5 in the UI technologies component SAP_UI.

The additional libraries in SAPUI5 include more controls on top of OpenUI5, like charts and smart controls. The exact feature range of SAPUI5 also depends on the platform.

For more information, please visit https://ui5.sap.com/ .

Technically, you can switch between OpenUI5 and SAPUI5 (provided you have a product where SAPUI5 is included). Please check first, which SAPUI5 version is needed. The version numbers of OpenUI5 and SAPUI5 might differ on patch level (last number).

A library bundles a set of controls and related types to make them consumable by Web applications. There are predefined and standard libraries with many commonly used controls:

• Responsive controls (sap.m)
• Smart controls (sap.ui.comp)
• Core controls (sap.ui.core)
• Layout controls (sap.ui.layout)
• Table-like controls (sap.ui.table)

The core library (technically, this is the sap.ui.core library) defines a core set of types that can be used in other libraries. Developers can create their own custom UI libraries, making it easy to use their own controls alongside predefined controls.

The Model View Controller (MVC) concept separates the tasks in an application into three programmatic elements:

Model

View

Controller

In SAP Fiori, views are defined using XML. The only SAP Fiori app that uses HTML is the SAP Fiori launchpad, which provides a frame for the XML-based views. Controllers are developed using JavaScript and are either bound to a view or standalone to be used by multiple views. Data binding can be used on the views to connect to data in the models.

SAPUI5 provides updates on a regular basis through maintenance and innovation versions.

Watch the video to get an overview of SAPUI5 versions.

A full list of all SAPUI5 versions including their end of maintenance can be found under https://ui5.sap.com/versionoverview.html.

Which SAPUI5 versions are available on an Application Server ABAP is provided via https://<host>:<port>/sap/public/bc/ui5_ui5/index.html.

The version a running app is using is visible in the technical information dialog opened via CTRL+ALT+SHIFT+P on Microsoft Windows or via CTRL+ALT+OPTION+P on Apple Mac.

OData specifies a simple, yet powerful query language that allows a client to request arbitrary filtering, sorting, paging and so on. A client is able to express, via query string parameters, the amount and order of the data that an OData service returns for the resource identified by the URI. The names of all query string parameters defined by OData are prefixed with a "$" character.

First, the structure of the data transferred from the server to the client can be formatted, for example, in JSON or XML. The data volume can be reduced by filtering data sets and by selecting the relevant data properties only. Paging is another way to reduce data traffic. Sorting guarantees the right sequence of the entities within a requested entity set. A client can also instruct the server to include associated data entries in the response, which is called inlining. This technique avoids subsequent read operations.

The versions of OData are additive. New versions include features of previous versions in the same way as they were used back then. But they are enhanced with additional features. This also counts for query options. One exception here is "counting" because the two ways to count in OData V2 were combined in just one in OData V4.

In OData V4, data can also be searched and computed. Both require a specific implementation depending on the application scenario.

An OData request consists of a server address, service URI, entity set, and additional query options. There are many combinations of query options possible. A full documentation is available at http://www.odata.org.

The three phases of the development of an SAP Fiori application are data modeling, service building, and UI development.

Watch the video explaining the key steps of SAP Fiori development. 

Since SAP NetWeaver 7.0, it is possible to use SAP Gateway to build OData services that access arbitrary business data through existing ABAP frameworks (function modules, RFC, BAPI, SPI…). This can either be done through service development or through service generation using SAP Gateway Service Builder.

For the UI part, SAPUI5 apps are deployed as Business Server Pages (BSP) in the FES and run in the SAP Fiori launchpad (FLP).

Since SAP NetWeaver 7.40, it is possible to use CDS views as data source. SAP Gateway uses the Service Adaptation Definition Language (SADL) to access CDS views. There, everything is defined to read data from application tables, so no additional (ABAP) code must be written by any developer.

Requests that perform changes can be implemented using code-based implementation of the create, update, and delete method in the data provider extension (DPC_EXT) class. In addition since 7.50, CDS views referenced as data source in the SAP Gateway Service Builder can be combined with code-based implementation.

Since SAP NetWeaver 7.51 SP01, a first managed runtime is supported that leverages the Business Objects Processing Framework (BOPF). The business objects (ABAP classes) are generated based on appropriate annotations in the CDS view. They are implemented using code-based implementations to call existing APIs performing change requests to business data. This model is called ABAP Programming Model for SAP Fiori (CDS-based BOPF).

Since ABAP Platform 7.54, an enhanced managed runtime is available that leverages CDS behaviors. Therefore, the business objects of CDS-based BOPF are replaced by behavior definitions (ABAP interfaces) and behavior implementations (ABAP classes). This model is called ABAP RESTful Application Programming Model (RAP).

Code-based implementation can still be used to call existing custom code or if CDS views are not suitable to solve the business scenario.