1 2 3 86 Previous Next

SAP for Mobile

1,279 Posts

While downloading the docx file type from SAP, sometimes the file gets corrupted and this is because of addition of NULL values added at the end of file in Java. To avoid adding NULL values in the file following logic can be implemented in Java object class.


If you are planning to migrate an SMP 3.0 OData environment none MBO from one environment to another, please check the following WIKI that provides you with a guideline on how what you need to be aware before the migration is done and the guideline on how todo the migration from a single node to a cluster environment.  Follow this link: https://wiki.scn.sap.com/wiki/x/wI6gGg

Don’t we all wish we could spend our time at work playing games? Could you imagine going into your weekly status meeting, sitting down, and annihilating all of your co-working in your own corporate DOOM dungeon?


Gamification is officially defined as


Gamification is the application of game-design elements and game principles in non-game contexts. Gamification commonly employs game design elements which are used in so called non-game contexts in attempts to improve user engagement, organizational productivity, flow, learning, employee recruitment and evaluation, ease of use and usefulness of systems, physical exercise, traffic violations, and voter apathy, among others. A review of research on gamification shows that a majority of studies on gamification find positive effects from gamification.


To us, gamifcation basically means working while having so much fun.. it doesn’t feel like work !


In order to fulfill our ultimate desire to has fun at work we started looking into how to truely add gaming capabilities to an SAP process. We have been spending quite a bit of time working with customers to build enhanced UIs on top of AP Approval processes, so we figure we would give that process as shot.



Here is a screenshot of the our ‘Galactic AP Approval’ mobile game running on an iOS device.


http://www.spyvee.com/wp-content/uploads/2016/06/Screenshot.png


The premise is pretty simple. You are the hero in the star fighter on the left hand side of the screen. You need to shoot down the nasty payables disguised as aliens flying at you from the right. Tapping on the screen shoots a powerful laser which ‘approves’ the invoices when they are hit.


In real life, this might not be the best use case. For it to make sense there needs to be a large number of low dollar amount invoices which need approval without any research. If there is a need to actually search the items, this might not make sense. But its fun!


Technically, the application is written in Apple’s SWIFT development language and utilizes the Sprite Kit framework.


Couple of things to keep in mind

 

  • There is an immense about of helpful hints on utilizing SWIFT and Sprite Kit, we recommend everyone interested to go out and give it a try!
  • This is a native mobile application and needs to be high performing. So we load of the approval objects, via a simple ODATA call, when the application loads. The approvals are transported back the the SAP system once the game is over.
  • If you look at the aliens, we added some additional information ( Due Date, Company Name ) these can ( and should ) be more atheistically integrated into the game. Maybe each company is a mother ship which launches her ‘aliens’

 

Here is a video demonstration of the mobile game.



If you would like some more information on how this was done, please let me know!


All Agentry users,

 

SAP and the Digital Business Service team proactively tries to share our learned lessons to the community to better assist the mobility users. In the route to a successful Agentry SMP 3.0 mobility deployment, we would like to share what is expected so that your team would know the best practice.

 

If the best practice steps are not followed here are the following symptoms that you may experience:

 

  • Patching of fixes (ex: Work Manager or Inventory Manager) may not show up properly
  • You will have a hard time reverting to a known good state (if backup or version control is not followed)
  • Escalation by the customer to SAP may be seen but the root cause is tied to improper deployment by the customer/user
  • There is a chance that you may be missing changes (deployment) or items may be not stored/saved properly in the SMP 3.0 cockpit

 

To prevent issues to occur, please follow the best practice deployment strategy as documented here:

 

SAP KBA # 2330407 - Deploying, Backing Up, Patching, Reversion and updating the SMP 3.0 cockpit for Agentry - Best Practice

 

We hope that by sharing this to the community, we can grow our mobility deployment faster and more efficient.

 

Thanks to all the SAP mobility users, designers and support for contributing our learned knowledge in the SAP Community Network (SCN).

 

Best Regards,
Mark Pe
SAP Platinum Support Engineer

SAP Product Support tries to be proactive in giving resolutions out to the customer to be readily before the need arises.

 

Based on some internal or external installation of SAP Mobility products(SMP SDK 2.3 or higher), the followings KBA articles will help user troubleshoot Agentry client crash issue.


Android Client:

2127557 - SDK SP06 Android client crashes on launch with UnsatisfiedLinkError - Agentry

2141810 - Agentry Android client crashes while navigating screens 6.0.40.3 and 6.1.5.9

2211732 - Agentry Android application runs out of memory and eventually the app crashes - SMP 3.0 SDK

2152190 - Agentry Android client crash after transmit when Wi-Fi is lost - SMP 3.0 SDK SP06/SP07

2176053 - Agentry Android client crashing (or closes unexpectedly) when launching - coming from background or resume from sleep - SAP Mobile Platform 3.0

2145271 - Agentry Android Clients not working on Android 5.0

2203405 - Client crash after overlay view in landscape mode

 

iOS Client:

2302936 - Agentry Client crashes when user selects to browse Documents folder - iOS Device

2290944 - Agentry iOS client crash when uploading document

1965897 - Agentry iOS client crash on iOS 7 for SAP Work Manager

2107493 - Application crashes on barcode scanner field for iOS IPAD Agentry client - Service Manager 4.1

2153328 - Agentry client Crash when clicking transmit 2 - 3 times simultaneously - SAP Mobile Platform 2.3 and 3.0

 

WPF Client:

2321983 - Agentry WPF / ATE clients not launching successfully in Windows 8.1 for SMP 3.0 SDK

2234405 - Client crash on OpenUI call to background Agentry action

2215665 - Agentry: Service Manager 4.1 Client Crashing


ATE(Agentry Test Environment):

2167661 - Agentry Test Environment (ATE) 6.1.3.10212 does not work in Windows Enterprise 8.0 or 8.1

2321983 - Agentry WPF / ATE clients not launching successfully in Windows 8.1 for SMP 3.0 SDK

 

All Client:

2211721 - Agentry client crashes with "java.lang.IllegalStateException" error

 

We value your feedback to help make our product best in class. Please let us know if you have any comment regard to this blog.

 

You may bookmark this article as we plan to update this article with new SAP notes/KBA/resolution later.

 

Best Regards,

Chung Yu

SAP Senior Support Engineer

Welcome to this overview on How to Trial SAP HCP, mobile service for app and device management. The trial is now available as part of the SAP HANA Cloud Platform Developer Edition. Please note the product name has also changed from SAP Mobile Secure to “SAP HCP mobile service for app and device management”. This blog post will cover the basics on how to get started with the trial.

 

Part 1: An Introduction to SAP HANA Cloud Platform, mobile service for app and device management

 

The mobile service provides enterprises with SaaS-based mobile device management (MDM) and mobile app management (MAM) capabilities without the complexity and expense of an on-premise installation.

 

The service provides the following key capabilities:

  • Single solution to manage, secure and publish mobile applications to their employees, business partners and even their consumers.
  • End User experience can be branded and localized.
  • Enhanced user experience to make it easy for employees to enroll and consume mobile applications easily
  • Support managed and unmanaged users securely.
  • Provides the lowest per device per month cost possible
  • Provides a dedicated environment at shared environment cost
  • Maintenance, upgrades and support are all included as part of the subscription
  • Requires no initial investment for licensing, hardware or equipment
  • Can be deployed in under 15 minutes

 

Pre-requisites:

  1. A free SAP HANA Cloud Portal trial account
  2. An Android, iOS or Windows Phone device

 

Part 2: Step-by-step guide

 

Step 1:

 

The first thing you'll need is a free developer account on SAP HANA Cloud Platform. If you already have an HCP Developer account you can skip steps 1-3. If you have a Production account, you will still need to sign up for a separate Developer account.

 

  1. Browse to sign up for a free account of the SAP HANA Cloud Platform.
  2. Activate your account (via e-mail activation link you received)
  3. Once you have activated your account, simply launch the HCP Cockpit
  4. Now go to Services tab, search for “Mobile Services”, locate and click on “App & Device Management.

Screen Shot 2016-06-09 at 3.39.29 PM.png

5. Click Enable to enable the mobile service (the service provisioning may take up to fifteen minutes or more).

Screen Shot 2016-06-09 at 3.43.49 PM.png

6. Once the service is activated. Click “Go to Admin Console” to get started.

Screen Shot 2016-06-09 at 3.48.43 PM.png

 

Please refer to the following:

 

Documentation:

HCP mobile service for app and device management

Additional documentation

 

Videos:

We are in the process of updating videos to the new UI. You can watch the videos in the Mobile Secure YouTube playlist.

List of videos

SAP Support tries to be proactive in giving resolutions out to the customer to be readily available before the need arises.

 

Based on some internal and external installation of SAP Mobility products, the followings KBA articles will help user troubleshoot Password issue. This article

can be used as reference to known Agentry Password issue.

 

1. SAP KBA # 2193329 - "Invalid user name or password" error when a Transmit session is restarted after an Error 14 - Agentry and SAP Work Manager 6.1

2. SAP KBA # 2152633 - (Agentry) SSO change Password issue (expiration) - SAP Work Manager 6.1 - SMP 3.0 SP04 - SP07

3. SAP KBA # 2160699 - SAP Work Mgr. - Change password not possible in Agentry

4. SAP KBA # 2133215 - Unable to do a local password change in Agentry iOS and Android clients

5. SAP KBA # 2289528 - Changing expired password from mobile device

 

How to KBA

1. SAP KBA # 1839866 - How does the password get encrypted in Agentry? - Agentry and SAP Mobile

2. SAP KBA # 2204360 - Disable(remove) "Change Password" from Agentry Client Login screen - How to

3. SAP KBA # 1919419 - How to change password in an Agentry Android 6.0.34 client

4. SAP KBA # 1815951 - How to access the database name, userID or database password in Agentry to be used in the mobile application? - Agentry

5. SAP KBA # 2287631 - Service Manager expired user password process

6. SAP KBA # 1867137 - How to Create a Self-Signed Certificate Using OpenSSL for Agentry?

7. SAP KBA # 1867061 - How to Create a Self-Signed Certificate Using Microsoft's Certificate Creation Tool? - Agentry

8. SAP KBA # 1839867 - How does encrypted client and encrypted data work in Agentry? - Agentry and SAP Mobile

9. SAP KBA # 2095690 - How to make SSO work if user have deactivated password in ECC - SAP Work Manager


We appreciate all the customers/developers/consultants/Support Engineers who gave all the field report about our SAP products. We value your feedback to help make our product best in class. In this blog, please let us know if you have comment or feedback.


You may bookmark this article as we plan to update this article with new SAP Notes/KBA/resolution later.


Best Regards,

Chung Yu

SAP Senior Support Engineer

Introduction:

This guide describes how to connect HANA to MS SQL Server and create a simple basic view to show all registered Devices in the connected database of the Afaria Server.

 

Used Versions:

Microsoft SQL Server 2014 ; 12.0.4213.0

SAP Afaria 7.0 Service Pack 14

SAP HANA 1.0 SPS12 (Rev. 120) on SUSE Linux Enterprise Server 11.4 for SAP

Microsoft ODBC Driver 11 for SQL Server ; 11.0.2260.0

unixODBC Manager 2.3.0

 

Prerequisites:

Installing ODBC on the HANA Server via this Blog Post: http://scn.sap.com/docs/DOC-68640

Follow Steps 1.0 - 2.4

 

Next Steps in HANA Studio

  1. Connect SAP HANA to MS SQL Server
  2. Launch SAP HANA Studio
  3. Log in to your Databse
  4. Expand "Provisioning".
  5. Right click "Remote Sources" and select "New Remote Source...".

2016-05-12_11-40-01.png

Enter the required Fields:

Source Name: Should match your DSN, but can be different if your like

Adapter Name: MSSQL (GENERIC ODBC)

Data Source Name: Has to match your DSN, the value in the [] in your odbc.ini. Below you will find a sample of my ODBC.ini file

User Name / Password: Here you should use SQL Credentials and not Windows Credentials

 

After filling in all values save the Source. It will be tested automatically.

 

Sample ODBC.ini:

[HBGLAB_afa_latest]

Driver=/opt/microsoft/msodbcsql/lib64/libmsodbcsql-11.0.so.2260.0

Description=HBGLAB MSSQL Server

Server=10.29.78.111,1433

Port=1433

Database=HBGLAB_afa_latest

[HBGLAB_Afaria05]

Driver=/opt/microsoft/msodbcsql/lib64/libmsodbcsql-11.0.so.2260.0

Description=HBGLAB MSSQL Server

Server=10.29.78.111,1433

Port=1433

Database=HBGLAB_Afaria05

2016-05-12_11-41-25.png

2016-05-12_12-24-57.png

Import a Table

  1. Expand your new Remote Source
  2. In the "dbo" Schema all tables can be found
  3. Perform a right click on a table and "Add as Virtual Table".

2016-05-12_12-41-14.png

2016-05-12_12-42-15.png

2016-05-12_12-44-41.png

For our sample here do this for the tables:

A_CLIENT

A_IPHONE_DEVICE

A_ANDROID_DEVICES

 

Create calculation view

Perform a right click on your content package and select new -> Calculation view

2016-05-12_12-45-09.png

Give it an appropriate name and finish

2016-05-12_12-47-02.png

Create 2 new Joins "Join_iOS" & "Join_Android"

2016-05-18_15-10-36.png

In the "Join_iOS" you need to join the A_CLIENT & A_IPHONE_DEVICE table as shown in the Screenshot.

We join them via the ClientUID value in both tables and using a Left Outer join here.

2016-05-18_15-11-24.png

The next join is "Join_Android" for the tables A_CLIENT & A_ANDROID_DEVICE

We use ClientUID again here for the Left Outer join.

For this join we only add values from A_ANDROID_DEVICE as output.

2016-05-18_15-16-23.png

Create a union based on Join_iOS & Join_Android

Drag and Drop the Sources to the Target column as shown below

2016-05-18_15-21-56.png

In the Semantics set the Types as shown below, then save and view the data

2016-05-18_15-29-10.png

2016-05-18_15-32-35.png

Links:

Installing the Driver Manager: https://msdn.microsoft.com/en-us/library/hh568449(v=sql.110).aspx

Installing the Microsoft ODBC Driver for SQL Server on Linux: https://msdn.microsoft.com/en-us/library/hh568454(v=sql.110).aspx

If you have recently tried to create Fiori application using Fiori Master Details Template under WebIDE version 160519 and deployed it to HANA Cloud Platform, you may have experienced an error 404 - Not found when you are trying to access your application through Hana Cloud Platform landscape as shown below:

404.jpg

 

If you do face this behavior, here is what's happening:

 

    1. By default, HCP was looking for index.html in order to load the site or whatever the parameter welcomeFile which is located in neo-app.json under your project in WebIDE.

    2. Now in WebIDE when the user selects the Fiori Master Details template, this template no longer creates index.html and no longer the welcomeFile = "index.html exists in the neo-app.json anymore. The reason for this change is to allow the application to run within Fiori Launchpad which does not require an index.html file. However this change in behavior, causes the application when it is deployed to HCP not to load anymore when it is accessed by the user. Having said that, the fix for this issue is simple

 

Here is how to fix this:

 

      1. In the WebIDE under the webapp folder under your project, create a blank file called index.html
      2. Add the following information below and modify it to match your application and change the following:
        1. Line 14 in the code below make sure that matches your namespace. My name space is called "com.sap.northwind"
          Example: data-sap-ui-resourceroots='{"com.sap.northwind": "./"}'

        2. Line 22 to same as Line 14 it needs to match your namespace, in my example it is:
          name: "com.sap.northwind"

          <!DOCTYPE html>
          <html>
            <head>
            <meta http-equiv="X-UA-Compatible" content="IE=edge" />
            <meta http-equiv="Content-Type" content="text/html;charset=UTF-8"/>
            <meta name="viewport" content="width=device-width, initial-scale=1.0" />
            <title>Northwind OData Application</title>
            <!-- Bootstrap the UI5 core library -->
            <script id="sap-ui-bootstrap"
            src="../resources/sap-ui-core.js"
            data-sap-ui-libs="sap.m"
            data-sap-ui-theme="sap_bluecrystal"
            data-sap-ui-compatVersion="edge"
            data-sap-ui-resourceroots='{"com.sap.northwind": "./"}'
            >
            </script>
            <script>
            sap.ui.getCore().attachInit(function() {
            new sap.m.Shell ({
            app: new sap.ui.core.ComponentContainer ({
            height: "100%",
            name: "com.sap.northwind"
            })
            }).placeAt("content");
            });
            </script>
            </head>
            <!-- UI Content -->
            <body class="sapUiBody" id="content">
            </body>
          </html>
          
          
          
          
          
          
      3. Save the changes
      4. Edit the file neo-app.json under your project in WebIDE which is located on the root of the project and add this line before "routers":

        "welcomeFile": "/webapp/index.html",

        It should look like this:
        {
        "welcomeFile": "/webapp/index.html",
            "routes": [
               {
                 :
                 :

      5. Save the changes
      6. Now deploy your application to HANA Cloud Platform (HCP)
      7. You should be able now to access your application
      8. Here is the end result for my sample running on HANA Cloud Platform Trial Landscape:

        northwind.jpg




 

 




iOS 9.3.2 testing has completed.  This iOS version is now supported for both SAP Afaria and Mobile Secure.  Documentation will be updated accordingly. 


To All SAP Agentry/SMP 3.0 users,

 

SAP Global Services and Support (GSS - One Service) tries to be proactive in giving the solution to the customers to make the knowledge available. We value your time in using our products and we always try to give the best solution out to the customer. Our mission is to give the best support anytime, anywhere and using any device.

 

Based on some internal and external installation of SAP Mobile Platform SDK 3.0 (Agentry) in SP08 to SP12, the SAP team believed that there may be a new security features available in Windows 8.1 OS that is preventing the full successful launch of the SMP 3.0 SDK Agentry WPF/ATE clients successfully. These features may be different in older Windows OS 7 environment.

 

This causes the SAP Agentry WPF/ATE client software (SMP 3.0 SDK) to show the following issues:

 

  • For some Agentry client - during usage or launching of the application, it crashes or gives errors
  • When launching the Agentry WPF client in Windows 8.1, the user cannot get pass the login screen
    • The popup may not be showing
  • The Agentry Editor Agentry Test Environment (ATE) cannot successfully launch the transmission to SMP 3.0

 

To resolve this issue, please do the following:


  1. Always try the latest SMP 3.0 SDK release available in our SAP download area.
  2. See SAP KBA # reference: 2321983 - Agentry WPF / ATE clients not launching successfully in Windows 8.1.


Thanks to all our valued SAP community of users, designers, engineers, partners and others who constantly share their knowledge to help one another to make SAP's support and user community - Best in Class.




Best Regards,

Mark Pe
SAP Platinum Support Engineer

Dear Valued SAP Customer:

This letter provides a notification that beginning with the July 2016 release, the Afaria Windows client will no longer contain support for computers running Microsoft Windows XP and Windows Server 2003.

After this release, the Afaria Windows client will support devices running the following Windows operating system versions: Windows 10, Windows 8.0 and 8.1, Windows 7, Windows Server 2008, Windows Vista

This change does not affect Afaria Windows CE, Windows Mobile, Windows Phone and Windows MDM clients. Please refer to the latest product documentation for Afaria (http://help.sap.com/afaria) for more information.

We regret any inconvenience that this may cause your organization. Our support staff is available to assist you in any way possible.

Here is a joint blog we published with Brad Anderson @ Microsoft to highlight the integration of SAP Fiori Mobile with Microsoft Intune.

 

We are really excited to announce the availability of some of work that Microsoft and SAP have been engineering together to ensure that custom SAP Fiori apps can be enabled with the management and security capabilities that come in the Microsoft Enterprise Mobility Suite (EMS ).

 

SAP has an incredible portfolio of apps.  One could argue that Microsoft is the gold-standard for the productivity tools that the world uses, and SAP is the gold-standard for the business apps.  Thus, it makes sense that customers would want both of these sets of apps to securely share data and empower users to achieve more!  And that is exactly what we hear from customers around the globe!

 

Engineering this integration to be both empowering and secure took some thought and innovation.  There were a couple key customer requirements we had to think through together:

 

  • Organizations want their users to be able to access all the data and apps their employees need, and they want to ensure the corporate data is separated from personal data on devices and has security and protection applied to it.  This is important for helping protect company assets as well as removing/wiping company data if necessary – all without touching any personal data.
  • Organizations want to empower their users to be able to re-use the business data across all business apps via capabilities like cut/copy/paste, but limit or prevent cut/copy/paste from business apps into personal apps.  These are key data loss prevention requirements to help guide user to keep the company data protected.
  • Organizations want their business apps to be tailored specifically to their needs (something SAP has a rich history of doing).

 

Together, Microsoft and SAP are delivering a solution that meets all of these customer requirements – and we are unique in delivering this.  You may remember that SAP blogged about this collaboration back in November, and today we’re announcing that the technology enabling these integrated scenarios is in public preview @ SAPPHIRE NOW and will GA in early Q3 2016.  Intune is the first EMM solution integrated into the SAP HANA Cloud Platform Fiori Mobile integration framework.

 

Here’s how it works:

 

  • SAP has developed SAP HANA Cloud Platform mobile service for SAP Fiori.  This is a cool service that enables SAP customers to easily generate custom SAP Fiori apps enhancing the SAP Fiori user experience with mobile qualities and significantly improving the usability while leveraging the investment customers made to deploy SAP Fiori applications. I think this is a tremendous innovation from SAP.
  • The Microsoft Intune App SDK is encapsulated in a Cordova plug-in that SAP has integrated into the mobile service for SAP Fiori.  If a customer is an EMS or Intune customer, when they build their custom SAP Fiori apps, the Intune mobile application management (MAM) capabilities can be automatically added to the apps.
  • The SAP Fiori apps are then published to SAP’s enterprise apps store – SAP Mobile Place.
  • The SAP Fiori apps can then be downloaded and published to Microsoft Intune where IT Pros can manage the full application lifecycle, including native MAM controls. In the future, we continue to invest to make the integration even more seamless.

 

At that point the apps can be pushed, the users’ mobile devices or the users can install the apps from the Intune Company Portal.  Because the Intune MAM capabilities are integrated into custom SAP Fiori apps, they have the same level of in-depth management as other apps like the Office mobile apps, Box and Adobe Acrobat.  Intune adds value to the capabilities that ship in iOS and Android to enable the top two customer requirements above.  And, because the Office and Fiori apps are participating in the same MAM solution they can securely share data on any device.  Very cool!

From the customer’s standpoint, with a few simple configuration steps, any current or net-new, SAP Fiori application can be consumed as a robust, highly customized, responsive mobile app. With Intune Integration, deployment and management and data loss prevention becomes a breeze as well.  There are a variety of SAP Fiori standard apps available already (it is an impressive list) go to this link!

 

Here is a view of building a custom SAP Fiori app with the Intune MAM capabilities auto-integrated into the apps.

 

SAP Fiori Mobile - Microsoft Intune integration video

 

We are really excited about this partnership.  And even more excited about the empowering environment that this delivers for end-users, while also delivering what IT needs in protecting the company data. This is just the first step in the SAP and Microsoft partnership. We look forward to continuing to expand the partnership.

 

Senthil Krishnapillai                                                                 Brad Anderson
Global Vice President - SAP                                                   Corporate Vice President – Microsoft

SAP Afaria 7 SP14 has been released and is available for download in the SAP Support Portal.

Please check the Readme for further details. The Product Documentation will be updated shortly with the SP14 documents.

 

If you would like to stay tuned on the latest news around Afaria, you may want to watch this wiki page to receive update notifications.
Hint: You need to be logged on in order to have the "watch this page" option available.

Abstract

 

SAP Fiori is SAP’s new web-based User Experience approach going forward. Being designed for omnichannel consumption of information, it is a natural fit with SAP’s Mobile offering. Nevertheless Mobile Computing is a broad field that comes with its own specific requirements and challenges. This paper discusses some advanced topics centred around architecture and life cycle management that apply to Hybrid applications in general, and to SAP Fiori in particular. First a description of various consumption models is given. Then the strengths and weaknesses of these approaches are presented. Finally reference architectures for Life Cycle Management are given for each of the approaches.

 

Related topics:

            How to Create The Offline CRM App Part 1 | Part 2 | Part 3 | Part 4

 

 

Browser-based Fiori

 

Fiori applications are typically consumed via standard browsers on desktop computers. In this scenario the Fiori Frontend Server (FES) acts as a web server, providing both the web applications and the underlying web services on a single host. Since Fiori apps are thick clients, the server does not need to provide any complex services beyond what is encapsulated by the OData services serving the corresponding application.

 

Figure 1 depicts this situation using the example of the Fiori Launchpad itself. It should be noted that it is not treated specially by the FES, making it a regular Fiori application. In this case we assume a simplified scenario, where the Launchpad is loaded as a whole, and does nothing but querying its associated OData services for the current user’s Fiori application catalog and configured home screen tiles. In reality Fiori applications are typically loaded in modules, meaning that requests retrieving code and data are interleaving each other. This applies to the Fiori Launchpad in particular, since it first retrieves the minimal amount of information required to display one’s applications. Only when an application tile is clicked, the remaining code for this particular application is being lazily loaded.

 

fig1.png

Figure 1: Standard Fiori client-server architecture and interaction


While this architecture implies that the application itself needs to be transferred to the client before it can be executed, it makes managing updates rather easy. Proper browser-based caching will ensure that round trips are reduced once the code has been transferred to the device, while still allowing code updates once the application deployed on the FES is changed centrally.

 

Fiori Client

 

As can be seen in Figure 2, the Fiori Client runtime looks very similar to regular browser-based Fiori consumption. Most notably no changes on the server side are involved. The difference is that this consumption form applies exclusively to mobile devices, such as iOS and Android phones. Rather than opening a browser window to the Launchpad, the users are installing a proper application that emulates browser behavior. Technically speaking, the Fiori Client is a simple single-screen application, which contains a single WebView. Those views are used to embed HTML content from external and local sources into native applications, and in this case it is used to display the whole user interface in terms of the Fiori Launchpad. While this brings Fiori closer to a native experience in terms of a proper application icon on one’s phone home screen, it is important to note that from the server-side both consumption forms are equivalent.

 

fig2.png

Figure 2: Fiori Client client-server architecture and interaction

 

What is the added value of using the Fiori Client then? A look under the hood reveals that the Fiori Client is in fact implemented using Cordova, a hybrid application framework that exposes native device capabilities to web-based applications. While the HTML standard is generally catching up with the features available on the average computer (i.e., including phones) nowadays, there are still huge gaps. For instance, Cordova provides access to sophisticated capabilities such as the user’s personal address book, and even platform-specific features such as the iOS fingerprint protection. This generally enables developers to write true cross-platform omnichannel applications, while still allowing access to platform-specific features depending on the runtime environment.

Figure 3 shows how these features are made available to the web application rendered within the Cordova container. As outlined before, the single most important piece in the Cordova application is the WebView which renders and executes arbitrary web applications, such as the Fiori Launchpad. It also exposes additional JavaScript-based Application Programming Interfaces (APIs) that are loaded from a number of plugins, two examples being the aforementioned contacts or fingerprint scanner plugins. There is a large number of open-source standard plugins ready for use, but developers are not limited to what is already available. It is also possible to implement and consume custom plugins. For instance, SAP also provides a collection of vendor-specific plugins, such as the app update and offline OData plugins.

 

  fig3.png

Figure 3: Cordova Architecture. Based on the official documentation.


Failure Scenarios

While the above setup generally works extraordinarily well under office conditions, it is important to note that we are in fact looking at a distributed system, and with that come the challenges particular to distributed computing, the most important one being the network itself. Despite the perceived stability of networks, they are very fragile especially in large scale. Not only are there many potential points of failure on longer routes, the data transfer rate typically also declines, leaving more time for failures to actually become apparent.

There is a multitude of possible causes of network failures, e.g. faulty hardware, peaks in data centers, or just the user moving between access points. Therefore in this section we are emphasizing the symptoms rather than the causes during two different points in time of the application life cycle: One while arbitrary code is being loaded, and one while data is being transferred.

 

  fig4.png

Figure 4: Network failure during initialization


Figure 4 depicts the former scenario, in which a network outage occurs while code is being loaded. In this case the effects are difficult to anticipate, since it depends on which component exactly failed to load. Continuing the example of the Launchpad, here are some examples:

  • The style sheets fail to load. The page works but looks broken.
  • A JavaScript module fails to load. Part of the page is not working, or a white screen of death occurs.
  • The application fails to load altogether and the WebView displays some network error message.
  • Either of these errors may occur when a tile is clicked, resulting in a failure to open the corresponding application.

These scenarios have in common that it is generally very difficult to catch and handle the related failures, the problem being simply that an application that is not fully loaded is unable to handle errors of any kind. In addition browsers do not expose an API to detect script load errors from within the WebView, making recovery even more difficult. Regardless if the Fiori Client or a browser is being used, there is no reliable and consistent way to deal with these failures short of having the user reload the application until it works. Caching does help a lot to mitigate these issues, albeit only once the application has been loaded successfully and until the caches are invalidated.

 

fig5.png

Figure 5: Network failure after initialization


In comparison, failures while loading data, as shown in Figure 5, can be handled easily by the application itself. Since it should generally be assumed that any network request may fail easily, most applications should deal with this failure scenario out of the box, e.g. by automatically retrying a number of times or notifying the user that due to network issues the requested information could not be displayed. What is crucial in these scenarios is the distinction between code and data: Even though the same causes for failure may apply, error recovery in the latter scenario is much easier, simply because the code required to handle it is already on the device.

 

Packaging

 

Packaging is a means of ensuring that failures such as depicted in Figure 4 can never happen by making sure the code is already on the device. This is actually the “intended” way of working with Cordova: When a template project is created from the Cordova Command Line Interface (CLI), a web app folder is actually created within the generated native application. The web app sources reside within this folder, rather than being loaded from the server. In that regard the Fiori Client is a special case, somewhere in between standard Cordova applications and the more traditional use of WebViews: While it enables the consumption of device-native features, it does not require you to have the application sources on the mobile device. This also makes it rather easy to derive the meaning of “Packaging” in the context of the SAP Mobile offering: It means moving the Fiori application code, including a Launchpad, from the server to the mobile devices, so that both native and web application code are installed alongside on the device.

 

fig6.png

Figure 6: Packaged application client-server architecture and interaction


Figure 6 outlines the difference to the other consumption models. Most notably it is irrelevant to the mobile application what is being deploy server-side in terms of web applications. The only thing that matters is that the required web services are up and running. This does not imply that there must not be application code deployed to the FES. On the contrary, both packaged and traditional applications may be used alongside each other.

 

Implications

 

As was discussed in the Section “Failure Scenarios”, the most obvious benefit of packaging applications is that network-related crashes are impossible, assuming that the packaged applications themselves are properly suited to deal with such situations. However, there is another benefit related to eliminating the network factor during initialization: Startup time. Especially the first start of a Fiori application may take longer than usual because the application code actually needs to be downloaded before it can be run. This means an occasional additional round trip, which may or may not be very noticeable depending on the network quality. Worst case the previously outlined failures may occur. On average the startup time is increased significantly due to the low transfer rates on mobile data networks. Once the applications are fully cached, best-case performance can be reached by saving these addition server round trips. Packaged applications, however, always guarantee the best-case application performance.

On the other hand, packaging is a typical time-space-tradeoff: Processing and network time is reduced by increasing the size of the built application. This is an issue with the average UI5 application since packaging also involves all dependencies of the packaged applications, and a full packaged UI5 distribution may lead to application packages well beyond eighty megabytes in size. However, considering that UI5 may be minimized in terms of the number of packaged modules, in practice the increased application package size may be neglected. Packaged applications and the Fiori Client alike are typically around thirty megabytes in size, most of that being plugins. For instance, the popular Crosswalk (XWalk) drop-in WebView replacement alone consumes around twenty megabytes in size on Android.

There also is an innumerable amount of differences in implementation details between a packaged Fiori application and the Fiori Client. While both are Cordova applications inside, the standard Fiori Client comes prebuilt with a huge number of plugins. This is the reason that the standard Fiori Client has a “double tap to open menu” feature, while standard packaged applications do not have it. Since both the Fiori Client and packaged applications may be customized to the heart’s content, this is more a matter of degrees than a sharp line between both consumption models. Generally a packaged application can be taken arbitrarily close to the Fiori Client in terms of behavior and features, and the other way around also works. It would, for instance, be possible to copy an arbitrary amount of Fiori applications and a Launchpad into a Custom Fiori Client project, and have the Custom Fiori Client display the local Launchpad rather than the FES Launchpad. Whatever is implemented in the Launchpad can easily be moved to packaged applications. The only real challenges are server-side components that are not part of the actual Launchpad, such as Gateway Logon classes. When the SAP Mobile Platform[1] (SMP) is not used, it may be necessary to add a login view to the local Launchpad that sends the user logon data to the Gateway logon class.

However, the biggest open question is: How do the applications actually get from the FES onto the device, when they are not being loaded directly during runtime?

 

Life Cycle Management for the Fiori Client

 

In order to comprehend the full implications of packaging, especially when it comes to Life Cycle Management (LCM), we first need to establish a reference architecture for the development environment prior to packaging. For that purpose, we revisit the simplified architecture from Figure 1. Figure 7 shows the same situation in a bigger context. Most notably, it can be seen that the simplified model introduced in Figure 1 is actually replicated across a number of mostly identical system landscapes: One for development, one for tests, and one for production. This is in fact more an example than a fixed rule; there may also be less or more stages on the way from development to production. The important thing is that applications are deployed once to the first stage (development), where they are tested. Once the quality check passes, a transport is requested from the first to the second stage, effectively updating the application on the second stage to the version on the first stage. This is repeated from stage to stage until the application is finally being deployed in production. This does not only apply to the FES, but also to backend systems. The FES separates the upstream landscape simply by means of named connection mappings. The application itself does not know to which backend system it is talking, but requests a generic endpoint that the FES would resolve appropriately according to the system configuration.

 

fig7.png

Figure 7: Mobile Fiori Life Cycle Management architecture


The journey of the code does not begin in the first deployment stage, however. The application is code in the WebIDE and shared between team members via Git, a source code management (SCM) system. Once a unit of work, e.g. a feature, is completed, the change is pushed into the upstream Git repository[2], from where the current project status is retrieved by a Continuous Integration[3] (CI) server. The CI server then continues to build the project and execute the project test suite. Only when these steps are successful, the built application is deployed to the first test stage.

It is easy to see how manual tests would be carried out from the browser: Each of the deployment stages comes with a full Fiori stack, so that each of the FES has its own Launchpad. On the mobile device this is somewhat trickier: A Standard Fiori Client is configured against a single FES, and one application (identified by its bundle ID, e.g. com.sap.fioriclient) may only be installed once per mobile device. Therefore it is either necessary to use different mobile devices for each of the stages, or to build three Custom Fiori Clients with different bundle IDs that may be deployed to the same device (e.g. com.sap.fioriclient.dev, com.sap.fioriclient.test, com.sap.fioriclient.prod).

Going forward we are going to assume the latter approach is taken. Since now development, build and distribution of the Custom Fiori Client itself become a concern, Figure 8 shows the corresponding LCM view on the mobile development landscape.

 

fig8.png

Figure 8: Typical Mobile Life Cycle Management architecture


It can be seen that apart from using a different set of tools for development, the build and test infrastructure still is the same with Git and the CI server in its center. The first large difference is that a Mobile Device Management (MDM) solution such as SAP Afaria[4] is the target of the CI server deployment rather than a FES. Secondly, it can be seen that it is not typical to replicate MDM systems for each testing stage. Instead, different application configurations are created in the MDM system, one for each Custom Fiori Client. Thirdly, the CI server builds one version per stage per update, resulting in three built Custom Fiori Clients per update in the current example, which are then pushed to the client devices. As outlined before, the mobile applications only differ in their configuration, and the subjects under test (SUTs) are the Fiori applications rather than the Custom Fiori Client. Therefore the separation between FES is sufficient, and switching to a different Custom Fiori Client stage is equivalent to switching to another FES Launchpad stage. The beauty here is in the clean separation between web application and native code, as was hinted in Figure 3. The Custom Fiori Client merely provides a shell in which the Fiori applications may run, and it only contains the rather rarely changing native components of a hybrid application. The more frequent application updates follow the quality assurance path shown in Figure 7, whereas Custom Fiori Client updates are shipped occasionally via the MDM solution.

 

 

 

Life Cycle Management for Packaged Applications

 

Now that a reference LCM architecture has been established prior to the implementation of packaging, we can now take a glimpse at the changes packaging would introduce. Figure 9 provides a unified view on LCM for (packaged) mobile and web-based Fiori applications.

 

fig9.png

Figure 9: Basic packaged application Life Cycle Management architecture


The first conclusion is that both approaches may actually coexist, which makes it easy to experiment with packaged applications while the existing system landscape remains largely untouched. In fact the packager included in the SAP Mobile SDK leverages FES as the source of truth, downloading apps and their dependencies from there. Secondly the CI server now not only builds and deploys to the FES once per Fiori application update, but it will also need to rebuild and redistribute the packaged applications to the mobile devices. This potentially introduces significant additional load on the MDM, depending on the frequency with which Fiori application updates are checked in. For this reason SAP provides the App Update plugin, which enables packaged applications to connect to the SMP and update themselves if a newer version of the web applications is available.

 

 

 

Figure 10 shows an updated architecture incorporating the (so far optional) SMP. In this setup the MDM service is only used for the first-time installation and updates when changes are made to the native application components.

 

fig10.png

Figure 10: Packaged application Life Cycle Management using SAP Mobile Platform


Just as before, when a Fiori application is updated in Git, the packager is triggered to assemble the required web assets for the packaged application Cordova build. This intermediate build result can now be used to create a web application package using the Mobile SDK Kapsel CLI and upload it to the SMP. Then it can be rolled out either automatically or manually to a number of test devices, or to all registered devices. The most important bit here is that the SMP calculates a delta based on previously uploaded web application packages, and only sends the differing files to the devices. This way frequent updates of thirty megabytes and above can easily be cut down to single-digit numbers and below.

 

Challenges unaffected by Packaging

 

On the previous pages we considered how packaging Fiori applications affects the LCM and client-server interaction. However, it is also important to understand that there are challenges in Mobile Computing that cannot be addressed by packaging, the most notable being processing power. Mobile devices generally have less computing power, main memory and storage capacity than the average desktop computer. While it is true that packaging may improve overall performance by eliminating server round trips due to code loading, it does not affect the performance of the applications themselves, i.e. their consumption in terms of processing power and main memory. To the WebView, it does not matter if the same piece of code was loaded from the local file system or from a remote server. The remaining network performance is not affected either, i.e. slow data requests in the Fiori Client will not complete faster in packaged applications.

 

Further Steps – Taking It Offline

 

With the packaging in place, network-related failures to load the application are mitigated. While this greatly improves stability, it does not address performance issues, since uncached data requests still require full server round trips, and especially time-intensive data requests are vulnerable to connection interruptions. Therefore it makes sense to think about going the extra mile and also implementing the SMP Offline OData support. Figure 11 shows an updated runtime architecture diagram, continuing the Fiori Launchpad example we used previously.

 

fig11.png

Figure 11: Packaged offline-enabled application client-server architecture and interaction


Rather than having the applications access the remote OData service directly, the SMP provides the client with a local database that is used to feed a local OData producer. Requests on the client are then rewritten to the local OData provider, allowing near-instant access to the data. Not only does this enable scenarios that are otherwise impractical due to network unavailability, but it also helps you provide a very fluent user experience. The local offline data can be synchronized with the backend in the background whenever network connectivity is available.

 

Conclusion

 

In this paper the technical concept of packaging, i.e. moving web application code from the Fiori Frontend Server onto a mobile device, was discussed. It was shown that both traditional Fiori consumption models (browser, Fiori Client) may coexist with packaged deployments without interfering with each other. The biggest difference between the approaches is in the life cycle management, which may or may not lead to additional load on the Mobile Device Management solution. It could be shown, however, how this issue can be addressed by leveraging the web app delta update capabilities of the SAP Mobile Platform.

 


[1] Throughout this paper the term SAP Mobile Platform may be exchanged equivalently with HANA Cloud Platform mobile service.

[2] This blog describes a typical approach to separating finished work and work in progress by means of Git branches.

[3] Martin Fowler described CI in depth on his homepage.

[4] Throughout this paper the term SAP Afaria may be exchanged equivalently with SAP Mobile Secure.

Actions

Filter Blog

By author:
By date:
By tag: