Why I think Portal on Device (PoD) has potential
Hi,
It’s been a while since I blogged anything on SCN, for no other reason really than things have been busy. The new SCN platform has given me that extra boost of inspiration I needed to get going and write a piece about the Netweaver Portal and in particular about the new Portal on Device functionality that is being developed.
If you haven’t heard anything about Portal on Device (PoD), then I suggest you take a look at these first:
Portal On Device Introduction: http://scn.sap.com/docs/DOC-16320
Webinar Replay: http://scn.sap.com/docs/DOC-13260
I‘d like to spend a few minutes detailing why I think this approach to mobility has merit and while it may not be the “be all and end all” of a mobility strategy (but then again no one single thing ever is) I think it gives a nice easy way for organizations to start adopting mobility into their business processes without having to commit to a new mobile infrastructure or target a particular mobile platform. Don’t get me wrong I am not saying Sybase Unwired Platform or other MEAPs aren’t required I just think that for different jobs you use different tools and I think PoD is a useful tool to have in your mobile toolbox. So lets go…. here are some reasons why I think PoD is a great idea:
- Many organizations already have a Netweaver Portal and in many cases it is already accessible over the internet (to customers or partners) or could easily be made to be. Even if that frightens the security guys a bit too much it is simple to configure VPN access into the corporate network and not really much of a hassle for mobile device users to access. So the infrastructure hurdle is low.
- The Portal already provides great useful features, services and APIs that can easily be leveraged by mobile content such as:
- Secure login mechanisms (including client side certificates)
- Role based access
- Navigation caching
- Ajax Framework API
- SSO to backend systems
- KM API (Portal Favorites, Doc Mgmt… etc…)
- Worklow API (Rating, comments, approval, publishing etc…)
- Software Logistics and Lifecycle Management
- … The list goes on (feel free to add ) but my point is why rebuild all these things when you can reuse them?
- By utilizing JQuery Mobile PoD is capable of running on a large variety of end user devices, so when the next best phone or tablet comes to market there is no need to start building that next native application.
- Many organizations are already familiar with the concept of Business Packages for the Portal that provide functionality such as Employee or Manager Self Service. I think it is a natural extension to augment these existing business packages with mobile content or create Mobile Business Packages that could be developed by SAP, partners or customers themselves.
So there is is just off the top of my head why I think PoD has value and provides a low barrier to entry into the mobility space for many existing SAP customers already running the SAP Netweaver Portal. Of course you still need to find those business process that will directly benefit from being mobilized – think about what critical processes would benefit from more timely information and actions and how you can build in useful device features like GPS or Contact List or even just the ability to make a phone call or send an SMS. Could you save money on airfares and hotels if your manager could approve your travel request sooner thereby allowing the travel agent to secure a lower fare or rate? What if a manager could just tap on your name and start a call with you to get more details?
If you haven’t played with this yet then I suggest you get your portal upgraded to 7.3 SP5 and take a look a the mobile framework. If you are a developer I’d suggest brushing up on your JavaScript and associated projects like JQuery and JQuery Mobile. Also get yourself familiar with data formats like JSON and ODATA. If you’re a BPXer start thinking about what processes in your area of expertise would benefit from being on a mobile device.
I’d love to hear what you think of this approach – are you already doing something similar? Do you agree or totally disagree with what I am saying? Please leave your comments below I really value your feedback.
Thanks.
Hi Simon
I'll kick start the discussion and play devel's advocate.
I like the concept of Portal on Device (PoD), I agree with you that it allows for a lot of reuse, specifically authentication and role based access and navigation, things that would burn a lot of time building from scratch, I think it is important to note these things are available as API's also.
However I cant help but think this PoD is a solution in search of a problem.
For me the areas where customers would be most interested would be in providing mobile access to MSS/ESS and UWL functionality, entering leave, time, contact details, simple approvals etc.
My first thought, what versions to target, what technologies. If we start with the latest version which is WD4A (built to be Portal agnostic), would it be possible/feasible to create a decorator which transformed a multi panel FPM into a simple usable mobile screen? If it meant a new UI paradigm, say a lighter mobile friendlier SAPUI5, would PoD be the right place to develop and deploy, wouldn't I want to get closer to the metal of the phone and reduce the number of layers?
Cheers
JSP
Hi John,
Thanks for getting the conversation started, I was starting to worry with nearly 300 views (not all me!) and no comments!
In essence I think we are in agreement. If you take the example you give of ESS/MSS functionality that now runs as WD4A it would be nice if there was a mobile optimized view for these services, but PoD isn't the right place to develop that... There are good reasons why ESS and MSS moved away from WD4J, it didn't make sense any longer to have that architecture (maybe it never did!).
But even in this case I would argue that PoD is a good place to launch a mobile version of ESS or MSS from, in a similar way that there are still light weight business packages for the standard portal now. You can build roles and control access using the standard portal services.
In other scenarios like UWL I might argue that PoD is a good choice, since it allows connecting to multiple systems and not just ABAP systems.
As for getting closer to the metal of the phone, the importance of that depends on the particular scenario. I think a lot of business apps don't require that and are not graphically or CPU intensive, and WebGL is now an option too.
Thanks for taking the time to comment.
Simon
Hi Simon
As I said I was playing devel's advocate, I really like the concept and also think there is a lot of potential, 300 views in one day shows others do too!
My comment "closer to the metal of the phone" was probably the wrong phrase. I saw PoD positioned (up until I re-read the Webinar Replay, specifically the roadmap) as only a mobile ready version of the Portal, business content and all. What I was trying to get across was that I dont believe this approach would provide the response and reaction times needed in many cases and that it would make sense to optimize the client side, having some of the code (and content?) sit there calling Portal and back-end API's.
One thing I hope is supported in PoD is Object Based Navigation (OBN), combine this with say Android Intents or Web Intents and you could quickly come up with some cool integration scenario.
Cheers
JSP
Thanks John. You bring up a great example of leveraging existing portal services when you talk about OBN - and I love your idea of combining this with the "intents" concept - brilliant!
I would like to also mention something I saw in the roadmap that worried me slightly.. namely the intent (no pun intended) to integrate with SUP. I really really hope that PoD doesn't end up requiring SUP... it seems like SAP are putting everything "mobile" into SUP which I think is a mistake and actually stifles innovation to some degree.
Right now it seems like to get your Mobile app onto the SAP Store it needs to be based on SUP, I really hope this changes and SAP doesn't force people down this road. SUP has it's place don't get me wrong but it shouldn't be be seen as the only way to mobilize SAP.
It will be very interesting to see how this evolves in the coming months and years.
Cheers,
Simon
Hi Simon, John,
Very nice blog post and great discussion.
John, regarding the "closer to the metal of the phone" =) You meant a native/hybrid app? Perhaps PoD could supply an API to allow native front end development.
Simon, I believe that regardless if SAP requires SUP platform for mobile apps we have enough integration in place to develop and promote other technologies and platforms to mobilize SAP.
Cheers,
Marco
Hi Simon
Thanks for your blog! PoD is something I've been wanting to look into for a while now and you've kick started that again. 🙂
I really like your balanced view on PoD - that it has some real potential but won't suit everyone in every situation. I'm not an expert in the mobility area by any stretch of the imagination but I used to work for a SAP customer who wanted to investigate mobility but only had small budgets and a small but strong team of traditional SAP developers. I've also held the opinion that PoD could be useful for businesses, like my former employer, wanting to dip their toe into the mobility waters without needing to invest too heavily in infrastructure or stretch their development resources with too much "new stuff".
Thanks to you too John, for your debate. I've learned a lot from it as I always do from your wealth of knowledge. A question for you... Are you suggesting a single "Native Client App for Portal" (if I may give it a clunky name :-P) that basically replaces the current PoD functionality and then serves up hosted web apps or fires up other native apps or are you suggesting that individual native apps would use some of the Portal APIs in addition to their normal functionality. I think both sound interesting but the first one sounds like a killer idea. 🙂
Looking forward to hearing more on this debate.
Regards
Glen
Marco, Glen
Trying hard not to pigeon hole for fear of a religious response. I think Marco had it with Hybrid, an application which is more than a website wrapper, uses mainly javascript for the processing and some native code, renders a webui. For my mind there is a lot of familiarity between coding Portal components and Android, I am sure this translates.
The two key things I wanted to get across, performance or the users perception of performance, for years we have all seen the portal get blamed for things that were outside of its scope, optimize the server(s) and optimize the client, which leads to the second thing simple API's = opportunity and possibility, which then leads to a more compelling experience.
I really like the idea of combining OBN's with Intents or something like it, an action could fire up whatever you wanted, web, native, notification, system service etc. Allowing the users to configure their defaults or letting them chose from a filtered list at runtime is one way to make the enterprise more consumable.
Simon, sounds like history repeating, repeating, a bloated proprietary platform that doesn't play well with others, tightly coupling content, development and more.
Cheers
JSP
Hi John, all,
Thanks for great insight and explanation. I believe another showstopper for companies going mobile with SAP is regarding security. The idea of having an external facing Portal for example raises lots of concerns. Do you know if an hybrid mobile app would facilitate in this matter? (Perhaps a vpn connection or SSO ticket in the app itself).
Cheers,
Marco
Hi Marco, yes security needs careful consideration, but no more so than any other public website and many organizations already have a portal facing out to customers for CRM or suppliers for SRM etc...
My security tips would include:
There is always also a balance between security and ease of use. Entering a username and password on a form can be awkward on a mobile device, using client certificates (which the portal already supports is a good option) - perhaps in conjunction with a pin number to provide two factor authentication. A hybrid or native app would also allow for secure storage of a user name and password - so uses would only have to enter it once or when it changes... not every time.
Thanks,
Simon
Lorem ipsum
sorry wanted to see how small columns got, now wont delete
Hi Simon,
I agree totally, we have seen a scurry for mobile POC in the last year. These have strong and commendable goals and I must add customers understand these offerings and opportunities it opens up to them.
It is so refreshing to see new insights with an approach to leveraging off existing SAP Netweaver Portal investments.
To motivate for a Mobile IT infrastructure
(SUP, Sometimes Gateway and Relay servers, and then throw in AFARIA) seems a tall task for the already Techno savvy CXO to agree to.
Coupled with this is the added device specific maintenance as the device OS’s progress. Motivating for totally native solution seems possible, but looks like this requires much more that sher brut and luck.
I believe the debate on Mobile Web vs. Native App is going to ring far into 2013.
When looking at any mobile offering 2 main points stand as strong amongst the many others in my mind.
The SAP Netweaver Portal does address both these. Whislt remote wipe of the device is till to be understood if this is really applicapble or not.
So here is a question: How do we make anywhere any function happen?
Should we rather look at an evolutionary approach (existing investments) as opposed to a revolutionary one (new solutions)?
Cheers
Arun
Hi Arun,
Thanks for your comments. Regarding your question of "how do we make anywhere any function happen?"... I don't think we necessarily want to do this at all. Surely we want to choose the processes we want to mobilize carefully to make sure that that are really adding value and giving us a competitive advantage, once that is decided I think we then need to look at both existing investments and new solutions to find the right answer for a given problem.
I think sometimes people want to be given a simple black a white answer, e.g. This (tool, medication, way of life) is the answer to all your problems... But the reality is much more nuanced and generally requires more careful consideration. 🙂
Thanks for taking the time, I appreciate your feedback.
Simon
Looking forward to get my hands on 7.3 Portal and PoD 🙂
Regards
Rajendra
Hi,
If anyone has tried to develop UWL for mobile, please help to get some idea.
Hi,
Yes there are a number of ways to do this.
1. UWL Java API - the Portal (Java Stack) provides an API for the UWL that you can use to develop your own Mobile UWL front-end.
2. You could use SAP NW Gateway to mobile enable the workflow from the ABAP system (downside is that you would need to aggregate from each ABAP system to create a Universal Work List).
Hope this helps you,
Simon
Thanks Simon for your valuable inputs. Could you please give some more detail hints for this development. Do you have sample code then please share.