Alternatives to Fiori

It's about to get a bit technical, because we want to take a critical look at Fiori technology and compare it with the architecture of our own product "CIS mobile".

To understand this, it is helpful if you try out a few Fiori applications and our CIS mobile beforehand. Here are the links:

• http://sapfioritrial.com for Fiori apps
• http://s10mobile.com for CIS mobile

Each Fiori app is an isolated, small standard application function that is implemented as a web application with HTML5 as the front end. It can be run on any web-enabled device (desktop, tablet, smartphone).

All Fiori apps have the same user interface because they follow strict standards, in particular the "Fiori 1-1-3 UI": one user role, one scenario, three clicks. Each Fiori app falls into one of the categories "Transactional app", "Fact sheet" or "Analytical app", whereby only "Transactional" does not require a Hana database.

Technologically, the Fiori apps use several complex frameworks: the application runs as JavaScript code in the browser. It generates the HTML5 interface dynamically with SAP UI5, requires the JQuery framework and communicates with the FES (Fiori Frontend Server) via the OData protocol, SAP Web Dispatcher and SAP Gateway.

Finally, FES contacts the SAP Business Suite, which provides data access and update functions as stateless services in Abap. For our product CIS mobile, a comprehensive mobile web application for sales employees based on SAP SD, Fiori is not sufficient in terms of both the 1-1-3 UI and the technological infrastructure.

This is primarily due to the justified requirements of the users: a sales employee wants an integrated view of all aspects of the customers he is responsible for, such as quotations, orders, deliveries, scheduling, visit reports, contracts, bonus agreements and customer documents.

He expects diagrams and key figures and would like to report customer information back to the central SAP system on a mobile basis. This means that all three application types, "transactional", "fact sheet" and "analytical app", are required and a seamless transition of all components.

Sales efforts can be all the more successful the better you know the customer situation. This includes not only quotations and orders, but also customer complaints and outstanding invoices, for example. Fiori would be overwhelmed by this wealth of information with its 1-1-3 UI.

Even if it were possible to squeeze the application into the Fiori schema, operation would be very awkward, as the master-detail schema used in Fiori forces constant context switches with only particular views.

The UI in CIS mobile, on the other hand, is generally designed so that you can call up detailed information successively, which is then dynamically inserted into the displayed page. For example, you can display the order items for an order and then the conditions for the item.

Now do the same for another order item. Now you can compare the two items in detail simply by scrolling the page, which is more convenient and effortless than constantly navigating forwards/backwards and memorizing the displayed information yourself.

UI and technology

But couldn't Fiori technology also be used to implement completely different, more complex UI patterns? SAP is apparently planning to do so, as Fiori is set to gradually replace SAP GUI as the front end for S/4 Hana.

Will that work? If you take a closer look at the implementation of the Fiori apps, a lot of JavaScript is required here despite the small size of the applications. If you implement an application function comparable to the Fiori app in the classic Abap Dynpro way, much less coding is required. This is not very optimistic as far as future complex applications are concerned.

CIS-mobile technology

There are some similarities between our CIS mobile technology and Fiori, but there are significant differences. Like Fiori, we use HTML5 as the front end to support all web-enabled devices.

However, CIS mobile does not run the entire application in the browser, but only the UI part in the form of predefined HTML5 masks plus very sparingly used JavaScript for special UI functions.

The advantage of static HTML is that any normal HTML editor can be used to develop and WYSIWYG customize the interface, which is not the case with UI5.

The CIS-mobile application itself is located on a central Windows server with Microsoft IIS (Internet Information Services). It is implemented in VB.NET, which offers the advantage of a mature and convenient development environment (Visual Studio) in which, unlike JavaScript, we have all Windows options at our disposal, for example using temporary files or creating diagrams with graphics packages.

CIS mobile communicates with the SAP system via high-performance interfaces in the LAN, which are based on SAP RFC and SAP GUI. SAP Gateway and OData are also possible, but are not used in CIS mobile, as we also support older ERP systems and non-Unicode.

The data retrieval is realized in Abap function modules, the update of SAP data (e.g. appointments, contact persons, offers) via SAP GUI transactions (scripting), so that all SAP standard checks and updates are guaranteed.

All components of the CIS-mobile architecture are standard technologies (HTML5, VB.NET, IIS, Abap, RFC and SAP GUI), each of which already offers robust and rich functionality.

These components are combined in a relatively simple and obvious way to form an architecture that enables the development of sophisticated web applications in the SAP environment.

Server-side application

The server-side application offers many advantages: Firstly, security, because a JavaScript application in the browser can be manipulated by calling JavaScript debugging.

Secondly, we can keep frequently used read-only data on the server in a dedicated application cache, accessible by all user processes, which the application can access within microseconds.

Thirdly, convenient development, troubleshooting and stable continuous operation are easier to ensure on one server than with an architecture in which large parts of the application run on a large number of devices and software versions. Dispatching to several servers is available for large numbers of users.

The connection between HTML UI and VB.NET takes place per user action in a single round trip between the frontend and server. Several requests can then take place between the server and SAP system.

As the response time of a web request is on average more than ten times the LAN response time, this is a sensible strategy with which we achieve very good response times.

In a browser-based application, on the other hand, you have to make an effort not to trigger too many round trips to the server per user action, which usually means that the data interface of the called services becomes more and more extensive and has to be adapted for each additional piece of information.

The reuse of services by other apps becomes difficult because you either get too much information and the SAP system is unnecessarily overloaded or you have many specialized services but then need more round trips.

UI and application

The logical connection between HTML UI and VB.NET consists of mapping the HTML hierarchy to the object hierarchy in VB.NET. In total, the CIS-mobile application is realized in the form of around 200 VB.NET classes, whose names and content are mostly based on SAP business objects, e.g. sales items VBAP or plants T001W.

The attributes of the classes are addressed in the HTML interface via their names, which are collected by interpreting the DOM and sent to the server.

The evaluation of the class attributes and navigation within the object hierarchy on the server then takes place dynamically. Each VB.NET class can contribute its own UI parts in the form of HTML frames.

This allows us to achieve a certain independence of the UI from the application. For example, if the shipping point is displayed as code "1000" in the order item ("VSTEL") and the corresponding text "Shipping point Zurich" is required, it is sufficient to use the "VSTEL.VTEXT" attribute in HTML.

The text is then automatically accessed on the server via the SAP table TVSTT, which usually only means a cache access of a few microseconds.

No additional coding is required here, neither in HTML/JavaScript nor in VB.NET, as the connection between the code of the dispatch point and the text is known via the data model. As soon as we replace "VSTEL.VTEXT" with "VSTEL" again, access to the text table is no longer required on the server.

So much for this brief excursion into a detail of the architecture, which shows that a lot of application code can be saved by modeling and interpreting the model at runtime.

Separation of concerns

The separation of UI (HTML), application coding (VB.NET) and SAP access (Abap) facilitates a robust and well-structured development process. In Fiori, this separation can only be achieved through appropriate discipline, as the UI and application are implemented together in JavaScript.

Conclusion

Due to its architecture, Fiori's strength lies in smaller, isolated applications. CIS mobile is optimized to make the SAP Business Suite adequately available to professional users in a mobile web interface: fast, clear and comprehensive.