Experiences with Development of Fiori-like Apps, SAP UI5 and some Best Practices
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-characteristics-unique-selling-points-and-first-programming-idioms 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.
Hi Tobias,
I'm just starting to do my first steps with UI5. In my current project we are working with BOPF, our UIs are build with FPM and the BOPF FloorPlan Integration (FBI). That's pretty easy to use and you can implement the UIs very fast and in most cases without coding. I really like that.
At the first sight, developing UI5 UIs will take much longer. Am I right and that's the prize we have to pay for the beauteousness of UI5?
Furthermore locking and conflict resolution seems to me a quite critical topic. As far as I know, conflicts detection is done using the eTag within the OData service. But that means for me, that the UI developer have to take about the conflict resolution. This sounds quite critical for me. Do you have some insides regarding this?
Thanks and cheers,
Martin
Hi Martin,
you are absolutely right: locking is a stateful approach and in a stateless Approach you need conflict resolution. But as I wrote in my TechED&&d-code wrap-up I expect that it will change and we will get a better support. And yes, there is more overhead, think of checks for example, since you have to implement it as customer function since it is not covered by CRUD-Q pattern. Moreover UI5 is not as configurable as FPM and you have better Integration using NWBC at the moment. So at the moment for many use cases FPM is the better choice. Moreover at the moment FPM is easier to configure.
In the Long run I think SAP UI5 will win the race since the separation of the UIs from the backend is superior: you can easily create and adapt existing dialogs according to the requirements of end users resp. user roles. Please also remark that the technology is very powerful: the SAP Web IDE for UI5 as central IDE is written in UI5 itself and I advantages in web technology (new JavaScript libraries for example, implementation of HTML5 will be available faster on UI5. So in my opinion you will create UIs with extraordinary user experience and completely new user experience in UI5 and not FPM.
But as BOPFexpert you are well prepared for any UI development since stateless and stateful are only two different contracts and soon we will use best practices to expose backend functionality in any UI: CDS, SADL and BOPF are here and I they are not only database agnostic but also provide channels to the UI. Those rameworks/technologies are getting better in every release and it would be wise for SAP to invest further in those technologies.
Best Regards and see you at SAP Inside Track Frankfurt
Tobias
Hello,
What I am already wondering for some time is what the consequences are for SAP CRM.
Since SAP CRM 7 they are using the WebUI.
A lot of companies have invested a lot of money in the implementation of the new CRM release. Not only the UI changed, but there was also a lot of work regarding the fact that the components were based on the BOL/GENIL.
But now I see a evolution in UI towards UI5, Fiori ... but what is the way forward for the applications build in WebUI.
I don't find a lot of info about this, not to say any info.
Is there a kind of 'roadmap' somewhere ?
What are the 'best practises' proposed by SAP ?
They should have some kind of strategy available for those systems as well I would expect.
Best regards,
Erwin
Hi Erwin,
these are excellent questions.
SAP published the roadmap for CRM Web UI on SCN: http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/c0e5d250-3e9a-3010-97a0-a0c7f48b5bd8?QuickLink=index&…
There are still activities in but it seems to me that cool new CRM UIs from SAP are delivered in Cloud solutions so you should look at them. In this context I have many questions: are there best practices for integration of/starting Fiori apps in CRM Web UI?
I think from the point of development it is easy: You can expose BOL/GenIL to OData. You can also implement new Business objects as BOPF objects and use bridges to OData but also BOL/GenIL.
Best Regards,
Tobias
Hi,
I personally really like UI5. It's one of the best things I've ever seen from SAP. I just don't understand why there is so much push for OData/Gateway. Two things mentioned in this blog:
I just wish for a better REST solution that is not based on OData. BTW if somebody wants to have a look at really nice RESTful interface delivered by SAP then have a look at BOBJ. The design seems really solid even though it still lacks functionality.
Cheers
Hi Martin,
this is an interesting question: Are GW services to the UI or are they an API compared to RFC or Enterprise Services? Do want to create a REST API for your custom developed solution are a set of Fiori-like apps? Of course one can create reusable OData services but we shouldn’t forget about the costs: in larger development projects it is likely that the development process between different teams has got to be synchronized. After changes of existing services you should retest all apps who use reusable services. This can be also a challenge if you system landscape is complex because you will have to synchronize the import of all different GW services otherwise your UI could break or you have to create UIs that support different versions of GW services.
IMHO if someone has an much experience with REST based applications and has an excellent reuse management, test management and software logistics then one should start to think about reuse of GW services. But one should also be aware that (in contrast to RFCs) GW services will be changed more frequently since it is very likely that GW services will be optimized for a specific UI. But if you have made a different experience I would like to read your best practices for reuse of GW services – this would be an excellent topic for a blog 🙂
Yes, XML needs more bandwidth. I only wanted to share my experience that nearly all discussions of bandwith have been completely ineffective because the real problems happened somewhere else: size of transmitted images, synchronous data access and so on. If you want to speed up your application it is very likely that you optimize the data access for a specific UI since existing BAPIs and function modules read too much data or not the attributes you need or use data prefetch which is completely useless in stateless architecture. If you have different best practices how to speed up GW artifacts this would be also a great topic for a blog 🙂
Cheers,
Tobias
Hi,
I guess that we could argue that it will cost more if we have to re-implement same functionality multiple times. Also a change to underlying business logic/data must be pushed to all implementations. I understand why SAP delivers GW service per app. It simplifies delivery units and customers can cherry pick which app will be deployed. Maybe approach employed by Netflix is a way to go for big customers. One team owns an interface and is responsible for providing it to other consumers. This team invests in fully automatic tests so introducing changes requested by new consumers should be pretty robust. I am also not sure if changes like adding additional field/new association/new function import will have any impact on old apps. The main source of issues would be probably changes in CU operations. Also GW supports versions, right?
I understand that XML overhead is usually not the issue with app. Still not sure why UI5 does not use JSON by default. I haven't looked into guts of UI5 so not sure what the benefits are achieved by this.
Cheers
Hi Tobias
Great post I have been looking for this and appreciate the way you have clarified when to use each UI technology.
Tell me, do you think there is any chance of an ABAP transaction being written to convert RFC\BAPI to OData service?
Similar to the program made available for Web Services in SE37?
In my view this would be very useful and possibly one to develop if SAP ain't gonna do it.
Another question, when to use SMP 3.0 vs. Fiori? My understanding is SMP 3.0 is when you have a large user base that require rich offline capabilities in their mobile apps?
Cheers,
Anthony.
Hi Anthony,
I do not expect that there will be a transaction to convert RFC/BAPI to Gateway Services. But you can already build (and that's what I recommend) your Gateway Services based on existing objects as BAPI, BOPF models and ABAP Objects classes.
Gateway actually offers just a way to expose your existing business logic as OData Services.
Regarding SMP 3.0 vs. SAPUI5 (Fiori is just a "brand name" for SAPUI5 apps with specific user experience which use OData Services for back-end integration):
For me that's exactly the case: for off line scenarios with caching and syncing use SMP. There are also some more features of SMP which might be worth to look on: user authentication, software distribution, etc. But I'm not on expert for SMP.
For a UI without off line capabilities I would go for SAPUI5.
Cheers,
Martin
Hi Martin,
I agree with you and only want to mention one detail: SADL based services are getting better: Consuming Business Entities with SADL - What's New in SAP NetWeaver 7.4 (Release Notes) - SAP Library
Cheers,
Tobias
Hi Martin, Hi Anthony,
there is a transcation to generate OData Services from RFC function modules without having to write a single line of code.
It is however necessary to map the RFC interfaces to the methods of the OData service.
You can find more information in the Gateway self-paced-learning here:
Service Development - Technologies - SCN Wiki
Best Regards,
Andre
Hi Tobias,
Great blog! I think there are a lot of misconceptions (as usual) about SAP UI direction, and I hope this helps to clear things up a bit for people.
Hello Tobias,
Great post! I have been taking the Intro to Fiori in OpenSAP and I agree about the landscape being more complicated with the back-end and front-end servers. My question is, if the client has ECC and APO systems and we want to implement UI5 apps, do we need a front-end server for ECC and a separate one for APO?
I appreciate your explanation on misconceptions moving from ABAP to mobile/UI5. As an ABAP developer, I am still learning the differences between them. How important would it be to learn JavaScript if I plan to move to UI5 development work?
Thanks again.
Hi Lorraine,
the question whether you need a Frontend Server or not depends on many aspects. If you are on a high release level you could use one SAP system (f.e. ERP) and use it as embedded Gateway server. But this scenario has disadvantages:
There are also security considerations - but this is a complex topic. SAP offered at some sessions about this topic and waiting for DSAG to publish the slides.
Learning JavaScript is not so difficult since there are many tutorials here on SCN in this space:
I'm sure that after performing tasks like there your JavaScript skills will be quite good.
Best Regards,
Tobias
Thanks Tobias. I'll look into those tutorials.
HI Tobias, Thanks for a wonderful blog. I am an abaper making an attempt to learn UI5, but I hear lot of terminologies, I dont know where to step first.
Have some basic questions.
1. What is difference between OPEN UI5 and SAP UI5, is SAP UI5 an JS library *** IDE customized by SAP?
2. I believe NEtweaver GAteway is required to inbetween SAPECC and UI5 app. What does this server do?, do we need to code in Gateway server also, to convert incoming ABAP data into JSON format, cant we just use ABAP FM to convert to JSON and supply data?
3. Do I need a Apache Server to be installed on my Machine to start off?, I know there is lot of information on web, but it is too much to search for.
4. Can we install SAP Ui5 library without license implications
5. What are these other libraries I hear about like Node.js, Cordova, ..blah..blah...blah..
6. What are the basic things we need to concentrate on...Is there a general guide(learning Map) saying start from, do this, do that..
It is difficult ABAP developers to transistion out as we are not used to hearing so many new terms and have become comfortable in our own world. Too much information is also a deterrent and can scare one away.
Wow - these are many questions - and you will answers in this space on SCN. The difference between Open UI5 and SAP UI5 is expalined here; What is OpenUI5 / SAPUI5 ? In fact Open UI5 contains most of SAP UI5 minus some charting libraries but this no problem since you can use open source libraries like D3.js - Data-Driven Documents . We asked your license guys and I was told SAP UI5 is bundled in SAP NetWeaver license. The same is true for Fiori although I think Fiori is bundled with SAP Business Suite licenses (http://www.news-sap.com/sapphire-now-sap-fiori-user-experience/) - so check your underlying licenses. But I don't expect there will be any problems.
I recommend to start with Eclipse tooling since everything you need is included: Tools & SDK - SAPUI5.ORG You will how to install it on SCN but also Youtube. Later you should have a look at SAP Web IDE.
Node.js is important if you want to build JavaScript applications on the server - but I think you want to build application running in the client. Cordova together with Kapsel (the Cordiva plugins for SMP) are necessary when you want to use Fiori to develop HTML5 based hybrid mobile apps.
Installing SAP UI components on an AS ABAP is not problematic. The component is not that big but import of MIME objects during installation is not that fast. You should think of it like the kernel - don't modify it.
In another answer to a comment of this blog post I explained how I learned UI5 - but this will be a topic for a new blog. At first step I recommend this excellent blog series: Building SAP Fiori-like UIs with SAPUI5 in 10 Exercises .
Best Regards,
Tobias
Thank you very much Tobias. That was really insightful.