Skip to Content

Mobility, Visual Composer, HTML5 and Quiche. Seriously.

As some of you may have already found out – building mobile strategy goes beyond developing cool mobile applications in Objective C or Android Java. One you build the first app that’s really cool, the second one is even better and the third one – pure joy. However – once you get to your 10th or 20th or 80th app – you enter a whole new universe of problems. How do I determine which one in my company gets which app? How do I make sure that all the sales guys have exactly the n apps which they should have, nothing more and certainly nothing less?

Furthermore – you will very quickly realize that the business needs of your mobile warriors extend beyond apps. They need reports, they need documents, they need to collaborate with their peers. You need to tie all of these together in a manner which is a lot more flexible than the rate in which you develop apps today.

In a lecture he gave at the Israeli Microsoft R&D Annual Event (ThinkNext), Steve Ballmer, Microsoft’s CEO pointed out that there is a dichotomy today – you have web sites, where you ALL the information you need (way more than what you really need) “in glamourous detail” vs. the apps – which enable pin-pointed, laser-focused tasks. You need to find the right balance point between them and even more than that – you need to be able to build a web site *around* the apps you have instead of an either/or strategy. So imagine you can create this web site – where on one hand you get all the information you need for a *role* (e.g. Sales Person), such as relevant news, documents, videos, etc. On the other hand – you are able to launch the right mobile apps for this *role*. Imagine you can do this based on the existing roles and content you already have in your landscape?

Too good to be true? Not anymore – Two new NetWeaver Portal – 7.3 SP8 and EWS 1.1 SP3 combine together to bring the “Mobile workspace” to life as part of the full “Portal On Device” offering. Tie that with your native app development tools (such as SUP / Gateway, etc) and you have a really nice offering. To get more insight on these offerings, I highly recommend reading the latest blog posts by Aviad Rivlin  – who is the product manager in charge or rolling-out the portal mobility offerings. IT Teams can very quickly build these mobile launchpads based on their existing NetWeaver Portal and use them to launch apps as well as drive information to their users, which is role-based.

But – And there is a big ‘but’ here (no pun intended / self deprecating humor) – Mobile application development is not a skillset which you normally find within the SAP teams at your regular IT department. Further more – a lot of times, the cost benefit of developing a native, full-blown application for each and every business process which you have now and will have in the future (These things change, if your company is lucky…) is just not there. So we tell our customers to use the 80-20 rule – Find the 20% of the apps which simply have to be native with pixel perfect design and amazing interaction. For the rest of the 80 percent – use HTML5.

Here’s the problem. Its not easy developing in HTML5. It takes a certain level of skill, which is not as common as Java developers. To avoid a religious war in the comments, lets just all agree that FORTRAN developers are real programmers and the rest just eat quiche. Where was I? Oh yes – Its not trivial to master HTML5. SAP is offering a new HTML5 library with the amazingly catchy name “SAP UI Development Toolkit for HTML5” or SAPUI5 for short. But building an mobile-oriented app using it still requires you to understand client side programming. And as mentioned before – this is not as easy as eating Quiche. What is easy as eating quiche? Building applications using SAP’s Visual Composer.

Image courtesy of Sugar & Spice (

A few months ago, I was approached by Kobi Sasson who leads the Visual Composer team with a crazy POC – A version of Visual Composer (VC for short) which consumes Gateway services (oData) and produces HTML5 runtime. Naturally – I blogged about it and moved on. However – it generated an immediate customer response. We had not one but several very large SAP customers line up asking – OK, Cool, When can we have this? For all of them – the use case was Rapid application development for Mobile scenarios. They all used Visual Composer in conjunction with the NetWeaver Portal and to them the transition from Web Dynpro Java runtime to SAPUI5 by using the same tool was an obvious quick win.

The next wave of feedback came from the BPM guys. SAP’s BPM has the ability to automagically generate UIs for a process step. Its a pretty nifty feature – You are the business process expert and you want to model a process and run it. You need a UI to fill in the details in several parts of the process, but you are not a UI developer. Using this feature, BPM creates the UIs for you, with the right input fields based on the context of the process step. This can be done either by Visual Composer or directly via Web Dynpro Java. The ability to use this feature, but instead of generating WDJ to generate HTML5 is something we got very positive ideas about.

Last but not least – the idea of using this for Rapid application development (RAD) on top of NetWeaver Cloud / NetWeaver Cloud Portal is also very appealing.

So – Based on the customer feedback we took the decision to move beyond POC to actual development. The good news is that in the beginning of 2013 (that’s not so far away) – we will be releasing the beta of VC5 – a version of Visual Composer which enables generating SAPUI5 runtime.

We have a roadmap which should take us until the end of 2013 to deliver on all the features which we want out of this (apply usual disclaimer here about timelines, scope etc.), but we are currently on the path to get this out of the door. Is VC5 the ultimate RAD tool that SAP customers will use for all their mobile needs from now until posterity? no. hardly. But it is a ‘good enough’ solution for existing VC/Portal customers to start generating those HTML5 screens which will fit the snazzy portal on device navigation which they just installed.

VC5 Runtime.png

A UI generated with VC5 – This took about an hour to model + deploy to the portal.

I will be attending TechEd Madrid next week. If you are interested to talk about this topic – just drop me an email or ping me on twitter (@vlvl). I’ll be carrying a live demo on my laptop 🙂

See you in Madrid!

You must be Logged on to comment or reply to a post.
    • Hi,

      We are working on building an HTML5 based worklist... This is done on several fronts - both from the BPM aspect and also to be integrated into the portal (as part of the workspaces capabilities).

      I hope we can share more details soon.

  • Thanks Yariv, Having just used Visual Composer on a SAP NetWeaver BPM project, and seen the recently announced Open Task UI for BPM finally released in 7.31 SP5 this is just more great news for process developers like me!

    Looking forward to seeing it happen.

  • Last but not least - the idea of using this for Rapid application development (RAD) on top of NetWeaver Cloud /NetWeaver Cloud Portal is also very appealing.

    OK - now I'm interested.  I assume the POC is for the OnPremise Portal. What about the plans for the Cloud Portal?


    • For the cloud portal we can of course deply the HTML5 files, but the big issue is connectivity. Having an HTML5 widget running on NW Cloud and calling BAPIs RFCs from the On premise ABAP system is problematic. Most likely, once we have the oData figured out this would make more sense as you would consume the oData services from the On Premise Gateway via the SAP Cloud Connector.

      Other option is to deploy the SAPUI5 app created by VC to a regular 7.3 EP and then consume the iView from a cloud portal (you just need to select it in the tenant admin)

      • You could probably create an export option for NW Cloud Portal that provides warnings if direct access to BAPIs, etc were used in the model. You could also think about having a VC Version that hooks into the NW Cloud Connectivity Service and lists those services so they could be used in the model. 

        As you suggest, if you had a model that just used URLs for Gateway / etc, the transition to the Cloud Portal might be easier.

        By the way, there are some interesting parallels between VC and AppDesigner....