Fiori App - POV of a Beginner

[Former Member]

In today’s UX world, the vision is to provide leading customer user experience ensuring that enterprise applications allow business to easily access the streamlined information which is scattered around multiple conventional GUI transactions/screen tabs via a single entry point in an attractive, coherent and simple manner.

In my Organization, we have started moving towards the path of adopting intuitive, role based and secure UX using SAP Fiori apps for the business applications which will be available across multiple platforms and helping the user to access and act upon real time data which will increase the productivity and brings a value to the business. 

During my UX journey (which is still quite new 🙂 ), i have developed couple of custom transactional Fiori apps and over the course of design & development process I realized that there few major aspects which one should consider thoroughly before & during the development cycle of a Fiori application. So, here below I am trying to document my point of views as a beginner on some of those items.

1) Design & Development Solution –
1.a) Discover & Design -  Discover and Design are two critical initial phases in a development cycle of Fiori app. In Discover, a user has been put first to understand the business process and their pain points, and in Design, initial prototypes/mockup screens are created addressing the issues/needs of a user.  Since, Design laid the foundation of a Fiori application so as an app designer one must follow the Fiori design guidelines to create interactive prototypes which should be validated with the end user to ensure that requirements are addressed properly – This step might require lot of iterations, but until and unless initial design gets validated Development should not be started. For more details on guidelines, please refer below link - Fiori Design Guidelines

1.b) Development - The onus to deliver a Fiori application meeting business requirements lies with both frontend and backend. No matter, how much coherent or responsive a Fiori app is but if it’s not meeting the functionality in a desired manner with an optimized performance then it will become an overhead.
Since, backend holds all the application and frontend the presentation logic so the approach of a development solution and its integration should be decided beforehand very carefully.
I would suggest to look some of the standard apps which have been delivered by SAP to understand the framework & methodology used (Note1). And, keeping that as a reference point try to design your development approach. And once you set an approach your development would be a smooth ride.

Note1 - You can directly import the UI5 code in WEBIDE or use export option by executing ‘/UI5/UI5_REPOSITORY_LOAD ‘ report on frontend server, for GW code import the project in 'SEGW' Tx and look for the functions/methods called for backend logic.

2) Understand the SAP WEBIDE Templates -
SAP has provided few built in templates which are nothing but a set of files with a specific structure and that can be utilized as a starting point for creating a new UI5 development project.
The SAP Web IDE (Integrated Development Environment) has a project template wizard, which makes it easy to create new applications quickly. I would suggest a fresher in a Fiori space to go through below link to understand the list of templates available.
WEBIDE Templates

The code which gets generated with each of these templates (Note2) will a good starting point to understand few of the critical concepts used in a SAP UI5 development like routing and navigations, basics of java script/jquery, coding standards, data binding etc.
SAPUI5 Essentials

Note2 - Bind existing oData service with the templates, in case it’s not available in your landscape then try to integrate ‘Northwind’ service.

3) Data container for an application –
The important facet of building an application using MVC concept is to choose a model which will hold the data for an application.
MVC Concept)

I believe for any beginner, opting an appropriate data container for an application is a tricky choice – Unfortunately, I learnt that in a hard way, had to switch an application model from server to client side during midway of my development 😞 ...
There are 4 different types of predefined models which can be used for handling a data in a FIORI application –

1. JSON (Client)


2. XML (Client)


3. Resource (Client)


4. oData (Server)

First 3 are client models and the last one is a server side. Most commonly, UI developers generally tend to opt between JSON or oData.
oData model is a server side model, which means that server will be holding the data and whenever a view is loaded then only the data will be requested. Also, it comes with out of the box functionality of sorting, filtering, pagination etc.
However, in case of a Json which is a client model, all the data will be loaded from the server and will be available for the application. Having said that, the sorting/filtering etc. needs to be done on the client side.

So, one should ask, which one is better and will fit to my application?
IMO, both are equally powerful but the answer depends upon the type of application you are creating whether it’s a display only application or it should also have the flexibility of manipulating the data. And, that’s the reason the choice of a model becomes more critical, and opting right model will eventually make the data binding job easy with an application.

So, if the application is for display purpose where it’s only going to provide the overview without any change functionality then I would suggest to go with server side (oData) approach, but when it comes to the app which should also provide the flexibility to change the data on the screen then both the model i.e. oData, Json can be used. What I noticed that, usage of oData model gets tricky when you have to deal with certain scenarios like adding a new item and displaying on the screen without committing it to the backend, similarly deleting a row from the screen w/o deleting from the backend, in these situations playing with oData gets complicated, so I would prefer to go with JSON model.


4) Test Strategy –
This is again one of the crucial phase post Fiori app development gets completed, and IMO it should be divided into three categories –

4.a) UI5 Testing – A comprehensive testing needs to be done for all SAP UI5 controls used in an application to ensure that they are compatible with your frontend [Note3] server version. Also, application compatibility and responsiveness test should be done with the popular browsers and devices which users will be using to access an application.

4.b) Functional Based Application Testing - A proper strategy needs to be designed to test the functionality of the enterprise application which should cover business driven scenarios.

4.c) Performance testing – Performance of an application should be measured to track the end to end response time. Preferably, one should try to define performance target definition after identifying the SLA of the transaction and then work towards reaching the same if it’s not meeting the standards. There are quite a few tools available which can help to analyze the performance of an applications by providing roundtrip response time, network traffic and traces such as Chrome developer tool, Fiddler etc.
https://help.sap.com/saphelp_uiaddon20/helpdata/en/b2/4e72443eb34d0fb7bf6940f2d697eb/content.htm
https://www.youtube.com/watch?v=CmIXJldq8J4

Note 3 – Since, SAP WEBIDE is continuously getting upgraded so it’s very much possible that the version of template used while developing custom Fiori apps may not match with the gateway version of your landscape and when you deploy that application certain key functions or controls doesn’t work. So, it’s always recommended to choose the templates version and UI5 controls which are compatible with the gateway so that will not cause any issues when application is deployed on the server. Also, at the same time try to ensure that the version of the gateway server is close to the latest from SAP by updating frequently so it’s not too far from WebIDE cloud version.

5) SAP UI5 & Coding standards -
During the UI5 development, I noticed that there’s enormous wealth already available on net and depending upon your problem the code snippets or suggestions shared by experts in other forums can be implemented.
But having said that, without understanding the impact of those references if you use it in your application then it could cause issues for instance performance. So, how one can avoid that?
Unfortunately, there is no short cut for this…Would suggest to go through below references to understand UI5/HTML/Java Scripts development standards and guidelines. Please check 'Must Read' section to find 'must read' references related to Java Scripts & HTML basics.
UI5 Development Toolkit
Development Guidelines
Buidling SAP Fiori-like UIs

6) Multi-phase approach -
Hope most would agree that the simpler the UI looks like the more complex is the logic which is written behind the layers specially if you are building a full fledged customized Fiori application.
So, that doesn’t mean that we should not follow the goal of developing user friendly UIs but instead of that try to adopt multiphase development approach wherein after having user’s consensus do a logical breakup of a complex business application (if one shot build is not possible) into subsets, and release each logical unit to the user so that they can start leveraging the app, share their feedback and in parallel continue enhancing it to reach to a final product.

Must Read References -
Java Script Essentials - JavaScript Basics
HTML Basics - HTML Essentials

To conclude, each organization has its own UX strategy and UI5 development approach but I hope, this blog would provide some details to a beginner in a fiori space about few of the major aspects of designing/building a UI5 solution. In case, any one of you have a similar experiences then please share the same.