Experiences with Development of Fiori-like Apps, S...

ttrapp · ‎11-15-2014

In my SAP TechED&&d-code wrap up I explained why I believe that SAP UI5 will become SAP’s most important UI technology. But where are we right now? What are the challenges when you develop and implement Fiori-like applications?

Starting with ABAP on HANA

I blogged about my first experiences with SAPUI5 in 2012 in the context ABAP on HANA: http://scn.sap.com/community/abap/hana/blog/2012/11/02/analytical-abap-for-hana-applications-charact... At this time my JavaScript know how was quite limited.

In above picture you can see an UI5 application created in 2012 having a shell in gold reflection design – at this time there was no Fiori and no Blue Crystal theme. In the mean time many things have changed: SAP developed now controls together with design guidelines and principles that define Fiori apps. Now UI5 is evolving from a technology for occasional platform users (and this is the meaning of the acronym “opu” in SAP Gateway context) to a general purpose UI technology.

After I started with UI5 very early I put my focus on other UI technologies due to the shortcomings of early UI5 versions but since some months I started to work with UI5 again. In the following I will discuss some aspects of UI technology strategy, UI development and implementation.

Which is the right technology for my development project?

I think the answer which UI technology to choose is very simple:

SAP Screen Personas is the right choice when you want to give an existing ABAP Dynpro and perhaps WDA (non-FPM) application a UI.
FPM is the right choice when the UI should be configurable and when complexity is so high that you need a stateful approach: you have a complex data footprint on the frontend, locking is needed and there are many operations that don’t follow the CRUD resp. Query pattern. FPM/NWBC is a also necessary when need good integration into ABAP Dynpro (Object Based Navigation).
Take Fiori / UI5 otherwise. Try to use existing frameworks like BOPF/SADL/BW Easy to create OData models. Do integration with ABAP Dynpro using SAPgui for HTML and embed WDA as well as SAPgui for HTML resp. Personas in Fiori Launchpad unless you can’t provide a complete set of Fiori-like apps for the endusers.
Do you want to develop and extraordinary application with new user interaction patterns that is completely different from ABAP Dynpro or Web Dynpro technology? Then choose UI5.
In mobile development you should consider building hybrid apps using Cordova and the plugins for SMP called Kaspel. I think this getting better and better since the HTML5 standard is now declared for complete and web applications will get more and more properties of mobile apps since they can access the device interfaces.

Reponsiveness – easily done?

Fiori apps are responsive, they have a fluid design and you can use them on any device – really? I think this is more complicated. For certain purposes the UI must be complex even when simplifying the process and chaining Fiori apps for example. These are my tips and “tricks”:

Test your Fiori-UI early on the target device: are the chosen controls the best choice on the tablet for example? Does the keyboard behave well when popping up?
Think about developing own UI5 controls if the existing ones don’t look well on a small device.
Optimize your application for the target device. This doesn’t mean that you have to implement an adaptive design but sometimes a compromise is necessary.

Possible Pitfalls when using Open Source JavaScript Libraries

One of the greatest advantages of the UI5 world is that you can use existing JavaScript libraries like d3.js, Crossfilter or DC. Do you need inspiration? Just look at amazing visualizations like the one here: http://www.nytimes.com/interactive/2012/02/13/us/politics/2013-budget-proposal-graphic.html?_r=0

But be warned and don’t expect that it will be so easy like in the SAP world: some of the frameworks don’t have a proper internationalization so you can get problems since they some of them won’t display date information not in your language and so on. And please be warned to use any code snippets for find on the web: I saw Fiori apps crashing in the Fiori Launchpad since they use global variables. Don’t forget that the Fiori Launchpad is a JavaScript application, too.

Development of Fiori-like and Fiori Apps and implementation of Fiori Launchpad

Fiori-like applications are easy to build and you will find many valuable sources here in SCN – just follow the blog og DJ Adams. I think development of Fiori-like apps is not that complicated since it is well supported by SAP UI5 resp. Open UI5 library. Please remark that Fiori apps have to be certified when you want to call them “Fiori” – otherwise they are only “Fiori-like”.

Don’t underestimate the effort of implementation the Fiori Launchpad and Portal integration. Fiori Launchpad is an application in the ABAP backend and most likely you will need a new ABAP system. This system will serve as a frontend server containing all UI5 applications and will be also a SAP Gateway hub. A web dispatcher (or reverse proxy) will help to deal with the same origin policy restriction. But this has an impact on your system landscape and please be prepared that you will have to update the UI libraries in the frontend server as well as gateway libraries on this server as well as on the backend frequently. So Fiori will add additional complexity to your systems landscape which is the price for simplification of UI as well as application development.

The integration of Fiori Launchpad into the portal needs special attention, too: how do you harmonize portal roles with Fiori Launchpad Roles? What happens if a user has different roles? What about SAP user names if you have different backend systems? How do you integrate CRM Web UI and Fiori Launchpad?

Moving from ABAP to the SAP UI5/SAP Gateway World

When discussing UI5 development with ABAP developers I often experience some misconceptions about the technology:

An OData service is different from an RFC. In fact it is a kind of middleware between the UI and the backend but it is also part of the UI. Usually one OData service corresponds to one Fiori application and reuse in different UI5 applications will cause much testing effort and much trouble so you should avoid it. And this is the main difference between BAPI and OData-Service: a BAPI is made for reuse and in UI5 context reuse is considered as harmful. So when designing OData services reuse should be done at the layer of implementation.
If you come from the ABAP world you have many reuse functions that you can use in UI development: display of archived documents, functionality for output management and so on. All this missing in UI5 right now but I think it is only a matter of time when those functions will be there. In fact SAP has already everything we need like CMIS interoperability features as well as solutions like SAP Mobile Documents.
UI5 applications are RESTful web applications and their architecture is different from stateful UI technologies like ABAP Dynpro and Web Dynpro ABAP. So the understanding the difference between statefulness and statelessness is most important.
You might not believe it but I heard ABAP some developers complain about the usage of XML in OData since XML is considered slow and takes bandwidth. This always makes me smile because from my experience gzipped XML is only 20% bigger compared to gzipped JSON – and, by the way, OData supports JSON serialization, too. In my opionio it is most important that ABAP developers without experience in web development have to learn “new” programming idioms like AJAX. Those techniques will help them to speed up web applications significantly.
UI5 is open and allows to create mashups and can be used in Web Dynpro ABAP as well as CRM Web UI. But never forget restrictions like above mentioned Same Origin Policy and security considerations. UI5 applications are vulnerable compared to Web Dynpro ABAP – using Google Chrome development tools you can change data and completely rewrite an existing UI. You have to be well aware of that.

In my opinion above examples show that you can’t transfer all best practices know from the ABAP to the new UI technologies. ABAP developers need to achieve new skills and have to learn new paradigms. Especially the combination of stateful UI technologies like Web Dynpro with embedded UI5 is most promising since Web Sockets that are available in ABAP since Release 7.40.

Summary

This blog far from being complete since I didn’t write anything about SAP Web IDE which I’ll try out in the near future. This blog reflects my own experience as well as many discussions at SAP TEchEd&&d-code in Berlin and I thank dj.adams, robert.eijpe and owen.pettiford as well as the UI5 team at SAP. In fact I don’t know whether they agree to everything I wrote in this blog entry but I’d like to hear their opinion.

I think the blog can be summarized in a few words: UI5 development is well understood and not so the difficult as you might think. Tools, frameworks and libraries are mature but one has to realize that some paradigms differ from traditional SAP UI technologies.