Objective
You may have a very specific use case that cannot be built using the standard SAP Fiori elements and the flexible programming model. In this case, we still recommend creating your app as an SAP Fiori elements app.
You can generate your app using the app generator by selecting a Custom Page (flexible programming model floorplan). This way, you will get all the FPM features and you will be able to use SAP Fiori tools.
SAP Fiori elements framework is based on SAPUI5 technology. You may be familiar with the Model View Controller concept in SAPUI5.
In the view, you can define the UI controls to be used in the UI.
The controller contains methods that define how models and views interact.
A model holds the data and provides methods to retrieve the data from the database and to set and update the data.
Thus, in a freestyle SAPUI5 app, you have to define the views and implement the methods needed in the controllers, for example, an event handler for a button if a user selects a button.
SAP Fiori elements framework generates views at runtime based on the predefined floorplans and your app-specific metadata and annotations. Thus, in the standard SAP Fiori elements applications, you do not have any static views or controllers in your project in the development environment.
If you use the extension points, a static xml fragment has to be added to the webapp/ext folder of your project. If needed, a controller will also be added. The Page Editor can generate both files, including an ext folder if not present yet.
Extension points are containers provided by SAP Fiori elements framework, which hook into the standard SAP Fiori elements runtime. There, you can add your specific UI controls or behaviors using the standard SAPUI5 programming model based on HTML5 and JavaScript.
In custom extensions, you can provide features that SAP Fiori elements does not offer, for example, process diagrams or maps.
Note: you can find the list of all extension points provided by SAP Fiori elements at Overview of Extension Points
Building blocks are reusable pieces of code that are consistently implemented in the SAP Fiori elements framework. If you use them, you can be sure that your app follows the SAP Fiori design guidelines and that the standard features, like draft handling or side effects, will be automatically supported in your building blocks. They are metadata driven, just like the floorplans.
Building blocks can also be used outside of the floorplans. You can use them in your custom applications, or in your custom extensions.
Building blocks are not SAPUI5 controls, but rather a set of templating instructions that are used to create a specific control tree, depending on the bound data structures.
Check the list of all available building blocks: Overview of Building Blocks
You may also check sap.fe.macros, a library of building blocks provided by SAP Fiori elements.
The Open Data Protocol (OData) includes the standard CRUD (Create, Read, Update and Delete) operations that map to the HTTP methods POST, GET, PUT/MERGE and DELETE.
In addition, OData supports further service operations (function imports) that can be invoked by the HTTP methods GET or POST for anything that cannot be mapped to the standard CRUD operations. You can implement the additional service operations in your back end.
In this training, you use CAP as your back end and you will create a function import within your CAP data model.
When you add a definition of the function import to your CAP data model, it becomes a part of the service metadata. You will find it in the $metadata document.
The screenshot above shows that the function import is added to the service container alongside the entity sets of the service.
In the same $metadata document, you can find the API of the function import.
As soon as the function import is part of $metadata, it can be used on the client side in your SAP Fiori elements application.