Skip to Content

Say Goodbye to the SAP AJAX Portal, and Hello to HTML5

It wasn’t long ago that I was singing the praises of the new AJAX Portal from SAP. Or maybe it was long ago?

Since then, I’ve been thinking: why not really rework these screens with the latest and greatest in web technologies? I’ve been spending a lot of time working on HTML5 and have really come to love the Twitter Bootstrap framework.

I know that companies don’t want to install new hardware or sign up for more licensing. They just want to take advantage of what they have, and make it better, and make it work for them.

So this is what we set out to do, redo the SAP Portal, on the SAP Portal.

You can preview it here:Mindset Consulting – Customized SAP UI

There are a few things I absolutely wanted:

  • no iFrames – I hate multiple scroll bars. There should only be one.
  • Responsive Design – The screen should work in all sorts of resolutions, and on devices like iPads.
  • Dynamic content – Deploying Java to the Portal isn’t very fun. Updating the PCD is easy. Everything should work with the same roles, worksets, and iViews that people are used to.
  • No extras – This sounds odd in the software world, but I think the problem with the Portal today, is there is too much. And it makes it slow.
Also of note:

  • You can still launch SAPGUI, which is I think what most companies really like to do anyway, given the single sign-on advantages of Portal.
  • The design is responsive. As you shrink it, it reformats. Beautiful.
  • But I think the key is that we really cut out the clutter. There is no iFrames.

Go to  Mindset Consulting – Customized SAP UI and let me know.

Also, feel free to share your designs and we can all do better.

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

    this is really excellent and it looks great.

    I look forward to the next blog in your series where you share with the community how you achieved this so that others can try the same.

    All the best,


  • Indeed, great blog Gavin. Thank you for sharing your ideas and POV with the community. looking forward to read your coming blogs.

    I also agree that customers are looking to re-use and leverage their existing investment in the SAP NetWeaver Portal - which is what you are showing here.



  • Nice way to make use of standard portal features. The real problem raises when you have to integrated BI reports, KM content, UWL, WDA/J/VC.

    But yes, a big problem (?) today is that there is no light weighted HTML5 landing page ootb available that lists most used / favorites apps/ pages.

    no iFrames - I hate multiple scroll bars. There should only be one.

    Actually, no scrollbars can be done with the vanilla portal, it's just configuration. And the iFrame issue, that's something you cannot get rid of completely in a corporate landscape where content is hosted on a different server / portal.

    And it makes it slow.

    The portal is slow when you use the default portal apps for navigation. These are made by SAP to cover a wide range of scenarios. Redo them and navigation is way faster.

    • Tobias,

      Thanks for your response, I appreciate the question and comments.

      I think you bring up a terrific point regarding the integrated content. What I try to do though, is determine if it's really suitable to have them integrated into the same "Portal" or launching page as everything else. I'm making the case for a Portal that is much simpler in purpose. For each of those items (BI report, KM, UWL, etc) you can simply have links to those and move to their own page. If there is a real usage where it makes sense to see them together, I would adapt each of those items with REST-based services and use AJAX to bring them into widgets directly in the same screen in a desirable way.

      As for the scroll bars, I get how we could turn them off. But the page is still designed in a way with iFrames that would make it difficult to read, and require either side scrolling or some other undesirable effect.

      The same point goes to the iFrames, I would just link to pages and let them have their own screen, rather than trying to wrap them inside the Portal.

  • I still like the SAP Portal 7.3 Interface much better.....Sorry.

    Also, for your information - I been working on SAP Portal since it's first version - SAP Portal was never meant to be a website........

    • Amr,

      I'm glad to hear from someone who has a hand in it!

      I have no doubt the SAP Portal can do a lot. I may be looking at it from a little different perspective. Sometimes things that you create and are intended be used a certain way, are rarely used that way. What has your research determined on the % of customers that use it to launch applications, versus the % who actually mash-up information on it? I would guess about 5-10% actually use mash-ups?

      Aside from that there are some real interface flaws as I described above, namely, lack of responsive design, overuse of iFrames, too many scroll bars, lack of browser support, and generally slow loading times.

      • I think Gavin is looking at Web Enabling SAP from an 'apps running on a tablet' perspective.

        Lots of individual apps for doing different things.

        SAP Portal cannot be compared to a bundle of apps running on a tablet.

        SAP Portal is a doorway to everything in the Enterprise, not a mash up of apps for people to play with,
        but a tool for business to do business.

        SAP Portal  has one of the smartest cleverest Roles concepts available in Portal technologies on the market.

        It has one url and single sign on to anything and from anything using the latest technologies
        including SAML.

        Since November and GA of Portal On Device SAP Portal's  usage scope is now extended to Launched Applications on Phones
        and Tablets, and brilliantly utilising to Roles concept of the Portal - brilliance, genius.

        To be honest Portal On Device questions the redundancy of what Gavin is offering.

        Still it would be interesting if Gavin would explain in a similar level of detail to the way I
        have explained setting up Portal on Device how he has worked with SAPUI5 to create these applications.

        Regarding Browser Support:

        OSS 1666862 - Allow other browsers to access the portal

        Regarding Performance...

        well that's a question of your sizing, tuning and performance configurations. If you have the know-how you can make EP fly.

        All the best,


        SAP Portal On Device:

        How to Setup Portal On Device:

        • Andy,

          Thanks for the discussion, I'm really enjoying it!

          A few responses:

          I'm not really just looking at enabling apps on a tablet, but each of the individual use cases. I think the foundational components of the SAP Portal are a great place to respond to unique desktops for smart phones, tablets, and desktops of all sizes. Having a single place to launch all of your SAP applications, including the roles concept, KM, and single sign-on are the reasons why I think it makes sense. However, I think the actual HTML display has some opportunities for enhancement.

          Regarding browser support, as you probably know that is very recent (SP7 of NW 7.3). And just allowing browsers access, is a bit different than building up a foundation based on cross-browser.

          SAPUI5 is an interesting case. I worked on an earlier version which was buggy and didn't work with Chrome, so I set it aside for a while. Maybe it's better now? My preference is to use an open source product (Twitter Bootstrap) which has a user community 1000x larger and is pushing the innovation at a faster rate. But it's definitely a step in the right direction.

          As for speed, yes, you can make it 'fast'. But when I mean fast, I mean 100k total download and page rendered in less than 1 second. Have you tried opening the Portal on a tablet on 3g for the first time? Even a finely tuned portal?

          Portal onDevice is another topic in itself. I've worked on this a lot and have actually used many components of this to again, build a simpler version of it. I think most people will do the same thing, since not every customer wants an RSS reader, KM content with favorites and so-on.

          Overall really I just built a skin with an open-source framework, set some rules about what not to do, cut out things I feel are not necessary, and use the same iViews, roles, and security to maintain a dynamic launching place for SAP content.

          • Hi Gavin,

            what you have been doing sounds interesting from an academic perspective, however,

            as a professional in the world of SAP Enterprise Software, the biggest advice I can

            give any SAP Customer regarding running SAP, is,

            as much as possible stick to the SAP Standard

            as much as possible avoid customisation

            To conclude, from an academic perspective what you are describing is interesting, from a professional perspective I would never recommend this customisation to a SAP Customer.

            All for the usual reasons, support, maintenance, operation, upgrading etc.

            All the best,


          • Andy,

            I think that is a good rule of thumb as well. I wasn't looking for a product endorsement, but rather I'm sharing a way to customize the Portal in a way that accomplishes some specific goals. In any implementation you need to weigh pros and cons of customizing. If you ever choose to implement Portal on Device, it will be custom code, so by those rules you are very much going to limit the opportunities of your clients.

            Best of luck,


          • Hi Gavin,

            I am really hoping that since POD is now in GA, SAP will get to market ASAP with the Phone & Tablet versions of the (Portal) Business Packages for the Business Suite.

            Otherwise, if like you say, the only alternative is for all Customers to start doing best of breed combined with writing their own code, history has shown the result is normally expensive and untidy, for all of the reasons already written above.

            All the best,


  • Hi Gavin,

    Thanks for sharing this. I went to your demo and had a look, but all I could see what a rather basic HTML5 page that really didn't do anything (e.g. none of the links worked). Is there really an SAP Portal behind that page? It looks like a PHP app to me 😕

    I have also heard rumour that SAP will release a SAPUI5 based portal framework in an up coming release - I look forward to seeing that.

    Like Andy Silvey mentions, I am a little concerned right now that there isn't more mobile ready content for the portal - I like the idea of the mobile optimized Business Package and hope that SAP get moving on that front - but unless they can sell a new license I am a bit afraid that we won't see that at all. Most of my customers shy away from the idea of custom code...

    Thanks for putting this out there and sparking this discussion.


    • Hi Simon,

      Re. SAPUI5 portal framework - we (SAP) have already released the HTML5 based framework pages (not SAPUI5 yet....) for smartphones and tablet.


      • Hi Tobias,

        I have to admit I am a bit cynical when it comes to good old VC 😀 , I am not sure it ever really lived up to its billing as something a power user (or business user) could use to build apps with... I always found it rather difficult to use and it requires a decent amount of training and practice IMHO.

        What I would like to see is a way to render standard Web Dynpro Apps (Java and ABAP) out to HTML5 or Mobile ready markup. Wasn't that one of the goals of Web Dynpro in the first place, to abstract the UI so that different rendering engines could be used to create different output?



        • Hi Simon,

          when the first VC came out, when was it ?

          Ok I'll answer my own question, I had to look through some old doco, it was the Gui Machine and the earliest doco I have is from August 2003.

          When the VC first came out it was a revolution in as much as, it made creating iViews which used BAPI's much easier than sitting with the PDK and writing the code by hand, something I liked was being able to pick the BAPI Import and Export parameters with the mouse instead of coding them by hand and making typos and classes not working because of JCo exceptions because of BAPI import/export parameter typos. So compared to coding by hand it made iView creating, testing and deployment really easy and fast.

          The VC today is a different beast, a world away in terms of complexity from the original Gui Machine. The Gui Machine was closer to a tool for Power User's than today's VC in my opinion.

          All the best,


        • SAP misplaced VC by saying its a tool for business experts and by using as runtime first flash and then the WDJ runtime, while the last one is quite better than flash. Although VC with flash meant to have portal applications running on a mobile device as soon as Adobe brought flash to Android (irony). That is: years before SAP noticed that people want to access SAP on a mobile device.

          VC5 should be a complete different product, bridging the gap between backend and HTML5. Still nothing for a business user, but for developers modeling an application using services it's way faster and better than WDJ/A.

          Although there still will be the same old problem: the service to be consumed needs to be designed by someone who understands that its a service.

    • Hey Simon,

      Thanks for checking it out. I took the html5 off of the portal, and replicated it in PHP, good eye! It wouldn't be very much fun to have to login to portal (what account and system?) for internet-users just trying to get an idea of what it could do.

      • Hi Gavin,

        it would have been fun to have had an Internet Facing Portal and simply provide a test User and Password (and it wouldn't be the first time this has been done for demo purposes) and allow people to run the apps


      • Hi Gavin,

        I understand it isn't easy to demo this to the public, I can imagine it might have license implications too. I look forward to reading more detail about the steps you went through to realize your vision.



  • Hi Gavin.

    I've tried to open the link to see the demo page, but i received the following message:

    Not Found
    The requested URL /solutions was not found on this server.


    Apache/2.2.24 (Amazon) Server at Port 80

    I agree with you in the point of view about "HTML" instead of "Ajax framework", I really think the "HTML5" comes to make our life more easily and the portal face more user friendly, we are now trying to make a custom top level navigation with ajax framework using the L-ShapeAPIs objects, but is very hard to understand it. Could you check the website in order to we can see the demo page.

    Thanks in advance.

  • As Simon noted above, I could only see the HTML pages when i go the above website. Not sure if i am missing something 🙁 . Can you please correct my understanding?

    Is this website all based on SAP Portal and you have customized the standard SAP pages to look like that? Can you please post some high level steps how you did this and also how you handled the security part?

    • Hello Vankat. Thanks for going through these. We have actually implemented this at a few customers now and they really enjoy it.

      The links above were just the HTML mock-ups, since it's a little difficult to share a portal on the internet with logins and licenses and so-on.

      There has been a few changes since when I originally posted this, and Fiori probably has the biggest impact. Lately we have been using SAPUI5 on the Portal to do this, and it seems like SAP is actually starting to integrate this into their core product.

      Our simple approach was:

      - Design HTML5 layout for launching.

      - Use Netweaver Developer Studio (eclipse) to build a Portal iView. This iView uses plain html5 and then uses the PCD tools / API to search for a user's content.

      - Deploy this iView to the Portal and create a new Portal desktop based on this.

      - Assign this desktop to a new url such as /irj/portal/HTML5

      We've also done very similar things for launching Mobile content, since the earlier versions of the Portal on Device were a little bit complex. Newer versions seem a lot nicer.

      Let me know if you have any other questions.