Skip to Content
Product Information
Author's profile photo Tobias Queck

The Open UX Tools Journey

Since we introduced SAP Fiori tools in June 2020, there have been requests from developers in our community to make the project open source. There are many advantages of releasing the software as open source. For us, the main motivation is to collaborate with the community to create more transparency and therefore increase the adoption of our tools.
This will help us with:
  • Delivering features relevant to community needs
  • Accelerating the development and delivery of these new capabilities
  • Ensuring that any new functionality is developed to work in your specific development scenarios
All of these allow us to rely on the wisdom of the development community, tapping into the expertise of developers in dozens of different countries, working in multiple industries, and creating many different types of applications.
We released Open UX tools as a public GitHub project in September 2021. It is intended to grow over time with modules extracted from SAP Fiori tools.

Initial Release

The main focus for the initial release of modules in October 2021 was to extract the SAP Fiori freestyle templates from the SAP Fiori application generator and provide them as a reusable writer modules for the SAP Fiori application generator and the community-driven easyUI5 generator. Instead of just extracting the templates as one module, it was decided to split the templates into standalone writer modules for (1) creating a basic/empty UI5 application project and (2) adding an OData service to a UI5 application. These two standalone writers are then composed by the Fiori freestyle writer together with the freestyle templates. Each writer module contains the templates as well as the domain knowlege to set defaults, calculate derived values and optionally call other writers. Finally, two helper modules have been identified that encapsulate the functionality to modify yaml files, especially UI5 tooling configuration files (e.g. ui5.yaml), with a more convenient API.

What’s Next?

With the repository in place, the CI/CD pipeline configured and the initial modules out, we are now able to better distribute the work of opening up SAP Fiori tools. There is still work needed to fine tune our process and also make it more transparent to the community.
From a feature perspective, we will continue our bottom-up approach and publish low level modules that are reused across SAP Fiori tools extensions and generators. Of course, the SAP Fiori elements templates are next on the list, but we intend to start other topics in parallel. One of these is the SAP Fiori elements flexible programming model ( that is only partially supported in SAP Fiori tools so far. For the tooling support for the SAP Fiori elements flexible programming model, we have decided to develop the new functionality as open source right away.
Once we are done with the SAP Fiori elements templates, we want to publish the intelligent prompting of the generators in a flexible, reusable format, so that others can also benefit from them. Furthermore, we have received requests from the community to publish the SAP Fiori tools middleware and tasks. Both the prompting as well as the middleware are heavily using a module called odata-client. We developed this to abstract the handling of different OData versions, as well as different environments e.g. local machine vs. SAP Business Application Studio. So, naturally, the odata-client is also on the ‘very next’ list.
This is only a part of what is coming next. Please have a look at the picture below that outlines how things depend on each other.
Is there anything missing that you think should be there? Let us know, open a feature request at

VSCode Extensions

If you are wondering why the VSCode extensions are missing in the ‘What is next?’ section, don’t worry, we also want to publish them. Our VSCode extensions are built on top of reusable node modules that we are focusing on publishing first. Once they are out, we want to pick one extension – Guided development being a prime candidate – and publish it. This will be challenging but exciting, because it will also come with quite an enhancement of our CI/CD pipeline to ensure that we can run our current, complex, internal automated tests.

Long Term Vision

Finally, let’s talk about the long-term vision*. We want to collaborate with the community to create transparency and therefore increase the adoption of our tools. We believe that the best way to do so is to completely open source SAP Fiori tools and SAP Fiori elements.
This will be a long journey, but we are excited and very passionate about it!

Cheers, Tobias!

*this is the current state of planning and may be changed by SAP at any time without notice.


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo William Oconor
      William Oconor

      UX is really important at the moment.

      Author's profile photo Nils Janßen
      Nils Janßen

      Hi Tobias,

      thank you for the detailled explanation. Is there any plan to develop some kind of Visual Editor alternative for VSCode?

      I think that this is a key element to get developers of FE apps to use the UX Tools.

      Author's profile photo Ashley Tung
      Ashley Tung

      Hi Nils,

      Thanks for the feedback. We have recently introduced experimental features in Page Map and Page Editor which makes development of SAP Fiori elements applications easier when using SAP Fiori tools. I encourage you to take a look at this and let us know what you think.



      Author's profile photo Nils Janßen
      Nils Janßen

      Hi Ashley,


      that does look very interesting. Is there any plan to write to webapp/changes  instead of pages/*.json files? (Just like the visual editor does)




      Author's profile photo Christoph Gollmick
      Christoph Gollmick

      Hi Nils,

      product owner of Application Modeler here. The json files you see and you can use for edit are virtual files abstracting the configuration options for SAP Fiori elements apps (manifest + SAPUI5 flexibility changes).

      Each change there either by directly editing the file or by the Application Modeler as the frontend triggers an update in the respective origin file, flex change or manifest entry.

      The virtual files are mainly used as internal interface for Application Modeler and Guided Development, but can also be used as a low-level text interface. But it's optional, the Application Modeler and Guided Dev give you much better UX for configuring your application, and are the recommended tools.

      Best regards,