Skip to Content
Technical Articles
Author's profile photo Andreas Kunz

UI5ers Buzz #56: New full-stack UI5 sample app featuring CAP + OData V4 + draft mode


We just published the code of a new SAPUI5 + CAP sample app at GitHub, similar to – and based on learnings from – the app we built in March to help the Foreign Office of Germany fly back citizens from abroad.

You can use this app as blueprint for similar full-stack apps or as example for the usage of the OData V4 model and its “draft” mode.



One of the never-deemed-possible events of 2020 was the shutdown of international air traffic and the necessity for governments to help their citizens abroad get back home. The Federal Foreign Office of Germany did so as well and reached out to SAP, to take care of collecting and managing the traveller data.

In the evening of March 17th, this call for help reached us. The task was to develop an app over the night, having it ready and demoed to the Foreign Office the next morning and productive soon after.
We and experts from other areas readily engaged and ultimately succeeded – helping 240.000 people to get home. This was likely a more direct value provided to humans than 12 average hours of UI framework development…

More about the effort can be read in this SAP News article. – the original app for German citizens to register for repatriation flights


Anyway, apart from stress and satisfaction, this night also came with lots of learnings about our own UI5 framework, the stack below (CAP on Node.js), how it all works together, and where examples and guidance are missing. With only a small handful of experts and huge time pressure, it really makes a difference that you can’t call another colleague with the missing expertise because it’s 4 a.m.! And design thinking? Fiori guidelines? UX experts? Nope.

So we decided during that night that we would build a similar app on the same stack again after all the turmoil had settled. That we would reach out to experts of all involved areas (including UX) and double-check that we were doing things right. That we would report issues and publish this new app along with documentation as an example how such a full-stack UI5+CAP app can be implemented properly. Finally we are done.


The App

Just like the original app built in March, this sample app consists of three parts: one UI5 freestyle app for data entry by end-users, one metadata-driven Fiori Elements app for data administration, and the CAP server. The scenario we chose is the registration for a company party, but you’ll see that the collected data is minimal and generic, so this app can be the base for any kind of data collection. Technically, the focus is on the UI5 freestyle side of things, in particular on the V4 ODataModel and the “draft” mode – an end-to-end scenario which we found to be under-documented back in March. Some thought has also gone into how a repository with those different parts can be structured.

The sample app is now available under the Apache 2.0 Open Source license on GitHub at

In the file, there is an extensive description which walks you through all areas of the code and the overall project. So we’ll not dive into the technical details in this blog post.

If you want to get started running the app locally first, then follow the instructions in the readme file.

On http://localhost:8080/index.html (user:, password: 123), you can then open the data-entry Form UI.


The Form UI where end-users enter their data


Thanks to “draft” mode, users can leave this app at any time during data entry (without saving!) and come back later to complete and finally send the data.


The same Form UI when re-opened after the user left it without saving the data


Administrators can log in on http://localhost:8081/index.html ( / 123) to inspect the data (including Spreadsheet export) on the SAP Fiori elements list report page. They can also drill-down to the object page to edit the data.


The Fiori elements app used by administrators to work with all entered data


We hope this sample app will help you as much as it would have helped us!


Andreas, Peter, and Joaquin


Previous post: UI5ers Buzz #55: Adaptation Project – your one stop tool for extending SAPUI5 Applications

All UI5ers Buzz Blog Posts


Andreas%20KunzAndreas is software developer and architect at SAP since 2005, focusing on web-based user interfaces. Member of the UI5 development team since its inception and a main driver behind open-sourcing it as OpenUI5.
Peter%20MuessigPeter is one of the initiators who started the Phoenix project (a.k.a. OpenUI5/SAPUI5) grown into the role of the UI5 Chief Architect mainly focusing on UI innovation in the area of the UI framework (UI5 Evolution), controls (UI5 Web Components), tooling (UI5 Tooling).
Joaquin%20Recio%20HuertasJoaquin works currently as Area Architect in UI5 Flexibility area with focus on Cloud Services. He started coding at the age of 9 and has not stopped yet. When he is not busy coding or with his family, you might find him training for his next triathlon.

Assigned Tags

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

      Thanks Andreas for sharing this and a big thank you to the team that behind the scenes made it all possible.

      Sharing the repo is valuable - enabling those on the outside to really pick it all apart and understand how it was done - learnings that we can apply in our organisations.



      Author's profile photo Andreas Kunz
      Andreas Kunz
      Blog Post Author

      Thanks, Andrew! We are sure the code is not 100% perfect, but hope it's good enough to learn from it or get some ideas. And whoever knows how to improve it can contribute - after all it's open source.

      Author's profile photo Muhammad Ilyas
      Muhammad Ilyas

      This is very generic use case, the repo will help get started with basic structure in minutes. I anticipate CAP porting to other dbs will increase UI5 adoption in large scale apps. The context made your blog more interesting ☺️

      Author's profile photo Thorsten Klingbeil
      Thorsten Klingbeil

      Excellent Andreas! - Thanks for sharing!

      Author's profile photo Phani Vasabattula
      Phani Vasabattula

      Thank you Andreas for this blog. I have been developing my app following your blog. However I am having an issue in my app. We have few input fields, and everytime I change a value in any of the input field...a batch request is triggered automatically changing the backend value, without clicking on SAVE button. Any idea what I would have missed? I have compared my code with yours.



      Author's profile photo Andreas Kunz
      Andreas Kunz
      Blog Post Author

      Hi Phani, actually this is what's supposed to happen! In the sample app, using draft mode, this updates the draft, so nothing is lost when the user aborts and resumes later. Pressing on "Save" will trigger conversion of the draft data set into a "really persisted" one, as described in the app's documentation. Without draft mode, the updates will update the "real" data set.

      If you want no such live updates to happen, you can set a custom "updateGroupId" on the ODataModel. Then it's your job to send the update to the server once needed (e.g. when "Save" is pressed). See the ODataModel documentation ( for more info and Step 4 of the OData V4 tutorial ( for an example.