Five things I learned as an SAP Fiori developer

5 min readDec 8, 2022

SAP Fiori is a GUI framework that provides users with a better experience when interacting with SAP Solutions. Traditionally, SAP implementations have received great acceptance regarding the system’s robustness, scalability, and business coverage. However, user experience was often left behind, preventing companies from taking full advantage of the SAP platform. SAP Fiori has been the answer to this problem, allowing a custom-made, easy-to-navigate user experience tailored to each company’s needs.

After spending the better part of this year developing Fiori Apps, I would like to present five things that took me an unexpectedly long time and effort to learn.

1.- It is highly tied to SAP’s traditional programming paradigm.

It might seem like a no-brainer, but it was a little bit of a surprise for me. SAP Fiori is sometimes touted as a completely independent library for building front-end applications. However, in my experience, it still relies on SAP infrastructure to perform basic actions, such as route guarding or runtime configuration. An SAP Fiori app always assumes it is running behind SAP facilities like user authentication.

This approach differs from other frameworks, such as Vue.js or Angular, where routing and guarding are an essential part of the facilities provided to developers.

It reminds me of the SAP WebDynpro paradigm, where web applications were conceived to be deployed as part of SAP solutions, not as standalone services.

2.- Everything is a model.

Consider the following example, where a firebase connection is being initialized, and then authentication established for later use throughout the application:

sap.ui.define([
 "sap/ui/model/json/JSONModel",
], function (JSONModel) {
 "use strict";

    const firebaseConfig = {
          // Here goes your traditional firebase credentials
        };

 return {
  initializeFirebase: function () {
   var app = firebase.initializeApp(firebaseConfig);
   const fireAuth = firebase.auth()
   const oFirebase = {
    fireAuth: fireAuth
   };
   var fbModel = new JSONModel(oFirebase);
   return fbModel;
  }
 };
});

We must later declare it during the app initialization routine and other required services. In this case, we also see the initialization of a MongoDB connection:

sap.ui.define([
        "sap/ui/core/UIComponent",
        "sap/ui/Device",
        "com/langure/MetadatosFiori/model/models",
        "./Firebase",
        "./Mongodb",
    ],
    function (UIComponent, Device, models, Firebase, Mongodb) {
        "use strict";

        return UIComponent.extend("com.langure.MetadatosFiori.Component", {
            metadata: {
                manifest: "json"
            },

            init: function () {
                UIComponent.prototype.init.apply(this, arguments);
                this.getRouter().initialize();
                this.setModel(models.createDeviceModel(), "device");
                this.setModel(Firebase.initializeFirebase(), "firebase");
                this.setModel(Mongodb.initializeMongodb(), "mongodb");
            }
        });
    }
);

Typically, authentication in Fiori apps is implicitly delegated to the SAP runtime it is contained in. But, for this example, I am using Firebase authentication, as this Fiori app should also work standalone. A Login.controller.js is created, and the action after setting the user’s credentials goes as follows:

const fireAuth = this.getModel("firebase").getProperty("/fireAuth");
fireAuth.signInWithEmailAndPassword(data.usuario, data.password)
.then((userCredential) => {
    var oAuthData = {
        currentUser:{
            authenticated : true,
            token : userCredential    
        }
    };

Notice how the fireAuth object is being stored and retrieved as any other model in SAP Fiori, using the standard method getProperty(). So, the lesson here is that models can store complex objects in addition to text-based properties.

3.- An Open-Source community

Even though SAP Fiori is proprietary (as it requires licensing), SAP also provides an open-source equivalent called OpenUI5, which is somewhat portable to the paid runtime. However, it was a pleasant surprise to find out about a whole open-source community around SAP, a company that is commonly known to be closed and, well, proprietary.

Open-source projects include a managed Kubernetes service (SAP Gardener), a cloud-native application runtime (SAP Kyma), and even an SAP Fiori theme for other application frameworks such as Vue.js, Angular and React, called SAP Fundamental Library Styles.

For SAP OpenUI5 applications, there is a scaffolding tool called Easy UI5 Generator that creates an empty app with all the bootstrapping and directory structure in place. Unfortunately, this tool assumes a lot of knowledge of SAP Fiori / OpenUI inner workings, and I would discourage its use for beginners. For reference, these are the commands I would use for a brand new project (notice the --config parameter that was not mentioned in the documentation):

yo easy-ui5 project
cd <DIR>
npm start
ui5 serve --config=uimodule/ui5.yaml 
ui5 build -a --config=uimodule/ui5.yaml

4.- Create once, use multiple times

I found out that controllers in SAP Fiori are continuously recycled, which means using its lifecycle hooks is a little finicky. Let’s look at the following example, where validation is required every time a specific view appears on the screen:

return Controller.extend("com.langure.MetadatosFiori.controller.Home", {
  onInit(){      
    const routingInterceptor = this.getOwnerComponent().
                                      getRouter().
                                      getRoute("Home");
    routingInterceptor.attachPatternMatched(this.forceInitializeController,
                                              this);
  },
  forceInitializeController (event){
      var authenticated = localStorage.getItem("user_auth");
      if(!authenticated){
          this.getRouter().navTo("Login");            
      }
      // else... keep processing
})}}

To solve this particular situation, I created the method called forceInitializeController() that gets subscribed to as the routingInterceptor variable. This subscription is done by the attachPatternMatched() and forces the contents of the callback to be executed every time this navigation gets triggered.

5.- 100% client side

Working with other web app frameworks, a developer can rely on some processing done server-side, such as rendering a specific view before being sent to the client or data pre-processing. In my case, I was required to read a collection from a MongoDB server, display it as a table and enable the users to download it as a JSON file. There is no application server in between, as the SAP Fiori apps can run entirely client-side, hosted by a static HTTP server.

In other words, the data handling and export must also be done client-side.

onGetJSON(){
  var blob = new Blob(["Data as Json"], 
                      {type: "text/plain;charset=utf-8"});
  saveAs(blob, "data.json");
},

In this example, I used the Blob library to create the file and allow the user to download it. Since it’s also javascript-based, the data can be easily obtained from the corresponding oModel inside the Fiori App.

SAP Fiori is quite an exciting paradigm for modular web applications. It allows the developers to discover and inject general configurations during runtime (as these apps are supposed to be executed in the context of an SAP Fiori Workbench). Therefore, all the server-side logic is wholly isolated from the view and heavily enforced by design. The UX provided by the graphical components is consistent, rich, and user-friendly. I would say that developers coming from other frameworks, such as Angular or Vue.js, should be able to adapt, but they would definitely benefit from having an SAP background.