Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
BWomelsdorf
Advisor
Advisor
Release 1.30 of the Hybrid App Toolkit provides some important updates regarding how customers use the cloud build service to create hybrid web apps from SAP Fiori or SAPUI5 based content.  Let's talk about those changes and see what it might mean for you.

Before we get started, let's ask the question - do I need to care?  Good one!  If you're a mobile service for SAP Fiori (Fiori Mobile) customer, not necessarily (but you still might).  You can use the cloud build feature of this mobile service in exactly the same manner as you did before.  If you are an SAP Cloud Platform Mobile Services customer, you're going to want to know what's going on.

A brief bit of historical perspective is in order.  The cloud build service was originally a feature included only in the Fiori Mobile.  Originally it was admin focused, but in October 2016 it was added to the SAP Web IDE experience as well.  But, and this is important, the purpose of the Fiori Mobile was to enable Fiori developers to create mobile apps without requiring them to be mobile developers.  As such, we did our best to handle all the mobility aspects "under the covers" where Fiori Mobile was concerned.

In November of last year, we added cloud build support to SAP Cloud Platform Mobile Services (see my blog here).  We added support for SAP Web IDE Full Stack around the same time, along with a toggle in the HAT that let Fiori Mobile customers "toggle" between a Mobile Services build and a Fiori Mobile build:



That's where things got interesting, and we started hearing from our Mobile Services developers.  And we listened!

News flash - Mobile Services developers are fundamentally speaking, mobile developers!  They want access to the nitty-gritty aspects of mobile.   As such, they are a fundamentally different persona than what we target with Fiori Mobile, and require a different approach.  The first aspects of that approach reveal themselves in the 1.30 release.

The Fiori Mobile model, in SAP Cloud Platform Web IDE Full Stack, looks like this:



In the last step, during the build, alot of stuff happens.  An index.html file is created, a bunch of JavaScript is inserted (including code for offline) and the web assets from the app are extracted from the launchpad.  All that, along with the UI5 libraries are then provided to the cloud build service and out comes a Kapsel-based app!  As you can see, the Fiori Mobile model requires SAP Cloud Platform Portal (or SAP Fiori Cloud), and for offline apps, the app communicates to the backend via the launchpad.

Initially, this model was used in Mobile Services as well, however from the beginning we knew that the model would change, and offline was always declared as out of scope - see the note in the HAT documentation here.

In the new Mobile Services model, the scenario looks like the following:



There are a couple core differences here.  First you see the new step "Enable as hybrid app".  You'll see this when you right-click on the project folder, and select Mobile.  First, make sure that the Hybrid App Toolkit option indicates to use Mobile Services as the build mechanism.



This step takes some of the code that used to be generated at the end, and instead creates a Mobile folder in the project itself:

 



This code can then be modified, if necessary, by the developer.  You can see the index.html file, there are also files to handle activating Cordova/Kapsel and to handle the logon plugin integration.

You'll also notice that the steps to deploy to the SAP Cloud Platform and register to the launchpad are now gone.  That's because the new model can build without this step.  The app also communicates to the backend in the same way that all Mobile Services apps communicate which is via a standard Mobile destination, no Fiori Launchpad is involved.

One bit of code that you will not see, at least in the 1.30 release, is the generated offline code.  This bit is very important:

22 May 2018 Update: It looks like we can loosen the restrictions on building offline apps with the cloud build service and SAP Cloud Platform Mobile Services.  While the story is still evolving (meaning our solution isn't perfect), this is now possible.  Please check out Ludo Noen's blog Creating an Offline CRUD hybrid mobile app in SAP Web IDE Full-Stack with Hybrid Application Toolkit for a detailed, step by step walkthrough in how to get it done.  Building offline apps with the SMP SDK directly or with the HAT local add-in are also supported approaches.

Apps built via the cloud build service interface to SAP Cloud Platform Mobile Services do not support offline OData.  This is true for all releases of the Hybrid App Toolkit up to and including 1.30.

We are still contemplating how and if to support offline apps in the new model.  Right now, if you need offline, you either need to use the HAT local add-in or download the SMP SDK and build the client locally.

The last difference you'll see is that specifying the UI5 version is part of the build screen:



So, what happens when the developer clicks the Build button?  Much of the same "stuff" happens, but it's just done differently.  Instead of packaging from the FLP, all the components are pulled directly from the developer workspace.  Instead of generating a bunch of code at build time, whatever code we do generate is mostly created at design time. Another important aspect is this - when building a packaged app, the content of the mobile folder will be merged with the content of the webapp folder. If your webapp already contains an index.html file, it will be ignored (actually replaced) when the project is sent to the Cloud Build Service. The cloud build service still creates a Kapsel app that you can download, test and deploy to your mobile users.

Most of the remaining aspects of the cloud build service interface remain the same.  The app will still show up in the Mobile Services admin cockpit and can have additional features applied, such as the Client Policies feature to enforce supplemental security.  It can be operationalized in the same way as any other Mobile Services app.

I want to conclude this blog by bringing Fiori Mobile customers back into the loop.  You can use the Mobile Services approach to build apps.  To do so, change the HAT option to use Mobile Services rather than Fiori Mobile.  If you have an existing app that already supports offline, then you probably don't want to do that - yet.  But we're working on creating some content to help you through the process.  So in the end, these changes might appeal to you too!

Last, but not least, a quick procedural note.  This functionality is only available in SAP Web IDE Full Stack.  You may need to clear your browser cache before trying to use it.  If you're a Fiori Mobile customer using SAP Web IDE (not Full Stack), you may need to clear cache to continue to use the Fiori Mobile build service implementation.

This implementation will evolve over time, keep on the lookout for future updates, and I look forward to your feedback.

17 May 2018 Update: Despite our best efforts and multiple reviews, sometimes we either say something we shouldn't or don't say something we should in some of these blogs.  While I thought I said this in the original post, I should clarify.  The statements in this blog have no impact on those customers who subscribe to the mobile service for SAP Fiori (via SAP Fiori Cloud, premium).  There is no change in support policy for customers who build using the Fiori Mobile implementation (either through the admin or through SAP Web IDE Full Stack).  Offline is still supported per the release documentation here.   This blog only applies to customers who have toggled their SAP Web IDE Full Stack Hybrid App Toolkit feature option to use the mobile service for development and operations build.  Thank you to those who brought it to my attention that the guidance wasn't clear enough!
21 Comments