1 2 3 68 Previous Next

SAP for Mobile

1,008 Posts

I have been working on Security for SAP's Mobile Applications for a few years now with internal developers, and the biggest challenge still seems to be communicating secure development methodologies in a world where the underlying infrastructure changes every few weeks, development paradigms evolve, and innovation happens rapidly in the application and platform spaces.


I can only imagine how tough it must be for developers outside of SAP to keep up with that change, and I think we need to do a better job helping them. The topic came up in the context of partner app certification, and the colleagues from the Integration & Certification Center have created a document with guidelines for partners that is supposed to outline the major security measures we would like to see adressed in mobile applications:


Mobile App Security Guidelines


I'm linking to this here also as a request for comments & improvements. I would like to use this blog as a landing page for Mobile Security information for developers; I'll try to curate the links here by technology.


Feel free to pint me to content that you think is relevant and should be included here.


Generic Mobile Security Links



SAP Mobile Platform











SAP Mobile Secure & Afaria


Beginner, Int, Expert.JPGI always attempt to push the envelope and ski the expert slopes. Going to undergrad school in Colorado helped fuel that extreme ski hobby.  A few Wide World of Sports crashes along with pointers from really gifted athletes helped even more. Pointers from experienced enterprise mobility experts offer the same guidance in the new Enterprise Mobility Strategy Map here. Whether beginner, intermediate or expert there are many trails or best practices to follow. A few suppliers offer the entire mountain, most offer only one or two type of slopes as is true in the ski industry. Let’s have a quick look at the map including some advice for Map contributor Maribel Lopez.



For starters, the easy green slopes often start with enterprise mobility management. The suite includes mobile device management, content management, app security and distribution. Many firms offer these basics often as highly-stylized “window pleasing” loss leaders. The underlying functionality is often dependent on the APIs or software levers exposed by the device manufacturers. For most enterprises this translates to iOS, Android and Windows Phone 8. Providing industry access to APIs is one of the primary reasons that Blackberry failed to hold onto enterprise leadership and support in EMM suites. No ski lift, few skiers as other slope operators simply offer more attractive operations.


Enterprises looking for the Blue Intermediate slopes are after mobile applications. These include field service apps, workforce management apps, retail analytics apps or even point of sale apps. SAP offers more than 300 mobile apps as a starting point here. Of course, enterprises will often want to customize or modify a mobile app to meet their specific needs including support for cross platform development and offline data. Business users often don’t start sequentially on the “easiest” slopes instead realizing the productivity gains of incorporating mobile apps in their businesses like Phillips 66 or Hallmark via Verizon. Both of these examples point to the larger trend of businesses looking to suppliers offering the entire mountain experience of the Mobile Strategy Map.




The tram doors open at top of Snowbird ski area in Utah during a complete whiteout. With a bit of experience beforehand, a few strategically placed guideposts and even a mountain guide the trail down is exhilarating. This is based on a true story in Snowbird and taking my then 13-year old on his first trip to Utah. Ascending to top of the Mobile Strategy Map through a trusted tram enterprise IT owners and their users will get to use all of mountain’s slopes. Case study in point here is National Grid, owner and operator of the electricity and gas transmission network in the UK including overhead lines, underground cables and pipes, substations and compressor stations. This “half pipe” snopark example shared their own story here and included comments such as: “combining core business functionality with enhanced capabilities, like taking photographs at the point-of-work and on-demand access to asset and work history, which dramatically improve decision-making and cost savings.”



Hopefully you’ve enjoyed this picturesque mobile journey as much as the SAP Mobile extended team did in building it for our customers, partners and prospects. I think you’ll agree after taking a few of the trails that there are a number of great and highly customizable approaches to your mobile journey. One size certainly doesn’t fit all and no business should start the mobile journey without considering what the future holds. Now there is a mobile map available to help point out the pitfalls and benefits of enterprise mobility for all levels of users.

While testing applications, we used the below strategies and it took us some time to work these out. So I sum these up as reference - I trust people will find it useful. These are based on my experience in dealing with iOS apps.

Problem 1: I was working on an enterprise mobile application project but we couldn’t use the organisation’s pre-existing mobile device management ( MDM ) solution. This can happen due to any number of factors - in our case, the app was simply too big to be supported by the current version of MDM solution (it’s not a SAP MDM solution ).

Solution :

We used the below alternatives and they can be employed to work.

1. DropBox. A simple html page can be created in DropBox which points to the app’s plist file ( property list file ) and the plist file in turn will point to the relative location of the .app file. I kept the app in the Public folder of dropbox.

Let me draw a picture to make it clearer.

Screen Shot 2014-08-23 at 11.07.08 pm.png

2. TestFlight: I wasn’t aware of this site when we were first working on testing release I but found it extremely useful for subsequent releases. You can set up a project team, assign users to test and check the devices registered.

See the sample screenshot below.

Screen Shot 2014-08-23 at 6.png

3. Through a public site. You’ll need infrastructure team to create a publicly accessible domain ( if you want them to access via normal internet ).

Add the below MIME types to your web server ( for IIS ).

Mime type for plist -> application/xml

Mimet type for ipa -> application/octet-stream

4. The most obvious one : If the users can come to your desk, of course just use Xcode to install by making the device a developer device.

Hints on creating the HTML page:

a) Create the HTML page - this page will point to the plist file.


<a href="itms-services://?action=download-manifest&url=http://dl.dropbox.com/u/xxxxxxxxx/app_live.plist">Download App</a>

This will create a quick and dirty page for users to install the app.

Screen Shot 2014-08-23 at 5.58.09 pm.png

Of course, you can make it better by adding icons etc.

b) The plist file will in turn point to the .ipa file. You'll need to edit it manually from the one generated by Xcode.

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">























   <string>Name Of Application</string>






Problem 2: While testing we realised that sometimes the user's app version was outdated and they'll report issues or have inconsistencies due to a lower version. This can cause a lot of confusion.

Solution :


- Store the supported version of the app on a text file in an external URL .

- Get the version of the app and compare the version from an external URL.

- If the version in the app is lower than the supported version , display a message asking the user to upgrade and quit.

The supported version may not be the current version of the app - for minor UI tweaks, we may not change the supported version but if there are changes to the underlying object structure, the supported version will need to be changed.

Sample Objective-C code:  We can put it in the Main View Controller.

Main view controller :


    [self checkifObsoleteAppVersion];


- (void) checkifObsoleteAppVersion{


//Get version from external site

    NSString *versionURLString = @"http://URL/version.txt";  //<<-- Version information stored in a simple text file

    NSURL *versionURL = [NSURL URLWithString:[versionURLString stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding]];

    NSString *versionOnExternalSite = [[NSString stringWithContentsOfURL:versionURL encoding:NSUTF8StringEncoding error:nilsubstringToIndex:6];


//Get version from App

    NSString *versionFromApp = [self.syncManager.appVersion substringToIndex:6];


//Format the versions to numbers

    NSNumberFormatter *versionFromAppNo = [[[NSNumberFormatter alloc]init]autorelease];

    NSNumber *appNo = [ versionFromAppNo numberFromString:versionFromApp];


    NSNumberFormatter *versionFromAppNoExt = [[[NSNumberFormatter alloc]init]autorelease];

    NSNumber *appNoExt = [ versionFromAppNoExt numberFromString:versionOnExternalSite];


//App version shouldn't be lower than the one maintained in version file


    if ([appNo floatValue] < [appNoExt floatValue] )



// Show a message

        UIAlertView *appObsoleteView = [[[UIAlertView alloc]initWithTitle:@"App version obsolete" message:@"A new version of App has been released and this version is obsolete.Please upgrade App to the new version." delegate:self cancelButtonTitle:@"Exit" otherButtonTitles:nil, nil]autorelease];

        appObsoleteView.tag = 666;

        [appObsoleteView show];








Problem 3: Just putting as a reference to consolidate the information in a single place. Users were required to be manually registered and there were issues caused sometimes due to wrong information being set up due to manual process.



I created a solution using SUP's Java APIs and shared the experience in an earlier blog.



The possibility of potential Fiori applications are endless, and it is an exciting time to be involved in SAP Fiori development right now.  While SAP provides us 360+ out of the box applications, it is not nearly enough to cover all of the business functions that may need to be accessed on the go. There seems to be a lot of interest in this topic, but confusion on how to get started.  This blog attempts to clarify some things.


First, what is needed from an architecture standpoint to start development?


Development Environment (UI):

You have two options here, for the record I prefer the Fiori RDE:

  • Eclipse: Open Source IDE which has UI5 plugins to build the applications.  Make sure you install the ABAP Team Provider which allows you to “push” your code to the SAP Backend for consumption.

       Information can be found here: https://tools.hana.ondemand.com/

  • Fiori River RDE: Rapid Development Environment, and a completely web based tool.  Connects to the HANA Cloud and allows you to deploy them to any connected instances.  Great functionality for code completion and suggestions.

       Check it out here: http://scn.sap.com/docs/DOC-55465


One of the most frequently asked questions I am asked by customers is: “How long does it take to build a custom Fiori App?”.  The answer to that varies widely, and truly cannot be answered until the business requirements are clear.  At NIMBL, we do a hands-on session with the business process owners, technical and functional teams and anyone else that needs to be involved to ensure a thorough blueprinting session is done.  The following factors greatly affect the timeline:


  • Number of screens and complexity of UI controls
  • Does the Backend logic(ABAP) already exist? (Can be leveraged in Fiori)
  • Is Gateway already installed in the landscape
  • Are there custom CSS considerations needed, or is the standard Blue Crystal theme sufficient


These are just a few factors (there are many more), but it is important to set the groundwork for a successful implementation.  Part of this process includes creating mockups that are reviewed by the business to ensure that all design and functional requirements have been met.  And this is all before development even begins!


The next question that I get a lot is: What kind of skillset is needed to build Fiori Applications? The main skillset needed is SAPUI5, which is the development framework for Fiori.  Next is Javascript, XML, HTML and some CSS.  Finally, having a background in ABAP is important (especially for troubleshooting).


Finally, I’ll list some examples of custom Fiori Applications that we have built – this is not an exhaustive list, but meant to show the possibilities:


Shop Floor App: The customer was using old barcode scanners with ITS Mobile.  They used the scanners to track equipment coming in and out of the plant, and track inventory.  The complaint was that the GUI screens were slow, and after each scan there would be a long wait while the system updated.

The customer was getting in new touch screens, and they wanted to build intuitive, fast screens that could handle several scans per minute.  We built this custom app using Fiori as the front end, and the results were immediate.  Productivity was significantly increased, the users were very happy with the new screens and the customer is undergoing a major transformation in their business to build more Fiori applications.


UWL(Universal Worklist): This customer wanted to expose their UWL on Mobile Devices.  They wanted to create an intuitive UI with the option to group the requests by type – Leave Approval, Time Approval, etc.   Yes, standard Fiori offers these individual applications out of the box, but they wanted a single screen to see all of their pending requests.  The customer was launching a new BYOD initiative, and after rolling out the new application to several people the feedback was very positive.  The customer is currently expanding on their mobile strategy and plan on rolling out several new ESS/MSS applications later this year.


Transportation Management App: This application is still a work in progress, and will be available soon.  We are working closely with SAP on building a Fiori application on HANA that will pull all transportation orders from SAP (including Date, Delivery Location) and pull in the Weather forecast from Weather Underground. The US government has created key KPI’s that determine how weather affects transportation and travel.  The application will use the weather forecasts as well as the KPI’s to determine the risk associated with on-time delivery of the shipment.  This scenario is only the tip of the iceberg, we plan on expanding this application to do much more – stay tuned.

David Clavey

Agentry OpenUI WebView

Posted by David Clavey Aug 18, 2014

While I as exploring the capabilities of Agentry 7 (i.e. as found in SMP 3.0) and the ability to improve the UI creation, I came across this youtube Video which I think explains it all in a visual way.




By Olivier Mercier


Well done perfect in every way, except perhaps the backing track !



Syclo agentry list view from agentry player.

Creating a customer class / components

Using native code

Render using HTML ?

Add social controls

Adding external fields.


Example using Android and OpenUI

Q&A 4.png


As part of the SAP Integration and Certification Center, I have the opportunity to collaborate with various SAP partners and third-party vendors who enrich and contribute to the ever growing SAP Partner Ecosystem by integrating their solutions with SAP platforms.


This is especially true in the area of mobility with the recent launch of SMP 3.0, SAP's flagship enterprise mobility platform. This release promised exciting new features to ease development and marked the arrival of a truly unified platform. Actually, many partners who have developed mobile apps on the Sybase Unwired Platform (SUP) or earlier versions of SMP have inquired about this new release in order to migrate their mobile solutions.


In an effort to shed some light on this, we have reached out to a few very early adopters of this new platform so they can share their mobile app development experience on SMP 3.0 with the broader SAP Community Network.


Here are a few excerpts from the first installments of this series:


What motivated you to jump onboard SMP 3.0?

As a professional, SMP 3.0 is a great fit for mobile-minded organizations: Mobile apps can be quickly designed, deployed, and managed using open standards and future-ready technologies.

As an enthusiast, the past few years of SAP products and direction have been historically exciting to say the least. REST APIs, OData, native apps, hybrid apps, and complete application lifecycle management? Yes, please.

I was further inspired to dig into SMP 3.0 and the related technologies from SCN content, openSAP courses, and SAP contests such as the SAP Game On contest. On SCN, John Wargo’s and Daniel Van Leeuwen’s content motivated me to dig into Kapsel, and DJ Adams inspired me to investigate a RESTful approach, SAPUI5, and my dim awareness the combination of two may be pretty powerful.


How would you compare your team’s experience developing mobile apps on this new version of SMP 3.0 versus the older one?

SMP 3.0 Native SDK is developer friendly to quickly enable integration with OData services compared with SMP 2.3 Native OData SDK. The build time with SMP 3.0 was reduced by around 20 % compared with SMP 2.3 Native OData SDK.


First impressions are the most lasting. With the positive comments we have received, it certainly looks like SMP 3.0  is off to a great start.


To read the complete Q&A session, please use the following links:


I hope you will enjoy reading about the partners' experience. If you would like to see more blogs like this, please comment below. Or you can simply use the like button if the information presented here was of interest.


Thank you !







Quick links for the mobile app certification on SMP 3.0:

Many of us have already experienced some part of the intersection of mobile and cloud. This should not come as a surprise since the emergence of the Mobile Cloud is the number 1 Technology Trend for 2014 according to the Top Technology Trends for 2014. IEEE Computer Society Journals. 2014.

As IT leaders and seasoned professionals we are asked to provide guidance on top trends like Mobile Cloud among others. "According to a roundtable of IT executives and tech recruiters, the top IT job skills for 2014 are big data, mobile, cloud, security", Hammond, Teena. "Top IT job skills for 2014: Big data, mobile, cloud, security." TechRepublic. 2014.

IDC Cohesive Platform Report.png

In the spirit of sharing best practices and knowledge, I would like to bring your attention to a new IDC research report and webcast with you that addresses mobile with big data, cloud, security and analytics. Reference these materials as you define, or even redefine, your strategy at the interaction of Mobile and Cloud.


In the IDC Report "Bringing a Cohesive Approach to a Complex Market", leading technology market researcher Jean Philippe Bouchard discusses some of the key trends taking place in the enterprise mobility landscape today, such as consumerization of IT (CoIT), the mobile application  explosion, and cloud computing. He explores how these paradigm shifts create opportunity while also driving the need for new technology solutions in the "third wave" of IT shifts. Bouchard provides an summary of his analysis of SAP's cloud and mobile enterprise solutions and even maps to current and future business and IT requirements.  The most valuable part of this paper is the essential guidance given to help end users and partners develop a strategic plan. You can access this report here.

In addition to the report, John Jackson, Research Vice President of Mobile & Connected Platforms at IDC, and Rick Costanzo, Global Mobility Solutions EVP & GM at SAP recorded a webinar about the IDC research behind the report and outlined how solution selection is a “future proofing” opportunity. For example, here is one of the fascinating findings from the IDC research that is shared in the session.

Mobile Cloud Webinar Slide.JPG

You can access the full recording that includes other research findings like the one above here.


While the research, report and webinar are a few resources to support your strategizing of mobile cloud, your personal experiences are also important. Please comment on this blog to share your thoughts and events around the intersection of mobile and cloud. Together we are learn together during this "third wave" of IT.

  • September 9, 2014
  • Click here for course details and to register
  • MOOC (massive open online course) hosted by openSAP (Website, SCN)
  • Free of charge!


This is a six-week course where you will learn about SAP Fiori UX fundamentals and the latest features. You will learn about product installation, configuration, and best practices for extensibility.


For more information and to register, please see the course description here.

Apple is now rumored to be holding their next iPhone event on September 9th, 2014 in what is becoming one of the most anticipated events in the mobile industry. While Apple rarely, if ever, foretells what will be coming, it is various players in the mobile industry (myself included) that forever speculate as to what this feature or that will mean when Apple finally announces it.  Whether the event is for iPad or iPhone, I would say that these are some of the most watched live-blogs (each of us have our favorites). I guess I am joining this speculation din with this blog posting!

It is at this upcoming event that the long-awaited iPhone 6 with new, larger screens is expected to be introduced, along with iOS 8. We've all seen various iOS 8 previews and some of it sounds quite exciting. Of course a new 4.7” and possibly a 5.5” screen for iPhone will also be exciting – I know I will be getting one or two!  But there are other rumors circulating about new capabilities that I think could be as disruptive to the industry as the original iPhone introduction was, should these rumors come to fruition.


One of them is a Point-of-Sale mobile payment ecosystem utilizing the iPhone as an instrument to initiate the payment process. iTunes with almost 600 million registered iTunes users (I’ve also seen as many as 800 million accounts) can be leveraged as an initial "base" to support this ecosystem. One article also noted that Apple had laid groundwork via iBeacon, which could be used for mobile payments in retail stores and other locations.  Others have cited Visa as offering support for an Apple iPhone payment system as well as a secure enclave within the new devices to securely store financial information. Interestingly, many industry pundits are split on whether the new iPhone 6 will be NFC-enabled. Certainly, a payment ecosystem based on Passbook as well as iBeacon does not need NFC to support mobile payments. I think NFC would only limit the possibilities as it did with Google Wallet - even with its more recent enhancements, it has failed to gain widespread adoption, although it might be improving.

It sounds like all of these elements coming together are pointing to the iPhone 6 as being the 1st digital wallet-enabled iPhone. The other interesting note is Apple launched a mobile payment system based on iOS 7’s Passbook – in Japan (called iTunes Pass).  Could this be foreshadowing of a more widely available mobile payments ecosystem from Apple?

Apple’s Passbook has enormous potential and given everything that I’ve read, I hope it plays a central role in an Apple/iTunes payment ecosystem. It can be delivered via text (MMS actually) and the Passbook files can also be downloaded via mobile websites and apps (through the API). Think about a common usage of Passbook that many of you have: your Starbucks card.  Starbucks Passbook.jpgYour balance is printed there.  If you use it, or recharge it through the Starbuck’s app, the balance changes – dynamically. This is done through the Apple Push Notification service. Similarly, when you use mobile boarding passes and the gate changes, the gate information on the pass would also be dynamically updated.


With today’s overabundance of apps and many of us starting to get “Push notification fatigue,” the ability to have all dynamic information included in the Passbook is quite compelling. PayPal, with almost 140 million users, has a nice mobile payment capability; however, at this time it does not integrate with Passbook.  I think it should… and this brings up another factor that would be convenient for an iPhone based payment ecosystem – the ability to integrate other, 3rd-party payments instruments (via APIs or Passbook passes), such as PayPal.  It would also be nice to see the ability to integrate various store cards such as Home Depot or Macy’s into the ecosystem as well. Leveraging Passbook and iBeacon could also potentially include Android, Windows and potentially Blackberry devices into this payment ecosystem.

When we use our physical wallet, it is filled with Debit and Credit cards. We choose how we wish to pay for goods and services. An Apple payment ecosystem should allow us the same level of choice. If Apple does this correctly, this could be game-changing and the catalyst for a more comprehensive mobile payments ecosystem and not good news for carrier-based solutions such as Isis (name change is pending) – especially if NFC is not used or required.

With this, I’m hoping that the Point-of-Sale integration becomes extremely easy for merchants, so that the ability to support mobile payments becomes simple to deploy. If merchants are required to replace or heavily modify their PoS terminals, this could be a major delay in widespread adoption. They would do well to look at the simple model used by Square – the wildly successful merchant selling solution leveraging iPhone, iPad, and Android devices. Unfortunately, I think Square screwed up when they discontinued their mobile app, allowing contactless payments from the mobile app to merchants that utilized the Square solution.


Again, this is all just my speculation; however, I think all of the elements point to a likely announcement from Apple and it certainly has the back-end infrastructure to support such global payment ecosystem. Besides the new iPhone screen sizes, iHealth (with an iWatch, either available with the new iPhone(s) or later on in mid-autumn) and all of the other iOS 8 goodies, I think this may be the most significant announcement from Apple in a long time.


Please follow me on Twitter: @wdudley2009

I described how to select the best use cases for standard SAP Fiori projects in a previous post, but you will find that the simplicity of the standard apps coupled with the broad ability to customize will lead you to explore extending Fiori.

For every user scenario, you should consider whether the out-of-box apps are going to be good enough - both for the use case and for the end user.  Just because you can enhance SAP Fiori, doesn't mean that you need to enhance it.

When to Extend SAP Fiori

In my last post, I discussed the criteria to use to determine whether a use case fit the mold for SAP Fiori, and I would argue that the same criteria stands for enhanced apps and even custom apps.  Those criteria are:

  • Can you boil the use case down to a task, rather than a comprehensive “set of functionality”?
  • Are you addressing a task that should be simple and straightforward? (regardless of how SAP does it now)
  • Does the task require minimal data moving back and forth? (field data, contextual data are okay)
  • Is the user base always connected when they want to perform this task?

However, I come back to a previous point: is the standard app going to be good enough?  For example, will a lack of branding confuse some users?  Does the standard app lack some customization your users are used to having?  Is the flow of the standard app natural based on how your users perform their jobs?

Extending Fiori - Getting Started

The questions in the section above are important questions, and choosing to extend Fiori should not scare you.  It should excite you, because there are so many realistic ways to extend Fiori that can be achieved quickly (especially when working with us) and in a way that is easy to support. 

You will need staff or a partner who has digital graphic design skills (for prototyping), UI development skills (HTML5, CSS3, Java), and you may need ABAP skills on staff.  [Removed by Moderator]

You should extend Fiori in order to:

  • Brand your Fiori apps - and avoid the SAP "stigma"
  • Onboard users who have rejected or struggled to do their job with SAP
  • Deliver the best, most effective user experience
  • Support existing customizations you've created in SAP


Ultimately, companies choose to extend and enhance SAP Fiori to ensure user adoption.  Let's consider a few ways.

Branding.  Branding is the single-most impactful enhancement you can make to SAP Fiori.  It seems funny, but when users and executives see the company logo, familiar fonts and recognizable nomenclature, it sends a message that this is a tool to be trusted.  It's also one of the simplestenhancements you can make.  Using HTML5 and CSS3 skills, we can implement various levels of branding across your Fiori footprint, including logos, layouts, buttons, fonts, terms, and really anything that mimics your other solutions.  This is also the gateway step to another scenario: onboarding users unfamiliar with or resistant to SAP.


Excellis enhanced this SAP Fiori Purchase Orders app for a client, including branding and enhanced features.
Excellis enhanced this SAP Fiori Purchase Orders app for a client, including branding and enhanced features.


Onboarding Users.  New users have usually either never seen SAP, or they are actively resistant to using it.  You may have communities of users that have purchased other products to avoid using SAP in the past.  SAP Fiori offers you the opportunity to give them the user experience that they've desired while integrating the data and processes that benefit the business overall.  The key to success is adoption in these user bases.   Remove barriers to adoption by leveraging your branding and changing  a layout to something more akin to what they've  created in their rogue systems.  You can replace or change the flow easily with SAP Fiori, especially if it  simplifies the experience for new users.

Best User Experience.  Not all of your user communities will be new to SAP, but many have been waiting for a better way to use the system.  SAP Fiori provides an opportunity to address some major obstacles that have existed for a while, such as re-training and data entry errors.  The UI of Fiori makes it simple for us to change the experience, like alter the nature of form fields, change the layout or design to simplify user entry, add a custom workflow to the app, or even just add terms that are less "SAP" and more "you."  Similarly, since SAP Fiori utilizes SAP's connections and Web services out of the box, it's fairly straightforward to add/remove fields, leverage security and context to populate information, and even create additional features.

Supporting Customizations.  If you've had SAP products for any period of time, you have likely customized some areas that will not be supported by SAP.  Alternatively, you may have some process that the existing SAP infrastructure can support, but not in the way you really need.  Or, maybe you want to integrate SAP Fiori with something else entirely.  All of these scenarios are possible, even with other products (as long as there are web services or APIs accessible - and note that this is not supported or encouraged by SAP).  Unlike the UI customizations above, delivering custom SAP Fiori apps or creating the features to leverage your backend customizations will take more technical chops.  However, the backend connections are there and the Fiori UI provides full capabilities for design and delivery within a standard framework.  This shouldn't scare you either, but knowing that it's possible and pulling in a partner like Excellis can help you is the first step to delivering.

Most companies will find that the standard SAP Fiori apps provide an excellent framework for getting started, but will determine that some are too limiting.  The SAP Fiori framework is designed to enable and even encourage companies to extend and enhance it.  Modify existing apps, create completely custom apps, and integrate non-SAP products into a single user experience, because as I've pointed out before, that is the core of what SAP Fiori really is.  It's a user experience platform with a mobile-first framework.  The possibilities are endless!

For more information, watch the SAP Fiori video by SAP Mentor Pete Lagana here.  [Removed by Moderator]


Message edited by Michael Appleby

SAP has significantly increased the usability of some of the most common business functions with the creation of Fiori – oh, and now it is free: Fiori is free, now what.

Here at NIMBL we have been busy configuring Fiori Applications in our lab environment, and this week we focused on GRC and more specifically, the applications that are available for SAP Access Control.


SAP has several applications available for Access Control – below are highlights of the most popular ones:

  • Request Access: A user can search for SAP roles based on various criteria, then they can request those roles with one click.
  • Check Request Status:  Search for all requests submitted by me or on my behalf and check the status of the request.  Additionally, see the list of all approvers and send them a message
  • Access Approver: Approve, Reject or forward access requests.  You can view risk information about the request and explore the information on the risk level and actions that caused the risks.  Send a personalized comment to the requestor.


The two applications that we have installed and configured are Request Access and Check Request Status.




Pretty cool huh? (It beats CUP any day)

Here are the basic installation and configuration steps for the above applications:


     1) Our GRC system is running on NW 7.4, which includes the SAP_UI and Gateway components – We did however need to install the      GRC Transactional  Applications for Fiori – this is: SAPK-100AGINUIGRC001


     2) Review and Install any relevant OSS notes.  For the GRC UI and the Access Apps, the needed OSS notes are:


          1929930 – General Prerequisites needed for GRC Fiori

           1966012 – Corrections for Access Request App



     3) Activate the OData Services via /IWFND/MAINT_SERVICE transaction code.  The two oData services needed are:





     4) Activate the UI Components in SICF, they are:


     GRC_ACREQ_CRE and



     5) Assign the Roles needed to the Users, they are:






And that is it – check out the screenshots: (Note: These were taken on a Nexus 7 tablet)



Overall – the installation and configuration for these two applications were very simple.  More, in-depth configuration steps are required for some of the other applications in GRC.  It is however worth the effort, as you can see the UI is simple, intuitive and pleasing to look at. 

openSAP invites you to join two free openSAP Enterprise MOOCs (Massive Open Online Courses) to learn more about SAP’s new UX, SAP Fiori. SAP Fiori applies simple, yet powerful principles to deliver an unmatched user experience and make SAP software more intuitive. SAP Fiori is the new UX across the entire SAP portfolio. Solutions such as SAP Business Suite are using SAP Fiori UX principles to deliver a completely new and reimagined user experience. There are 300+ role-based apps, that apply the SAP Fiori UX providing enhanced user productivity and personalization for customers.


The first course, SAP´S UX Strategy in a Nutshell by Sam Yen, begins August 27 and gives you the chance to hear first-hand from SAP’s Chief Design Officer. Sam will explain SAP’s UX strategy which aims to meet users’ expectations, in other words matching usability of enterprise software with consumer software. Sam will also review the history of design thinking at SAP, the core elements and products we provide to meet the strategy, and the real business value it brings to our customers. This course is a special edition openSAP course and is just two to three hours in duration. You can dip in and out of the course at your convenience and pick up from where you had left off!


The second course is Introduction to SAP Fiori UX and starts September 9. This course will introduce you to the fundamentals and latest features of the SAP Fiori UX. You will learn about product installation, configuration, and best practices for extensibility. Topics include:

               • SAP Fiori UX Basics

               • SAP Fiori UX Deployment

               • SAP Fiori UX Configuration

               • Securing SAP Fiori UX

               • SAP UI Tools

               • Extending SAP Fiori UX


Introduction to SAP Fiori UX is a standard openSAP course, which means it’s six weeks in duration and can be completed at your own convenience with approximately four hours per week to complete the content. openSAP courses are delivered using MOOC (Massive Open Online Course) format through video lectures, hand-outs, self-tests and weekly assignments. The content is released on a weekly basis and you can access it from any device and at any time. You will also have the opportunity to gain experience of what you learn with the optional add-on of using a system environment during this course. There are minimal fees associated and more information will be provided in the first week of the course of the course.

If you would like to earn a Record of Achievement for this course, you will need to submit a weekly assignment before the deadline. There will also be a Final Exam which also contributes to your final grade for the Record of Achievement.


All openSAP courses have a discussion forum where you can discuss content and ask questions with other learners and SAP experts. Registration, content, assignments and final exam are all provided free of charge.


Register today and learn more about SAP’s UX Strategy!


Explore openSAP today and if you’ve missed out on a previous course, you can still access them in self-study mode meaning you can complete all of the course content and review the discussion forum.


Follow us on Twitter

Find us on Facebook

Join us on SCN

Download our iPad app
(Android users can download course materials using Google Chrome)

The mobile security team has been investing significant time and engineering effort into enhancing the SAP Mobile Secure enterprise mobility management portfolio, making it the ideal solution to manage and secure mobile apps, content and devices. As a leader in enterprise applications, SAP has now further expanded this portfolio with the addition of a mobile application management (MAM) offering to expand our app-centric focus. This technology, referred to as Mobile Place is a brandable, localizable and secure enterprise app store that makes it easy for companies to simply and proactively push their mobile apps into the hands of employees, business partners and consumers.

This new app management capability was included in the latest release of SAP Mobile Secure and was announced at Sapphire. It has been available since late June and is already gaining applause from our customers. Our top priority with this new enhancement is simplicity - making the mobile app experience as easy as possible for all mobile users. The technology delivers apps, services and content in a simple way to both managed and unmanaged mobile devices. For managed users, it identifies when their device is out of compliance and directs them to download the appropriate mobile device management (MDM) solution before they can download any apps (note that MDM solutions include SAP Mobile Secure's own cloud based MDM offering, our on-premise SAP Afaria product or other MDM vendor products).

The best news is that Mobile Place is included at no additional cost with the purchase of SAP Mobile Secure in the cloud. And that's only 1 euro per device per month.

For IT admins, Mobile Place it is the single destination to publish, manage and analyze apps, content and profiles -- including any MDM, enterprise mobile management (EMM) and mobile content management (MCM) offering. For end users, it is the place to easily discover and download relevant apps and set up related services such as network access, email, identity and more.

The press release quoted Senthil Krishnapillai as saying "With the expansion of the SAP Mobile Secure portfolio on both managed and unmanaged devices, we are delivering the best mobile experience for our customers for consuming enterprise apps. For example, a large beverage company will use mobile place to make their mobile apps easily accessible to distributors, and a healthcare provider can provide a single mobile app to authorized patients. The discovery features of mobile place help ensure any corporate developed or licensed apps can be easily configured."

Mobile place provides a secure, multi-channel central hub that offers self-service capabilities to best serve employees, business partners and consumers while reducing IT support costs. This solution brings the management of content, apps and devices together in a seamless workflow for IT admins, application developers and end users.

So far the response has been fantastic - you can see for yourself by watching the short video. Check out the free trial of SAP Mobile Secure. It is available today at www.sapmobilesecure.com.

The UX Explorer is a tool that answers questions relating to user experience and user interfaces at SAP. It provides information that allows you to clearly understand the availability and capabilities of UX innovations, UI technologies, and services. The UX Explorer is committed to providing you with the most up to date UX information and the addition of the SAP Fiori launchpad section is proof of this commitment.


The launchpad section can be accessed directly from this link or you can access the UX explorer homepage and navigate to Explore Items -> UI Clients -> SAP Fiori launchpad, alternatively you can use the search on the homepage. On the launchpad page you will find a summary, list of features, screen shots and much more. I encourage all of you to check out this tool and benefit from the power it provides.




For those of you interested in learning more about the UX Explorer tool please visit this page in SCN and watch the video recorded by Juergen Jakowski.

In a previous post, I've already discussed the fact that SAP Fiori is not a mobile platform, but a user experience platform with a mobile-first framework.  Understanding this is even more important once you move past the strategy and architecture steps, and into a deployment exercise.

Choosing proper use cases for SAP Fiori is critical.  Fortunately AND unfortunately, Fiori provides standardized, out of the box feature sets delivered as standalone applications.  At first blush this seems great, because you can deploy a new experience to users, already integrated with the backend, within days or weeks.  The ability to achieve rapid success is realistic.  However, doing so with the wrong use cases can lead to frustration, which breeds rejection.

You absolutely must select appropriate use cases for the standard apps, plan to extend the Fiori toolset when needed, and ensure the user communities you engage for early projects are up for the challenge.


It is realistic to deliver Fiori solutions quickly with the right approach to delivery.
It is realistic to deliver Fiori solutions quickly with the right approach to delivery.


Use Cases for Standard Fiori Apps

In my earlier post on SAP Fiori strategy, I pointed out Fiori's core strengths:

  • You can derive value quickly with standard apps
  • No native development skill sets are needed in-house to support it
  • Responsive/Multi-device is a cornerstone
  • No need to deal with app submission
  • Built to support extending the platform with minimal effort


When choosing which of the numerous standard apps (190 in all for waves 1 & 2) to deploy, it makes sense to adhere to the lightest, simplest use cases possible.  So what does that mean?  It means that to succeed with standard Fiori apps, you need to play to the solution's strengths.  Consider this checklist when looking at use cases.  Compare the projects you're considering to this criteria:

  • First, can you boil the use case down to a task, rather than a comprehensive "set of functionality"?
  • Are you addressing a task that should be simple and straightforward? (regardless of how SAP does it now)
  • Does the task require minimal data moving back and forth? (field data, contextual data are okay)
  • Is the user base always connected when they want to perform this task?


In order to succeed with a standard Fiori app, the project use case needs to be a "Yes" for every criterion I just listed.  In addition - and this is the most important part - the standard features have to match up with the requirements for the use case.  And if they don't - you will need to amend the use case or consider extending Fiori.

Extending SAP Fiori

Great news - SAP Fiori, as a user experience platform, was designed to be extended and enhanced.  It's so much simpler to enhance than SAP Portal or any of the other past UI technologies that SAP or competitors have released.  Most of our clients select at least a small amount of enhancement, if only to simplify a few fields or implement branding.

The most important thing to ask yourself when you begin a use case is: "Will the out-of-box functionality drive the users to do what they want to do?"  The phrasing of this question is deliberate - because functionality is key, but Fiori is all about the User Experience.  You want to equip the user, but also aid and encourage the user to use the new app.  So, if the standard app doesn't completely pass muster because it's one screen too many or the fields aren't in the right order, you can make those changes without breaking the bank.

There are many ways to extend SAP Fiori, and we do them all.  I'll talk more about customizing SAP Fiori and what it takes in the final post of this series.

User Groups

I'll define "User Groups" as the community of users that you will focus on for the deployment of any Fiori apps.  Because Fiori is task-based, not a comprehensive "module", you have the opportunity to deploy multiple specific apps based on the user's identity context.  This means a simpler, more relevant experience for each user, rather than muddying up their day with a bunch of confusing extra features that don't matter to their role.

That said, considering user groups is nearly as important as the use case itself.  That's because SAP Fiori is so different than the traditional SAP applications some old school SAP users may be used to using, yet for other user groups, it's much more in-line with the marketplace (including Salesforce.com, and other tools).

At a very minimum, your target groups need to have a very well-defined role.  This is imperative, as the solution is focused on tasks, so you have to be able to break down what you're delivering to one or a group of tasks rather than the traditional functionality mix.

Secondary to that, it will help if you decide if you want to deliver first to user communities with familiarity with SAP systems or new non-users.  Accommodating the non-users allows you to bring in groups that may be "rogue" on other systems, but you may determine that with the early projects you want to serve the experienced staff who've been waiting for improvements.

It's also beneficial to look for user champions to help with the solution deployment, because though it should be simple to use, any project benefits from evangelism.

Finally, you need to be sure you educate users on the fact that the Fiori experience is one that can easily be enhanced over time.  Unlike traditional SAP projects, this doesn't have to take months or years - enhancing or creating custom apps can be completed in just weeks.  I'll cover that in my final post in this series [Removed by Moderator].

Looking for the entire SAP Fiori overview?  Watch our video on SAP Fiori by SAP Mentor Pete Lagana here.

Message edited by Michael Appleby


Filter Blog

By author:
By date:
By tag: