Skip to Content

Live with #FioriCloud: Lessons Learned


One of my customers recently went live with Fiori, Cloud Edition.  We have one bespoke app so far, with more in the pipeline.  I thought I would share my thoughts as a developer, in the hope that this might prove useful to someone about to make the leap or thinking about doing so.

Why #FioriCloud?

The cloud version of Fiori runs on HANA Cloud Platform (HCP).  This means that:

  • Your apps can be accessible off-LAN (e.g. on mobile devices) without the need for a Virtual Private Network (VPN).  Because SAP’s data centre is accessible from the public web any device anywhere can connect with ease.  In my experience VPNs can make the user experience a little awkward and can lead to sub-optimal perfomance (e.g. due to limitations in browser caching).  Our app is designed to run on a phone over a 3G or 4G network so this was a big plus for us
  • You can connect multiple back-end systems (e.g. ECC, SRM, CRM, non-SAP) without the need for an on-premise ‘hub’ system.  Such a system would require in-house computing resource and also need maintenance, patching and periodic upgrades.  In many organisations commissioning a hub system could slow down a project by weeks or even months

In an on-premise hub setup the system is used to deliver the UI5 code, to run the Fiori Launchpad (FLP) and to serve the OData requests. To get the benefits above you really need to move all three functions to HCP.  In practice that means using HCP OData Provisioning as well.

Of course, you could have an on-premise hub and move it outside the firewall to make it accessible off-LAN.  In my experience however organisations often don’t have the expertise or the desire to do this.

How does #FioriCloud work?

The FLP is delivered by the Cloud Portal service in HCP.  Each launchpad is a portal site. In essence there is a specific template for FLP-type sites.  The standard Fiori apps (currently a subset of the full list) are pre-deployed.

If you need to develop bespoke apps then you use Web-IDE (running as a service on HCP) and deploy them as HTML5 applications to HCP.  You can create a tile on your FLP for your app directly from Web-IDE.

For OData services your back-end development proceeds exactly as it would with an on-premise hub.  Often you will be using transaction SEGW to build your services.  Rather than publishing to a hub from there however you need to make the service accessible in HCP OData Provisioning.  To be more specific you must activate your service.

Before you start

Once your HCP instance has been commissioned by SAP it’s very quick to get going with development.  However there are a couple of issues that need to be thought through long before you get to that stage.  I’ll discuss these briefly as I am developer not a BASIS or security consultant.

  • You must have the HANA Cloud Connector (HCC) installed inside your network, otherwise HCP cannot connect to your back end systems.  This may be obvious but I raise it because it isn’t always easy to explain to the IT-function why it is needed and why it is safe and secure.  I was lucky that my customer understood and acted fast but I suspect many of you will not be so lucky.  If you want to use HCP and you don’t have the HCC start asking for it and explaining your case now
  • Authentication is much easier if you have a suitable identity provider (IdP).  If you have a really good single sign on (SSO) setup already then it should be easy to connect HCP.  If however you don’t have a suitable IdP, or it isn’t accurate and complete then you may need to use SAP Cloud Identity for authentication.  This is an area that you need to research and understand before you get HCP.

Does it work?

Working with HCP has been a very positive experience for me.  I was very impressed with the FLP in particular and I found it easier to setup than than the on-premise version.  Our app performs well and we were up and running within a few weeks.  I had far fewer issues with caching (of service metadata and launchpad config) too.  Of course we did face some problems but we were able to get around those.

In my opinion the on-premise FLP betrays it’s evolution over time but with HCP the team were able to make a fresh start, and it shows.

Some Practical Tips

  • You need to take care that you have the right roles in HCP.  For example you will need TENANT_ADMIN to set up the FLP, GW_ADMIN to activate your ODATA service and GW_USER to run the service.
  • Every version of your HTML5 application (your ‘UI5 code’) is stored and you can activate whichever version you choose.  If you have problems with a new release you can always activate the previous version until you solve the issues.  This is a great feature in my opinion.  You need to be aware though that the FLP site doesn’t change the version that it uses until you explicitly set it.  You need to go to the Portal Service, edit your site, choose Site Settings and then click Clear HTML5 Application Cache under the Actions menu
  • Deploying from Web-IDE is a little faster to HCP (than to ABAP repository) because the name of the HTML5 application you deploy to is saved in the .project.json file.  You don’t have to choose each time you deploy
  • The Usage Analytics function gives you a great overview of which apps are being used and by whom.  There are breakdowns by OS and device for example. To see the analytics edit your site and choose Usage Analytics.  It would be great to be able to raise custom events to track – if we could do so there would often be no need to use an external product such as Google Analytics
  • To clear the metadata cache (for OData services) go to the OData provisioning service, choose Metadata from the menu (on the left), select your service and click Clear.
  • To create an FLP tile directly from Web-IDE choose Register to SAP Fiori Launchpad from the Deploy menu and follow the wizard
You must be Logged on to comment or reply to a post.
  •   Mike Doyle

    Congratulations on GoLive !!!

    Can you please also share how your team tackled the transports imports and testing phases? Also did you have three instances for DEV, QAS, PRD . What was the sizing that you have subscribed for and the end users using the application.


    What factors lead to the decision of going to HCP instead of On Premise deployment for Fiori. Of course no dedicated support/maintenance / low cost. But still convincing the customer for cloud is nt much easy just for FIori apps. Please share the decision making process followed by your customer.

    • Hi Vijay,


      Customers get one global account with all the resources assigned to it. Its upto the customer to create several subaccounts representing the landscape and accordingly split the resources for each subaccounts. You can have each subaccount tied to a DEV/TEST/PRD backend system accordingly.


      For Transporting a Portal contents/Fiori App/ Destination - you could use Export/Import option to move them from one account to another.


      In this case, it was an easy decision to go with Fiori Cloud Edition. The customer has no  Gateway or Reverse Proxy infrastructure.  The requirement was set of Fiori Apps which are already available in HCP. These Apps need be available on Fiori Client Mobile App. As you pointed out - TCO/less maintenance/Support are all the driving factors. Another benefit is the latest SAPUI5 library which gets readily available without the need to constantly patch your backend gateway system to use new functionalities which come out of the library.

    • Thanks Vijay, and thanks Murali for covering lots of these questions


      We did indeed have a DEV/TEST/PRD landscape and I would certainly recommend that.  As Murali said you can export/import both the cloud portal site (your FLP) and the HTML5 Application (your UI5 code).  This is easy but of course it does miss some of the audit trail that CTS gives you in an ECC system.  You need to have a procedure in place, e.g. storing the export files on a shared drive.  You might also want to keep the version numbers in sync across the systems but that is not automatic.


      Once you are up and running and you make changes to the app you would

      1) Export the HTML5 application from DEV

      2) Import it to TEST

      3) Go to FLP portal site and clear the HTML5 app cache


      Then repeat 2 and 3 for PROD


      I think that for our use case HCP is actually the obvious solution and that's because of the ease of access from mobile devices over public networks.  The on-premise hub has only become so prevalent because it wasn't possible to entirely replace it with HCP.  I expect that in a couple of years time new Gateway hub installations will be quite rare.

  • Hi Mike,


    Thanks for sharing your experience. I am glad your team was able to do a great job in a short timeframe (overcoming several hurdles) for this goLive.


    Just one thing to add - Fiori Cloud Edition is simple as you explained. I think the implementation journey will get even more easier for customers once they spend enough time understanding how the security model would eventually work for FioriCloud Edition and how it ties up with an Identity provider based on their existing landscape.




  • Hi Mike,


    Thanks for sharing your experience. A quick questions, can you give more details on how your landscape was? did you use ERP connecting to your HCP System, and having odata services from HCP oData provisioning?, if, yes, can you please share more details on how you achieved it?


    I have not used oData provisioning, so would like to explore more about it.




    • The OData provisioning simply replaces the 'front-end' half of the gateway server.  That's the part that would often be done by a 'hub' box.  It makes your service accessible to the outside world


      To get up and running

      1) Get the Cloud Connector running and allow access to the ERP system

      2) Create a destination in HCP for your ERP system

      3) Develop the back-end of your service in ERP using the service builder (SEGW)

      4) Activate the service in HCP


      Murali would be too modest to mention his own blog which explains the process in detail.  We used it as a reference

  • Hi Mike,


    Thanks for sharing your experience. It will definitely be helpful for lot of us. You have explained most of scenarios in FLP configuration. But still I have got few doubts and it would be really helpful if you could spare some time in answering those.


    • When you say "apps accessible off-LAN" - I understand there is no need of web dispatcher/reverse proxy, but how secured it is? Does it mean anyone from anywhere can directly hit the server?
    • Do we have a place where we can get all the right roles available in HCP like TENANT_ADMIN, GW_USER. Because I spent almost a week to find GW_USER role initially
    • If the HANA Cloud Connector(HCC) is turned off for moment, does it mean I will not be able to pull real time data from backend system for FIORI application?




    • Hi Sabarinathan, for sure anyone from anywhere can hit SAP's datacentre.  As a developer I'm not the right person really to explain the security features at length.


      When you launch a service in HCP you can often find the role assignment as an option in the menu.


      If the HCC is down then yes, your Fiori apps would not be able to connect to backend systems.

    • Hi Sabarinath,


      HCP is in the public cloud and can be accessed from anywhere. Have a look at this link where SAP explains how it ensures high security standards for its data centers.




  • Thank you Mike for sharing the great fioricloud story with the community!  If the sales pipeline stories are true, then your next project will soon be underway and you will be building on these learnings.  Can't wait to see the next blog, customer testimonial video, or live event session!


    Best Regards,

    Jeremy Good

    SAP Technology RIG