Skip to Content

Mobile ESS in 3 weeks – How to get the most out of your existing solution

Yes you read that title right. 3 weeks. I can scarcely believe it myself, but it’s true. The most pertinent question to follow on from that statement is HOW???? This is what I’ll be covering in this blog so that quick wins can be achieved by all.

Let me give you a little background on how I came to this point. We implemented ESS/MSS in August 2010 as part of a major HR implementation at large postal company based in Australia. ESS/MSS was rolled out to about 8,000 users out of approximately 30,000 in the organization (this is because many of our employees don’t have convenient access to a PC, having to deliver mail and all). The ESS services included leave, payslip, payment summary and personal information among other items.

The leave application in ESS was a custom application designed to best fit our complex leave scenarios. Because ESS was only available to a subset of the organization, a lot of employees who had no regular access to computers were not able to benefit from this solution. A gap was identified with the operational employees where they had to request leave through paper forms and were not able to view their balance.

This provided the impetus to trial a mobile solution that would leverage the existing ESS functionality. The plan was to provide a mobile solution that would enable a user to request leave, check their leave balance as well as view their leave history. This in turn would reduce the dependency on their manager to provide that information, and remove the reliance on paper forms.

Online payslip information was also not available to employees without ESS; they received a paper version in the mail. The operational side of the business was very keen for this functionality to be made available in the mobile ESS solution as well.

We decided to serve up the mobile application through a browser as opposed to a standard SAP app due to the following reasons:

  • Tight timeframe
  • Trial basis
  • Standard SAP apps does not support public sector leave or payslips
  • Cost to build on existing framework was cheaper than the cost to setup and install SAP standard framework

So here we have our starting point. We had services in ESS that could be leveraged in the mobile version, so business logic was pretty much taken care of. The next step was to adapt the mobile solution to incorporate that functionality. But before we did that, we had to plan our architecture of the solution.

Below is a diagram of how the technical architecture of the solution would work:

Mobile ESS Technical Architecture.jpg

This architecture was pioneered at Post by Sascha Wenninger and has been introduced for desktop browser solutions as well as mobile. The idea is to have a framework that is agnostic to the UI rendering so it could be reused in many different ways. In our case we chose to use a JSON format to return the data since it is lean and fast, but the framework is also capable of returning data in pdf or csv format. This framework was built on top of work by DJ Adams and Uwe Fetzer.

With the architecture designed, here are the technical steps that were involved in putting everything in place:
1. Create web service nodes in SICF

Maintain service_2012-08-07_15-52-10.jpg

2. Create handler class for each web service to hold the processing logic and tie it to the web service. The class makes use of interface IF_HTTP_EXTENSION.

CreateChange a Service_2012-08-07_15-52-43.jpg

3. Create BSP to hold the HTML and calls to the web services. This BSP is purely to serve up static HTML (UI) and JavaScript with JQuery Mobile.

Web Application Builder Display Page ZESSMOBILEAPP_2012-08-07_15-53-34.jpg

On top of that, we also used the portal as the authentication tool to the SAP system. We did this by creating an alternative login page just for this mobile application that would use the SSO cookie provided by the portal to authenticate against the backend. See below a video of the application (dummy data is being used):

Couple of pain points with this solution:

  • Since the SAP systems are all behind the firewall, using this application required use of VPN client on the device. This authenticates into the VPN network, but they also had to login to the portal KM page to achieve SSO into SAP, so a 2 step login process was involved. Not ideal for long term but we worked with what we had. A true mobile solution would leverage off an external facing system if it was to be browser based
  • Because we had to use VPN, users had to be setup with a VPN account

Having said that, the next step is to setup external access via secure reverse proxies so that the mobile app could be accessed easily. We stayed with the 2 step access path as it was quicker and brought us closer to the goal of building momentum for mobility.

However, here are the benefits to this model:

  • Quick deployment as all objects that had to be created or changed were in the SAP space
  • Changes would be automatically shown on devices when the change hit production
  • Using existing functionality reduced the time required for the business logic
  • Application delivered through the browser meant that it could potentially be used by any mobile device with internet capability – Android, iPhone, iPad or even PCs.

I hope this blog has helped give you a different perspective to how mobile applications can be deployed and gives you the inspiration to try it out.

Almost everything here is based on John Moy‘s blog here.

You must be Logged on to comment or reply to a post.
  • Great job with this blog Joanna and I think there is a real appetite for SAP customers “to get the most out of their existing system” without having to pay for additional licensing.

  • What a great little app! Looks to run much faster than the sap provided leave request app (which we’ve been testing) with all the other sap mobile infrastructure in the way…   😉

    Couple of questions:

    1) When a user wanted to use the app did they just have a url to click on (saved as a home screen icon) or was this wrapped in phonegap?

    2) Authentication: when the user launched the app did the phone ask for network login (for vpn) and then the sap login – ie the two stage authentication you spoke about above?

    3) Just wondering how you got it to use the portal security. The app was in the BSP. In sicf did you point the BSP’s login page to a static html page in Portal KM? Thereby- the portal auto handled the logon and sso into sap, etc?

    Thanks for the blog.


    • Hi Jason,

      Yes it runs very fast because of the architecture. Answers to your questions:

      1) We embedded a home icon for them to save to their home screen. However initially they were given a URL in an SMS and just opened that directly

      2) Yes VPN login then portal/SAP login

      3) We had a KM file hosted in the portal which was pretty much a html that calls the BSP. We required the system name as a URL parameter so it could direct to the system. Calling the KM page triggered a logon and therefore SSO


  • Nice job Jo.

    This is a great example of what a single talented developer can accomplish in a short timeframe when given the freedoms to do so.  We need more devs like that in the SAP ecosystem.  Well done … you are a true long-haired developer! 

    Hope we see more blogs from you in the future.



  • Very nice!

    Go mobile web apps!

    Did you consider using the portal on device (part of 7.3 SP7) or the cloud portal to wrap your mobile web apps?



    • Hi Ohad,

      No we decided to use portal on device because of the way it interacted with the mobile device. Our portal is not on 7.3 and we wanted to use what was already available.



      • Hi Joanna, above you mentioned you didn’t use portal-on-device because “of the way it interacted with the mobile device”… Are you able to expand on that for us? We’re playing around with PoD now so interested in any feedback or thoughts you have on the subject.  😉

        • The portal iViews don’t load very nicely on mobile devices, and it’s usually better for something to render on a mobile device in a format that suits it. We wanted the application to look and feel like a mobile application, rather than a traditional portal view.

          • I agree that the standard FW page and standard iViews don’t render nicely on mobile devices.

            This exactly the reason the portal on device capability was introduced: a FW page that renders just perfectly on tablets and smartphones such as iPad or iPhone, including considerations like form factor, touch gestures and performance.

            Check out for more info.

            We’re getting great feedback on this from others that implemented mobile support via web apps – I suggest you try it out and let us know after playing with it a bit.

  • Thanks for sharing this Joanna. I agree with Ohad, this would be a good application to run inside of Portal On Device… but I am guessing you probably aren’t on NW 7.3 SP7 for your portal yet! 😛

    Just some other things that spring to mind:

    1. I believe that it is possible (at least for iOS devices) to configure the device to connect to VPN for particular URLs – that way the user doesn’t need to activate the VPN first. Also the VPN credentials can be stored so they should not have to put in their username/password for VPN each time.

    2. One way to avoid a nasty portal login screen is to use client side X.509 certificates. I set this up for a demo and it works well, the only issue is the overhead of managing generation and distribution of the certs… not sure if you already have such an infrastructure at Post or not.

    Thanks again,

    • Hi Simon,

      Yes that correct we aren’t on 7.3 yet. Also since it was a trial we wanted to get it up as quickly as possible with the infrastructure we already had. For VPN, we had a URL that could connect to VPN, but it did not render nicely on the mobile device, so we recommended installing the VPN client.

      We definitely considered certificates, but the overhead was not suitable for the timeline we had.



  • Nice one, Joanna!

    As is my duty, I’ll be that guy questioning the security of this, or rather trying to point you to potential issues that you should make sure to address: 😉

    • Once you’re dropping the VPN you’ll expose your BSP to the world. A reverse proxy only solves a limited number of the issues arising from that, so make sure you know how to deal with rogue devices, requests from illegitimate sources (spiders, security scanners) and DDoS attacks.
    • Please be careful what kind of data you’re storing on the frontend (i.e. the phone, browser, browser cache) – a stolen phone exposing HR data could be a serious issue.
    • Session handling is crucial. Don’t ever store authentication credentials (user/passwd, SSO2 cookie, Certificates) in an insecure manner. iPhones are more secure than Android devices, but you don’t want to make that data accessible to malware or other illegitimate access.

    Apart from developing secure code, make sure you have the processes in place to deal with issues like password problems, lost devices etc. – which also means you need to be able to detect those without users alerting you to them.

    Many of those issues SUP deals with, which is one of the reasons we’re promoting it so heavily. I don’t mind seeing apps without SUP, but please make sure you have your based covered.

    Kind regards,


    • Hi Frank,

      Thanks for the tips. As for storing data, we only chose to store certain details offline. Authentication credentials were definitely not stored on the device, so if VPN drops out and they have to reconnect, it reauthenticates against the portal again.

      Please note this is still technically a trial, so if it takes off to be distributed to the rest of the organisation, the issues you raised would be considered.



  • Joanne, this is a great example of how simplicity does it. As pointed by you, this sure needs polishing for e.g. to avoid 2-step login process. Also, if we follow this approach to call  the WD ABAP based applications which use OBN, like standard ESS application, we may have to take care that OBN navigations do not break. Some details on this are provided in the post

    Keep up the good work. Thanks for sharing.



    • Hi Nishant,  We are not using WD components at all, as the HTML and look and feel is driven by the BSP page. Therefore no OBN is ever involved.   Regards, Jo
      • Joanna, the tile of this blog was so enticing that I chose this over other topics 😉 So, I assume many a ESS/MSS folk will arrive here as well. This seems a quick way to do things for many custom scenarios that I can think of. Of course the solution described in this blog did not use WD components, but I pointed this out as it will help others who think they can publish ESS applications on mobile via this method.  Thus my warning ” … if we follow this approach to call  the WD ABAP based applications which use OBN,…”.  Regards, Nishant

      • Hi John,

        AS you are telling we are not going to use WD component but in BSP HTMLB component will give problem to rending a page on phone.

        I think it is only possible when we will use PURE HTML , JavaScript and J query code.

        Thanks Joanna.

        • Hi Pappu,

          Yes, I would not be using HTMLB these days.  In the blogs I have written I have never used that, as it is unsuitable.  If you have seen my blogs you will notice that instead I prefer to leverage the jQuery Mobile framework, which this blog also uses.



  • Hi,

    Cape of good hope for BSP developers sans some limitations…but really nice to get such a wonderful result without much (infact ZERO) investment and maximum utilization of existing system landscape….

    Thanks for sharing…

    Best Regards,

    Tushar S.

  • Hi All,

    When we will Access BSP page out of SAP system on that time we required VPN connection. How we are going to provide VPN connection to phone.


    How we are going to set proxy for mobile phone.

    Please suggest some answer.

    Thanks & Regard.

    P. Kumar.