Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
Showing results for 
Search instead for 
Did you mean: 
Active Contributor
UI5 really sets itself apart by the heaploads of documentation and the many examples. Most of us use SAPUI5 to build applications, components and controls to use in a Fiori Launchpad for our customers. And that's where SAP has a blind spot. There are plenty of standalone examples, but very few examples on how to integrate a component in a launchpad, and even less examples of plugins for the Fiori Launchpad.

Both Wouter and myself have been active as UI5 developers for quite a while, and we have constructed many plugins. Many of those plugins are generic, require no data from a backend and could be reused at other clients. We asked ourselves the question: Could we share our plugins with the SAP ecosystem, so they can be reused by others, and perhaps in turn the eco-system could share their plugins as well?

A first question that needed answering is obviously the legal aspect. You can't just share intellectual property of another organization. So you need permission of your customer/employer before you can share a plugin, or you need to build it in your on time, under your own Intellectual Property.

The second problem is that the Fiori Launchpad is not available publicly. Fortunately there is a Fiori Launchpad Sandbox.js file, for testing and development purposes. It's not officially supported, and doesn't have all the features of a real launchpad, but it serves our purpose perfectly: Testing and development.

Having sorted these two issues out, we set about creating a Plugin showcase, based on the development and testing launchpad sandbox. We needed multiple git-repos for this.

Since we don't want to get into any issues with individual IP-issues, we decided that each plugin source code must remain as the original author built it. To make sure we don't violate any IP, we expect the original author to build the plugin in his/her own repo, and then publish it via NPM. If you then choose to share it, you can add it in the plugin assembly via a pull request. Once we approve the pull-request, a fancy script gets triggered on Travis to generate a new release on the published repo.

You can see the result here:

Notice how many plugins are immediately active. That's something we want to fix. We built a plugin-manager plugin (a bit of a meta-plugin if you like), which allows visitors to choose which plugins are active or not. Unfortunately, we haven't figured a clean way to disable plugins at the start of the application. That's a point of improvement.

If you want to build a plugin yourself (and test it locally) you can use the WebIDE, or use a local dev environment with vscode and expressui5 templates:

  1. Install the expressui5 node package:

  2. Get my quickstart templates from

In any case, check out the plugin template, because there are a few important points:

  • A plugin is typically not designed to be deactived and reactivated, but because the showcase contains many plugins, we want to make sure that visitors can choose which plugins to activate and review. So your plugin needs a destructor that cleans up the plugin's activity and UI element.

  • Plugins must be compatible with Fiori 3 as well.

  • There's certain metadata (properties) that you ideally provide as well. It's not a must, but it would be nice.

Anyway, we hope to share a bit of our knowledge and handywork this way, and we hope that the eco-system chimes in and makes this a fancy central showcase.

So add your plugins:


1 Comment
Labels in this area