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:
This architecture was pioneered at Post by sufw 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.fetzer2.
With the architecture designed, here are the technical steps that were involved in putting everything in place:
1. Create web service nodes in SICF
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.
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.
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.moy3's blog here.
- SAP Managed Tags:
29 Comments
