Live with #FioriCloud: Lessons Learned

Background

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