Personal Insights
The idea of a unified UI5 scaffolding tool
When we look at Open Source software, one of the most prominent ideas of the movement is that contributions get redistributed back to participants in order to “promote the production of high-quality programs as well as working cooperatively with other similarly-minded people” 1 The SAP Open Source website even strengthens this with a punchline on “Co-Innovation”: “No single company can keep pace with the power and speed of communities that openly co-innovate. We believe that sharing creates value.” 2
With regards to this statement, a look at the current state of UI5 scaffolding tools is somewhat sobering. There are many different code generators, both within SAP and outside. The official UI5 tooling has no scaffolding support. Then there is @sap/generator-fiori
for both freestyle UI5- and Fiori Elements apps. Then generator-easy-ui5
by developer advocate Marius Obert. And a plentitude of community generators (do an npm search ui5 generator
and see for yourself).
All of them are geared toward the same purpose:
- bootstrapping (parts of) a UI5 application from scratch
- preconfigured for a particular use case (think Fiori Floorplans)
- with dev-, build- and deploy-time tooling included.
While some parts of one generator might be better than the others, and a combination of all of them might even get you where you want at some point, the fact stands:
it’s terribly inefficient.
And any effort of manually combining them becomes highly frustrating quickly, even for experienced UI5 devs.
What we’d need instead is a unified approach, following the initial thought at the beginning of this article:
a UI5 scaffolding approach everyone benefits from – the UI5 team, other SAP departments + -products, the UI5 community.
How could this be achieved?
Here’s an idea.
Let me walk you through this step by step.
1. community-based tooling is out there, manifold
On the one hand, the variety of community-based solutions for UI5 scaffolding might seem too diverse in numbers and quality.
But on the other hand: the solutions exist already, they are out there, some of them even advanced and presented in detail at UI5cons.
The challenge is to find a way to entice streamlining the existing community solutions into a single “engine”. Ideally also under a single roof, so finding and referencing them becomes more easy.
Also, that aggregation of solutions needs nuts and bolts for quality assurance (think auto-executing tests via Github Actions) so that bespoken engine can humm along smoothly.
Then this proverbial community engine would be ready for a proper chassis to put its horsepower onto the street. Or, in software development terms, have the community engine assembled for (re-)use.
2. bolt things together via easy-ui5
The easy-ui5
generator was recently featured in a UI5 NewsCast, and rightfully so. Marius has created a useful tool that has come a long way from a Friday evening pet project to a feature-laden UI5 source generator. Not the least being easy-ui5
’s capability of bootstrapping application layouts for different deployment scenarios – a focus area where Marius has his ear on the tracks of other SAP teams, following up on changes on target infrastructure, bringing it back to the community via easy-ui5
.
So what chassis other than easy-ui5
would be better suited for holding the afore mentioned community engine?
That’s right: none.
So all them streamlined UI5 scaffolding and templating solutions would find a natural fitting bond in easy-ui5
.
3. re-use easy-ui5
in SAP generators
Now that a powerful engine and flexible chassis is in place, the groundwork is layed for bodywork and model variance. Namely that the generator-modules present in SAP products/solutions (e.g. WebIDE, Business Application Studio BAS) make re-use of the existing scaffolding capabilites in easy-ui5
.
Note that this is not equivalent to a exact 1:1 re-use demand; on the contrary, it makes absolute sense to build enterprise features on top of easy-ui5
– such as multi-language capabilites, preconfigured BTP service bindings, integration stubs, and so on. There’s even no need to build onto all features of easy-ui5
, as some might not hit home for SAP use cases.
The point is: don’t redo the functionalities that are already offered via easy-ui5
, but make use of them to jump start an enterprise scale-up. No need to re-use all, but re-use at least.
To stay within the automotive analogy: build different car models on a shared chassis/engine base, but don’t build a dedicated engine and chassis for every model.
Return of Investments – for all
As laid out in the beginning of this article, the collaborative nature of Open Source software development benefits all participants, be it individuals or companies.
But in the sketched unified UI5 generator approach, there’s even more to it: by building up the re-use pyramid …
@sap
/generators
↑ delivers core functionality
easy-ui5
as “framing” aggregator
↑ provides templates + generators
UI5 community organization
… a value-adding scenario is created that could be returned – via BAS/VS code extensions.
Obviously, the @sap
/generators hold the combined functional benefit of the re-use pyramid. When distributed in BAS/VS Code extensions, the investment contained in them gets returned to both UI5 developers who use VS Code (and/or BAS) and paying BAS customers (they might even constitue the same target audience – developers paying for using BAS!).
Voilà. Return of Investment for parties involved.
Isn’t that a nice win-win scenario for all – SAP as a company, developers as a community and UI5 as a technology?
I’m game.
This is on point Volker Buzek!🍻
I have finally been able to work in VS Code, rather than Web IDE, for the first time. And I love it. But do I have stories to tell about that journey! The jungle of tools and documentation (or lack of) is not for the faint hearted. Without you helping me, I would probably still be struggling. Today I finally worked out how to use the html5-repo-mock with service bindings, to run the FLP sandbox. Because that seemingly couldn't just load up the default-env.json, so I had to reformat it for it not to crash. And the documentation doesn't really explain how to configure it. It tell us what it can do (and that is a lot), but not how to do it. I know we as developer can figure out lots on our own, but sometimes it is more satisfying to developer applications, rather than reverse engineering our tooling.
Another challenge with such a wide field of play, is that it is hard to find a good best practice, when everything is up for grabs. We have to be realistic, and admit that the UI5(and Fiori😊) community is tiny, compared to many other frameworks. But we are a great little group, we love what we are doing, and we are strong when we work united.
great blog, i think SAPUI5 bundlers or Ui5CLI is lacking of a feature to bundle the components you use in your project. We can do this in vue/react when we are using any design framework but it would be great if we can use with SAPUI5 as well. SAPUI5 does not allow to use their CDN and you have to use a separate CDN if you want to develop an app with a specific UI5 library version without relying on your application server's FES component. So either you have to use your application server's UI5 library, or a separate CDN (if you have an index.html in your project) for a newer SAPUI5 library. It is also weird, SAPUI5 library upgrade requires an entire component (FES) upgrade. Very inefficient and not convenient at all.
wrt bundling:
ui5 build self-contained
actually should bundle your entire app, incl all components and the used ui5 libs, into a standalone app you can deploy anywhere
Thanks Volker,
will bundle correct but theme files, message bundles and some other files are missing (or somehow i couldn't make it install).
You need to add
to make a fully working based on example here : https://github.com/SAP/openui5-sample-app
but you will end up having thousands of files. I was expecting a
npm run build
oryarn run build
but i am not able to bundle properly. Finally ended up using CDN.Here is my .yaml libraries
I agree with you. I have same problem. If you use the -a option you will end up having a big project size which too big to deploy to the server.
i had same discussion with the king, the chief, the doer, the decision maker, the one and the only Peter Muessig here
https://blogs.sap.com/2020/04/15/ui5ers-buzz-51-ui5-tooling-2.0-how-to-develop-and-run-sap-fiori-elements-locally/comment-page-1/#comment-555587
i think bundling all theme files like
sap-ui-custom.css
and bundling all js files assap-ui-custom.js
is not possible now.Most likely FIORI development does not need this approach and that is why team is not spending time on this. But if you are not building a honkie-ponkie app like FIORI apps and you need latest files to deploy (as a BSP app), you need an approach like above :/
Only option is deploying app without self contained, just preload files only but with CDN for UI5 library.
Hi Bilen,
Did you try the Progressive Bundle? Peter explains it here:UI5ers Buzz #50: The Loading Evolution: “Get the most out of your UI5 app!” | SAP Blogs
It works fine for me. With this approach you still need a reference to CDN library but not to bootstrap your app. It is needed for missing css/property files.
Below as example my app:
hi Add,
You can't use SAP CDN in your index.html i mean it is forbidden. If it was allowed, i would not need bundling for ui5 library files.
Here is the Note;
2943781 – Is the usage of SAP’s Content Delivery Network for onPremise systems permitted?