Skip to Content
Author's profile photo Tobias Hofmann

Mobile apps or HTML?

Recently there has been a series of blogs about developing mobile applications using HTML5:

You cannot ignore it: mobile access to SAP is a hot topic. As there are also series of blogs focused on mobile business using Sybase and almost all news around SAP and mobile involve somehow Sybase, it’s interessting to see what customer are using. At TechED Las Vegas I had the chance to attend some lectures about mobile applications running on BSP and SAP Portal. The Demo Jam winners demonstrated a HTML5 app. The question  now is: mobile access to SAP data by an app or HTML?

App

There are use cases where you need a local app installed on the device. MAM is a good example:

  • you’ll need a local database
  • long offline time
  • complex data to be modified and
  • to be synchronized
  • background sync

Drawbacks from using apps:

  • Distributing apps is a challange, updating them too.
  • Sensitive data stored on the device; ensure security of data.
  • SAP MI, Gateway, Sybase or 3rd party mobile software bring their own infrastructure that needs to be integrated into the current landscape
  • Mobile policies change. Now the users are using Blackberry, soon  some will switch to an iPhone, Android or WM7 phone. And you’ll have to  develop a version of your app for that device. Project  Gateway promises to ease this work.
  • An app for iPhone works on iPhone, but not an Android, BB or WM phone.

HTML(5)

  • simpler use cases, no RFID, tag scanner or other special device hardware needed
  • online & offline
  • local storage of data
  • can be used by mobile and standard browser (1 application for all)
  • use of mobile device features like GPS

The usual offline access mode that demands for a local app is obsolete: we are living  in an online world and being offline means that you are either offshore  or in a  plane (and that is also changing: on some planes wifi access is  already reality). The background sync from apps is sometimes not even  considered, as the user will get a notification by e-mail or initiates the activity as part of his daily routine (while beeing in the train, bus, traffic jam,). Another point to consider HTML(5) is the experience available for high number  of concurrent user access to your web server.

The maiority of use cases is online consumption of data, the interaction  sometimes is only that the user is hitting the “approved” button or to  look simple data up like the phone or e-mail adress. To consume employee  data you may use a local app (+db) and store the contact data on the  device, but you cannot store all the employee data – at least when your  company has more than 1000 employees – or company policy don’t allows  it. As this data is changing, doing a sync is mandatory; you don’t  want to have an outdated phone number when you need it. A feature that counts more than offline storage of these data is to asve the contact data into the devices PIM.

Considering the number of concurrent users: while I attended the  lectures at TechEd LV I left with the impression that most mobile SAP  applications are made for a small number of users. 50 users already was considered high;  and that a really big issue is the sync of the data (users of MI may  remember the DOE sync issues). Looking at the usual “simple” use cases of  mobile applications, HTML(5) is the right choice: independently whether  you are using BSP or the Portal, you already have the knowledge of a  high number of users accessing SAP data. There won’t be surprises when  >50 users are accessing the application at the same time.

The technolgies available and from what I’ve seen at TechED is what the customers are using for their development are:

  • BSP
  • Java (NetWeaver AS Java and SAP Portal)

The problem I see in developing HTML5 apps with SAP is that  there is a gap in the solution offering from SAP: there is no offering from SAP.  If you want to develop such a HTML5 application, you’ll have to do it by yourself. And mobile browsers are not really supported (Service Market  Place: PAM).

Do you want to use BSP or AS Java or the SAP Portal? Of course I only can recommended using the SAP Portal. It offers:

  • Profiles
  • Filter content based on URL (Filter ID)
  • Made for browser access
  • System landscape with SSO to backend systems
  • Caches
  • Portal services

With profiles, roles and filter ID the portal filters the navigation. Instead of having 20 apps for ESS and MSS on the home screen, the users may only have 2: ESS and MSS that open the navigation of the area in the portal depending on the associated roles of the user. With SSO, it is also possible to easily integrate other web content (ex.: ITSmobile transactions). The HTML application can reuse interfaces already in use: Web Services  and JCo/JCA/BAPI from WebDynpro applications. The same HTML5 application can be used by mobile and desktop access. No need to develop the same application several times. Once logged in the portal, the end-user can make use of the portal services like UWL, favorites, KM (download documentation), or other APIs available.

Assigned Tags

      24 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo YUNUS KALDIRIM
      YUNUS KALDIRIM
      Hi Tobias,
      I was thinking about your topic also. Which is better solution for future? Browser based solutions or installed apps. This is really hard to answer. But i think browser solutions will win at the end 🙂 Because development on browser side is growing. However we see ipad, android or winCE apps more attractive but i can say a well designed browser based solution is ever lasting and %99 compatible on any system or OS.
      Software world(SAP) says the right choice is mobile apps. Let's see what will happen 🙂
      Author's profile photo Tobias Hofmann
      Tobias Hofmann
      Blog Post Author
      Companies like apps because they can treat it as a physical product: there is a market place, it needs to get installed, money (may) get transferred, it's partly a hype / lifestyle. It get's pushed from every OS vendor as they can make money with the market. And apps is what consulting companies can sell.
      Apps for consuming some JSON / AJAX data to show a form or table in most cases just doesn't makes sense for companies (for 3rd party solutions it makes sense).
      With an up-to-date smartphone with flash it's possible to access BSP, WDJ/A, BI reports and the portal. Now it's just to optimize the applications in regards to traffic sent, layout and light Javascript.

      br, Tobias

      Author's profile photo Martin English
      Martin English
      The key takeaway is your last three sentences ... and in fact, this COULD be done today.  Write the code once, but have User Agent dependent CSS.

      In BSP, this could be done 'manually' per page by the developer, although I'd suggest integrating something like jQuery (http://jquery.com) and / or JQuery mobile (http://querymobile.com) so that the user experience degrades gracefully in a standard way on each page in the application. 

      When using the Portal, the second approach would be easier to implement; again, using User Agent to control the CSS and therefore layout, so that it become a more natural part of the user's 'phone experience'.

      BTW, the reason for allowing graceful degradation is that the IT department is losing control of the business environment (which, BTW, is a good thing) and therefore physical tools used in the business; Especially with mobile devices, there is no corporate standard phone or browser anymore, but even if their was, it's nice to allow the user to slip their sim card into an old nokia (as backup in case their 'modern' phone is broken).  Maybe it won't support ALL the functionality, but at least it will provide some access.

      Author's profile photo Tobias Hofmann
      Tobias Hofmann
      Blog Post Author
      "COULD" ? I'm doing this right now 🙂

      Using the Portal, I can have an portal application that identifies the user agents and redirects the browser to a HTML file stored in the KM, passing a parameter like: IE, Mobile, FF. This HTML file loads the layout dynamically and passes it to jQuery to finalize the layout. The rest is loading the content from SAP by AJAX.

      The problem is that there is no "final" version of jQuery for mobiles.

      Author's profile photo Nigel James
      Nigel James
      Somethings that come to mind. You could expose your back end SAP data as xml or json via a REST API. This is what Gateway will make easier. (You can do this manually today)

      There is project Phoenix which is SAP's UI widgets for HTML5 and they were demonstrated at SAP Inside Track London in June 2010 and at a UI Session in TechEd this year. I have no idea for the GA of Phoenix.

      You are right there are many choices to be made in mobile and you need to have the right app for the right audience.

      Cheers,
      Nigel

      Author's profile photo Chris Paine
      Chris Paine
      I'm not sure Gateway will make this much easier. Parsing/consuming an oData response and dealing with the extra verbs (MERGE) that it uses - to me isn't as easy as just coding your own ICF handler and using it. Perhaps it's more reusable, but it puts a layer of formality on simple communications that sometimes just doesn't need to be there.

      We're becoming more and more welcoming of simple RESTful interfaces, because of the pure simplicity . I guess it depends on how low level you want to go. To me oData/Gateway is an unnecessary complexity in many cases, simpler is better. 😉

      I completely agree with the the blog though - I'd have to choose HTML5 over custom apps at the moment, purely for the ability to deploy to multiple platforms easily. And because I really don't want to learn Objective C 😉

      Author's profile photo Tobias Hofmann
      Tobias Hofmann
      Blog Post Author
      "oData/Gateway is an unnecessary complexity"
      Agree. There are already several ways to realize data consumption, why add one more product in your landscape? ECC comes with ICF, all you need to develop and HTML application is already delivered.

      "And because I really don't want to learn Objective C"
      Developers are really excited when it comes to app development: Motivation was at 350%. After I presented my solution - HTML and no apps - motivation felt to less than 10%. For developers it is cooler to develop an app.

      br, Tobias

      Author's profile photo Chris Paine
      Chris Paine
      "For developers it is cooler to develop an app."

      And I thought _I_ was a developer - oh well 😉 Perhaps I'd have been part of the 10%. Building a *good* HTML5 web app has all the complexity of building an Java Android app and an Objective C iOS app and a WP7 app (what is it that you have to build Windows Phone 7 in) and an Abobe Air App for your BB Playbook, etc, etc. and is a build ONCE(ish) scenario. You'd think that if the developers thought about their marketability in the enterprise world, rather than setting up their own businesses selling apps, they'd realise that having excellent HTML5 knowledge is a much better career move than trying to master a range of different techs. It's also interesting to see the move even with app development to move to different model on how to make money. Angry Birds for Android, for example is free, but has inline advertising. Perhaps a reaction to the ease of "sideloading" apps on an Android device, but shows how the wider audience of an HTML app could still be profitable.

      Anyway - enough blabber time to start work for the day (or get a coffee anyway 😉

      Author's profile photo Tobias Hofmann
      Tobias Hofmann
      Blog Post Author
      Gateway promises easier development of apps by using REST to consume SAP data. REST is good for Internet access (Web Services tried, but failed), for Intranet I would use something faster: JCA connection to SAP (that is: JCo, RFC). The portal also allows for SSO, with user mapping. Without the need to install a new product.

      Project Phoenix also promises a new way to interact, but will it also support mobile browsers?

      br, Tobias

      Author's profile photo Chris Paine
      Chris Paine
      > for Intranet I would use something faster

      what sort of use case are you considering that would need anything faster than HTTP transfer using JSON? RESTful doesn't have to equal slow 🙂 Although I can see your point about it being nice to use the portal to generate a logon ticket using SSO - but once it has created a ticket, you can use it to access SAP ICF services - you don't have to use JCA (or am I mistaken - I often am - an I really should be going to bed - too late - yawn.) 🙂

      Author's profile photo Graham Robinson
      Graham Robinson
      I love the ICF - just saying
      Author's profile photo Chris Paine
      Chris Paine
      +1

      just built a Yahoo Widget to query interface statuses using a poll on an ICF service that sends out data using JSON.

      So simple, so clean, so easy. complexity, no thank you.

      Author's profile photo Simon Kemp
      Simon Kemp
      Hi Tobias, thanks for the blog. I'd like to chime in and support you regarding the use of the SAP Enterprise Portal to support mobile access. I think the portal has many useful features (role based access, ajax navigation api, sso, etc...) that make it a nice choice - it would be nice to see a Mobile Framework Page to closely follow the Ajax Framework Page 🙂

      Thanks again,
      Simon

      Author's profile photo Former Member
      Former Member
      Hi Tobias,

      Great Blog! In my opinion you are correct - using the portal as a front-end for mobile applications is good choice.

      I like the idea of using the Desktop Filter mechanism to display only a subset of the navigation entries.

      I would also like to hear about challenges you encountered when trying to use the portal in this scenario.

      Regards,
      Yoav (EP 7.3 Development Architect)

      Author's profile photo Chris Paine
      Chris Paine
      "using the portal as a front-end for mobile applications is good choice" > I'd disagree.
      SCN runs on a portal - trying to view any content in SCN via a mobile device takes a long time (too long) in my experience. There are multiple calls to retrieve goodness how many style sheets, etc.
      My feeling is the SAP portal as it currently stands is far too heavyweight to be used to purely provide an SSO ticket (cookie) that can be used to authenticate secondary ICF communications. I think there are other reasons that using the portal as a front-end for mobile web apps is not a good choice - eg the lack of HTML5 support and by implication webkit browser support, Chrome, Safari, etc) the portal currently is not mobile...
      Perhaps in NW7.3 things are better, but that's not a world that most of us have access to. 🙂 7.2 might be better, but as 7.0x is most likely to be the "production" portal, that's where we need the advances.
      Author's profile photo Former Member
      Former Member
      Hi Chris,

      You are correct in your analysis that the portal, with its default UI is not mobile-ready. It is too heavy and the user experience is all wrong (for devices).

      In my previous comment I was referring to the portal as a framework, putting aside the UI layer. The portal framework has many capabilities that make it appealing as a front-end for mobile applications.

      Regarding the UI - nowadays, most sites that want to be viewed by mobile devices offer a specialized UI for these devices. I see this when I use Gmail on my smartphone (you can try it yourself by changing the user-agent to some mobile one and connecting to Gmail - you get a totally different UI). I don't think the out-of-the-box portal UI should be used for mobile access (neither the Classic Framework Page nor the new Ajax Framework Page). However, the Ajax Framework Page, and especially its new version which is coming up in 7.3 is designed to enable customers to implement their own UIs using a set of portal services. More simply - with the AF part of AFP (Ajax Framework) you can start with a blank web-page (not one pixel comes from SAP) that already contains all the APIs you need to create your UIs (Navigation Nodes, Favorites, Search, Suggestions, Tabsets, ...). We use the same APIs for our own UI implementations, so we expect them to be very useful for you as well.

      Regarding standards compliance - this is not yet coming out-of-the-box from the portal (unfortunately) however recently I have seen some awesome XHTML and HTML5 framework pages created for the portal. I hope that in the near future we can improve our standards support to make life easier for you.

      Regards,
      Yoav.

      Author's profile photo Chris Paine
      Chris Paine
      Hi Yoav,
      "the Ajax Framework Page, and especially its new version"
      Sounds very interesting! I look forward to seeing some of this technology and some details on how to implement it. It certainly sounds like it has a lot of potential. Any chance of a backport to 7.0x land?
      Thanks very much for the very informative feedback!
      Chris
      Author's profile photo Former Member
      Former Member
      There are already some published materials about AFP in 7.3. Check out the Advanced Level guide in: http://wiki.sdn.sap.com/wiki/display/AFP/SAP+Portal+-+Ajax+Framework+Page

      We are working on more guides which we will publish soon.

      Yoav.

      Author's profile photo Tobias Hofmann
      Tobias Hofmann
      Blog Post Author
      Yoav,

      "recently I have seen some awesome XHTML and HTML5 framework pages created for the portal"

      I too wanted to create a custom framework page in the beginning, but opted not to do so:
      - No time to learn and to code
      - No official support from SAP when using my own framework page.
      Any chances that someone from SAP will publish on SCN how to create your own framework page?

      Regarding the mobile experience:
      With a recent smartphone you can access the standard portal and use all functionality: navigation, BEx, VC, BO flash, WebDynpro. Given the size of tablets you even don't have to adjust the screen layout. It's hard to believe for developers, but people accept this as a mobile access to SAP; they don't care if it's running on BSP, ICF or Portal. They can access SAP while on the road and that's more than they were able to do a year ago.

      The iPad has the size of a bodyboard and barely can be considered a mobile device, so the portal has to work on a smaller screen size - that's were screen estate comes into: how does it work on a 4" to 5" display? You'll need all the space for the application. Without a rethinking of the navigation it won't work. Do you need WD to display data? Or is a simpler version with less fields not easier to use? That's were I strongly believe that the portal offers the best solution.

      br,
      Tobias

      Author's profile photo Former Member
      Former Member
      Hi Tobias,

      In the AFP Wiki (http://wiki.sdn.sap.com/wiki/display/AFP/SAP+Portal+-+Ajax+Framework+Page) you can find today a guide by SAP RIG on how to create your own FWK page from scratch (not using any SAP UI at all). It is relevant for 7.3.

      As I said before, we are working on a very cool guide in collaboration with SAP Consulting which will show you how to create an amazing FWK page using latest web technologies (jQuery anyone?) on top of the AFP APIs.

      I suggest you stay tuned to the AFP Wiki for updates.

      Regards,
      Yoav.

      Author's profile photo Tobias Hofmann
      Tobias Hofmann
      Blog Post Author
      Chris,

      it depends on how you use the portal. The framework pages delivered by SAP are not meant to be used by a mobile device. Using the standard page I get way too many browser requests:
      1st access: 55 request, 411 KB transfered
      Navigating: 20 request, 176 KB transfered with 168 KB loaded from cache.

      In the setup I use, I get for the 1st access 11 requests with 25 KB transfered. Navigating in the page is 10 requests and 24 KB, 20 KB loaded from cache. That is using the light framework page with Web Page Composer.

      You don't need the portal to issue an SSO ticket, you can use the J2EE engine: code a J2EE application, use form or UIDPW based authentication and the underlying logon module stack will issue the SSO ticket: that's 3 requests: (logon page, submit, portal resource and logon ticket issued) with less than 3KB of data.

      What really is a problem is the missing support for mobile browsers from SAP.

      br, Tobias

      Author's profile photo John Moy
      John Moy
      Thanks Tobias,

      A partly wanted to comment here so I could be notified of the ongoing comments.

      From my perspective, I believe use of Portal or BSP are equally valid, and each has its own pros and cons. 

      The architecture however that I am considering with my own activities is to thread the initial call to a ABAP BSP via a lightweight KM page (which simply redirects the user to the BSP).  The important point here is that we achieve the benefits of picking up the portal SSO token, which can then be used for SSO purposes to any other trusted system from the BSP.  Effectively I am using portal as a ticket-issuer, so that the BSP has all the benefits of single sign-on to any trusted systems.  Also, since our portal is tied to AD the user only needs to enter their AD credentials (which they know) initially to retrieve the KM file, or better yet, we can seek to achieve SSO between our secure Sonicwall Aventail service and the portal.  From there on we can control everything simply via ICF communications (I prefer this simplicity in the architecture, depending upon the use-case).  One might argue that services such as UWL are not available from the ABAP stack, but interestingly there is a ABAP-based UWL POWL that SAP has delivered in 7.01, so SAP must have seen the benefit of exposing 'UWL' from the ABAP stack (although it is arguable to what extent this is 'universal'). The point is that in some cases is it simpler to deal directly with the ABAP stack.  And I am saying this even though I have been a J2EE developer for as many years as I have in ABAP and I have a great love of Java as a language.

      But as I mentioned earlier, there might be use cases where it makes more sense to use the portal more extensively than my suggestion. 

      Rgds

      John

      Author's profile photo John Moy
      John Moy
      Hi Tobias,

      My comment on apps versus HTML5. 

      Having actually pursued the learning process of building skills in native app development (in my case iPhone) and deploying these to the app store, then looking at web apps using HTML5 and frameworks such as iUI and jQuery Mobile, I can say from my experiences that for many (but obviously not all) use cases the HTML5 path makes the most sense.
      I think the key ingredient is these new frameworks (eg. jQuery Mobile) that allow web developers to really easily harness the capabilities of HTML5.  I think the full potential is only now emerging, and becoming apparent to all.  And if you are still hampered by the need for native features of the device, simply wrap your web app in a solution such as PhoneGap, which provides a wrapper to enable you to deploy native apps and a javascript API to trigger native device features.  Unless you are coding games (and I don't expect in SAP circles that would be common), you should look at web apps first and ask yourself WHY you wouldn't use that path before going native.

      Just my thoughts anyway.

      Rgds

      John

      Author's profile photo Tobias Hofmann
      Tobias Hofmann
      Blog Post Author
      "you should look at web apps first and ask yourself WHY you wouldn't use that path before going native."

      Judging from the comments from other users, everybody agrees with that statement.

      @SAP: http://www.sdn.sap.com/irj/sdn/mobile
      -> Why are there sections on how to develop apps for iPhone and Android, but not on how to use HTML(5)?

      br, Tobias