Skip to Content

Portal on Device – why it makes so much sense

This is part I of a blog series on Portal on Device.


Thanks to the rapid advancement of mobile hardware in the past few years, we are entering an era when Mobile is becoming the new Desktop. But our mobile software development methodology seems to be lagging behind. Native applications, which used to be a perfect fit for the less powerful mobile devices, still dominate the world of mobile-oriented applications. But are they still the best option to develop mobile application at this age, especially for business applications?


While it is technically possible to deliver a comprehensive solution (say a complete suite of business applications) via native applications, it is often not a wise approach. First of all, you will typically need to target more than one platform, such as iOS, Android, Blackberry, Windows Phone, etc, so for each individual app, you need to develop at least two or three versions. This does not only double/triple the implementation efforts, but also requires a rich skill set, including Objective C (iOS), Java (Android/Blackberry), C#, etc. Needless to say, it will add up Total Cost of Implementation (TCI) significantly. Secondly, rolling out new updates to existing installations may become unmanageable when you have too many applications. Different mobile platforms have different ways for software distribution and update, so you will have to cope with all of them every time you roll out a software update. All these factors will lead to a higher TCI and Total Cost of Ownership (TCO).


On the other hand, modern mobile web browsers, together with its underlying hardware, have evolved by leaps and bounds over the years. New capabilities and performance improvement of mobile web browsers have brought a new dimension to mobile web applications, which has made mobile web browsers ready for serious business applications. Many new capabilities which we used to believe were impossible for web browsers have come true, such as multi-threading, full-duplex network communication, access to hardware resources such as GPS and accelerometer,  image processing, access to local storage and database, etc. The performance of mobile web applications have also improved significantly, thanks to modern JIT-based JavaScript engines and hardware (GPU)-accelerated UI rendering. The following table lists some of the key improvements of mobile web browsers. Note that not all mobile browsers support all the new capabilities yet.



Mobile Web App

Native App

Performance of Code Execution



Performance of UI Rendering

Fast (hardware accelerated)



Yes (by HTML5 Web Workers)


Full-duplex communication between Browser and web Server

Yes (by WebSocket)


Direct P2P Communication

Not yet (pending on support for ConnectionPeer API)


Cross-domain server access

Yes (by Cross-Origin Resource Sharing)



Yes (by Geolocation API)



Yes (by DeviceOrientation API)



Yes (by DeviceOrientation API)



Yes (by DeviceOrientation API)


Image Processing – Pixel manipulation & interaction

Yes (by HTML5 Canvas)


Image Processing – Vector Graphics

Yes (by SVG)


3D Graphics

Limited (pending on support for WebGL)


Offline execution

Yes (via HTML5 Offline Web Applications)


Local storage and Database

Yes (by Web Storage and Web SQL Database /Indexed Database API. Size limitation per domain applies, e.g. on Mobile Safari: 5MB for Web Storage and 50MB for Web SQL DB)


Local File Access

Limited (supported on Android via File API)





Audio and Video

Yes (by HTML5 Video and Audio)


Camera and Microphone

Supported on Android (by HTML Media Capture API).


Media Recording and Streaming Media

Not yet (pending on support for Stream API).


Push Notification (when web page is open)

Yes (by Server-Sent Events)


Push Notification (when web page is closed)

Not yet (pending on support for Web Notifications API)



With all those new capabilities at our disposal, it is often easily possible to create powerful and beautiful web applications without turning to its native counterpart (By the way, in the relatively rare cases when pure native capabilities are absolutely required, Custom URL Schemes can be used to easily bridge the web app and the native app, so you don’t have to turn to the native approach just because you need it sporadically). Meanwhile, the TCI for implementing a major suite of business applications may be significantly lowered because only one version is required for various types of mobile devices (or even including desktop devices). The skill set required (i.e. web development skills) is easily accessible in the current market. What’s more, it is a lot simpler to maintain a central version of software where updates/bug fixes can be performed without touching each individual device, which would reduce TCO considerably. 


The advantages of mobile web apps are so significant and obvious that many companies have already started to build mobile solutions on the web platform. This will in turn further expedite the innovation of mobile web technologies. In the business application world, we will probably see the web become the prevailing mobile application platform in the near future.


So the next question for us is, on what server platform should we run the mobile web applications? Should we run them on each and every business system (such as ECC, CRM, SRM, etc) or on a central system? The first option might be easy to implement, but in a typical corporate landscape, it may not be a preferable choice because it essentially means that (in most cases) those mission-critical business systems would have to be exposed to the Internet to allow mobile access. This is usually not acceptable from a security perspective. A central “mobile gateway” system is therefore needed which has good connectivity to enterprise information systems and at the same time can be exposed to Internet without too much security concern. SAP NetWeaver Portal is a good candidate to act as such a mobile gateway to enterprise information systems. It has well-established connectivity to SAP and non-SAP backend systems, and it is often already exposed (or can be easily exposed) to Internet due to its role as a portal.


Additionally, NetWeaver Portal offers a rich set of services that would ease the development and maintenance of mobile business applications, including:

–        Unified user/role management services for desktop web apps, mobile web apps and native mobile apps (through Custom URL Schemes).

–        Contextual services (e.g. search),  productivity and usability services (e.g. personalization, favorites, suggestions), etc.

–        Business supporting functions, including  Document  Repositories, Wikis, Forums, etc. Those functions can be easily mashed-up in mobile apps using Portal environment.

–        Support for End-to-End Change Control Management.

Those services further make NetWeaver Portal a perfect fit as a mobile gateway to enterprise information systems.


Inspired by the exciting new capabilities of the modern mobile web, we have been actively working on a “Portal on Device” strategy which targets making our NetWeaver Portal the entry point of mobile business applications, leveraging both the powerful mobile browser capabilities and rich portal services. For more details, please visit the Portal on Device wiki page.


In the next blogs, I will illustrate how Portal on Device looks and how it works under the hood – please stay tuned.

You must be Logged on to comment or reply to a post.
  • Portal on device (PoD) will use Neo or the established SAP Portal?

    The UI will be based on HTML5@SAP or we will have only the framework (LS-API)?

    What will be the role of Sybase? Sybase makes no sense for pure online scenario but can when the PoD gives access to portal services like UWL or user directory (images, HTML can be saved locally and only the actual data will be transmitted).

    A central access point for mobile access is a must have, the portal already has this role taken in the landscape. What's missing is a merger of the different approaches: one server offering what Gateway, River/Neo, Portal, Sybase are offering. Maybe a dual stack mobile gateway solution offering combining everything?

    Welcome portal to the mobile world. I fear that it is too late as many customers already implemented mobile solutions and will have to re-implement or migrate their custom solutions to the "new" standard, as mobile access is not a hot topic since yesterday.


    • Hi Tobias,
      From the little which we can share at this point:
      1. The mobile portal framework page (initially) will be based on the On Premise existing Portal. There is an initiative for an On Demand Portal running on Neo/River which is running in parallel.
      2. UI will be based on HTML5 Navigation. The existing content is of course, existing content 🙂
      3. We are working with the Sybase guys to discuss the integration between portal and SUP/Afaria. More details as the roadmap is clarified.
      4. I disagree with the the "too late" comment. Based on the feedback which we are getting from customers, a lot of them want SAP / Portal to provide a mobile solution.
      • I agree with the opinion that it is not "too late", not at all.  A lot of customers require a pure online scenario and will either go with alternatives to SUP/Portal now or wait until SAP delivers the portal mobile if that is not too far in the distant future.  Providing a roadmap is very important for customers and consultants working on this topic.  The planned and implemented mobile scenarios today are a fraction of a percentage of the mobile scenarios that are going to be in place within the next 3-4 years.

        Great blog by the way, can't wait for more information.

      • Hi Yariv,

        thanks for the info.

        About the too late: Of course you are getting feedback from customers, but there are also customers that are already mobile, maybe even with SAP, but not in-line with the (future) SAP recommendation. Many are already mobile with mobile BSP or Portal apps using jQuery. Or with native apps using JSON calls to a service. These will have to adjust their coding and do an additional investment, just to be in line what SAP recommends (... year(s) after their go-live).

        Other companies do have a nice little internal process that produces a document telling them what kind of software can be used for every use case scenario. When that doc was defined, the portal surely wasn't considered. And the recommendations given in such a document survive for many years ...

      • I agree with Yariv, it is not too late. As usual (please correct me if I am wrong) many customers have misinterpreted the use of the portal. The Portal has manifested itself in many forms answering the call of integrator, web application/based platform and now mobile. It is an ingenious bit of software/infrastructure that has left many confused. Hence the miriad of solutions some customers have when the 1 thing that can perform those duties is probably in use by them. Now I am not writing it will answer every company's needs, but I am sure it can cover most of them. If the integration with SUP/Afaria prove frutiful, it should be the go to product for Enterprise Applications.