Building SAP Fiori Apps can be mundane and boring work. Having to repeatedly code common interaction patterns and functionality for every application is a mindless task where time could be better spent improving the efficiency of the user and making their life a little more enjoyable (in the world of interacting with SAP).
Michael Golz, Chief Information Officer at SAP Americas, made a profound statement at the Newtown Square, headquarters of SAP America, for the SAP Cloud Platform & Design Innovation Customer Forum, when he said, “Take the work out of work”.
At the time Golz was giving a keynote on the SAP Intelligent Enterprise and how the SAP Cloud Platform (SCP) plays an integral part. However, as he clarified his meaning, it was immediately obvious that our IQX AppBuilder development platform does exactly that. It takes the mundane and boring work out of creating Fiori Applications for SAP.
Today, starting from scratch is unnecessary, slow and mundane. Low code, drag and drop capable development platforms with deep SAP integration are available and should be utilized. What they save in time, cost and coding frees teams up to focus on what is really valuable – business process efficiency, user experience and compliance. Or if using the latest buzz words, true ‘Digitalization’.
So, let’s take an example of building a basic Fiori app that stores some non-SAP data and needs the ability to attach some documents. Here are 5 basic tasks you need to perform before you even get started on the real functionality of the application. Included are also examples of where you could be saving time and costs by using the IQX AppBuilder for SAP Fiori development platform.
- Create Tables for Data Storage
- Create OData services for CRUD operations
- Create OData services for search helps (F4)
- Create OData services for server-side actions (e.g. Validation)
- Build pages (MVC) using XML or WebIDE layout designer
1. Create Tables for Data Storage
If you are dealing with data not stored in SAP, need to implement an approval process or have a collaborative data collection process, the chances are that you will need to create some tables (Z Tables) in SAP to store your application data.
This requires going into transaction code SE11 to build the necessary structures, data elements and table definitions that represent the data that your application will operate on.
Developers are forced to navigate to a different area in SAP from their development environment, taking additional steps in the development process that aren’t exactly rocket science but very time consuming.
2. Create OData Services for CRUD Operations
Fiori architecture dictates that any call to SAP for data retrieval or persistence be done through an OData service configured in your SAP Gateway system. This results in developers needing to go into transaction code SEGW and build the necessary services that will facilitate the C(reate) R(ead) U(pdate) and D(elete) operations on your data.
To fully implement these, you need to create the underlying MPC (Model Provider Class) and DPC (Data Provider Class) objects where the ABAP code to perform these data operations is written. SEGW isn’t exactly the simplest transaction in SAP to become proficient in and the fact that any data you need to read or write has to be exposed as an OData service adds a number of mind-numbing steps to your development.
3. Create OData Services for Search Helps (F4)
Search Helps are those fantastic little helpers on input fields that allow people to search for values in SAP by descriptive names rather than their codes. (e.g. Plant 1070 = “North America”). SAP works off the underlying codes, but most people like to deal with something that they can read and understand.
To implement this functionality, there are a number of steps that need to be taken.
- Firstly, an OData service needs to be created that will allow the Import and Export parameters to be transferred in and out of the SAP Search Help. That requires going into SEGW and either wrapping an existing SAP search help or building one from scratch.
Fiori focusses heavily on a major improvement of User Experience (UX). Although search helps don’t necessarily improve the UX that much, it’s almost a given that an application needs to make it easy for any user (SAP expert or not) to find the data they’re looking for. That means that most of the fields in your Fiori application will need search helps configured.
4. Create OData Services for Server-Side Actions (e.g. Validation)
As explained previously, any interaction between the web front end and SAP is done through OData services. We’ve covered the reading and writing of application data but that doesn’t include any other server-side functionality that needs to be implemented in ABAP such as simulating a Sales Order before posting.
5. Build Pages (MVC) using XML or WebIDE Layout Designer
User Interface (UI) design is a standard requirement but there are a lot of other things that happen throughout the design process. Not only are you designing what the screens look like, you are also binding the fields to your data model, setting up search helps and developing your controller to implement the required logic when actions occur.
“Take the work out of work” by accelerating standard development pieces and drive true digitalization value. Leverage the value Fiori can really bring to your organization when your app is deployed and in the hands of your business users.
Other Fiori App Features to Consider
This article only covers the basic development tasks for a custom Fiori app but there are a number of other features and functionalities that you will probably need to include in your Fiori app if you’re building for the business. Ask yourself if any of the following are features you may need to implement, as starting from scratch is unnecessary. IQX Business Solutions takes the work out of work with the business process focused features of the IQX AppBuilder development platform:
- Collaborative Data Entry – Often, a single business process can span multiple users and roles requiring an interim (staging) data store where the data resides during the individual interactions before it gets posted into the SAP transactions.
- Approval Workflow – To provide control and governance over your processes, an approval workflow needs to be configured and integrated with the Fiori application.
- Full Audit Trail – Visibility into exactly who provided information as well as the individual changes throughout the process are typical requirements of any business process.
- Cross Application Request List – Your application is done but what about giving your users a record of what they submitted, where it is in the approval workflow, or what is currently awaiting approval?
- Excel Integration – Fiori enhances the UX of your solutions but that shouldn’t mean that you force them to re-enter data manually when they already use Excel today.
- Process Analytics – Understanding how and when your applications are used as well as the bottlenecks in your approval flow are typically only thought of well after the app goes into production. This should be a standard capability for each of the apps you want to build.
- Save as Draft Capability – Large processes may require draft capabilities to allow users to work on the data when they can and have that stored securely until they are complete and ready to submit.
- Attachments – Capturing supporting documentation or your business process is crucial and not always an easy thing to implement in each of your Fiori apps.
Developing custom Fiori Apps doesn’t have to be mundane, repetitive work that takes months and require an extensive skill set. Explore a smarter way to empower your ABAP developers and SAP Functional consultants to be the driving force to sustainable Fiori apps and digitalization.