SAP Fiori Demo Cloud takes on a mobile focus
I may be a bit biased since I’m one of the product managers working on SAP Fiori Cloud, but I think that the SAP Fiori Demo Cloud (https://www.sapfioritrial.com) is pretty cool. We’ve probably all heard of the concept “start with the end in mind” right? Well Fiori Demo Cloud allows you to start with the end in plain view! One of the benefits of SAP Fiori Cloud is an adoption accelerator; enterprises can begin their Fiori journey quickly without needing to touch in any significant way their digital core. But wouldn’t be nice to see how that journey could end before you even begin? That’s what the Fiori Demo Cloud gives you – a glimpse of your digital future. Want to see a fully functional Fiori Launchpad? No problem. Want to customize it to have your enterprise brand Sure thing. Move things around a little? Absolutely! Want to try your hand out at extending some of the Fiori apps? We can do that too!. And it can all be done without any investment other than the time it takes to walk through the guided feature set. Love it.
So you can appreciate that for me, the addition of Fiori mobile in the Fiori Demo Cloud is pretty big news! I hope it is for you as well. But how do I enable the Fiori Mobile service on the Fiori Demo Cloud, and how do I use it? You’re about to find out!
Enabling Fiori Mobile is so easy. All you have to do to enable it is…..nothing! Okay, not nothing, but not very much. Fiori mobile will be automatically enabled when you Customize and Extend your Fiori Demo Cloud environment.
There is a great tutorial covering how to enable a customizable Fiori Demo Cloud environment here. Follow those steps and then come back here.
You now have a fully customizable, connected SAP Fiori Demo Cloud environment that includes Fiori Mobile! Accessing Fiori mobile capabilities can be done in two ways – through WebIDE and through the admin service interface. While a detailed blog will be published on how to use the developer experience tools will be released soon, you can visit The Fiori mobile developer experience has arrived! for some information the topic.
Let’s walk through a simple example on how an administrator can use the admin interface to create a custom LOB-style Fiori app using the help of Fiori mobile. With this first phase of the integration, there are, a few manual steps that have to be completed by you, the valued customer. We’re doing our best to eliminate them over time, but want to make sure you can get started.
The first thing you might want to do is open up your favorite text taking tool, as there are a few URLs/values we’ll paste into there for safe keeping. Once that’s done, you need to copy the URL the Fiori Launchpad that was generated when the “Customize and Extend” action was completed. For me, it was:
We are going to need this later, but we don’t need anything but the protocol and host:
Next we have to get to the SAP Cloud Platform cockpit. To do this, click on your username in the upper right hand corner, and then click Manage Site. This will take us to the Fiori Configuration Cockpit. At the bottom of the screen, you will see an image of the SAP Cloud Platform cockpit. Click that to launch the SAP Cloud Platform core admin console:
For accounts created before 4/15 ONLY, next we need to create a role that gives you the proper authorizations to access the Fiori mobile service. To do this, click on Security > Authorizations then the Group tab, and finally New Group. Type in the name FioriMobile and click Save:
You’ll need to Assign the following roles to this group:
|mobilecloudpreview||mcipreview||App Catalog Admin|
|mobilecloudpreview||mcipreview||Mobile Place User|
Next we must Assign our user to the group (again, only for accounts created prior to 4/15). This is done on the right hand side of this same screen, you’ll be adding an Individual User. You’ll need the ID created when you registered. If you don’t know it by hand, you can find it by clicking on the User icon at the top right of the SAP Cloud Platform Console:
It’s time to go to the service itself, we’re almost done with the pre-configuration, so stay with me! To access the Fiori mobile service, click on Services > Fiori Mobile Preview (the word “Preview” is there because this is deployed in a landscape that is parallel to our production landscape). Then click Go to Admin Console. This will take you to the admin service home page, which should look something like this:
Once this page is launched, you can feel free to bookmark it so that finding it is simpler the next time!
During the provisioning of your environment a connection to the SAP Fiori Cloud launchpad was pre-created for you. That’s the good news! Unfortunately, when you try to access it, it may show as Unreachable. That’s the not so good news. Let’s make sure the right URL is there so that you won’t have any issues. To do this, you’ll need the URL you copied earlier in this blog:
Click on Account > Fiori Mobile, and you will see a single Fiori Cloud Edition connection, which will likely show as Unreachable:
Click on the Gear Icon and select Edit. Update the URL to the URL copied earlier, and it should show as Available:
We’re almost done! Actually, from a System Configuration standpoint, we are done! We have access to the Fiori Mobile service, and an available, fully backend-enabled Fiori Cloud site to mobilize. In order to run a newly created app on a mobile device though, we have to do one additional step – and that’s to create a signing profile.
Creating a Signing Profile
In order to deploy a Fiori mobile app to a real device, two things have to happen. It has to be built, and it has to be signed. Building the app we’ll describe in the next section. But first a word about app signing. App, or code, signing is about proving app ownership and more importantly, fidelity. It proves that the app hasn’t been changed since the owner of the app signed it. Apps must be signed (differently) on both iOS and Android before they can be deployed.
App build and app signing can occur either together or separately. I can build my app and then sign it later if I choose. In our scenario, I want to build the app and sign it all in one motion. For that, I need to create my signing profile first. Then I can build my app and sign it with the newly created profile. In this scenario we will describe how to create a signing profile for Android, and how to sign your Fiori mobile app to prepare it for deployment.
NOTE: In our example, we will be using Android as our deployment platform. Creating an iOS signing profile is outside of the scope of this blog. But if you know how to do it, feel free to upload your cert and try with iOS as well!
To create an Android signing profile, click on Applications > Manage Signing Profiles from the admin console. This will show you a list of all available signing profile, both for iOS and Android. In a new account scenario, the content area will be empty because there are no profiles.
Click on New Profile, and the Add New Profile screen will appear. Leave the settings at the defaults (Android, Generate), and click OK:
The ensuing screen will prompt you for several pieces of information. For the most part this information is free-form, but for readability we suggest you enter the information in the following manner:
|Profile Name||Default Android Profile|
|Common Name||UserFirst UserLast (Leave default)|
The rest, for the purpose of this blog, you can leave blank. For a production deployment you should fill out the remaining fields with relevant information for your organization.
The screen should look something like this:
When complete, click the Generate button to create your signing profile. It will now show up in the content area and is ready to use! NOW we can create our first app!
Creating your first app
Let’s create our first Fiori mobile app. Let’s be more specific about what that means. What we will be doing with Fiori mobile is transforming your business content (the Fiori app itself) into a native (ok hybrid) app that can be installed on a mobile device. It’ll all be done in the cloud, and you don’t have to have any development skills.
The Fiori mobile app we will be building is what’s known as a packaged app. You can find out more about app packaging in the Introduction to App Packaging blog, but one of the benefits of a packaged app is the ability to pick and choose the Fiori tiles to be included, and to include the UX assets of the app when the app is deployed. In our scenario, we will create a cross platform packaged app, called My HR, for iOS and Android devices. It will contain 3 Fiori apps, each of which is intended to provided a specific HR-related function. As part of this exercise we’ll pick the apps, customize the experience and publish it to Mobile Place, our enterprise app store.
From wherever you happen to be, you should be able to see on a “+” icon in the upper right hand corner. Click on the icon, then select Applications (you can also get there by clicking Applications > Manage Apps > New Application):
This will take you to the Fiori mobile app guidance workflow. The app guidance workflow is designed to gather up the information you most likely need to specify in order to build the right app for your use case. Click the Get Started button.
In the What’s your Fiori Scenario page, leave the default selection of I want to create a local launchpad with only the apps I want to mobilize. This tells the solution you want to build a packaged app.
Next, select your Fiori server. Fiori mobile can provide mobilization benefits to Fiori content installed on-premise as well as in the cloud, but for this demo we’ll probably only see a single entry, which is the Fiori Demo Cloud site. Go ahead and pick it then click Next:
At this point you will see a list of apps to select from. Add the following three (double-click or drag-and-drop):
- Employee Lookup
- My Benefits
- My Leave Requests
Click Next, and you will arrive at the Build your Fiori Application page. This page allows you to apply app customizations, enterprise branding and signing information for the app you’re about to build. Let’s give our app a name. Let’s call it My HR. Next, let’s specify our first branding element – the app icon. Later on, you’ll specify the splash screens. If you have your own images, go ahead and use them. If not feel free to download (right-click and select Save image as – save as .png files) and use these:
|App Icon||Portrait Splash Screen||Landscape Splash Screen|
For the Build Options, we need to uncheck iOS. For Android, select the Default Android Profile that we created earlier.
Upload the remaining images to customize your app. If you don’t have images, and don’t want to use these, they can be left blank. The default Fiori images will shown on the client device. Your screens will look pretty much like the following:
then click Finish. You will be placed in the Platforms screen and the app begins to build:
So what happens now? Up until this point you’ve specified a variety of inputs – the Fiori server to use (the destination), which apps to collect, what to call the app, how to brand it. Fiori mobile uses its cloud build service to combine that information along with other things like the UI5 library to create the app. It creates the routes for the app to talk to the Fiori Server, be it in the cloud or on premise. It sets up the infrastructure so that, if the app supports it, functions like offline and push will work.
While I’m trying (poorly) to keep this brief, there are some other concepts that I think are worth mentioning. What you’ve just created is called an App Container in the Fiori mobile world. It has one to many app platforms supporting one to many operating systems and form factors, each of which can be in one of many lifecycle states. The App Container has an admin interface, but it also has an end user interface called SAP Mobile Place. SAP Mobile Place is SAP’s enterprise app store – you can find out more about it on Milja Gillespie’s blog on the topic. Apps that are created with the guided workflow are automatically inserted into our enterprise app store, ready to be managed by the Mobile App Management lifecycle.
The App Container has in it several features worth mentioning, some of which are applicable to how the app is built and run, but others are focus on how the app is represented in Mobile Place. Features are organized under the header icons:
- Insight – Provides information back to DevOps about app adoption and peformance and also provides insight into app specific logs needed for troubleshooting.
- Details – Information here describes the app, including the app name and description as it would appear in Mobile Place.
- Groups – Who gets to see this app in Mobile Place.
- Multimedia – App Icons, splash screen and banner image can be edited here, as can app screenshots, videos and supporting documentation.
- Plugins – if your app needs to access device functionality, it may need a Cordova plugin to do so. These can be added here.
- App Settings – Describes app runtime behavior like app password, logging level, push settings and device access restrictions
- Platforms – Shows which device operating systems, form factors and OS versions this container supports.
- Categories – Controls how the app is organized on Mobile Place
- Owner Info – Governs who can make changes to this app.
So we’ve triggered the app build, which automatically creates an entry in the enterprise app store. This entry will become visible to end users when the admin says the app is ready for deployment. New builds create new versions of the app which can be managed in the same way.
As an admin, I can feel free to watch the progress indicator go from zero to 100%. I might do that once, but after that one time it’s likely that I will say to myself “I’m not doing that again!” And there really is no need. When the app is done building, I will get an email indicating whether or not the build process succeeded or failed. Open it from your mobile device (in this case Android):
Click on the Install on Mobile button. This will take you to Mobile Place. After you authenticate (with your trial credentials) you can click the Install button to begin downloading the app:
As soon as the download is complete, you should be able to install it on your mobile device. NOTE: This download is sometimes called “side-loading”, and some devices don’t support it by default. Your device should somewhere have a setting that allows you to install from “Unknown Sources” (It’s usually a security setting).
Once installed, you’ll see the app installed on your device:
Launch it, and authenticate with your demo credentials. Once you set your app passcode, you’ll see the 3 apps you picked earlier:
Play around the apps to get a feel for how they work, but essentially, you’re finished!
In short, what we did was simple. We took 3 Fiori web apps and we transformed them into a native app, with the SAP Fiori UX installed in the app and not loaded remotely from SAP Fiori Cloud. We did it all in the cloud, and all in about 30 minutes (and that’s including the amount of time it took to build).
There is alot more you can do with this mobile service. For more information and more blogs about the topic, please see our resource site at https://blogs.sap.com/2016/10/13/sap-hcp-mobile-service-sap-fiori/.