If you want to be sure your Fiori application is optimized, efficient and will work seamlessly even after an SAP update – you must follow the best practices. To make it easy I have gathered and organised them into five categories. Stick to these rules and developing your applications will be easy and pleasant.
Table of content
Let us start with the most basic thing. One of the most important best practices is to use SAP WebIDE, a development environment provided by SAP. It works perfectly well with an on-premise SAP ERP system, as well as with SAP ERP on Cloud.
Thanks to WebIDE’s tools and templates, a Fiori developer can design an application quickly and efficiently. What is more, this solution also provides seamless integration with Git, and allows you to not only code frontend applications, but also solutions for databases, like SAP HANA. The most important advantage is that, since WebIDE is an SAP solution, it makes many actions much easier and faster. For example, with this environment, you can quickly add a new communication service, add a new extension point or refresh metadata. It all is just a click away!
Developers that work with other programming languages and non-SAP frontends may want to use different environments, like Eclipse or Visual Studio, but I advise against it. The very philosophy of SAP Fiori is to create applications that are intuitive, easy to use and seamlessly integrated with the SAP ERP system. With WebIDE, you can ensure all those characteristics – without any additional effort.
WebIDE is a great tool not only for advanced developers. It combines a programming tool with a visual layout, making it easy even for an SAP business consultant to make simple changes in the applications. You can import any out of nearly 500 standard applications and add to them custom features. It means that all tasks that are normally done by a developer (like hiding columns, changing the order of elements on the screen or adding conditions) now can be done by a business consultant, or by a person without an extended experience with Fiori.
An additional advantage of WebIDE over other development environments is that it performs minification on its own. You do not have to do it manually, which saves you a lot of time and reduces the risk of making mistakes in the code.
Choosing the right repository is one of the most important aspects when we start developing. But when you start working with SAP Fiori development, you usually do not think about storing the code. You know it is saved… somewhere. But according to the best practices, you should never edit the code that is in the system. Instead, you always must have a copy in the remote repository. Choosing the right repository is a key because if you make a correct choice, it will greatly facilitate your work later.
As I said, WebIDE provides integration with Git. What are the advantages of such a solution? First, if you make a mistake, it is as easy as loading the stored version. Secondly, a whole team of developers can work on the same file at the same time. Git’s algorithms are compiling all changes and merge them into one code.
We prepared our development environment. The next step is to set the standards and make sure to keep them during the whole process of creating Fiori apps.
There is no way around it – you must have it defined. If you want to develop SAP Fiori applications according to the best practices, then the naming convention needs to be the same between front- and backend, in all your solutions.
In SAP UI5, it should be adapted to the web solutions’ convention. What are the guidelines here? Use the camelCase – everyNextWord starting with a capital letter and no spaces between words. Use right prefixes for styling. A good idea is to use the SAP naming convention, or – if your company does not have it defined – to use the one prepared by your development team. At Hicron, we have our own convention, settled upon the SAP standard. Most clients are happy to adapt it since it is well-documented and consistent.
All SAP Fiori applications should be build based on data binding, which means data exchange between a model and SAP UI controllers. The goal is to have everything bound to a model. Think about the applications in a technical way: what a user can edit is controlled not by the application, but on the server-side – in SAP ERP system, on the backend. It is the data stored there that impact, what the user will see in the app. Bind each parameter, such as field visibility, field editability, bind these elements to the appropriate properties in the model and draw data from the backend to this model. It guarantees that every change in the application will happen in one place on the backend.
In this way, the data is not multiplicated and is always uploaded straight from the SAP ERP system. All fields are assigned to models. It might be a local, json or Odate model.
As a result, users do not have to type any details when filling a form. Instead, since the form is bound to data in SAP ERP system, all information is downloaded and automatically inserted into correct places. This is an example of one-way data binding.
CRUDQ is short for Create, Read, Update, Delete, Query. These are 5 basic actions of Odata service. We have also Function and Import, Associations and Navigations. The best practice of working with SAP Fiori I want to explain here is simple: use them.
The problem is, you can write applications without these actions, or with a minimal amount of them. But when you do that, your app is a mess. A developer that inherits such code wastes a lot of time trying to get into it.
So, how to operate with these methods? First, we have CRUDQ actions. Read reads a single line from a table, and Query searches in many tables at once. It seems logical: we want to create a record – we use “create”, we want to update it – we “update”, and so on. But what happens when we get to more abstract actions? Imagine that a user wants to accept a file in SAP Fiori application. Now, developers commonly decide to “update” and “create”, using the solution they know in a way that is simply wrong. Soon, they will want to really update something… and they will run out of methods.
What they should do instead, is to use the functioning pod, a thing that is available in Odata services. For some reason, it is very often omitted in the development. This is the method that lets you perform actions such as approve or enable.
The next thing, closely related to CRUDQ, are associations and navigation. They also can be defined in Odata service. All these elements run perfectly well with SAP Fiori – that is why I am putting such emphasis on them.
The operations are for connecting the data between the tables, using keys. If you use associations and navigations, your solution starts to run smoothly, without the need to code additional connections. When a user clicks into an item’s details in the table, the URL will be modified with a slash and the number of that item. Now, if the user wants to share this with their colleague, they only need to send a link. For the colleague, the link will work just fine – but only, if the associations and navigation were used.
It is all about designing your app in a very structured way. Everything is within the URL address – it sends the query to the backend, using navigation that is based on keys connecting the tables. If you design it right, the URL will always work, no matter who will use it – the user that clicked the item’s details, or their colleague.
Out of all best practices, the most important is to design and code applications so it works regardless of where we use it, or how. The principles we follow here are:
- accessibility on mobile devices;
- availability in different languages;
- intuitive layout.
We will start with mobility – the flagship of SAP Fiori.
The layout that works for desktops usually does not look well on mobile devices. When designing apps for users, you need to think beforehand about how your solution is going to be used. We need to know which tables and controls hide behind the buttons or in a drop-down menu, and which elements need to be accessible immediately.
When the layout is simple, it is possible to design only one layout in a responsive way. It will render itself according to the size of a screen. But when designing a more complicated application, with forms, popping up screens or search bars, then we need to design every layout separately. It is best to make using applications intuitive. That is why we do not want to force the user to zoom in or out on the mobile or scroll to find something. The layout must be clean and simple, with tiles organized in a way we know from Android or iOS operational systems.
It is personally surprising to me how many applications are supporting multiple languages. SAP provides a very efficient way to localise the application. In SAP UI5 you find a set of files, i18n. These are simple text files, contained on two lists of words – one in English, the other in a target language. The language is chosen based on the browser’s language, and the correct file loads automatically when the application launches.
SAP Fiori best practices demand that there is no text that is not translated to the user’s chosen language. There is no option that most of the app will be in French and some elements will be set in English without a possibility to change. All texts that the user can encounter has to be written in the i18n files.
SAP Fiori is all about the user experience. From SAP Fiori Launchpad to the look of tiles – everything has to make the apps intuitive and easy-to-use.
If in SAP S/4HANA a transaction for requests in MN21M system has 15 tabs and more than 30 fields to fill, then in SAP Fiori the same transaction has to be designed in a way that will not give a person new to accounting a headache. In SAP UI5 we will break this complicated transaction into stages and put each stage on a separate screen. We will keep a few tabs, make sure they all fit on the screen, but most importantly – we will design the app to guide the user through the process step by step. The app will ask for the required details and will not let the user proceed without filling them first. The process must be designed so the user will not face errors every time he missed some fields. User experience, in this case, has to be simplified – but that does not mean it will miss any important steps!
Compare the same order in two layouts:
Even colours have their meaning in SAP Fiori’s user experience. The philosophy is to keep pastel colours, so users working for many hours with the applications will not be overstimulated. Important fields or buttons use colours that evoke emotions – e.g. green for approved files, red for the files that were not approved and so on. It will make it easy to recognize, what is important, without making the system’s visuals too complicated.
After designing the architecture and visuals, our next step is to code it smartly. Smart here means using elements that do some of the development for us. These elements are controls in SAP. It is very interesting facilitation, especially for ABAP developers that start coding in Fiori. Some development is happening in the backend, but its effects are shown in the frontend – in SAP Fiori.
How to use smart controls? First, we build an Odata Service based on annotations. Annotations are parameters in metadata, that comes with the definition of the service and the data model to the frontend. The application can render the control for the date along with the calendar, format the amounts and so on. Additionally, if we are using a smart table instead of SAP Mtable, a standard Fiori table, we can define which fields can be used as search bars, which columns should be filtered or sorted and so on.
To do this, we do not define it in the transcript, or SML. We do not code in the frontend. Instead, we write the annotations in ABAP. The SAP UI5 engine will render the table for us – with filters, menu and any additional features we need.
When a user wants to filter the table using some value, our task as developers is to intercept this value, search the right data, and send it back to SAP Fiori. We do this by writing ALV in ABAP. In SAP UI5, there are controls that makes it much easier and faster, than it is usually in SAP S/4HANA or other ERPs.
Annotations can be in three places: in Odata service itself, in the Fiori apps themselves as a .xml file, and CDS view.
Using CDS view makes it even easier. Here, we actually write everything as a database query. The reporting applications that are meant to display only data can be defined simply as a select with parameters. We import the CDS view as an Odate service and it imports the annotation file. Then, we design an application based on this service… and that is it. We do not code anything, the app is up and running.
This is an affordable thing for low budget projects. If we are talking about a set of several reports, and you know that the budget will not be significant, then with a really small amount of effort, this technology can create sets of such reports in a flash.
Smart Controls give us a full set of visual tools that makes Fiori apps very pleasing to look at. For example, we have access to interactive charts, like pie or bar charts. For users to be able to see them, we have to implement it on the SAP UI5 side, so it is purely web coding plus Service Odate. It is worth it: when it comes to the area of Fi, accounting and controlling, with these wizard charts you can enrich any solution in a very nice way.
You know now how to design the application and how to make it efficient. The last part of SAP Fiori best practices is to keep working efficiently. A company like Hicron develops many applications, and some elements we design can be used again, with only a simple modification. Think about a simple search bar, that will look the same in most projects. Thanks to reusing the element, the project takes less time, and that means lesser costs.
But to be able to use these elements, you have to code it properly. In SAP UI5, it is a view saved as .xml. It does not depend on the application and is not connected with it; no file is its controller. In other words, it is a standalone element. Prepared that way, the element can be implemented into any project and will work just as good without any additional preparation.
The idea here is to get to the point when creating a solution will be about opening the repository, picking tiles and build the whole solution with them.
To act accordingly to the best practices, you must take care not to do anything that will damage the application in a long run. When working with global variables, do not use these objects in SAP UI CORE. Despite this place being accessible from any place and seemingly perfect for it, you cannot do this. This is the core of the whole SAP Fiori Launchpad. It is common for all apps. If you use a variable name that was previously used in a different application, you risk breaking it. You can overwrite something that is being used in many environments. Be aware of the damage you can inflict.
A better place for global variables is a component. Use components to initialize global variables, models, global settings. In the end, every element is connected to the component, here every solution is launched – so your variables will be available just as you wanted it.
The last thing to look at is extension points. When we expand SAP applications, we must use hooks. Hooks are places in the code, where SAP has planned the space for extensions. It is like extension points in SAP GUI.
If we expand the application using hooks, then the next SAP update will not be installed seamlessly and without any additional coding from your side. But if you decide to copy the SAP application, and then change its code outside of hooks, then with every update your solution can stop working.
Expanding it by changing the code is easier but multiplies the amount of work you will have to perform in the future endlessly. With hooks, after doing it once, you do not have to make any significant changes later.
Building applications for SAP S/4HANA or other SAP ERP is a great way to expand the possibilities of the system. If you stick to the rules I presented, then the development process will be efficient, productive and much easier than you might be thinking.
If you have any questions, want to know more about working with SAP Fiori environment or wish to see how SAP Fiori applications can expand SAP ERP system, talk to us via chat or the contact form! Our experts are ready to share their knowledge with you!
Author: Mateusz Pawłowski, SAP Full-Stack Developer