Skip to Content

HANA Cloud Portal can auto-discover your widgets!

We all been there, you just finished developed your shiny application with its 5 spec.xml files and you just can’t wait to see them together on your HANA Cloud Portal site.

But wait,

we need to deploy the application.

Go to the landscape cockpit, click the new application URL.

Find your spec.xml URL according to its location in your project.

Check its location again on the eclipse IDE.

Go back to the URL together with the XML relative path.

Found it? Great!

Now go to your admin page on HANA cloud Portal. Create a new Generic Widget with the URL you copy-pasted.

Click Done. OK! You did it.

now do it again 4 more times…

No more! 😀

All you need to do for start using the widgets immediately, is to make sure all your spec xml files has a *.spec.xml suffix. That’s it.

Cloud portal will know to create them on deployment, update them on re-deployment and remove them on un-deployment. It’s that simple.

Now you could say, but I will still need to set the title, description and thumbnail after the discovery.. right? Wrong. 😉

On discovery, these values are extracted from the spec.xml and handed to us by the platform.

Here is what you need to set to take advantage of this capability:

<?xml version="1.0" encoding="UTF-8"?>
     <!-- as you can see, the title, the optional description and the optional thumbnail are set on the ModulePerfs tag -->
     <ModulePrefs title="SAPUI5 example" height="250" description="A widget used to manage to-do lists"
                         <Require feature="sap-theme"/>
     <Content view="authoring, consumption, mobile, preview" href="../index.html"/>

So what do you think? are you planing to use the widget’s auto-discovery?

Tsafrir Sklarski

UPDATE: it is now possible to set the thumbnail value as a relative path to the application root context URL. on deployment, the full URL will be constructed accordingly.

You must be Logged on to comment or reply to a post.
  • This is some great functionality.

    It’s not massively complex, but it does mean consistent cloud portal deploys across environments, and that is important.

    Simple, tidy, tight.

    Nice work!

    • Worth highlighting this bit (as it wasn’t immediately obvious to me).

      All you need to do for start using the widgets immediately, is to make sure all your spec xml files has a *.spec.xml suffix.

      The files can be anywhere in your deployed WAR and you can have as many of them as you like. I’d suggest adding your own thumbnail and using some sort of common prefix/name for your widgets in order to make them easier to find in the catalog once deployed.

  • Hi Tsafrir,

    I was wondering if it is possible to pass a reference to an image file supplied in the WAR to the widget definition. In the example above you had hosted the thumbnail on a publicly accessible site – but I’d like to just have this as part of my WAR – so the eventual path might be

    but I’d like not to have to modify this for each and every deploy.

    Any suggestions? Other than hosting that file somewhere publicly accessible 🙂



    • Hi Chris,

      Again, good point! 🙂

      unfortunately, currently only absolute path is supported.

      the good news is that we develop the improvement to support also relative thumbnail path and it will be available on the next release.

      targeted in the next two weeks.

      in short, when setting a thumbnail path, relative to the spec.xml location. we will construct the full path on deployment. and automatically will set it as the widget thumbnail.

      but again, on the next two weeks 🙂



      • Hi Tsafrir,


        I set the location to be “applicationname/PortalWidgets/widget_icon.png” after having a look at what was attempting to be shown when I tried deploying with various things in the spec.xml file and it worked 🙂 The auto discovered widget has the rather awful icon I assigned to it. 😀

        the was automatically added to the front…

        guessing that will now break in two weeks time 😉

        If you’re looking for things to throw into the next backlog prioritisation session – perhaps some way to set the category of the widget would be great – although “auto-discovered” is cool – it’s not very useful as a filter when I have multiple projects that are using the spec.xml auto discovery to add the widgets into the portal – although having the icons helps 🙂

        Thanks for getting back to me!



      • Unfortunately it does seem the recent update did break the functionality – and rather badly 🙁

        the image is now served in the catalog directly as whatever the thumbnail property is set to. The URL of the server upon which the application was deployed is no longer added at the start.

        result – the browser tries to load the image from the HANA cloud portal site – where is does not exist.

        portal auto discovery issue.png

        the icon is rendered thus:

        <div class=”sapUiTableCell”><img id=”__image0-col0-row9″ data-sap-ui=”__image0-col0-row9″ src=”javaapplicationname/PortalWidgets/widget_icon.png” class=”sapUiImg” role=”presentation” alt=”” tabindex=”-1″></div>

        and unfortunately javaapplicationname/PortalWidgets/widget_icon.png doesn’t exist on the website

        so I get the unfound image icon.

        It would be great to get my icons back 🙂

        Thanks for any help!



        portal auto discovery issue.png
          • Thanks Eliel,

            I’m sure I’ll be redeploying many times before and after then, so no worries. Great to hear that a fix coming and in such a short timeframe. In the old on premise days we’d have been waiting months! 😉

            I look forward to updating with a successful auto discovery including icon 🙂