SAP Community - SAPUI5

Stop Users from Typing Invalid Values in SAPUI5 ComboBox – A Practical Validation Approach

2026-06-29T21:36:52.647000+02:00

Introduction

In one of my recent SAPUI5 projects, I needed users to select a value from a predefined list. Since the list was quite large, I wanted to make the selection process as smooth as possible. Instead of using sap.m.Select, I went with sap.m.ComboBox because it lets users search for values by typing, making it much easier to find the right option.

Everything worked as expected until I started writing unit test cases. While testing different scenarios, I noticed that users weren't limited to selecting values from the dropdown they could also type any value they wanted. Even if the entered text didn't exist in the list, the ComboBox would still accept it.

It might seem like obvious behavior once you know how ComboBox works, but it was something I hadn't considered during development. That's when I realized that while the control offers a great user experience, it doesn't automatically guarantee valid input.

We could have used a value help dialog for selection, but the requirement specifically called for a dropdown-based experience. That’s why the focus stayed on ComboBox and a deeper validation approach around it.

In this article, I'll walk through the approach I used to keep the search functionality intact while ensuring users can only submit values that actually exist in the dropdown.

The Real Issue in Applications

In actual business scenarios, this becomes a real problem when data moves to the backend. Users may enter free text in the ComboBox and it still gets treated as valid input even if it doesn’t exist in the master data.

This can lead to invalid payloads, failed backend validations, and inconsistent business data in reports. What starts as a small UI behavior can quickly turn into a data integrity issue.

That’s why, when using sap.m.ComboBox for strictly controlled fields like Country, Plant, or Company Code, frontend validation becomes essential before processing the input.

Picture 1: Understanding the ComboBox and It's Behaviour

The Approach I Used

To handle this, I added a simple validation on the ComboBox events. The idea was straightforward—accept the input only if it matches a valid item from the list.

I mainly relied on the change event along with getSelectedKey(). If the user entered something that didn’t match any item, I cleared the value, showed an error state using setValueState("Error"), and displayed a meaningful message.

I also used selectionChange to reset the error state when a valid option was selected from the dropdown, ensuring a smoother user experience.

Implementation

The validation was handled mainly using the change and selectionChange events. The goal was to ensure that only valid values from the dropdown are accepted, while giving clear feedback when something incorrect is entered.

XML View Code: (.xml file)

<!-- XML View -->
<ComboBox
    id="countryCombo"
    items="{path: '/Countries'}"
    selectionChange=".onSelectionChange"
    change=".onChange">
    <core:Item
        key="{CountryCode}"
        text="{CountryName}" />
</ComboBox>

Controller Code: (.js file)

// Controller Logic
onChange: function (oEvent) {
    const oCombo = oEvent.getSource();
    const sValue = oCombo.getValue().trim();
    const sKey = oCombo.getSelectedKey();
    if (!sValue || !sKey) {
        oCombo.setValue("");
        oCombo.setValueState("Error");
        oCombo.setValueStateText("Please select a valid value from the list.");
        return;
    }
    oCombo.setValueState("None");
},

onSelectionChange: function (oEvent) {
    oEvent.getSource().setValueState("None");
}

Best Practices

When working with sap.m.ComboBox, validation should always be treated as part of the design, not an afterthought.

Use getSelectedKey() instead of relying only on getValue(), since free text input is always possible. Trim user input before validation to avoid whitespace-related issues.

Always provide clear ValueState feedback so users immediately understand what went wrong. Also, reset the error state on valid selection using selectionChange to improve usability.

Finally, even if frontend validation is in place, always enforce the same checks at the backend to ensure data integrity.

Picture 2: Data Integrity

Alternative Approaches

Depending on the requirement, there are a few other ways to handle this.

If search is not critical and the list is small, sap.m.Select is a simpler option since it only allows predefined selections.

In some cases, developers try disabling free typing in ComboBox, but that removes the search flexibility, which is often the main reason for choosing it in the first place.

Another option is model or backend-level validation, but that should always complement frontend checks rather than replace them.

Picture 3: Right Approaches for Handling Selections

Key Takeaway & Conclusion:

A ComboBox is not automatically restricted to its items. If your requirement is to allow only predefined values, you must explicitly validate the user input before processing it.

The goal is not to remove the flexibility of sap.m.ComboBox, but to balance it—keep the search experience intact while ensuring only valid, business-approved values make it to the backend.

Kindly Note: We could have used a value help dialog for selection, but the requirement specifically called for a dropdown-based experience. That’s why the focus stayed on sap.m.ComboBox and a deeper validation approach around it.

If you have any alternative effective solutions, please feel free to share your thoughts and so everyone can learn from each other.

Thank you for taking the time to read this blog! If you found this helpful, i would love to hear your thoughts, feedback or questions in the comments. Let's keep learning and growing together!

I’m still new to blogging, so if you notice anything that could be improved or corrected, please don’t hesitate to let me know!!

Deploy a SAP Fiori Elements App from BAS to S/4HANA Cloud and Register It as a Launchpad Tile

2026-06-30T11:31:48.957000+02:00

Most tutorials about deploying Fiori apps from Business Application Studio (BAS) stop at 'Deployment Successful.' But deployment is only the midpoint. For a user to actually find and launch your app in the SAP Fiori Launchpad, you need to wire up four more things: a crossNavigation inbound in the manifest, an IAM App, a Business Catalog, and a Launchpad Space. Get any one of these wrong and you hit silent failures — the app exists in the system but never shows as a tile.

Prerequisites

SAP Business Technology Platform (BTP) subaccount with SAP Business Application Studio subscription
S/4HANA Cloud system with an active OData V4 service
A BTP Destination configured for your S/4HANA system
Eclipse ADT connected to your S/4HANA system

Architecture Overview

OData V4 Service (S/4HANA ABAP)
        │
        ▼
Fiori Elements List Report App ◄── Generated in SAP BAS
        │
   npm run deploy (deploy-to-abap, ui5-deploy.yaml, gCTS transport)
        │
        ▼
BSP Application + LADI /NAMESPACE/MYAPP_UI5R (auto-created on deploy)
        │
        ▼
IAM App (External App type) ◄── Created in ADT, Published Locally
        │
        ▼
Business Catalog ◄── Created in ADT, Published Locally
        │
        ▼
Business Role ◄── Assigned in Maintain Business Roles
        │
        ▼
Launchpad Space / Page ◄── Tile visible to user

Step 1 — Open Business Application Studio via BTP Cockpit

BAS is accessed through the SAP BTP Cockpit — not through the S/4HANA Fiori Launchpad. Open BTP Cockpit → Subaccount → Instances and Subscriptions.

Find SAP Business Application Studio → click Go to Application. You land in the SAP Build Lobby.

Step 2 — Create the Project in SAP Build

In the SAP Build Lobby, click Create (top right) to launch the Create Project wizard.

Wizard Step 1 — Objective: Application

Wizard Step 2 — Category: Full-Stack

Wizard Step 3 — Type: Full-Stack Node.JS

Wizard Step 4 — Name and Dev Space

Provide a project name (e.g. myapp-audit-log) and create or select a Full-Stack dev space.

Click Review then Create. SAP Build provisions the dev space and scaffolds the project.

Step 3 — Generate the Fiori App

With the project open in BAS, press Ctrl+Shift+P and run: Fiori: Open Application Generator

Template Selection — List Report Page

Data Source — Connect to a System

Data Source: Connect to a System
System: Your S/4HANA destination (e.g. YOUR_SYSTEM (S4HC))

Once connected, choose your OData V4 service.

Entity Selection

Main Entity: Root CDS entity exposed by the service
Automatically add table columns: Yes
Table Type: Responsive

Click Finish. BAS generates and opens the project.

Step 4 — Add the crossNavigation Inbound to manifest.json

⚠️ This is where most guides go wrong by omission.

By default the Fiori generator creates an application-type app with no crossNavigation block. If you deploy as-is, the BAS terminal shows:

warn No LADI was created as no inbound is defined in manifest.json
warn App descriptor of type 'application' does not define a launchable inbound

Without a Launchpad App Descriptor Item (LADI), you cannot create an IAM App that references your app, and therefore cannot add a tile to a Business Catalog.

Fix: Open webapp/manifest.json and add a crossNavigation block inside sap.app:

"sap.app": {
"id": "com.mycompany.myauditlog",
"type": "application",
"crossNavigation": {
    "inbounds": {
      "MyAuditLog-display": {
        "semanticObject": "MyAuditLog",
        "action": "display",
        "title": "{{flpTitle}}",
        "subTitle": "{{flpSubtitle}}",
        "signature": {
          "parameters": {},
          "additionalParameters": "allowed"
        }
      }
    }
}
}

Also add the keys to webapp/i18n/i18n.properties:

flpTitle=My Audit Log App
flpSubtitle=View sales order change history

📝 Tip on additionalParameters: Setting it to "" produces a harmless warning. Use the explicit string "allowed" or "ignored" to avoid it.

Step 5 — Create a gCTS Transport Request in ADT

The deploy-to-abap task requires a gCTS transport — a Workbench Request with target 1GT. A normal transport fails with:

Request does not have transport target 1GT

In ADT: Transport Organizer → right-click your user node → Create → Transport Request:

Type: Workbench Request
Target: 1GT

Note the transport number (e.g. ABC9xxxxx) — you will plug it into ui5-deploy.yaml.

Step 6 — Configure ui5-deploy.yaml

Create ui5-deploy.yaml in the project root:

specVersion: "4.0"
metadata:
name: com.mycompany.myauditlog
type: application
builder:
resources:
    excludes:
      - /test/**
      - /localService/**
customTasks:
    - name: deploy-to-abap
      afterTask: generateCachebusterInfo
      configuration:
        target:
          destination: YOUR_SYSTEM
          authenticationType: reentranceTicket
        app:
          name: /MYNAMESPACE/MYAUDITLOG
          description: My Audit Log App
          package: /MYNAMESPACE/MY_PACKAGE
          transport: ABCK9xxxxx
        exclude:
          - /test/
          - /localService/

⚠️ app.name must use your registered ABAP namespace prefix (e.g. /MYNAMESPACE/). Using a Z* name in a namespaced package causes: Customer object WAPA cannot be assigned to package

Step 7 — Build and Deploy

Open a terminal in the project root and run:

npm install
npm run build
npm run deploy

A successful deployment shows:

Inbound MyAuditLog-display was converted to LADI /MYNAMESPACE/MYAUDITLOG_UI5R
Launchpad App Descriptor Item /MYNAMESPACE/MYAUDITLOG_UI5R was created
SAPUI5 Application has been uploaded and registered successfully
Deployment Successful.

📝 Note the LADI ID (/MYNAMESPACE/MYAUDITLOG_UI5R) — you need it for the IAM App in the next step.

Step 8 — Create the IAM App in ADT

In ADT: right-click your package → New → Other ABAP Repository Object → search for IAM App.

Fill in:

Name: /MYNAMESPACE/MYAUDITLOG_APP
Description: My Audit Log Fiori App
App Type: External App ← critical (see gotcha below)
Fiori Launchpad App Descr Item ID: /MYNAMESPACE/MYAUDITLOG_UI5R

Select your transport request and click Finish.

Click Publish Locally.

⚠️ Do NOT select 'Fiori App' or 'UI Adaptation App' as the type. The UI5R descriptor created by deploy-to-abap is only compatible with External App. Wrong type gives:
UI5R can only be used in Adaptation UI Apps

📝 Publishing auto-generates _UI5A and _UI5_EXT runtime artifacts. Always reference the IAM App by its logical name /MYNAMESPACE/MYAUDITLOG_APP, not the runtime objects.

Step 9 — Create and Publish the Business Catalog

In ADT: right-click your package → New → Other ABAP Repository Object → Business Catalog.

Name it (e.g. /MYNAMESPACE/MYAUDITLOG_BC), select your transport, click Finish.

In the Apps tab, click Add and search for your logical IAM App name.

Save, then click Publish Locally.

⚠️ The catalog MUST be Published before it appears in:
• The Maintain Business Roles app's Business Catalog picker
• The Select Catalogs dialog in the Launchpad page editor
If you can see a colleague's catalog but not yours, come back and verify the Publication State.

Step 10 — Assign the Catalog to a Business Role

In the Fiori Launchpad, open the Maintain Business Roles app:

Open your role → Edit
Business Catalogs tab → Add → search for /MYNAMESPACE/MYAUDITLOG_BC → OK
Set Access Category to Unrestricted
Save

⚠️ The Select Catalogs dialog in the page editor (next step) only lists catalogs already assigned to the role that owns the space. Skip this step and your catalog won't appear in the dialog even if it's published.

Step 11 — Add the Tile to a Launchpad Space

In Maintain Business Roles → your role → Launchpad Spaces tab:

Click Add → Create New Space

Open the space/page → Edit → click Select Catalogs

Tick your catalog → Select
On the Manually Selected tab, drag the tile into the page
Add a Section Title, then Save

Step 12 — Access the App

Hard-refresh the Fiori Launchpad (Ctrl+Shift+R). Navigate to your space.

Click the tile. The List Report loads. Press Go.

Troubleshooting Cheat Sheet

Symptom	Root Cause	Fix
warn No LADI was created	No crossNavigation.inbounds in manifest.json	Add the crossNavigation block before deploying
Request does not have transport target 1GT	Wrong transport type	Create a gCTS transport (target 1GT) in ADT
Customer object WAPA cannot be assigned to package	Z* app name in a namespaced package	Use namespaced app name: /MYNAMESPACE/MYAPP
UI5R can only be used in Adaptation UI Apps	Wrong IAM App type	Create IAM App with type External App
My catalog missing from Select Catalogs	Not published or not assigned to the role	Publish in ADT + assign to Business Role + reload
403 Forbidden on BSP URL	UCON blocks direct access	Access via the Launchpad tile, not the direct URL

Summary

The key insight this guide captures is that deployment and launchpad registration are separate concerns that must be completed correctly and in order:

crossNavigation inbound → enables LADI creation on deploy
gCTS transport → enables deploy-to-abap
IAM App (External App) → links the LADI to the authorization layer
Business Catalog (Published) → groups the app for role assignment
Business Role (catalog assigned) → makes the catalog visible in the page editor
Launchpad page (tile dragged in) → makes the tile visible to the user

Tested on SAP S/4HANA Cloud Public Edition, SAP Build / BAS (2024/2025 release), @SAP-ux/ui5-deploy task via specVersion: '4.0' ui5-deploy.yaml.

Your Voice on the Future of SAP UI Technology

2026-07-01T09:00:00.021000+02:00

AI is reshaping how enterprise applications are built, used, and experienced. This raises fundamental questions for SAP's UI technology strategy - and we want to hear from you.

TL;DR: We are running a short, anonymous survey on the future of enterprise UI development with SAP. It takes 5 minutes and is open from July 1 to July 19, 2026. Take the survey →

What are we asking?

We have put together a short survey on the future of enterprise UI development with SAP. It covers topics such as:

How well SAPUI5 meets your needs today - and in the age of AI
Which UI experiences you expect to dominate enterprise apps in the coming years
Which capabilities matter most for your future development work
Where you see SAP's UI technology strategy heading

Why your input matters

SAP's UI frameworks power thousands of enterprise applications worldwide. Decisions about their future direction affect you — whether you are building new apps, maintaining existing ones, or advising customers on their architecture. Your perspective as a developer, architect, or decision maker in the SAP ecosystem is what we need to make the right calls.

Who should take this survey?

This survey is for anyone working with SAP UI technologies: SAPUI5 / Fiori developers, UI and UX architects, technical leads, enterprise architects, and IT decision makers at SAP customers and partners.

Call to Action

Make your voice heard by participating in the survey here: SAP UI Technology Strategy Survey. It only takes 5 minutes to complete, and is open from July 1 to July 19, 2026.

Project HomeControl 2 · Part 1 — 10 years later, my whole house talks (and an AI drew the dashboard)

2026-07-05T16:20:13.554000+02:00

Sequel to Project HomeControl (2016). A short series about wiring up a modern smart home — and, running underneath it, what you can actually do with AI today. Every part ends with one concrete lesson on building with an agent. All passwords, tokens and keys are deliberately left out.

Ten years ago I soldered my meter cupboard to UI5

In March 2016 I wrote my first Project HomeControl post. The trigger: the EU was rolling out smart meters, the Netherlands would replace every old meter before 2020, and I had an electric car and wanted to know what it did to my consumption.

The solution back then was gloriously hacky: an Arduino on a breadboard, a wire in the P1 port of the meter, reading serial number, tariff, current and total usage — shown in a UI5 app I built myself.

Ten years on, almost everything about that story has changed, and one thing hasn't.

The thing I soldered? It's now a HomeWizard P1 — a €30 plug that does exactly the same, reliably, out of the box. The electric car is a Porsche Taycan. And it's no longer one meter: it's a whole house — solar, a heat pump, chargers, Hue, Sonos, thirteen cameras, blinds.

What didn't change: the curiosity, and — spoiler for Part 2 — that it ends up being about UI5 again.

This is Project HomeControl 2. This part is the boring-but-important half: the setup, and a first dashboard. The fun half (an AI agent that did most of the work) is Part 3.

What's in the house now

Everything reports into one hub — Home Assistant, running in Docker on a QNAP NAS. The integrations fall into three neat buckets, and that split matters later:

Local, real-time — SolarEdge inverter over Modbus TCP, the HomeWizard P1 meter, the Tesla Wall Connector's local API, the heat pump via a CMI gateway.
Local, discovered — Philips Hue (79 lamps, 83 scenes), Sonos, the Brel blinds hub.
Cloud — Porsche Connect for the Taycan, Ring for the cameras.

By the end of the setup, Home Assistant held 424 entities across eight integrations. The 2016 version tracked about six values from one meter. Progress.

Three kinds of integration feed one hub: local and real-time where it matters (solar, meter, charger), local discovery for lighting and media, cloud where there's no other way in. Home Assistant is the single source of truth the dashboard reads from.

Design before framework: a static dashboard first

Here's a habit worth stealing: before reaching for a framework, I build the dashboard as a single static HTML file. No build step, no components, no bindings — just a design I can look at and react to. It's the cheapest possible way to decide what the thing should feel like before committing to how it's built.

The result is a small, deliberate design system:

Design tokens for colour, surfaces and text, with a genuine dark and light theme (not a naive invert — each theme tuned so the accent still reads).
Tabular numerals everywhere digits line up, so values don't jitter as they update.
Status encoded in form, not just text — a green "Live" chip, an amber "Almost done", a red battery figure — so what needs attention reads at a glance.
A live energy-flow: where the power is going right now, and how much of it the sun covers.

The static dashboard (dark theme). Summary tiles up top, then energy, car & charging, and the house — every number is real data from Home Assistant. There's a light theme too, driven by the same design tokens, so one set of components serves both.

That energy-flow card tells a true story from one afternoon: the Taycan was charging at 11 kW while the sun only produced 3.1 kW, so 8.9 kW came from the grid. Seeing that immediately raised the question that becomes Part 4 — can I make the car charge on sunshine only?

The part that surprised me

I didn't hand-code that dashboard pixel by pixel. I described it — "a clean, dark energy dashboard, tokenised, dark and light, tabular numbers, status chips" — and an AI agent produced the design system, wired it to the live Home Assistant data, and rendered it in both themes. My job shifted from typing CSS to directing taste: react, refine, decide.

That's the thread running through this whole series. Not "AI writes code" — we knew that — but that the unit of work moves up a level. You bring the intent and the judgement; the agent brings the hours.

What this shows about building with AI
A plain-language description — "make it feel like a clean energy dashboard" — became a real, themeable design system wired to live data, in minutes. The lesson isn't speed for its own sake; it's that the cheap-to-throw-away exploration phase gets almost free. You can see three directions before lunch and keep the one with taste. Start vaguer than you think, then direct.

The dashboard is static HTML today. In Part 2, I turn it into a proper UI5 frontend — and the interesting bit is that I do it with non-UI5 Web Components, hosted inside a UI5 app. It's the same question I asked in 2016, only reversed, with a much better answer.

Part 2 — A UI5 frontend with (non-UI5) Web Components — is next.
https://community.sap.com/t5/technology-blog-posts-by-members/project-homecontrol-2-part-2-a-ui5-frontend-built-from-non-ui5-web/ba-p/14433981

Project HomeControl 2 · Part 2 — A UI5 frontend, built from non-UI5 Web Components

2026-07-06T08:26:02.639000+02:00

Part 2 of Project HomeControl 2. In Part 1 I connected the whole house to Home Assistant and drew a dashboard as static HTML. Now I make it a real UI5 frontend — using Web Components that aren't UI5. As with every part, there's one lesson about building with an AI agent at the end.

The question I couldn't let go

In 2016 I built a UI5 app to show my smart meter. In Part 1 of this sequel I had a dashboard again — but as a static HTML file with a bespoke design system: dark tokens, tabular numbers, status chips, a live energy-flow. Lovely to look at, but not a UI5 app.

Rebuilding that look in stock Fiori controls would mean fighting the theme every step of the way. So I asked the question a lot of UI5 developers quietly wonder about:

Can I keep this exact design — as Web Components — and still host it in a UI5 app, with proper model binding, in an XML view, driven by a JSONModel?

Yes. Here is the whole thing, end to end, including the parts that bit me.

Why UI5, and not React or Astro?

Fair question — and an honest answer: if I were building this dashboard greenfield, I probably wouldn't reach for UI5. For a bespoke, consumer-style dashboard, Astro, React or Lit are the natural picks. UI5 is built for enterprise Fiori apps with OData, not dark energy dashboards.

But that's not the interesting scenario. The interesting one is the reverse:

Nobody starts a bespoke dashboard in UI5. Plenty of teams have a large UI5/Fiori landscape and want to bring modern, shared Web Components into it — without rewriting.

That's a real, non-niche need: reuse a design-system component across apps, drop in a third-party Web Component (a charting library, a Shoelace control), or share slices of UI between UI5 and non-UI5 apps as micro-frontends. In that world, the dashboard here is just the vehicle — the point is that your UI5 investment can host framework-agnostic components, with binding.

And it's oddly under-documented. SAP even ships "UI5 Web Components" — but that's the other direction (UI5 controls exposed as custom elements for React/Angular). Hosting arbitrary Web Components inside a classic UI5 app, with model binding and the sharp edges, is territory most UI5 content skips. That's exactly why it's worth writing down.

A 30-second recap: what a Web Component is

A Web Component is three browser standards working together:

class PeppieTile extends HTMLElement {       // 1. a custom element
  constructor() { super(); this.attachShadow({ mode: "open" }); }   // 2. Shadow DOM (scoped CSS)
  set data(d) {                              // 3. a PROPERTY that takes an object
    this.shadowRoot.innerHTML = `<style>…</style><div class="tile">${d.value} ${d.unit}</div>`;
  }
}
customElements.define("peppie-tile", PeppieTile);   // tag MUST contain a hyphen

Use it with plain DOM:

const t = document.createElement("peppie-tile");
t.data = { label: "Solar now", value: "3.1", unit: "kW", accent: "amber" };
document.body.append(t);

No framework. It runs standalone, in React, and — the point of this post — in UI5.

The bridge: one UI5 control

Am I not reinventing something SAP already ships? Partly — yes, and it's worth saying up front. UI5 has an official base class, sap.ui.core.webc.WebComponent, that does this generically: it renders the tag, forwards object values onto the element as properties (not attributes), updates them without a full re-render, and maps slots and events. For a fixed set of components, extending it per element is the idiomatic route — and a lot less code than the wrapper below. Nico Schönteich walks through exactly that in Consuming your own (or external) Web Components in UI5 Applications. I'm rolling the glue by hand here on purpose: it's the clearest way to show why .data has to be a property, and where the upgrade-order and re-render traps live. Do it once yourself, then reach for the base class. (I also wanted one generic control that wraps any tag via a single data object — a different trade-off, handy for a fast-moving bespoke design system.)

UI5 already renders DOM. A custom element is DOM. So the bridge is a single control that renders the tag and hands the element its data:

// peppie/control/WebComponent.js
sap.ui.define(["sap/ui/core/Control"], function (Control) {
  "use strict";
  return Control.extend("peppie.control.WebComponent", {
    metadata: {
      properties: {
        tag:  { type: "string", defaultValue: "div" },  // which custom element
        data: { type: "object" }                        // bind your model object here
      }
    },
    renderer: {
      apiVersion: 2,                                     // semantic rendering / DOM patching
      render: function (rm, oControl) {
        rm.openStart(oControl.getTag(), oControl);       // <peppie-tile id="__control0">
        rm.style("display", "block");
        rm.openEnd();
        rm.close(oControl.getTag());
      }
    },
    onAfterRendering: function () {
      var oDom = this.getDomRef();
      if (oDom) { oDom.data = this.getData(); }          // property, not attribute (pitfall #1)
    },
    setData: function (vData) {
      this.setProperty("data", vData, true /* suppress re-render */);
      var oDom = this.getDomRef();
      if (oDom) { oDom.data = vData; }                   // live update in place (pitfall #3)
      return this;
    }
  });
});

rm.openStart(tag, oControl) is the trick in the renderer: passing the control writes UI5's id and bookkeeping onto the custom element, so apiVersion: 2 can patch it in place instead of throwing it away on every change.

Wiring it into a real UI5 app

Four small pieces, all of them standard UI5.

1. Bootstrap — load the custom elements before UI5, register a resource root for your control namespace, and pick a theme:

<!-- index.html -->
<script src="webcomponents.js"></script>            <!-- define elements first (pitfall #4) -->
<script id="sap-ui-bootstrap"
  src="https://sdk.openui5.org/resources/sap-ui-core.js"
  data-sap-ui-theme="sap_horizon_dark"
  data-sap-ui-libs="sap.m,sap.ui.layout"
  data-sap-ui-resourceroots='{"peppie": "./peppie/"}'
  data-sap-ui-oninit="module:sap/ui/core/ComponentSupport"
  data-sap-ui-compatVersion="edge"
  data-sap-ui-async="true"></script>

2. The model — declared in the manifest, so it's there before the view:

"sap.ui5": {
  "models": {
    "": { "type": "sap.ui.model.json.JSONModel", "uri": "model/data.json" }
  }
}

3. The view — the namespace peppie.control resolves to peppie/control/WebComponent.js via the resource root. Now binding is exactly what you'd hope for:

<mvc:View controllerName="peppie.controller.Main"
  xmlns:mvc="sap.ui.core.mvc" xmlns="sap.m"
  xmlns:grid="sap.ui.layout.cssgrid" xmlns:wc="peppie.control">

  <VBox class="peppieWrap">

    <!-- a native UI5 control, bound to the same model -->
    <MessageStrip text="{/suggest}" type="{/suggestType}" showIcon="true"/>

    <!-- tiles: one control, four bindings, in a real CSS grid -->
    <grid:CSSGrid gridTemplateColumns="repeat(auto-fit, minmax(220px, 1fr))" gridGap="0.6rem">
      <wc:WebComponent tag="peppie-tile" data="{/tiles/0}"/>
      <wc:WebComponent tag="peppie-tile" data="{/tiles/1}"/>
      <wc:WebComponent tag="peppie-tile" data="{/tiles/2}"/>
      <wc:WebComponent tag="peppie-tile" data="{/tiles/3}"/>
    </grid:CSSGrid>

    <!-- cards: two columns that each stack tightly -->
    <HBox wrap="Wrap" class="peppieCols">
      <VBox class="peppieCol">
        <wc:WebComponent tag="peppie-flow"        data="{/flow}"/>
        <wc:WebComponent tag="peppie-metric-card" data="{/p1}"/>
        <!-- … taycan, ring -->
      </VBox>
      <VBox class="peppieCol">
        <wc:WebComponent tag="peppie-metric-card" data="{/solar}"/>
        <wc:WebComponent tag="peppie-metric-card" data="{/wp}"/>
        <!-- … tesla, hue -->
      </VBox>
    </HBox>

  </VBox>
</mvc:View>

One generic control wraps every element in the library. Ordinary UI5 layout does the arranging — a sap.ui.layout.cssgrid.CSSGrid for the tile row and two sap.m.VBox columns in a wrapping HBox for the cards (a float-based sap.ui.layout.Grid left ragged gaps between cards of different heights, so I switched). And a native sap.m.MessageStrip sits at the top, bound to the same model — proof that stock UI5 controls and Web Components mix freely in one view.

Running OpenUI5 app (sap_horizon_dark). The toolbar and its buttons are stock sap.m controls; everything below is Web Components bound to a JSONModel. Two worlds, one app.

The pitfalls (this is where the time goes)

1. Property, not attribute. The big one. UI5 binding, and most snippets you'll copy, write to attributes. Web Components take rich values — objects, arrays — as properties. setAttribute("data", {...}) stringifies to [object Object]. So in onAfterRendering you do element.data = this.getData(). That one line is why this works at all.

2. Bind objects, update them immutably. The wrapper binds a whole object (data="{/tiles/0}"), and JSONModel compares by reference. Mutate that object in place and the binding never fires. The tempting fix — model.refresh(true) — works, but it's a smell: it re-evaluates every binding in the app to paper over mutated state. The clean fix is to treat model data as immutable and replace the node with a new object, so the reference changes and exactly that binding updates:

onSimulate: function () {
  var m = this._oModel, oTile = m.getProperty("/tiles/0");
  // new object → new reference → the {/tiles/0} binding fires on its own
  m.setProperty("/tiles/0", Object.assign({}, oTile, { value: solar.toFixed(1) }));
}

No refresh(true), no shared state mutated in place — each changed node fires its own binding.

3. Re-render vs. live update. UI5 controls invalidate and re-render. You do not want to tear down and rebuild a custom element on every model tick. That's why setData uses suppressInvalidate = true and updates the live element directly. In the demo, "Simulate reading" changes the model and every tile, bar and card updates without a single re-render.

4. Load order and the upgrade trap. Define your custom elements before the control first renders. If UI5 renders <peppie-tile> before the browser knows the class, it's an inert unknown element; worse, setting .data on a not-yet-upgraded element creates an own-property that shadows the class setter after upgrade. Loading webcomponents.js in <head> before the bootstrap avoids the whole class of "it works on refresh but not first load" bugs.

5. Layout and height. Web Components are display: inline by default — render them display: block (the control does this). And don't drop them into a sap.m.Page that has no height: the Page positions its content absolutely, so a zero-height container renders a blank screen. I lost a minute to exactly that; a VBox/Grid that flows with content, or a container with a real height, fixes it.

6. Getting events back into UI5. Binding flows data in; for interaction out (a light toggled, a card clicked) let the element dispatch a CustomEvent and re-fire it as a UI5 event:

metadata: { events: { action: {} } },
onAfterRendering: function () {
  var oDom = this.getDomRef();
  oDom.data = this.getData();
  if (!this._wired) {                       // wire once
    oDom.addEventListener("peppie-action", (e) => this.fireAction({ detail: e.detail }));
    this._wired = true;
  }
}

Now <wc:WebComponent action=".onAction"/> works like any UI5 event handler.

The honest alternative

If you want to stay fully inside the SAP toolbox, you can: sap.f.Card for the layout, sap.suite.ui.microchart for the little charts. You get binding for free and a Fiori-native look. For this deliberately non-Fiori design, the Web Component route was less fighting and more reuse — the same components run outside UI5 too. Pick per project; just know both exist.

Try it

The full runnable demo is in ui5-demo/ — OpenUI5 from CDN, one wrapper control, a JSONModel, no build step. npx serve ui5-demo, open the URL, hit Simulate reading and Theme.

What this shows about building with AI
I described the goal — "wrap these custom elements as a data-bound UI5 control" — and the agent produced the control and got the app running fast, naming most pitfalls as we hit them: the attribute-vs-property gotcha, the sap.m.Page height trap, the upgrade-order bug. But not everything it produced was senior-grade. Its first fix for the object-binding problem was model.refresh(true) — and my own instinct said mutating model state and force-refreshing is not done. We replaced it with immutable setProperty updates. That's the real division of labour: the agent brings speed and breadth; you bring the judgement that turns working into clean. Treat its output as a strong first draft, not the final commit.

Your turn — a give-away

This demo is JavaScript. It should be TypeScript: the model typed, the control's managed properties typed, the Web Components' data typed end to end. That's a real, multi-file refactor across the UI5 Tooling — exactly the kind of well-scoped job an agent is good at and you review.

I ran this prompt myself before publishing it, and it turned out to be the whole series' thesis in one artifact. Left vague, the agent produces something that looks converted but doesn't build: a broken generator dependency (@ui5/ts-interface-generator pulls in an ESM-only yargs and won't run), the OpenUI5 framework config the CDN app never had, a setData signature that clashes with the generated interface, a type-only module that gets stripped to a non-module. So the prompt below is deliberately specific — exact versions, and the three real blockers baked in. That specificity is the difference between "the agent tried" and the build is green.

Run it in the ui5-demo/ folder and hold it to the acceptance criteria at the end.

You are a senior SAPUI5 + TypeScript engineer. Convert the JavaScript UI5 app in this folder to
TypeScript — fully typed, strict:true — and make it BUILD and SERVE with the UI5 Tooling. Do NOT
change runtime behaviour; the app must render and behave exactly as it does now. Work in small,
reviewable steps: layout & framework first, then toolchain, then types, then module conversion.

0. Environment. @ui5/cli 4 wants Node >= 22.12; older Node only prints an EBADENGINE warning and
   still works.

1. Layout & framework — the app currently loads OpenUI5 from a CDN; that must change, because the
   UI5 Tooling serves the framework itself.
   - Move all app sources under webapp/: index.html, Component.ts, manifest.json, controller/,
     view/, control/, model/, and the web-components module.
   - Add ui5.yaml that pins OpenUI5 locally (no CDN):
       specVersion: "3.0"
       metadata: { name: peppie }
       type: application
       framework:
         name: OpenUI5
         version: "1.120.46"
         libraries:
           - name: sap.ui.core
           - name: sap.m
           - name: sap.ui.layout
           - name: themelib_sap_horizon      # required for sap_horizon_dark
       builder:
         customTasks:
           - name: ui5-tooling-transpile-task
             afterTask: replaceVersion
       server:
         customMiddleware:
           - name: ui5-tooling-transpile-middleware
             afterMiddleware: compression
   - In webapp/index.html change the bootstrap src from the CDN URL to "resources/sap-ui-core.js"
     (served by the Tooling). Keep data-sap-ui-theme="sap_horizon_dark", the ComponentSupport
     oninit, and data-sap-ui-resourceroots='{"peppie": "./"}'. Ensure manifest.json sap.app.id =
     "peppie" so the resourceroots, the /** @namespace peppie.* */ values, and the manifest id all
     agree.

2. Toolchain & exact, known-good versions.
   devDependencies:
     "@openui5/types": "1.120.46"
     "@ui5/cli": "^4.0.57"
     "@ui5/ts-interface-generator": "^0.11.1"
     "typescript": "^5.9.3"
     "ui5-tooling-transpile": "^3.11.3"
   overrides (MANDATORY — see step 4):
     "@ui5/ts-interface-generator": { "yargs": "^17.7.2" }
   scripts:
     "ts:check": "tsc --noEmit"
     "build": "ui5 build --clean-dest"
     "start": "ui5 serve --open index.html"
   tsconfig.json: strict:true, target/module "ES2022", moduleResolution "node",
     lib ["ES2022","DOM","DOM.Iterable"], skipLibCheck:true, rootDir "webapp",
     paths { "peppie/*": ["webapp/*"] }, types ["@openui5/types"],
     include ["webapp/**/*.ts","webapp/**/*.d.ts"].

3. Convert each sap.ui.define([...], function(){}) into an ES-module TypeScript class with
   import / export default, UI5 TS style, keeping the namespace via /** @namespace peppie.control */.

4. The custom control — mind the interface generator.
   - Keep the metadata block; type the renderer (RenderManager), onAfterRendering, and the setData
     override.
   - Run @ui5/ts-interface-generator to emit WebComponent.gen.d.ts (typed getTag/setTag/
     getData/setData plus $WebComponentSettings), and make sure tsconfig includes it.
   - BLOCKER: @ui5/ts-interface-generator@0.11.1 require()s yargs but resolves the ESM-only
     yargs@18 -> ERR_REQUIRE_ESM, so the generator won't run at all. The overrides pin in step 2
     (yargs ^17.7.2) fixes it. Install that BEFORE running the generator.
   - Two things the generator will NOT do for you:
       a) It prints three constructor(...) overload lines and says "copy & paste manually" — paste
          them into the class (referencing $WebComponentSettings). It never edits your source.
       b) It also generates setData(data: object | null): this. Your hand-written setData MUST use
          the exact same `object | null` parameter type, or declaration-merging fails with an
          overload-compatibility error.

5. Types. Add webapp/model/types.ts with interfaces TileData, FlowRow, FlowData, MetricItem,
   MetricCardData, EvCardData, RingCam, RingCardData, LightGroup, LightsCardData, and a root
   DashboardModel including suggest:string and
   suggestType:"Success"|"Warning"|"Error"|"Information"|"None". Type the JSONModel and the
   controller's onSimulate against DashboardModel.

6. The web components — make it a real UI5 module.
   - Write webcomponents.ts with a typed `set data(d: …)` per element and augment
     HTMLElementTagNameMap so createElement("peppie-tile") and the control's getDomRef() are typed.
   - IMPORTANT: add at least one runtime `export` (e.g. export { PeppieTile, PeppieFlow, … }). A
     module with only TYPE exports gets type-stripped to a plain script and is NOT wrapped as a
     sap.ui.define AMD module — the build then warns it "requires eval". A real runtime export
     makes it a proper module.
   - Have Component.ts do a side-effect import "./webcomponents"; so the custom elements are defined
     before the controls render.
   - In the wrapper, type the element so assigning .data is checked. A single, commented
     `getDomRef() as HTMLElement & { data: unknown }` cast is fine — do not use `any`.

Acceptance criteria (all must pass):
- `npm run ts:check` -> zero errors with strict:true.
- `npm run build` (ui5 build) -> green, no warnings, produces a runnable build.
- `npm start` (ui5 serve) -> renders identically: four tiles, two-column cards, the MessageStrip,
  and "Simulate reading" flipping the strip between Warning and Success.
- The generic WebComponent wrapper still wraps any element through one `data` property; no `any`
  anywhere (the one commented getDomRef() cast excepted).

When done, show me the final tsconfig.json, ui5.yaml, package.json, the typed WebComponent, and
model/types.ts.

Validated: this produced tsc --noEmit with zero strict errors, a green ui5 build, and a ui5 serve render pixel-identical to the JavaScript original. First draft from the agent; the specificity — and the final commit — from you.

The house is connected (Part 1) and it has a real UI5 frontend (Part 2). In Part 3 I pull back the curtain on how most of this actually got built: an AI agent that read a login captcha, hacked a solar inverter, and then deleted its own hack when the clean route opened up.

Part 3 — I let an AI agent connect the whole house — is next.

Code Connect 2026: Final Info Before We Kick Off!

2026-07-06T11:02:20.615000+02:00

Code Connect 2026 is just around the corner! From July 13–16, 2026, the SAP developer community will gather in St. Leon-Rot, Germany – onsite and online.

Here’s everything you need to know before we get started.

We Are Fully Booked!

All onsite tickets are fully booked - thank you for the amazing interest!

If you couldn’t secure a ticket:

Join the waiting lists on Code Connect 2026 in case seats become available.
Follow selected sessions via live stream or Microsoft Teams link.

Even if you're not onsite, you can still be part of Code Connect. Selected sessions will be streamed live, and recordings of some sessions will be available afterwards. Check back soon for details.

UI5con (July 14)

Main stage sessions will be live streamed on YouTube.
Check the agenda to see which sessions are streamed.

re>≡CAP (July 15)

Main stage sessions will be broadcasted.
Some sidetracks (W1/W2) can be attended via Microsoft Teams link.
Check the agenda to see which sessions are broadcasted or available via Microsoft Teams link.

HANA Tech Con (July 16)

The links will be announced on the event day.

The Agendas Are Live

The full program is already available - time to plan your schedule!

Check-In opens at 8.00 AM every day. Please bring the QR code with you that you can find in your ticket.

July 13 – Code Jams & Community Meetup

Hands-on Code Jams:

OpenUI5
CAP
AI Agents

Informal pre-event meetup (no registration needed):
Ihle Besen, Höfe am Sträßel 3, 69231 Rauenberg
5:00 PM CEST

July 14–16 – Main Conference Days

Explore all agendas:

July 14: UI5con
July 15: re>≡CAP
July 16: HANA Tech Con

On July 14 also the HANA AI CodeJam takes place.

Location

Code Connect takes place at:

SAP-Allee 27
68789 St. Leon-Rot, Germany

Find detailed information on directions, parking, and public transport here.

Final Tips

Bookmark your favorite sessions in advance
Arrive early for popular sessions (rooms fill quickly!)
Bring your laptop for Code Jams and hands-on sessions/ workshops
Don’t miss the networking moments - some of the best conversations happen in between sessions
Follow the agendas closely for last-minute updates

See You Soon!

We’re looking forward to an inspiring week of learning, sharing, and connecting.

See you at Code Connect 2026!

SAP Fiori Development newsletter issue #41 (July 2026)

2026-07-07T15:50:00.014000+02:00

Summer is here and it’s getting hot. I’m not just talking about the weather. AI is heating up both for the companies that create the large language models and everyone trying to keep up with the latest innovations. All while managing their token costs. SAP is embracing AI for our internal application development and the tools we provide customers and partners for building their own applications.

Sapphire produced several major announcements around our development tools, the biggest being Joule Studio 2.0. Joule Studio 2.0 is SAP’s AI-first development environment for building custom AI agents, apps, and workflows. Powered by the SAP Business AI Platform.

As the development landscape shifts, we want to know what’s important to you. We are interested in how well SAPUI5 meets your needs today, which UI experiences you expect to dominate enterprise apps in the coming years, and which capabilities matter most for your future AI-powered development work. Please take this 5-minute survey.

If you want to join other developers to discuss various traditional and AI-powered Fiori development-related topics from the comfort of your office or home, I encourage you to join our monthly SAP Fiori development roundtable. Register online or email me for an invitation.

Development News

Optimizing SAP Fiori Elements for Mobile Phone Users

While SAP Fiori elements applications are responsive, they adjust controls based on screen size and device type, it does not provide an optimized experience for users. We recently reimagined the SAP Fiori elements mobile experience to include native mobile feel, intuitive navigation, and smarter mobile-optimized layouts. Read more.

Develop RAP-Based SAP Fiori Applications in Minutes with SAP Fiori Tools AI Project Accelerator

Developing enterprise SAP Fiori applications using the ABAP RESTful Application Programming Model (RAP) provides a standardized way to build modern, cloud-ready applications. These applications are typically developed in environments such as SAP BTP ABAP Environment and SAP S/4HANA Cloud Public Edition (version 2602 or higher). The Project Accelerator now supports RAP-based projects. It is available in SAP Business Application Studio under an SAP Build Code subscription. Learn more.

TypeScript 6 and 7 – What UI5 TypeScript Developers Need to Know in 2026

TypeScript is going through its biggest transition in years — and if you build UI5 applications with TypeScript, here we have all the details you need to know. Read about it in this blog post.

UI5 Plugins for Coding Agents: Now Supporting GitHub Copilot

The UI5 Plugins for Coding Agents — previously known as UI5 Plugins for Claude — are now also available for GitHub Copilot. The plugins bring up-to-date SAPUI5 and OpenUI5 knowledge directly into your AI-assisted development workflow, whether you work with Claude Code or GitHub Copilot. Version 0.1.3 also introduces three new skills covering UI Integration Cards, OPA5 integration tests, and OpenUI5 tables. Read more.

Introducing the UI5 Modernization Plugin

Keeping your SAPUI5 or OpenUI5 app up to date just got easier. The new UI5 Modernization Plugin automates the most time-consuming parts of app modernization: replacing deprecated APIs, eliminating global namespaces, updating manifest.json and Component.js, and getting your app ready for Content Security Policy compliance. The plugin is available as a Claude Code plugin and in the GitHub Copilot marketplace. Read the full walkthrough.

What's next for UI technology in the age of AI?

We're running a short survey to collect input from developers, architects, and UI technology enthusiasts in the SAP ecosystem — and we want to hear from you. Topics include how well SAPUI5 meets your needs today, how AI tools work with your current UI stack, and which capabilities matter most for your future development work. Shape the SAPUI5 road map by answering few questions in just 5 minutes, open July 1–19. Take the survey.

Joule Studio 2.0 announced at Sapphire

SAP announced its latest development environment for building apps, agents, and workflows. Read how it changes how you build apps.

SAP Joule for Developers, ABAP AI capabilities including agentic capabilities is now available!

ABAP AI in SAP Joule for Developers include agentic capabilities and is now offered as a service across SAP BTP ABAP Environment, SAP S/4HANA Cloud Public Edition, and SAP S/4HANA Cloud Private Edition for releases 2021 and higher. Joule speaks ABAP, and now it speaks more than ever before. See the details.

Upgrading your SAPUI5 Rich Text Editor: Beyond TinyMCE version 4

The Rich Text Editor is an SAPUI5 control for data input and editing. It is used to enter rich text with different styles, colors, and formatting. The Rich Text Editor allows users to format text and add different types of elements, such as images and hyperlinks. he SAPUI5 team further plans to permanently remove TinyMCE version 4 from the SAPUI5 code later in 2026. Learn how to adjust your code to avoid any problems.

Events

The future of UX is here. Are you ready for an AI -powered world?

At Sapphire 2026 I had the opportunity to speak with many customers and partners about their reaction to the way we are moving with our UX strategy. Generally, people are excited about the direction we are going and having more automation to free up time for deeper thought and analysis, but they are concerned about trusting AI to do things that might have significant business impact. Read my full analysis.

SAP Connect Day for UX in Silicon Valley focused on AI strategy and tactics for implementation

SAP Connect Day for UX in Silicon Valley connected customers with SAP experts and selected partners to discuss how AI will improve the lives of SAP Cloud ERP users. Read about highlights and where you can learn more about the topics we discussed.

Back issues from the past year

SAP Fiori Development Newsletter issue #40 (May 2026)

SAP Fiori Development newsletter March 2026 (issue #39 )

SAP Fiori development newsletter January 2026 (issue #38)

SAP Fiori development newsletter November 2025 (issue #37)

SAP Fiori development newsletter September 2025 (issue #36)

SAP Fiori development newsletter July 2025 (issue #35)

Adding a Custom Column in Fiori Elements (List Report + Object Page)

2026-07-09T20:58:27.605000+02:00

Introduction

The purpose of this blog post is to specify the elements to add in order to set up this custom column, and more specifically to understand the path to configure in the manifest when you want to modify a table, because using this extension in an association facet of an Object Page can be more complicated to understand.
To do so, two elements must be implemented: first, the column definition through an XML fragment, and second, its registration in the manifest file.

I had to use this extension because I was asked to customize the data display by applying CSS styles, such as changing the color depending on the displayed value.
This blog post also aims to specify when to use this extension and why it is preferable not to use it, along with an example of a regression I experienced during its addition.

This column can be added either to a List Report page or to an Object Page. Each table type has its own extension name, and the implementation differs slightly depending on the table type.

Why use this extension as a last resort?

In this blog post, we will look at how to add a custom column. However, other approaches can often meet the requirement. This extension should be considered only when no standard alternative is available, for the following reasons:

Fiori Elements Flexibility: Some requirements can be fulfilled through manifest customization or OData annotations without writing any JavaScript or XML code.
Maintainability: View extensions are custom code that must be maintained whenever the Fiori Elements framework is updated, whereas standard annotations are automatically handled by SAP.
Regression Risk: A poorly implemented extension can interfere with native table features such as sorting, filtering, Excel export, and P13n personalization.

Example of a regression I encountered with this extension:

While developing my XML, I needed to add a specific width to my column. However, by defining this width in pixels (px), I caused a regression in the native behavior, which uses rem units. For example, the display variants were altered depending on the screen size, because rem units rely on a relative value, unlike pixels which impose a fixed size.

Table Types and Associated Extensions

Fiori Elements supports several table types. Each has its own extension name that must be declared in the manifest.

Table Type	Extension Name	Description
ResponsiveTable	ResponsiveTableColumnsExtension ResponsiveTableCellsExtension	Responsive table adapted for mobile and desktop (default)
GridTable	GridTableColumnsExtension	Table with fixed columns, suitable for large datasets
TreeTable	TreeTableColumnsExtension	Hierarchical (tree-like) table

Important: For a ResponsiveTable, two extensions are required: one for the column header and one for the cell content.

How to Implement the Column?

XML Extension

To add this column, you need to define a fragment for the view extension. Create a file in the webapp/ext/fragments/ folder to add any desired column.

In this fragment, you define the desired properties of the column (position, displayed element, etc.). You can also add P13N parameters, such as sorting, to enable users to sort the column.

Example XML extension:

Manifest Extension

In the manifest.json file, declare the view extension and the application parameters. Create an extension corresponding to the table type on the desired entity, then specify the fragment name and type.

Example Manifest:

Result :

After adding the XML extension and declaring it in the manifest.json, a new column appears in the table. In the example, the column customizes data display by applying CSS styles, such as changing colors based on displayed values.

The document also highlights a date-coloring scenario where different colors indicate whether a deadline is distant, approaching, or overdue. In such cases, a view extension is generally unnecessary because OData Criticality annotations can provide the same functionality in a standard, Fiori Elements–compliant way.

Therefore, this standard approach should be preferred whenever they satisfy the requirement.

Adding a Column to an Object Page

Differences Compared to a List Report

An Object Page can contain multiple sections, each with its own table. The main differences are:

Aspect	List Report	Object Page
Target View	ListReport.view.ListReport	ObjectPage.view.Details
Extension key	TypeTable + '\|' + EntitySet	TypeTable + '\|' + EntitySet + FacetID
Number of Tables	One main table	Multiple tables (one per section)
Configuration Scope	Entity-wide	Specific to each section/facet

Example in an Object Page

In this example, a custom column is added to a Responsive Table within the Object Page of the Category entity.

The custom column contains an Order button that is displayed only when the product stock is below 30 units. This behavior relies on business logic that cannot be implemented using standard Fiori Elements annotations.

As with the Grid Table example, an extension fragment is created for the column definition:

However, because this is a Responsive Table, a second extension is required to define the column header:

Since the extension is used within an Object Page, the manifest.json configuration differs slightly from a List Report. You must target the ObjectPage.view.Details view and specify the corresponding facet in the extension key to indicate which table should receive the custom column.

The point I spent time on due to a lack of understanding: 'TypeTable' corresponds to the CDS of our table and not the CDS of the Object Page. In our example, 'Products' is a CDS association (added in a 'ProductsFacet' facet) of our application, which is based on the 'Category' CDS.

Result:

Purpose of the Extension

When Should You Use This Extension?

This extension is relevant in the following scenarios:

Complex conditional display: color, icon, or text based on multi-field business logic that cannot be expressed through annotations.
Non-standard UI5 component: action button, link, image, slider, or any component not natively supported by UI.DataField.
External data integration: displaying data coming from another JSON model or a separate REST API call.
Frontend-side calculation: combining or calculating values using a JavaScript formatter.

Best Practices

Always prefix IDs: avoid conflicts with IDs generated by Fiori Elements.
Use i18n: never hardcode header texts; always use entries from the i18n.properties file.
Keep JavaScript out of fragments: complex logic should be implemented in a dedicated formatter.js file, not inline in the XML.
Test P13n (personalization): ensure that the custom column behaves correctly with sorting, filtering, and show/hide functionalities.

Getting Started with GitHub in SAP Business Application Studio for SAP UI5 Development

2026-07-09T21:48:03.370000+02:00

Overview:

SAP Business Application Studio (BAS) trial accounts expire every 90 days, making it essential to safeguard SAP UI5 projects using a reliable version control system. GitHub not only helps prevent project loss but also introduces the collaboration practices widely used in professional software development.

This blog covers:

Connecting SAP Business Application Studio (BAS) with GitHub
Step-by-step process to push and manage SAP UI5 projects using GitHub.

The intent is to provide a simple and practical guide for SAP UI5 learners and developers to protect their projects, understand Git and GitHub fundamentals, and adopt industry-standard version control practices.

Introduction:

When I started learning SAP UI5, I was using a trial account on SAP Business Application Studio (BAS).

Everything was going great — until I hit my first big obstacle.

Every 90 days, the trial account expires. And when it does, everything is gone. All my projects. All my code. Vanished.

My only option back then was to manually download each project as a zip file to my desktop before the account reset. Then when the new trial started, I had to upload everything back again.

It was painful. It was repetitive. And one time, I forgot — and lost a project I had worked on for weeks.

That's when I discovered GitHub — and it completely changed how I work.

I started learning how to:

Upload my SAP UI5 projects from SAP Business Application Studio (BAS) to GitHub.
Access them anytime, from anywhere, even after my BAS trial account resets.
Share my projects easily with teammates and collaborate more effectively.
No more downloading ZIP files. No more worrying about the 90-day deadline. My code was safely stored in the cloud, always accessible, and backed by version control.

What Is GitHub and Why Do We Need It?

The easiest way to think about GitHub is this: it's like Google Docs for source code. Instead of collaborating on documents, developers collaborate on code while Git keeps track of every change.

GitHub is a cloud-based platform built on top of Git, a distributed version control system. It enables developers to store their source code in the cloud, track changes over time, and collaborate with others while maintaining a complete history of every modification.

In addition to version control, GitHub provides features such as repositories, branches, pull requests, and code reviews, making it easier for individuals and teams to manage software projects efficiently.

Although GitHub is widely used for open-source development, it is equally important in enterprise environments. Development teams use it to collaborate on projects, review code, manage changes, and maintain high-quality software throughout the development lifecycle.

GitHub is not just a tool for beginners. It is an industry-standard platform used by organizations of all sizes to support real-world software development and team collaboration.

In real-world software projects, developers rarely work alone. Front-end developers, backend developers, testers, and other team members often work on the same application simultaneously. Without a version control platform like GitHub, collaboration can quickly become difficult, with developers accidentally overwriting each other's changes and having no clear way to track who changed what or revert to previous versions.

GitHub solves this challenge through features such as branching. Think of the main project as a tree trunk, where each developer creates their own branch to work independently on a feature, enhancement, or bug fix. Once the work is complete, the changes are reviewed through a Pull Request (PR) and then merged back into the main branch.

This approach enables multiple developers to work in parallel without interfering with one another, maintains a complete history of code changes, and ensures that every update is reviewed before becoming part of the main project. As a result, GitHub has become an industry-standard platform for version control and team collaboration in professional software development.

A Typical Team Workflow
A typical GitHub workflow in a development team looks like this:

main branch          → Stable, production-ready code

├── developer-1      → Working on the Login feature
├── developer-2      → Working on the Dashboard feature
└── developer-3      → Fixing a bug in the Search feature

Each developer works on their own branch without affecting the work of others. Once a feature or bug fix is complete, the developer creates a Pull Request (PR) to request that their changes be reviewed before they are merged into the main branch.

A senior developer or technical lead reviews the code, provides feedback if any changes are required, and approves the Pull Request once the code meets the project's quality standards. After approval, the changes are merged into the main branch.

This workflow helps ensure:

Developers can work independently without interfering with one another.
Every code change is reviewed before being merged.

A complete history of changes is maintained, making it easy to track who changed what and when.

The main branch remains stable and ready for deployment.

Now, let's walk through the step-by-step process of connecting SAP Business Application Studio (BAS) to GitHub and uploading your SAP UI5 project.

Step- 1: Create a GitHub Account

Step 2: Initialize the Git Repository

Open your SAP UI5 project in SAP Business Application Studio (BAS).
Open the Terminal by navigating to Terminal → New Terminal.

Run the following command to initialize a Git repository with main as the default branch:

git init -b main

This command initializes a new Git repository in your project directory and creates the default branch named main. Git will now start tracking changes made to your project.

Step 3: Stage All Project Files

After initializing the Git repository, stage all the project files by running the following command in the terminal:

git add .

The git add . command stages all the files and folders in the current project directory. Staging tells Git which changes should be included in the next commit.
Once the files are staged, Git is ready to create a snapshot of your project using a commit.
Note: The . (dot) represents the current directory, so git add . stages all files within your project.

Step 4: Commit the Changes

Once all the project files have been staged, create your first commit by running the following command:

git commit -m "Vendor Details"

Creates a commit with the message "Vendor Details", which serves as a snapshot of your project at its current state.
Verify the Commit
To confirm that the commit was created successfully, run the following command:
git log
Displays the commit history of the repository, including the commit ID, author, date, and commit message.
If the commit was successful, you should see an output similar to:

commit 3f2c9b8e6d4f1a2b...
Author: <Your Name> <your-email@example.com>
Date:   Sat Jun 6 10:30:15 2026

    Vendor Details

This confirms that your project has been committed successfully and Git is now tracking this version of your code.

Step 5: Configure Git (First-Time Setup)

If you're using Git for the first time, configure your username and email address using the following commands:

git config --global user.name "<github_username>"
git config --global user.email "<github_email>"

Configures your Git username and email address. These details are associated with every commit you create.

Step 6: Create a GitHub Repository

Sign in to your GitHub account.
Click New Repository.
Enter a repository name (for example, Vendor_Details_App).
Click Create repository.

Step 7: Connect the Local Repository to GitHub

After creating the repository, copy its HTTPS URL and run the following command in the BAS terminal:

git remote add origin https://github.com/sap-honey/Vendor_Details_App.git

Connects your local Git repository to the remote GitHub repository.

Step 8: Push the Project to GitHub

Push your local commits to the remote GitHub repository using the following command:

git push -u origin main

Uploads your local main branch to the remote GitHub repository. The -u option sets the upstream branch, so future pushes can be performed simply by running:

git push

When you run the git push command for the first time, GitHub prompts you to authenticate your account.
Click Copy and Open GitHub.
This copies the verification code and opens the GitHub device activation page in your browser.
GitHub automatically opens the device activation page. If prompted, sign in to your GitHub account.
Paste the verification code and click Continue, then click Authorize to grant SAP Business Application Studio permission to access your GitHub repository.
After the authorization is complete, return to SAP Business Application Studio. The git push command will finish automatically.
Open your GitHub account and navigate to the repository you created.
Refresh the repository page. You should now see all your SAP UI5 project files successfully uploaded.
This confirms that your local SAP UI5 project has been successfully pushed to GitHub. From now on, you only need to commit your changes and run:

git push

GitHub is an essential tool for every SAP UI5 developer. By connecting SAP Business Application Studio with GitHub, you can securely store your projects, track changes, and continue your work even after a BAS trial reset.

I hope this blog helps you get started with GitHub and makes managing your SAP UI5 projects easier and more efficient. Happy coding!

How to Add a Custom Formatter in SAPUI5: View vs. Controller Approach

2026-07-13T08:22:22.969000+02:00

Hi Everyone,

Introduction

When building SAPUI5 applications, we often bind data directly from a model to the UI. While simple property binding works well for displaying raw values, there are many scenarios where the displayed value needs additional formatting before it reaches the user. For example, you might want to combine multiple fields into a single sentence, display semantic colors based on a value, or convert technical data into a more user-friendly format.

This is where custom formatters become useful. They allow you to keep formatting logic separate from your XML views, making your application easier to read, maintain, and reuse.

In this blog, we'll explore:

What a custom formatter is and why you should use one.
Two different ways to integrate an external formatter into your SAPUI5 application:
- Using core:require directly in the XML View.
- Importing the formatter through the Controller.
A practical example that demonstrates both approaches side by side using real code and application output.
When to use each approach, so you can choose the one that best fits your application's structure and development style.

Project Context

While practicing SAPUI5, I wanted to organize my formatting logic outside the XML View instead of writing formatting code directly in bindings. During this exercise, I discovered that SAPUI5 provides more than one way to use external formatter files.

I experimented with both approaches, loading the formatter directly in the XML View using core:require and importing it through the controller. Since both approaches produce the same result but differ in how the formatter is referenced, I thought it would be useful to compare them side by side with a simple practical example.

What is a Custom Formatter, and Why Use One

A custom formatter is a JavaScript function that transforms model data before it is displayed in the UI. It allows you to present data in a more meaningful or user-friendly format without modifying the original data in the model. Since a formatter only affects the displayed value, it supports one-way binding and cannot be used for two-way (editable) bindings.

Some common use cases include:

Converting technical values into user-friendly text.
Combining multiple model properties into a single display value.
Applying semantic states such as Success, Warning, or Error based on a value.
Formatting dates, currency, or performing simple calculations before displaying data.

In the following sections, we'll implement these concepts with a practical SAPUI5 example using reusable external formatter files.

Project Setup and Folder Structure

Here's the folder structure used for this example, a simple table of users with their age and salary, where we'll apply one formatter for each column:

project1/                        ← SAPUI5 application
└── webapp/
    ├── controller/               ← Controller logic
    │   ├── App.controller.js
    │   └── View1.controller.js   ← attaches AgeFormatter (controller approach)
    ├── formatter/                ← Reusable external formatter files
    │   ├── AgeFormatter.js       ← used via controller
    │   └── SalaryFormatter.js    ← used via core:require in the view
    ├── model/
    │   ├── models.js
    │   └── users.json            ← sample data
    ├── view/
    │   ├── App.view.xml
    │   └── View1.view.xml        ← table using both formatter approaches
    ├── Component.js
    ├── index.html
    └── manifest.json             ← model & routing configuration

For this example, I created two separate formatter files to demonstrate both approaches independently. One formatter is loaded directly in the XML View using core:require, while the other is imported through the controller. This makes it easier to understand how each approach works without mixing the implementations.

AgeFormatter.js – Combines a user's name and age into a readable sentence.
SalaryFormatter.js – Maps a salary value to an appropriate semantic state.

Sample Data (`users.json`)

The application uses a simple JSON model containing user information. The age and salary properties are used by the formatter functions in the following examples.

{
  "users": [
    { "id": 1, "name": "Monkey D. Luffy", "age": 16, "salary": 22000 },
    { "id": 2, "name": "Roronoa Zoro", "age": 21, "salary": 64000 },
    { "id": 3, "name": "Nami", "age": 20, "salary": 2400 },
    { "id": 4, "name": "Usopp", "age": 19, "salary": 2500 },
    { "id": 5, "name": "Sanji", "age": 21, "salary": 7000 },
    { "id": 6, "name": "Tony Tony Chopper", "age": 17, "salary": 6800 },
    { "id": 7, "name": "Nico Robin", "age": 30, "salary": 9200 },
    { "id": 8, "name": "Franky", "age": 36, "salary": 88000 },
    { "id": 9, "name": "Brook", "age": 90, "salary": 33000 },
    { "id": 10, "name": "Jinbe", "age": 46, "salary": 440000 }
  ]
}

Registering the Model (`manifest.json`)

"oModel": {
    "type": "sap.ui.model.json.JSONModel",
    "uri": "model/users.json"
}

The JSON model is registered in manifest.json, making it available throughout the application using the model name oModel.

Approach 1: Using `core:require` in the View

This approach loads the formatter module directly in the XML view using the core:require attribute, and gives it an alias you can reference in any binding inside that view. No changes are needed in the controller.

SalaryFormatter.js

sap.ui.define([], function(){
    "use strict";
    return {
         /*
         * This formatter is required directly in the VIEW via core:require
         * (see View1.view.xml) and referenced as 'Salary.salaryState'.
         */
        salaryState: function(salary){
           if (salary >= 10000) {
                return "Success"; // green color
            } else if (salary >= 5000) {
                return "Warning"; // orange color
            } else {
                return "Error";   // red color
            }
        }
    }
})

While implementing this example, I kept the salary-related formatting in a dedicated formatter file instead of writing conditional logic directly in the XML View. This keeps the binding expression clean and makes the formatting logic reusable.

View1.view.xml

<mvc:View controllerName="project1.controller.View1"
    xmlns:mvc="sap.ui.core.mvc"
    xmlns="sap.m"
    xmlns:core="sap.ui.core"
    core:require="{ Salary: 'project1/formatter/SalaryFormatter' }">
    <!-- Approach 1 (view-based):
         core:require loads the SalaryFormatter module and makes it available
         under the alias "Salary" for use anywhere inside this view. -->
    <Page id="page" title="{i18n>title}">
        <Table items="{oModel>/users}">
            <columns>
                <Column><Text text="ID" /></Column>
                <Column><Text text="Name" /></Column>
                <Column><Text text="Age" /></Column>
                <Column><Text text="Salary" /></Column>
                <Column><Text text="Age Classification" /></Column>
            </columns>
            <items>
                <ColumnListItem>
                    <Text text="{oModel>id}" />
                    <Text text="{oModel>name}" />
                    <Text text="{oModel>age}" />

                    <!-- "Salary" here refers to the alias declared in core:require above -->
                    <ObjectStatus text="{oModel>salary}" state="{path:'oModel>salary', formatter:'Salary.salaryState'}" />
                </ColumnListItem>
            </items>
        </Table>
    </Page>
</mvc:View>

One thing I found convenient about this approach is that everything required by the formatter stays inside the XML View. Since the formatter is only used in this view, there was no need to modify the controller. This also keeps the formatter dependency close to where it is actually used.

Approach 2: Attaching the Formatter in the Controller

While exploring formatter implementations, I also tried importing the formatter through the controller. In this approach, the formatter is loaded as a controller dependency and then exposed to the XML View through the formatter property.

AgeFormatter.js

sap.ui.define([], function () {
    "use strict";

    return {
        // Classifies a person's age into a category and returns a readable sentence.
        ageClassification: function (sName, sAge) {
            var nAge = Number(sAge);
            var sCategory;

            if (nAge < 13) {
                sCategory = "Child";
            } else if (nAge < 18) {
                sCategory = "Youth";
            } else if (nAge < 60) {
                sCategory = "Adult";
            } else {
                sCategory = "Senior Citizen";
            }

            // Pick "a" or "an" based on whether the category starts with a vowel sound
            var sArticle = /^[aeiou]/i.test(sCategory) ? "an" : "a";

            return `${sName} is ${sArticle} ${sCategory}`;
        }
    };
});

View1.controller.js

sap.ui.define([
    "sap/ui/core/mvc/Controller",
    // Import the formatter module here and attach it to the controller
    "project1/formatter/AgeFormatter"
], (Controller, AgeFormatter) => {
    "use strict";
    return Controller.extend("project1.controller.View1", {

        // Attaching the module as "formatter" is what makes
        // ".formatter.ageClassification" resolvable from the view
        formatter: AgeFormatter,

        onInit() {
        }
    });
});

View1.view.xml (relevant part)

<!-- The leading dot means "look this up on the controller instance",
     i.e. this.formatter.ageClassification -->
<Text text="{parts:[{path:'oModel>name'}, {path:'oModel>age'}], formatter:'.formatter.ageClassification'}" />

Only the binding expression changes in the XML View. The remaining XML structure stays exactly the same as in the previous approach, so only the relevant binding is shown below.

Figure 1: XML View showing where each formatter approach is used

After implementing both approaches, I noticed that the application behavior and output remain exactly the same. The only difference is how the formatter module is made available to the XML View. This observation helped me understand that the choice is primarily about code organization rather than functionality.

Putting Both Together

Here's the same app with both formatters wired up, salary status via the view-based approach, age classification via the controller-based approach, running against a simple JSON model:

Figure 2: Output showing salary status and age classification for all users

Both approaches produce correct, working output. The difference is purely in where the dependency is declared and how it's referenced.

View vs. Controller Approach

Both approaches ultimately achieve the same goal. They allow you to keep formatting logic outside the XML View and produce the same output. After implementing both in the same application, I noticed that the primary difference isn't what they do, but where the formatter dependency is managed.

With the View approach (core:require), the formatter is imported directly into the XML View. This makes the view self-contained because anyone reading the XML can immediately see which formatter modules it depends on. I found this approach straightforward when the formatter is only used within a single view.

With the Controller approach, the formatter is imported as a controller dependency and then exposed to the XML View through the formatter property. This keeps all module imports together inside the controller, which can make the XML slightly cleaner. I found this approach useful because the controller becomes the single place responsible for managing its dependencies.

Another thing I observed is that the formatter implementation itself doesn't change. The same formatter function can be used with either approach. Only the way SAPUI5 resolves and accesses that function is different.

From a functionality perspective, both approaches produce identical results. The choice mainly comes down to how you prefer to organize your application and how your project structures reusable modules.

Conclusion

While building this example, I realized that both approaches ultimately achieve the same result. The difference lies in how the formatter dependency is organized rather than how the formatter behaves. Implementing and comparing both approaches side by side gave me a better understanding of how SAPUI5 resolves formatter functions, and I hope this practical comparison helps you make the right choice for your own applications.

Thank you for reading! If you've used a different approach or have additional insights, I'd love to hear about them in the comments.

How To Create Value Help In CAPM.

2026-07-13T11:43:54.619000+02:00

Hi Everyone,

In this blog, I'll walk you through one of the easiest ways to implement Value Help (F4 Help) in a SAP CAPM application.

While developing SAP Fiori applications, we often have fields such as Category, Department, Country, Employee, Supplier, and many others where users should select values instead of typing them manually. If users enter values manually, there is always a chance of entering incorrect or inconsistent data.

To solve this problem, SAP provides Value Help (F4 Help), which allows users to choose values from a predefined list. This not only improves the user experience but also ensures that only valid data is saved.

In this blog, I'll demonstrate how to create a simple Value Help for the Category field by using a lookup entity, exposing it through a CAP service, and configuring the required CDS annotations.

To Demonstrate this I have Created a simple CAPM application, folder structure of this Looks like this below image

Step 1 – Create Database Entities

First, open the db folder and create a schema.cds file.

In this example, I created two entities:

Products
Categories

The Products entity stores the product details, while the Categories entity acts as the lookup table that provides the values for the Value Help.

Below is the content of my schema.cds file.

namespace demo.valuehelp;

entity Products {
  key ID       : UUID;
  name         : String(100);
  category     : String(10);
  price        : Decimal(10,2);
}

entity Categories {
  key code     : String(10);
  description  : String(50);
}

Step 2 – Create Sample Data

Next, inside the db/data folder, I created two CSV files.

demo.valuehelp-Categories.csv
demo.valuehelp-Products.csv

The Categories CSV file contains the values that will be displayed in the Value Help dialog.

Below is the content of the Categories CSV file.

code,description
ELEC,Electronics
FURN,Furniture
BOOK,Books

The Products CSV file contains sample product records.

ID,name,category,price
3b5a1e2a-1111-4a1a-9a1a-000000000001,Laptop,ELEC,55000.00
3b5a1e2a-1111-4a1a-9a1a-000000000002,Office Chair,FURN,4500.00
3b5a1e2a-1111-4a1a-9a1a-000000000003,Notebook Set,BOOK,250.00

Step 3 – Create the Service

Next, create a service.cds file inside the srv folder.

In this file, I exposed both entities as projections so that they are available through OData services.

Below is the content of my service.cds file.

using demo.valuehelp as db from '../db/schema';

service CatalogService {
  entity Products   as projection on db.Products;
  entity Categories as projection on db.Categories;
}

Step 4 – Configure Value Help

After exposing the required entities in the service, I created a Fiori application inside the app folder by selecting New Project from Template in SAP Business Application Studio. I chose my local CAP application as the data source, and the project automatically generated the annotations.cds file.

In this file, I added the required UI annotations and configured the @Common.ValueList annotation for the Category field. The CollectionPath property points to the Categories entity, while LocalDataProperty and ValueListProperty map the selected value from the Value Help dialog back to the Product entity.

One thing I learned during this implementation is that even a small typo in an annotation or entity name can prevent the Value Help from working, while no clear error is shown in the UI. I found it helpful to verify the service metadata and ensure that all entity and property names matched exactly before troubleshooting further. This saved me a significant amount of debugging time.

Below is the content of my annotations.cds file.

using CatalogService as service from '../../srv/service';

annotate service.Products with @(
  UI.SelectionFields: [ category, name ],
  UI.LineItem: [
    { Value: name },
    { Value: category },
    { Value: price }
  ]
) {
  category @Common.ValueList : {
    Label          : 'Category',
    CollectionPath : 'Categories',
    Parameters     : [
      { $Type: 'Common.ValueListParameterInOut', LocalDataProperty: category, ValueListProperty: 'code' },
      { $Type: 'Common.ValueListParameterDisplayOnly', ValueListProperty: 'description' }
    ]
  };
};

Step 5 – Run the Application

After completing the above configuration, open the terminal and execute the following command.

cds watch

Once the application starts successfully, open the generated Fiori application.

here click on the URL which is having index.html
In this application I created value Help for a Selection field I mean a Search field.
Click On the Value Help Icon
Here is the Image How My Value Help is looking

How Does It Work?

Let's quickly understand what happens behind the scenes.

The Categories entity stores all valid category values.
The Products entity contains the Category field.
The service.cds file exposes both entities.
The annotations.cds file connects the Product Category field with the Categories entity by using the @Common.ValueList annotation.
When the application runs, SAP Fiori automatically recognizes the annotation and displays the Value Help dialog.

Because of this configuration, users don't have to type category values manually, reducing data entry mistakes and improving consistency.

Conclusion

In this blog, we learned how to implement Value Help in SAP CAPM by using a lookup entity, service projections, and CDS annotations.

We created the required database entities, loaded sample data using CSV files, exposed the entities through a CAP service, and configured the @Common.ValueList annotation to display the Value Help dialog in the SAP Fiori application.

This approach is simple, reusable, and can be applied to many business scenarios such as Customers, Suppliers, Departments, Countries, Employees, or any other master data.

I hope this blog helps you understand how Value Help works in SAP CAPM.

Thank you for reading!

The Fourth Way to Go Offline in UI5 (And Why the Service Worker Stays Dumb)

2026-07-15T23:10:06.816000+02:00

Written up after attending "Offline capabilities in UI5 – Let's discuss" at UI5Con, run by Viktor Sperling and Lars Kissel from SAP's UI5 team as an open discussion rather than a one-way talk. The app described below is a real, shipped project — a handheld scanning app for warehouse/inventory operations — with client-identifying details deliberately left out.

Three ideas, three shapes of "offline"

The session's core insight, stated up front, was that "offline" isn't one problem — it has a shape, and the right architecture depends on that shape. They presented three ideas, each solving a distinct scenario:

Idea 1 — OData V4 Model as Change Buffer. v4.ODataModel holds changes locally (updateGroupId), disables actions that can't succeed offline, submits once back online (submitBatch). Connectivity is actively probed — a fetch/AbortController ping, not just navigator.onLine. Scenario: a commuter on a train, signal drops between two stations. Duration: seconds to minutes.
Idea 2 — Service Worker as OData Proxy. The service worker becomes an OData-aware proxy: it parses $batch and read requests, resolves query options, keeps its own IndexedDB store and changelog, and rebuilds a combined $batch on reconnect. Scenario: a field worker visiting customers, connection comes and goes. Duration: minutes to hours.
Idea 3 — JSONModel with Explicit Sync. An explicit download → work → submit workflow. JSONModel as the UI model, a v4.ODataModel downloads the required entity sets up front, changes go into a changelog, submitted via Context#setProperty/#delete. Scenario: a traveler on a flight, working for hours in airplane mode. Duration: hours to days.

Idea 1 is elegant if you can stay inside the OData V4 model's own change-tracking. Idea 3 matches the shape of what we needed almost exactly — an explicit, user-initiated offline session, not an accidental one.

Idea 2 is the one worth pausing on, because it's easy to misread it as "just cache the OData responses." It doesn't. It builds its own IndexedDB store and changelog inside the service worker, and re-implements a slice of the OData protocol there — parsing $batch payloads, matching query options against locally held entity sets, replaying a changelog into a fresh $batch on reconnect. That's a genuinely more sophisticated design than an HTTP cache, and it's also exactly why it didn't fit our case: it means OData-protocol knowledge and business logic now live inside a service worker — a context that's already awkward to debug, awkward to unit test, and now also carries backend-shaped logic.

The session closed with a "Pain Points" slide worth quoting directly, because it names this tension independent of any particular implementation:

Back-end logic in the client — understanding the OData protocol, $filter options that quickly become complex, resolving navigation properties locally, duplicating business logic, OData Actions, server-side calculated fields.
Conflicts at sync time — concurrent modifications or business-rule violations, and expired authentication or session tokens, refresh before sync.

That first point is the crux of this whole post: the problem isn't "service workers shouldn't hold data." The problem is putting protocol-aware business logic inside a service worker specifically. The approach below solves the same problem idea 2 solves — resilience across a flaky connection — without paying that price.

Our shape of offline

Before the architecture, the shape of the problem, because it explains every choice below:

Runs on ruggedized handheld scanners with genuinely intermittent connectivity — sometimes hours without a signal, not a brief tunnel dip.
Scans in bulk via RFID — hundreds of local mutations in a single session before anything needs to reach a server.
Submits as a batch at the end of a session, not request-per-scan — the backend should never see a half-finished state.

That's squarely "spontaneous, business-logic-heavy, shared" territory — borrowing the session's own three-axis framing (Preparation: predictable ↔ spontaneous; Interaction complexity: simple form ↔ business logic; Conflict sensitivity: exclusive ↔ shared) — which rules out idea 1 immediately and makes idea 2's in-worker protocol logic feel like the wrong place to carry that weight.

A fourth option: two layers, two jobs

The architecture splits cleanly into two layers that don't know about each other's internals.

Two isolated layers on the device. The service worker never touches OData or $batch; the JSON model/IndexedDB layer owns all sync logic and only reaches the backend at two named moments — a fetch at the start of a session, a $batch submit at the end.

Layer 1 — the shell, and only the shell

The service worker knows nothing about OData, nothing about business entities. Its fetch strategy has three branches:

Skip — OData entity sets, lookup endpoints, $batch: always straight to the network, never cached. Stale business data is worse than a failed fetch, and offline resilience for that data lives entirely in the layer below.
Network-first with a timeout race — our own app resources (JS/CSS/XML/i18n): online gets fresh content plus a cache update, offline or a timeout falls back to cache. We deliberately avoid navigator.onLine — it lies in both directions. Racing a real fetch() against a timeout is symmetrically correct for "no network" and "server unreachable" alike.
Cache-first — third-party/library resources that rarely change.

const NETWORK_TIMEOUT_MS = 2000;

function rejectAfter(ms) {
  return new Promise((_, reject) =>
    setTimeout(() => reject(new Error("SW network-timeout")), ms)
  );
}

async function networkFirst(request) {
  const cache = await caches.open(CACHE_NAME);
  try {
    const response = await Promise.race([fetch(request), rejectAfter(NETWORK_TIMEOUT_MS)]);
    if (isCacheable(response)) cache.put(request, response.clone());
    return response;
  } catch {
    const cached = await cache.match(request, { ignoreSearch: true });
    if (cached) return cached;
    throw new Error("no network, no cache");
  }
}

One gotcha worth flagging for anyone building this themselves: cross-origin <script src> loads — like the UI5 runtime, loaded no-cors — come back as opaque responses. response.ok is false even on success, but the body is perfectly cacheable. Skip that check and your library bundles silently never get cached.

Loading UI5 itself deserves its own paragraph. Our bootstrap script picks its UI5 source depending on where it's running: an on-premise deployment loads sap-ui-core.js from the same server (no internet dependency at all), local dev loads from the public SAPUI5 CDN. "Offline-first" starts at the very first <script> tag — if you fetch the UI5 runtime itself from a CDN, your app is, by definition, not offline-capable anywhere without internet access. Those two sources produce different response types (same-origin vs. cross-origin no-cors), which is exactly why the opaque check above matters — without it, cache-first would silently never cache the UI5 runtime in the on-premise case.

Also worth knowing: the service worker doesn't register at all when the app runs inside a Fiori Launchpad — more on why below.

Layer 2 — data, entirely in ordinary application code

IndexedDB is the source of truth; the JSON model is loaded from it on boot and reloaded after every mutation. OData traffic isn't scattered through the app — it happens at exactly two named operations:

Fetch — pull existing records from the backend when online, including a bulk status update so colleagues can see something's been picked up.
Submit — at the end of a session, one $batch per document with everything — header update, item/serial changes — inside a single changeSet, so the backend never sees a half-written state.

private _queueHeaderUpdate(record: Order): void {
  this.model.update(getHeaderPath(record.id), {
    status: "3",
    processedBy: record.processedBy,
    processedAt: toBackendTimestamp()
  }, { merge: true, groupId: BATCH_GROUP, changeSetId: CHANGE_SET });
}

private _submitBatch(): Promise<void> {
  return new Promise((resolve, reject) => {
    this.model.submitChanges({
      groupId: BATCH_GROUP,
      success: (data) => this._hasError(data) ? reject(data) : resolve(),
      error: reject
    });
  });
}

After a successful sync, the server's response is merged back into the local record — fields the server owns get overwritten, purely local UI state stays as-is.

This is, in workflow terms, closest to idea 3 — download, work, submit — but hardened with a persistent IndexedDB layer underneath instead of a purely in-memory JSONModel, so a page refresh mid-session doesn't throw everything away.

The bit I'm not proud to admit: session expiry

An architecture built around hours of offline work immediately raises a question: what happens to the session/XSRF token when you come back online? Honest answer: we don't have a good one yet.

There's no custom 401/403 detection or re-login flow anywhere in the app. Every OData call leans entirely on the OData V2 model's default XSRF fetch/retry behavior.
The batch-submit code only checks HTTP status codes (>= 400) to decide whether a sync succeeded — it doesn't distinguish "the server rejected this data" from "the session expired, retry after a token refresh."
Practical consequence: if a device has been offline for a day and the underlying session has since expired, the first sync batch after reconnecting fails as a generic error, not a recognizable "please log in again."

Reassurance, not excuse. This isn't a shortcoming unique to this approach. The session's own Pain Points slide names it directly: "expired authentication or session tokens — refresh before sync." Even SAP's own UI5 team presents this as an open problem across all three of their ideas, not something any of them has solved. That took some pressure off having to invent something clever here — naming it honestly is enough.

This isn't a showstopper in practice (logging back in on the device always fixes it), but it is a real gap: this architecture solves the transport problem, not the identity problem. "Offline-first" here does not mean "session-independent." You'd need to layer explicit 401 detection with a clear re-auth prompt on top if that matters for your case.

How the cache invalidates itself

Every build — production or local dev start — stamps a fresh build timestamp into a small generated file, imported into the service worker via importScripts. The service worker script itself never changes between builds; only that one value does.

self.BUILD_VERSION = "1737012345678"; // stamped per build

const CACHE_NAME = "app-v" + self.BUILD_VERSION;

self.addEventListener("activate", (event) => {
  event.waitUntil(
    caches.keys().then((keys) =>
      Promise.all(
        keys.filter((k) => k.startsWith("app-v") && k !== CACHE_NAME)
            .map((k) => caches.delete(k))
      )
    )
  );
});

No semver, no manual version bump to forget — a timestamp per build means the cache invalidates itself automatically on every build/start. Worth noting separately: the app's manifest version is a static marker, unrelated to this cache version or the OData service version — a deliberate decoupling, since it's tempting to conflate all three kinds of "version."

The Fiori Launchpad has its own appetite for the network

A natural question: could this run inside a Fiori Launchpad instead of standalone? In our case, no — and it's worth explaining why, because the reason generalizes.

A Launchpad is itself an application full of network-dependent shell services that have nothing to do with the app you're hosting inside it: personalization (tile layout, saved filters), intent/navigation resolution against a catalog, notifications, enterprise search, usage tracking, user preferences and theming. None of that is "your app" — you don't control it as an app builder, and none of it is designed to gracefully degrade without a network. That's exactly why registering a custom service worker under a Launchpad route conflicts with the shell: it already has its own lifecycle and caching assumptions, and a second service worker layered on top produces, at best, inconsistent behavior. Practically, our app runs standalone via a direct deep link, not as a Launchpad tile.

Speculative — a wish, not a feature. An officially supported "shell offline mode" would let an individual app register its own service worker scoped strictly to its own sub-path — the shell owning the root scope — and would let shell services degrade gracefully (personalization/notifications/search no-op instead of blocking) rather than all-or-nothing. To be clear, I'm not aware this exists today; it's the question this project left open, and a good one to put back to the community.

What about Fiori Elements and OData V4?

Also raised at the session: Fiori Elements with V4 bindings makes offline hard. I think that's right, and it's worth explaining why rather than just asserting it.

Fiori Elements is metadata- and annotation-driven: value helps, filters, side effects after an edit, and draft handling are, at their core, live interactions with the OData V4 service — they're not designed to be replayed from a local cache. sap.ui.model.odata.v4.ODataModel does keep an in-memory cache of already-loaded data, but that's request-level caching within a session, not a persistent offline store with conflict resolution the way a dedicated IndexedDB layer is. Historically, SAP's "real" offline-OData story has lived more at the native/mobile SDK level than in-browser Fiori Elements — worth double-checking the current state of that, since this area moves.

Practically, the options that hold up today, roughly in order of "how much Fiori Elements you keep":

Limit offline to read-mostly reference data (cache value-help lists locally), keep write flows online.
Freestyle islands inside an otherwise Fiori-Elements-driven app for exactly the screens that need to work offline.
Go fully freestyle, as we did — you lose FE's automation (annotations → UI), but gain full control over what lives locally.

Fiori Elements optimizes for speed and consistency while you're online; the moment offline becomes a hard requirement, you're trading away precisely the automation that makes FE valuable — and freestyle starts looking attractive again.

Lessons that cost us a debugging session

Silent cache misses on lazy-loaded fragments. Dialogs that only load at runtime via Fragment.load failed silently if they weren't explicitly named in the pre-cache list — an empty dialog, no error — and the symptom only ever showed up under genuine offline testing, never in normal dev with a network.
navigator.onLine lies. It's true whenever a network interface exists, not when a server is reachable, and false isn't reliable either. A race between a real fetch() and a timeout is symmetrically correct in both directions.
Two UI5 sources, two response types. The same bootstrap code sometimes loads UI5 same-origin, sometimes cross-origin/no-cors — normal vs. opaque responses — and a cacheability check that only looks at response.ok silently misses the second case.
A service worker and a Fiori Launchpad shell don't mix. Registering a custom SW under a Launchpad route caused conflicts with the shell's own layer; registration had to be explicitly excluded for those routes.
Deliberately no IndexedDB schema migration. On a breaking model change, we chose a new database name over a migration path — old local data is simply ignored, not converted. For a small, known fleet of devices carrying mostly in-transit data, that's a cheaper, safer call than maintaining migration code.
Session expiry isn't solved for free by any of this — see above. Worth saying explicitly so the takeaway isn't "offline-first means never thinking about sessions again."

When this pattern fits — and when it doesn't

This isn't "the best option" — it's the option that fits a specific shape of app. The session's own "Technical Aspects" slide offers a genuinely useful way to reason about that shape: three axes — Preparation (predictable ↔ spontaneous), Interaction complexity (simple form ↔ business logic), and Conflict sensitivity (exclusive ↔ shared). Our app sits firmly at the right-hand end of every axis — unpredictable offline moments, non-trivial document logic, multiple colleagues touching the same stock. That's exactly why idea 1, built for predictable and simple cases, wasn't a fit.

Fits well:

Apps where users mutate a lot before anything needs to reach a server (scan sessions, inspections, field forms) — the win is decoupling "mutating" from "submitting."
Longer, unpredictable offline periods (minutes to hours), not just a brief tunnel dip.
Business logic that doesn't fit neatly into a generic entity cache — merges, batch/changeSet semantics, status derived from other fields, locally created records that only get a server ID at sync time.
A limited, known set of devices/users, where "no automatic IndexedDB migration" and "manual session recovery" are acceptable trade-offs.

Fits less well:

Apps where nearly every action needs a direct server round-trip anyway (real-time collaborative, prices/stock that must be correct right now).
Short, second-scale, unprepared offline blips: idea 1 is probably cheaper to build and maintain — you get most of the resilience for free from the model itself.
Many concurrent users editing the same records ("shared" on the conflict-sensitivity axis): this pattern solves "one device, local, sync later," not multi-user conflict resolution. Look at CRDTs, optimistic locking with real conflict UI, or just staying online with a good loading state instead.
Teams that would rather lean on a standardized offline framework than maintain a custom SW + IndexedDB layer.

A short aside: why not Cordova, Capacitor, or a native SDK?

A fair question: why a PWA/service-worker approach, and not a hybrid or native app that's offline-capable by default? First, a framing correction: a service worker isn't an experimental bet — it's a mature, broadly supported web standard. This isn't "proven vs. experimental," it's "proven vs. proven."

Apache Cordova (formerly PhoneGap) wraps a web app in a native webview shell with plugin access to device APIs. Still an active Apache project, but development velocity has been low for years — much of the hybrid ecosystem has moved toward Capacitor. Worth checking current release cadence and plugin health before repeating that as fact, since it dates quickly.
Capacitor (Ionic) is the de facto successor for "web app in a native shell" — a similar model, more actively maintained, a more modern plugin architecture.
Native, vendor-specific offline SDKs often ship a ready-made offline layer with built-in conflict resolution — at the cost of vendor lock-in: a proprietary data model/SDK, lower portability, and the loss of "it's just a web app, patch with a new build."

We stayed on web/PWA for three reasons: it's built on proven, stable technology rather than a moving target; a new build is a set of static files picked up by the service worker on the next online load — no app-store review, no MDM rollout cycle per patch; and the sync logic is our own readable code against a standard OData service, not a proprietary SDK locking us to one vendor.

Where this leaves things

None of this is a silver bullet, and it isn't meant to replace the session's three ideas — it's meant to sit alongside them as a fourth shape for a fourth kind of problem. If your offline story is short and unprepared, idea 1 will get you further with less code. If you want the app itself to stay entirely unaware of offline handling, idea 2's service-worker-as-proxy is a genuinely clever answer, provided you're comfortable carrying protocol logic in that layer. If your offline sessions are long, deliberate, and business-logic-heavy — ours were — this is the shape that held up.

Thanks to Viktor and Lars for running the session as a discussion instead of a monologue — it's the reason this idea exists in writable form at all. Curious how others have handled the session-expiry gap in particular — that felt like the one open thread nobody in the room had a clean answer for.

Advanced VizFrame Customization in SAPUI5 OVP Applications

2026-07-17T11:21:09.926000+02:00

Advanced VizFrame Customization in SAPUI5 OVP Applications

Introduction

As we all know, that we can create Fiori charts easily using the standard templates provided by SAP, but it does not give enough flexibility to customize on top of that, when we want to make any changes in those standard templates then we must make use of custom charts. For custom charts, VizFrames are used to perform the customization on the chart as per the requirement.

In one of my recent implementations, I defined the custom chart using VizFrame with two lines and two columns on x and y axis. Apart from this there was a dynamic colour change option given to the user, so that they can dynamically change colors of both the lines and columns, and the colour once picked, has persisted in the localStorage of the browser for next time use.

This blog explains the implementation steps:

Business Requirement

Dual combination chart (2lines and 2 bars)
Allow user to personalize chart colours.
Saves the colour preference.

Solution

To achieve the above requirement, we have used

sap.viz.ui5.controls.VizFrame
dual_combinatoin chart type
ColorPickerPopover
Sap.m.Menu
Browser localStorage

Step1: Create a dual combination chart using VizFrame:

The custom chart is created using VizFrame with dual_combination as the chart type.

<viz:VizFrame id="idVizFrame" vizType="dual_combination" uiConfig="{applicationSet:'fiori'}">
</viz:VizFrame>

Step2: Define the chart dimensions and measures:

Here, I am defining the chart dimensions and measures.

Dimension:<vizDataset:DimensionDefinition
                             name="Period"
                             value="{Date}" />

Measure:  <vizDataset:MeasureDefinition
                             name="Metric A"
                              value="{Value1}" />

                     <vizDataset:MeasureDefinition
                             name="Metric B"
                             value="{Value2}" />

                   <vizDataset:MeasureDefinition
                             name="Metric C"
                             value="{Value3}" />

                 <vizDataset:MeasureDefinition
                             name="Metric D"
                             value="{Value4}" />

Step3: Configuring chart feeds:

First, I have configured the primary axis to display column measures and then the secondary axis to display line measures.

<vizFeeds:FeedItem uid="valueAxis" type="Measure" values="Metric A,Metric B"/>

<vizFeeds:FeedItem uid="valueAxis2" type="Measure" values="Metric C,Metric D"/>

<vizFeeds:FeedItem uid="categoryAxis" type="Dimension" values="Period"/>

Step4: Creating colour palette button:

Enabling palette button as drop-down menu, so that the user can select the measure for which personalized colour needs to be picked.

<Button
       icon="sap-icon://palette"
       type="Transparent"
       tooltip="Change Chart Colors"
       press=".onOpenColorSettings"/>

When the user clicks on the menu item, a color selection menu appears.

onOpenColorSettings: function(oEvent) {
        if (!this._oColorMenu) {
            this._oColorMenu = new sap.m.Menu({
                items: [
                   new sap.m.MenuItem({ 
                   text: "Metric A",
                   press: this.onMeasureSelect.bind(this, "Metric A")   }),
                   new sap.m.MenuItem({
                   text: "Metric B",
                   press: this.onMeasureSelect.bind(this, "Metric B")  })
               ]
         });
      }
     this.oColorMenu.openBy(oEvent.getSource());
    }

As shown in the snap below, we get a colour palette button, with the dropdown menu and all the required options, and when we select on each one, we get the colour picker as shown in the snap below.

Step5: Define the default colours during Initialization:

I have set the default colour values for all measures inside onInit() method.

this.aColors = {
     "Metric A": "#2E86AB",
     "Metric B": "#28B463",
     "Metric C": "#F39C12",
     "Metric D": "#8E44AD"
 };

Step6: Applying personalized colours using dataPointStyle in VizFrame:

I have used VizFrame's dataPointStyle config to apply personalized colours to the measures.

plotArea: {
     dataPointStyle: {
          rules: [
            { 
              dataContext: { measureNames: "Metric A"},
               properties: {color: "#2E86AB"}
            },
           {
               dataContext: {measureNames: "Metric B"},
               properties: {color: "#28B463"}
           }
         ]

Step7: Open color picker when the measure is selected:

When the measure is selected from the menu, a color picker dialog appears.

_openColorPicker: function(oControl, sMeasure) {

        if (!this._oColorPicker) {
             this._oColorPicker = new sap.ui.unified.ColorPickerPopover({
                  colorString: "HEX",
                  change: fuction(oEvent) {
                       var sColor = oEvent.getParameter("colorString");
                        this.applyMeasureColor( sMeasure, sColor );
                  }.bind(this)
             });
           }
       this._oColorPicker.openBy(oControl);
      }

Step8: To dynamically update the VizFrame properties:

The selected color is updated dynamically by updating the VizFrame properties.

_applyMeasureColor: function(sMeasure, sColor) {
          var oVizFrame = this.byId("idVizFrame");
          var oProps = oVizFrame.getVizProperties();
          oProps.plotArea.dataPointStyle.rules =
                oProps.plotArea.dataPointStyle.rules.map(function(oRule) {
                      if (oRule.dataContext.measureNames === sMeasure) {
                               oRule.properties.color = sColor;
                        }
                   return oRule;
                });
               oVizFrame.setVizProperties(oProps);
    }

Step9: Persist the selected colours using browser local storage:

The user selected colors are stored in the browser's local storage, so that the preferred colors are picked up when you reopen the application.

localStorage.setItem(
        "CHART_COLORS",
          JSON.stringify(oColorObject)
    );

We can retrieve the same during initialization, so that the colours remain consistent even while reopening the application.

 JSON.parse(
        localStorage.getItem("CHART_COLORS")
   );

Output

Here is the final working chart snap:

Conclusion

This shows that instead of limiting to pre-defined charts or templates, one can personalize the charts and visualize their own preferences and in turn makes it easy to read and analyse data using VizFrame.

Reference: Documentation - Demo Kit - SAPUI5 SDK

Build an Auto-Rotating Image Slider in SAPUI5 using Carousel Control.

2026-07-20T10:38:36.206000+02:00

Hello everyone,

Introduction

While working on one of my SAPUI5 applications, I wanted the landing page to look more attractive instead of displaying a static image.

After exploring different approaches, I found that combining the Carousel control with JavaScript's setInterval() function provides a simple and effective solution. In this blog, I'll share how I implemented an auto-rotating image slider and explain the logic behind it so that you can use the same approach in your SAPUI5 applications.

The sap.m.Carousel control is a container control in SAPUI5 that allows users to navigate through a collection of content items. Each item within the Carousel can be an image, form, layout, or any other SAPUI5 control.

Overview

The Carousel control is commonly used for displaying image galleries, but it can also contain any sap.m control.

Structure

The carousel consists of the following elements:

Content area - displays the different items.

Navigation - arrows to the left and right for switching between items.

Paging (optional) - indicator at the bottom to show the current position in the set.

The paging indicator behaves as follows:

showPageIndicator: Determines whether the indicator is displayed.

If the dataset contains less than 9 pages, the indicator displays as bullets.

If the dataset contains 9 or more pages, the indicator becomes numeric.

pageIndicatorPlacement: Determines where the indicator is located. The default setting is sap.m.CarouselPageIndicatorPlacementType.Bottom (below the content).

Step 1 :

Create the SAPUI5 Project Using a Basic Template

Step 2 :

Configure the XML View (View1.view.xml)

In this view:

The left side contains the image slider using the Carousel control.

The right side contains Login and Sign Up forms using IconTabBar.

I chose this layout because it resembles a common login page design used in many business applications. Although the focus of this blog is the Carousel, placing it beside a login form demonstrates a practical use case.

<mvc:View controllerName="carouselcontrolproject.controller.View1"
    xmlns:mvc="sap.ui.core.mvc"
    xmlns="sap.m" 
    xmlns:form="sap.ui.layout.form">
    <Page id="page" title="{i18n>title}">
        <HBox width="100%" justifyContent="SpaceBetween">
            <Carousel id="id1" loop="true" width="600px" height="500px">
                <Image src="https://images.pexels.com/photos/16767121/pexels-photo-16767121.jpeg" />
                <Image src="https://images.pexels.com/photos/32162192/pexels-photo-32162192.jpeg" />
                <Image src="https://images.pexels.com/photos/32228687/pexels-photo-32228687.jpeg" />
                <Image src="https://images.pexels.com/photos/32730210/pexels-photo-32730210.jpeg" />
            </Carousel>
            <VBox width="50%">
                <IconTabBar>
                    <items>
                        <IconTabFilter text="Login">
                            <form:SimpleForm editable="true" layout="ResponsiveGridLayout">
                                <form:content>
                                    <Label text="Email" />
                                    <Input id="inputLEmail" value="" valueState="None" valueStateText="" liveChange="onLiveChangeLEmail" />
                                    
                                    <Label text="Password" />
                                    <Input id="inputLPassword" value="" valueState="None" valueStateText="" type="Password" liveChange="onLiveChangeLPass" />
                                    
                                    <Label />
                                    <VBox alignItems="Center">
                                        <Button text="Log in" type="Emphasized" press="onPressLogin" />
                                    </VBox>
                                    
                                    <Label />
                                    <Link text="Forgot Password?" press="onPressOpenForPassFrag" />
                                </form:content>
                            </form:SimpleForm>
                        </IconTabFilter>
                        <IconTabFilter text="Sign up">
                            <form:SimpleForm editable="true" layout="ResponsiveGridLayout">
                                <form:content>
                                    <Label text="Name" />
                                    <Input id="inputSName" value="" valueStateText="" liveChange="onLiveChangeName" />
                                    
                                    <Label text="Email" />
                                    <Input id="inputSEmail" value="" valueStateText="" liveChange="onLiveChangeEmail" />
                                    
                                    <Label text="Password" />
                                    <Input id="inputSPassword" type="Password" value="" valueStateText="" liveChange="onLiveChangePass" />
                                    
                                    <Label text="Confirm Password" />
                                    <Input id="inputCPassword" type="Password" value="" valueStateText="" />
                                    
                                    <Label />
                                    <HBox justifyContent="SpaceBetween">
                                        <Button text="Reset" type="Emphasized" press="resetSFields" />
                                        <Button text="Sign Up" type="Emphasized" press="onPressSignUp" />
                                    </HBox>
                                </form:content>
                            </form:SimpleForm>
                        </IconTabFilter>
                    </items>
                </IconTabBar>
            </VBox>
        </HBox>
    </Page>
</mvc:View>

In my example, I configured the Carousel with loop="true" so that the images continue rotating without interruption. I also assigned a fixed width and height to maintain a consistent layout beside the login form. Each Image control represents one slide in the Carousel.

Note: Since external image URLs are used from Pexels, an active internet connection is required to load the images.

Step 3:

Implement Auto-Rotation Logic (View1.controller.js)

sap.ui.define([
    "sap/ui/core/mvc/Controller"
], function (Controller) {
    "use strict";

    return Controller.extend("carouselcontrolproject.controller.View1", {
        onInit: function () {
            // Fetch the Carousel control instance
            var oCarousel = this.byId("id1");
            
            // Set up a safe interval function for auto-rotation
            this._iIntervalId = setInterval(function () {
                if (oCarousel) {
                    oCarousel.next();
                }
            }, 1000);
        },

        onExit: function () {
            // Clean up the interval when the view is destroyed to prevent memory leaks
            if (this._iIntervalId) {
                clearInterval(this._iIntervalId);
            }
        }
    });
});

I used JavaScript's setInterval() function because it provides a simple way to execute the same action repeatedly. Every second, it calls the Carousel's next() method, allowing the images to rotate automatically without any user interaction.

Note : For demonstration purposes, the interval is set to 1 second. In production applications, a value between 3 and 5 seconds generally provides a better user experience.

Step-by-Step Execution

View loads
onInit() executes automatically
Carousel with ID id1 is fetched
The setInterval() callback function executes.
The next() method is called on the Carousel.
The Carousel navigates to the next image.
If the last image is reached and loop="true" is enabled, navigation continues from the first image.

Output

The application displays:

An auto-rotating image slider on the left side

Images automatically change every second using JavaScript interval logic

Conclusion

While implementing this feature, I realized that SAPUI5 already provides everything needed to build a simple image slider without relying on external UI libraries. By combining the standard sap.m.Carousel control with a small amount of JavaScript, I was able to create an auto-rotating banner that can easily be reused in landing pages, dashboards, or product showcase applications.

I hope this example helps anyone looking to add a more dynamic and engaging user interface to their SAPUI5 applications.

UI5 Linter in Action: A Hands-On Workshop at UI5con 2026

2026-07-20T15:50:50.154000+02:00

UI5 Linter in Action: A Hands-On Workshop at UI5con 2026

Still running legacy OpenUI5/SAPUI5 code with deprecated APIs, inline scripts, and global variables? It's time to modernize — and this workshop shows you exactly how.

What Happened

At UI5con 2026 Germany, we ran a one-hour hands-on workshop where attendees took a real OpenUI5/SAPUI5 application from "legacy" to "future-proof" using UI5 linter. Step by step, participants:

Ran their first UI5 linter report and learned what it tells them
Auto-fixed issues with a single command
Manually resolved deprecated APIs, CSP violations, and legacy patterns
Integrated UI5 linter into a CI pipeline so regressions never come back

The feedback was fantastic — attendees loved the practical, hands-on format and walked away with real skills they could immediately apply to their own projects.

Do It Yourself

Couldn't make it to UI5con? No problem. This workshop is fully self-paced and available for you to complete on your own. All you need:

Prerequisites

Node.js (LTS) and Git installed
A code editor of your choice
Basic UI5 development experience

Simply clone the workshop repository and follow the step-by-step instructions. You'll get the same experience as the live attendees — modernizing a real app from start to finish at your own pace.

What You'll Learn

How the UI5 linter identifies deprecated APIs, CSP violations, and legacy patterns
How to auto-fix common issues with a single command
How to manually resolve findings that require deeper changes
How to integrate UI5 linter into your CI pipeline for ongoing code quality

Bonus: AI-Assisted Modernization

As an outlook, the workshop briefly explores the UI5 Modernization plugin for coding agents — automating the very steps you'll learn manually.

Clone the repo, follow the steps, and modernize your first app today!

Visualizing Business Processes in SAPUI5 using the sap.suite.ui.commons.ProcessFlow Control

2026-07-21T10:56:11.351000+02:00

Hello everyone,

In this blog post I'm going to explain the ProcessFlow control in SAPUI5 in a simple way, with the steps I followed while trying it out.

Overview:

So, in simple words, ProcessFlow is a control which is used to show a chain of connected documents as one single picture, instead of showing them as separate rows in a table.

For example, in most SAP scenarios one document leads to another document. A Sales Order leads to a Delivery, and the Delivery leads to an Invoice. If we show these in a normal list, all three will appear as separate rows, and the user cannot easily tell how they are connected or which one is stuck. So, by using the ProcessFlow control, we can show all three documents together in one single flow, with colors showing the status of each document.

So here I have created one small project to try this out, where I have taken a simple Order-to-Cash example - Sales Order, Delivery, and Invoice - and shown them using the ProcessFlow control.

Why I used ProcessFlow instead of building it myself

So, first I thought of building this on my own using some divs and CSS and manually giving colors based on status. But then I realized SAPUI5 already gives a standard control for this, so I did not have to build the status colors, click behaviour, or zoom behaviour on my own. Also, since it is a standard Fiori control, it looks and behaves the same as other Fiori apps, so I did not have to do any extra styling.

Project Structure

The important files for this control are inside the webapp folder, mainly the view, controller, model, and manifest.json file, same as any normal SAPUI5 app.

processflowcontrol/
├── webapp/
│   ├── controller/
│   │   ├── App.controller.js
│   │   └── View1.controller.js
│   ├── css/
│   ├── i18n/
│   ├── model/
│   │   ├── data.json
│   │   └── models.js
│   ├── test/
│   ├── view/
│   │   ├── App.view.xml
│   │   └── View1.view.xml
│   ├── Component.js
│   ├── index.html
│   └── manifest.json
├── package.json
└── README.md

Step 1: Declaring the Data Model in manifest.json

So, first we have to declare our JSON model in the manifest.json file, so that the framework will load it automatically when the app starts. We don't need to write any extra code in the controller for this.

"models": {
"i18n": {
   "type": "sap.ui.model.resource.ResourceModel",
   "settings": {
     "bundleName": "processflowcontrol.i18n.i18n"
   }
},
"process": {
   "type": "sap.ui.model.json.JSONModel",
   "uri": "model/data.json"
}
}

Step 2: Create the JSON data (model/data.json)

So, the ProcessFlow control needs two things in the JSON file - lanes and nodes.

lanes means the stages, like Sales Order, Delivery, and Invoice. nodes means the actual documents which sit inside these stages.

{ 
 "lanes": [ 
   { "id": "order",    "label": "Sales Order", "icon": "sap-icon://sales-order",     "position": 0 }, 
   { "id": "delivery", "label": "Delivery",     "icon": "sap-icon://shipping-status", "position": 1 }, 
   { "id": "invoice",  "label": "Invoice",      "icon": "sap-icon://receipt",         "position": 2 } 
 ], 
 "nodes": [ 
   { "id": "SO-1001",  "lane": "order",    "title": "SO 1001",       "abbr": "SO", "state": "Positive", "stateText": "Completed", "children": ["DEL-2001"] }, 
   { "id": "DEL-2001", "lane": "delivery", "title": "Delivery 2001", "abbr": "DE", "state": "Positive", "stateText": "Shipped",   "children": ["INV-3001"] }, 
   { "id": "INV-3001", "lane": "invoice",  "title": "Invoice 3001",  "abbr": "IN", "state": "Critical", "stateText": "Overdue",   "children": null } 
 ] 
}

A few important points about the JSON data:

position (on lanes) — controls the left-to-right order of the lanes. I removed it once in my own testing file just to check, and the Delivery lane came before the Sales Order lane. So this field decides the order, and it's easy to forget.
children (on nodes) — this is what draws the arrow to the next node. SO-1001 has DEL-2001 as its child, so an arrow is drawn from SO-1001 to DEL-2001, and so on. Since children is written as an array, we can give more than one document ID here if the process branches into two paths.
state (on nodes) — decides the color of the node:
- Positive → green
- Critical → orange
- Negative → red
- Neutral → grey
stateText (on nodes) — just the small label shown under the node (like "Completed" or "Overdue").

Step 3: Bind the control in the view (View1.view.xml)

<mvc:View controllerName="processflowcontrol.controller.View1"
    xmlns:mvc="sap.ui.core.mvc"
    xmlns="sap.m"
    xmlns:n="sap.suite.ui.commons">
    <Page id="page" title="{i18n>title}">
        <Panel headerText="Order Fulfillment Status">
            <n:ProcessFlow id="orderProcessFlow" scrollable="false" nodes="{process>/nodes}" lanes="{process>/lanes}" nodePress="onNodePressed">
                <n:nodes>
                    <n:ProcessFlowNode laneId="{process>lane}" nodeId="{process>id}" title="{process>title}" titleAbbreviation="{process>abbr}" children="{process>children}" state="{process>state}" stateText="{process>stateText}" highlighted="{process>highlighted}" />
                </n:nodes>
                <n:lanes>
                    <n:ProcessFlowLaneHeader laneId="{process>id}" text="{process>label}" iconsrc="{process>icon}" position="{process>position}" />
                </n:lanes>
            </n:ProcessFlow>
        </Panel>
    </Page>
</mvc:View>

So here we are simply binding the nodes and lanes arrays from our JSON model to the ProcessFlow control, and inside that giving the aggregation binding for ProcessFlowNode and ProcessFlowLaneHeader.

Step 4: Handling Node Clicks (View1.controller.js)

sap.ui.define([
    "sap/ui/core/mvc/Controller",
    "sap/m/MessageToast"
], (Controller, MessageToast) => {
    "use strict";
    return Controller.extend("processflowcontrol.controller.View1", {
        onInit() {
        },
        onNodePressed: function (oEvent) {
            var oNode = oEvent.getSource();
            var sTitle = oNode.getTitle();
            MessageToast.show("Node selected: " + sTitle);
        }
    });
});

So, in the above code, whenever a user clicks on any node, the onNodePressed function will be called, and we get the clicked node using oEvent.getSource(). From there we can read its title, and any other property we need. I was a little confused initially whether to read the node details from getSource() or from the event parameters, but getSource() gave me the correct node object, so I used that.

Here I have just shown a MessageToast with the node title when clicked, but in an actual application, this is the place where we can navigate to the object page of that particular document.

Output

Conclusion:

So, this is how we can use the ProcessFlow control in SAPUI5 to show a chain of connected documents in a single, easy-to-understand picture. Instead of showing Sales Order, Delivery, and Invoice as separate rows in a table, we can show them together as one flow, with colors telling us the status of each document at a glance.We just need to give the control two things - lanes (the stages) and nodes (the documents) - in a simple JSON format, and the control takes care of the rest: drawing the lanes in order, placing the nodes correctly, drawing the arrows between them, coloring them based on status, and also giving us zoom and click functionality without any extra code.This same JSON structure is not limited to Sales Order-Delivery-Invoice - we can reuse it for any multi-step process, like a support ticket lifecycle, a purchase approval chain, or an onboarding process, just by changing the lane and node data.So this is a simple and quick way to build a document flow screen without writing our own timeline UI from scratch.

Creating a Custom Action to Export Selected Records to Excel Using Fiori Elements and CAP

2026-07-21T12:30:55.085000+02:00

Introduction

While working on a Fiori Elements application, I came across a requirement that initially seemed straightforward but wasn't available as a standard feature. The application already had the built-in Export to Excel option, but it always exported every row displayed in the table. The business users wanted something slightly different—they wanted to select only a few records and export just those.

My first thought was to implement a backend action that generated an Excel file and returned it to the UI. After exploring the available options, I realized that wasn't necessary. SAPUI5 already provides a Spreadsheet API that can generate Excel files directly in the browser, making the implementation much simpler while avoiding additional backend development.

In this blog, I'll walk through the approach I used to add a custom Export Selected button to a Fiori Elements List Report. By the end, you'll have a working example that exports only the selected rows and integrates naturally with the standard Fiori toolbar.

Step 1: Initialize the CAP Project

First, create a new directory for your project and initialize a standard SAP CAP application. Open your terminal and run:

mkdir employee
cd employee
cds init

Step 2: Define the Database Schema

Next, we will define the data model for our employees.

Create a file named schema.cds inside the db folder and add the following code:

// db/schema.cds
namespace company.hr;
 
entity Employees {
    key ID     : UUID;
    name       : String;
    department : String;
    role       : String;
    email      : String;
}

Step 3: Create the Service and UI Annotations

Now, expose the database entity as an OData service and add the basic Fiori UI annotations to define what columns will appear in our Fiori List Report table.

Create a file named cat-services.cds (typically in the srv folder) and add this code:

// srv/cat-services.cds
using { company.hr as db } from '../db/schema';
 
service EmployeeService {
    entity Employees as projection on db.Employees;
}
 
annotate EmployeeService.Employees with @(
    UI.LineItem : [
        { $Type : 'UI.DataField', Label : 'Employee Name', Value : name },
        { $Type : 'UI.DataField', Label : 'Department', Value : department },
        { $Type : 'UI.DataField', Label : 'Role', Value : role },
        { $Type : 'UI.DataField', Label : 'Email', Value : email }
    ]
);

Step 4: Add Mock Data

To test our application, we need some dummy data. SAP CAP automatically loads CSV files that match the namespace and entity.

Create a folder named data inside your db folder, then create a file named company.hr-Employees.csv and paste the following:

ID;name;department;role;email
1;Alice Walker;Engineering;Backend Developer;alice@company.com
2;Bob Smith;Sales;Account Executive;bob@company.com
3;Charlie Davis;Engineering;Frontend Developer;charlie@company.com
4;Diana Prince;HR;HR Manager;diana@company.com

Step 5: Configure the Custom Action in the Page Map

Once your Fiori Elements application has been generated, the next step is to add a custom action to the table toolbar.

Follow these steps:

Right-click on the webapp folder in your project.
Select Show Page Map.
In the Page Map, select the List Report page.
Click the Edit (pencil) icon to modify the page.
Under the Table / Table Toolbar section, click the + button next to Actions.
Select Add Custom Action.

Configure the custom action with the following properties:

Label: Export Selected
Requires Selection: Enabled
Press Event: exportSelected

Step 6: Implement the Custom UI5 Export Logic

Now, we will write the logic that extracts the selected rows and converts them to an Excel file using the Fiori V4 API.

Open the newly generated controller extension file (ListReportExt.js) and replace its contents with the following:

sap.ui.define([
    "sap/ui/export/Spreadsheet",
    "sap/m/MessageToast"
], function (Spreadsheet, MessageToast) {
    "use strict";
 
    return {
        exportSelected: function (oEvent) {
            
            // 1. Access the Fiori V4 API
            var oExtensionAPI = this.editFlow ? this : this.getExtensionAPI();
            
            // 2. Get only the rows selected by the user
            var aSelection = oExtensionAPI.getSelectedContexts();
 
            if (!aSelection || aSelection.length === 0) {
                MessageToast.show("Please select at least one employee to export.");
                return;
            }
 
            // 3. Extract the raw JSON data from those selected rows
            var aData = aSelection.map(function (oContext) {
                return oContext.getObject();
            });
 
            // 4. Map the Excel columns to your CDS database fields
            var aColumns = [
                { label: 'Employee Name', property: 'name' },
                { label: 'Department', property: 'department' },
                { label: 'Role', property: 'role' },
                { label: 'Email', property: 'email' }
            ];
 
            // 5. Configure the Excel Workbook properties
            var oSettings = {
                workbook: { 
                    columns: aColumns,
                    context: {
                        sheetName: 'Selected Employees'
                    }
                },
                dataSource: aData,
                fileName: "Custom_Employee_Export.xlsx",
                worker: false 
            };
 
            // 6. Build and Download the Excel file
            var oSheet = new Spreadsheet(oSettings);
            
            oSheet.build().then(function() {
                MessageToast.show("Excel export successful!");
            }).catch(function(sMessage) {
                MessageToast.show("Export failed: " + sMessage);
            }).finally(function () {
                oSheet.destroy(); // Destroy object to prevent memory leaks in the browser
            });
        }
    };
});

Step 7: Run and Test the Application

With the code in place, start your server by running:

cds watch

After running the application, select one or more employee records from the table. You'll notice that the Export Selected button is enabled only when records are selected. Clicking the button downloads an Excel file containing only the selected employees instead of the entire table.

Conclusion

What I liked most about this approach is that it keeps the implementation lightweight. Since the Excel file is generated in the browser using the SAPUI5 Spreadsheet library, there was no need to create a custom CAP action or write backend logic just for exporting data.

One thing I found useful was enabling Requires Selection for the custom action. Without it, users could click the button even when no rows were selected, resulting in unnecessary validation. Letting Fiori handle the button state provides a much better user experience.

Although this example exports employee data, the same approach can be used in almost any Fiori Elements application, such as Sales Orders, Purchase Orders, Expense Reports, or Products. If you've ever wanted to provide users with more control over what they export, this is a simple customization that's worth adding to your applications.

JSX Runtime for UI5: write your views as TSX, and tell us what you think

2026-07-21T14:36:39.304000+02:00

JSX Runtime for UI5: write your views as TSX, and tell us what you think

We've been experimenting with something and we'd like to put it in front of the community early: a JSX runtime for UI5. It lets you author UI5 views as .tsx files, with full per-control TypeScript typing, and it does so without a virtual DOM, and without a reconciler.

This is an incubation. It works, the showcase runs end-to-end, but the whole point of this post is to get it into your hands and hear back from you before we commit to more. If you write UI5 apps, we want your opinion.

What it actually does

A JSX element compiles to a plain constructor call. That's the entire idea:

import Button from "sap/m/Button";
import Page from "sap/m/Page";

export default class Main extends View {
    createContent() {
        return (
            <Page title="Hello">
                <Button text="Click me" press=".onPress" />
            </Page>
        );
    }
}

<Button text="Click me" /> becomes new Button({ text: "Click me" }). Nothing more magical than that. Babel emits the calls, the runtime hands them to UI5, and from there it's UI5 exactly as you already know it: metadata, applySettings, bindings, aggregations, events. There's no re-render loop, because a JSX expression is a constructor call, not a render description. Reactivity comes from UI5 bindings, same as in an XML view.

One thing to set expectations up front: this JSX describes the UI5 control tree, not the DOM. There's no native HTML. A <div> or <span> won't work, because a lowercase tag can't become a UI5 control. You compose controls (<Page>, <Button>, <VBox>, …), exactly as you do in an XML view, and UI5's renderers produce the actual markup. (An HTML-aware renderer is on the radar, but it's not here today.)

If you don't use TypeScript, plain .jsx works too. You still get the new Control(settings) calls, you just skip the author-time type checking.

Why we think it's worth a look

Per-control typing that we didn't hand-write. <Button> is typed from Button's own $ButtonSettings interface, which @openui5/types already publishes from each control's metadata. Wrong prop names, wrong value types, wrong event payloads. The TypeScript checker catches them. No code generation step in the project.
It's the control tree you already have. XML views and TSX views coexist in the same app. You can migrate one view at a time and keep everything runnable, or never migrate at all and just write new views in TSX.
No fork of UI5. The runtime doesn't patch or replace anything in the core. It glues Babel's output into UI5's existing settings model.
A small set of directives that read well. <Fragment> for grouping, <For> for bound aggregations, <If> for conditional rendering and falsy children ({flag && <X/>}) just work without crashing an aggregation.
A plugin SPI, if you want to extend it. Five extension points let libraries add their own directives and behaviors on top of the core without touching it. Everything the core itself does, the dot-handler events, <For>, <If>, is built on that same SPI, so nothing in the core is privileged. We ship a <Switch>/<Case>/<Default> sample plugin as a worked example.

Where to start

The fastest way to get a feel for it is the live showcase. It's a running UI5 app that doubles as the documentation, with runnable samples for every concept:

👉https://ui5-community.github.io/jsx-runtime/

The source, the setup guide, and the monorepo (the library, the showcase, and a minimal from-scratch reference app) are on GitHub:

👉https://github.com/ui5-community/jsx-runtime

If you already have an app with XML views, there's a step-by-step guide for converting them one at a time.

This is where you come in

We're calling this an incubation on purpose. Before we invest further, we want to know whether it solves a real problem for you, where it feels awkward, and what's missing. Concretely, we'd love to hear:

Would you write new views in TSX? Would you migrate existing ones?
Does the typing carry its weight, or is it more ceremony than value?
What breaks, or what did you expect to work and it didn't?
What would you need before you'd use this in a real project?

Please open an issue with anything: a bug, a rough edge, a "this is great," a "this is not for me and here's why":

👉https://github.com/ui5-community/jsx-runtime/issues

Honest feedback, including the critical kind, is exactly what makes an incubation worth doing. Thanks for taking a look.

Export Selected Rows to Excel in SAP Fiori Elements Using Custom Actions

2026-07-22T08:23:34.383000+02:00

Hello Everyone,

While working on a CAP-based SAP Fiori Elements application, I came across a requirement where users needed to export only the selected records from the List Report page instead of the entire dataset.

SAP Fiori Elements provides a standard Export option that downloads all the records displayed in the table. However, there may be business scenarios where users need to export only specific rows that they have selected.

In this blog, I'll show you how to create a custom action that exports only the selected rows to an Excel file using the sap.ui.export.Spreadsheet API.

Prerequisites

Before implementing this solution, ensure that:

You have a CAP-based SAP Fiori Elements application.

Your List Report page is already displaying data.

You are using SAPUI5 version that supports sap.ui.export.Spreadsheet.

You have created a Controller Extension for your List Report.

Step 1: Create a Custom Action Using a Controller Extension

Add a handler function in the controller extension and update the manifest.json file to register the custom action.

In this step, you create a controller extension to define a handler function for the custom action button and add the extension settings of the custom action to the manifest.json file.

If a controller extension is already available for a page, you can copy the code and use it.

Add the following configuration to the manifest.json file:

"controlConfiguration": {
                "@com.sap.vocabularies.UI.v1.LineItem": {
                  "tableSettings": {
                    "type": "ResponsiveTable"
                  },
                  "actions": {
                    "controller1": {
                      "press": "project1.ext.controller.controller1.exportSelectedRowData",
                      "visible": true,
                      "enabled": true,
                      "requiresSelection": true,
                      "text": "Export Selected Rows of Data"
                    }
                  }
                }
              }

Step 2: Implement the Export Logic in the Controller Extension

sap.ui.define([
    "sap/m/MessageToast",
    "sap/ui/export/Spreadsheet",
    "sap/ui/export/library"
], function(MessageToast, Spreadsheet, exportLibrary) {
    'use strict';
    const EdmType = exportLibrary.EdmType;
    return {
        /**
         * Generated event handler.
         *
         * @Param oContext the context of the page on which the event was fired. `undefined` for list report page.
         * @Param aSelectedContexts the selected contexts of the table rows.
         */
        exportSelectedRowData:function(oContext, aSelectedContexts) {
            // 1. Guard clause: Ensure there are selected rows
            if (!aSelectedContexts || aSelectedContexts.length === 0) {
                MessageToast.show("Please select at least one row to export.");
                return;
            }

            // 2. Extract the raw JSON data from the selected contexts
            const aSelectedData = aSelectedContexts.map(function(oRowContext) {
                return oRowContext.getObject();
            });

            // 3. Define the columns for the Excel file
            const aColumns = [
                {
                    label: 'Department ID',
                    property: 'ID',    
                    type: EdmType.String             
                },
                {
                    label: 'Department Name',
                    property: 'deptName',
                    type: EdmType.String
                },
                {
                    label: 'Location',
                    property: 'location',
                    type: EdmType.String
                }
            ];

            // 4. Configure the Spreadsheet settings
            const mSettings = {
                workbook: {
                    columns: aColumns,
                    context: {
                        sheetName: 'Selected Row Data Sheet'
                    }
                },
                dataSource: aSelectedData,
                fileName: 'Selected_Departments.xlsx',
                worker: false // Set to false because we are passing client-side JSON data directly
            };

            // 5. Generate and download the Excel file
            const oSheet = new Spreadsheet(mSettings);
            
            oSheet.build()
                .then(function() {
                    MessageToast.show("Exported selected rows successfully.");
                })
                .catch(function(sMessage) {
                    MessageToast.show("Export failed: " + sMessage);
                })
                .finally(function() {
                    // Always destroy the spreadsheet instance to prevent memory leaks
                    oSheet.destroy();
                });
        }
    };
});

Now let's understand how the export functionality works internally

Step 1: Import the Required Libraries

Import the required SAPUI5 libraries for Excel export.

sap/ui/export/Spreadsheet – Used to create and generate Excel files.

sap/ui/export/library – Provides export-related data types such as EdmType, which are used while defining the Excel columns.

Step 2: User Selects Rows

The user selects one or more rows from the List Report table and clicks the Export Selected Rows of Data button. This action triggers the exportSelectedRowData() function.

Step 3: Validate the Selection

The application checks whether at least one row has been selected. If no rows are selected, a message is displayed to the user, and the export process is stopped.

Step 4: Convert Context Objects to JSON

The selected rows are received as binding context objects. Using the getObject() method, each context is converted into a plain JavaScript object. These objects are then stored in an array, which serves as the data source for the Excel export.

Step 5: Define the Excel Columns

The application defines the structure of the Excel file by specifying the column headers (label), the corresponding data properties (property), and the data type (EdmType).

Step 6: Configure the Spreadsheet

A Spreadsheet configuration object is created by specifying the workbook details, sheet name, column definitions, data source, and output file name. These settings determine how the Excel file will be generated.

Step 7: Generate the Excel File

A new Spreadsheet instance is created using the configuration object. The build() method then generates the Excel workbook and automatically downloads it to the user's system.

Step 8: Handle Success or Errors

The application displays a success message if the export is completed successfully. If an error occurs during the export process, an appropriate error message is displayed.

Step 9: Destroy the Spreadsheet Object

Finally, the Spreadsheet object is destroyed to release the resources occupied by it and prevent memory leaks.

Output

Selecting the Required Rows

The user selects one or more rows from the List Report and clicks the Export Selected Rows of Data button.

Excel Export in Progress

After clicking the export button, the Spreadsheet API generates the Excel document. Once the process is completed, a success message is displayed.

Downloaded Excel File

The generated Excel file is automatically downloaded to the user's local system with the configured file name (Selected_Departments.xlsx).

Conclusion

In this blog, we learned how to implement a custom action in SAP Fiori Elements that exports only the selected rows from the List Report into an Excel file.

Unlike the standard Export functionality, which exports all records, this approach gives users greater flexibility by allowing them to download only the data they need.

Since the implementation uses the sap.ui.export.Spreadsheet API, it can be easily reused across different SAP Fiori Elements applications with minimal changes to the column configuration.

Thank you for reading! I hope you found this blog helpful and that it helps you implement a similar requirement in your own projects.

Happy Coding!

reCAP 2026 – Recordings of our Annual CAP Developer Conference

2026-07-22T12:07:54.874000+02:00

On 15 July 2026, the CAP community came together for reCAP 2026 in St. Leon-Rot. Again, tickets were sold out within just a few minutes. We had more than 400 participants onsite and many more joining online.

For everyone who couldn’t attend live, most sessions were recorded. Below is a summary of the recorded sessions, along with links to the recordings. You can find all recordings on YouTube.

Opening & Keynote

Intro by Ole Lilienthal
Setting the stage, Ole gave an overview of the Autonomous Enterprise and how CAP plays a key role in enabling the SAP Business AI platform as the underlying platform for the Autonomous Enterprise. He also explained the importance of CAP in the age of AI.

Recording link

Keynote by Daniel Hutzel
In his keynote, Daniel shared an overview of the biggest CAP achievements since the last reCAP, including AI-related topics.

Recording link

Main Track Sessions in Audimax

CAP Tools – What’s New and Hot by Christian Georgi
A tour through the latest and greatest in CAP tooling, including:

`cds repl` with queries
Debugging apps on Kyma
CDS Project outline in Visual Studio Code
CAP in browser

Recording link

Optimizing CAP Performance with Data Replication and Caching – Part II by Mike Zaschka
As a follow-up to last year’s talk on cds-caching, this session broadened the view to the full landscape of caching, replication, and federation strategies in the CAP ecosystem. Mike walked through a curated selection of solutions and offered practical guidance on which approach fits which scenario.

Recording link

AI-Assisted Development of CAP Apps by Daniel Schlachter and Stefan Rudi
A look at the CAP MCP development server, which gives AI coding assistants direct access to CAP documentation improving code quality in tools like Claude Code and GitHub Copilot.

Recording link

Expressions and Abstractions – Two Developer Superpowers in CAP by Patrice Bender and DJ Adams
A demonstration of two powerful CAP affordances: expressions (what they are, how to use them, and why they matter) and mocking (letting you iterate fast on data, auth, messaging, and remote services).

Recording link

CAP Plugins: Latest and Greatest by Max Eckert, Dries Van Vaerenbergh, Matthis Vansteenhuyse, and Lisa Julia Nebel
CAP plugins dramatically simplify integration with SAP BTP services. This session demystified the plugin model and spotlighted the enhanced attachments plugin, the renovated change tracking plugin, a new notifications plugin for Java, and the new SAP Build Process Automation plugin.

Recording link

Plug, Connect, Play: CAP Integration Made Effortless by Ram Prasad GS and Bilal El-Massoudi
An introduction to cap-connect, a production-ready, open-source CAP plugin from Aarini Consulting that brings first-class connection management to any CAP application. The talk also showcased how cap-connect powers Prodsphere, Aarini’s own CAP-based product.

Recording link

Production GenAI in CAP: Beyond the Demo by Moudhaffer Azizi
This session explored the architecture behind a production-grade CAP application on SAP BTP that uses RAG to analyse custom ABAP code against Clean Core standards. The session highlighted the journey from a single prompt to a resilient solution orchestrating 14 AI-powered operations.

Recording link

Beyond Vibe Coding: Engineering Deterministic CAP Applications with SDD by Maximilian Hartig and Abdulbasıt Gülşen
A live "0-to-1" walkthrough of Spec-Driven Development using the open-source Spec Kit in Visual Studio Code to transform a raw business requirement into a CAP application.

Recording link

From Click-Ops to Code-Ops (Terraform) by Nicholas Arefta
Nicholas demonstrated how to use Terraform to deploy multitenant apps on SAP BTP. He demonstrated provisioning of a Provider subaccount, deploying a multi-tenant application and onboarding a Subscriber completely hands-free.

Recording link

Custom Business Logic with Predefined Extension Points – Using CDS-Oyster by Nick Josipovic and Konrad Koschel
Together with Subscription Billing and Cloud Foundation, Nick and Konrad built an extensive Extension Box using CAP and the CDS-Oyster Code Sandbox enabling secure code extensions in a complex cloud environment.

Recording link

Implementing Runtime Plugins in CAP Java by Joshua Mitchell
Joshua demonstrated in his live session how to program a basic soft delete plugin for CAP Java using annotations, the IntelliJ debugger, and an expression evaluator.

Recording link

Side Track Sessions in W1/W2

Building Code-Based AI Agents with CAP and UI5: From Concept to Production by Wouter Lemaire

Using the Smart Monitoring Agent (previously demonstrated at SAP TechEd) as a real-world example, Wouter showed how to build intelligent, code-based AI agents by combining SAP AI Core with CAP and UI5. The session covered the complete journey from development to deployment.

Recording link

Building AI-enabled Applications with CAP by Max Eckert, Simon Engel, Markus Riedinger, and Peter W. Szabo

An overview of how CAP is evolving to meet the AI era including: exposing CAP services as endpoints for AI agents, leveraging the CAP AI plugin, exploring additional features, and building intelligent, code-driven agents.

Recording link

Building a CAP Application with Latest Best Practices and AI by Lukas Theis, Johannes Vogt, Marc Becker, and Robin de Silva Jayasinghe

A practical, end-to-end walkthrough from idea to production-ready CAP app, combining proven CAP architecture patterns with AI-assisted workflows.

Recording link

Declarative Programming Patterns in CAP - Less Code, More Power by Adrian Görler, Robin de Silva Jayasinghe, and Vitaly Kozyura

A look at how declarative mechanisms in CAP such as calculated elements, annotation-based constraints (e.g. @assert, @assert.range, @assert.format), and field control help to reduce custom code. The session also covered how status transition flows help reducing the need for custom validation logic while ensuring data integrity.

Recording link

Update from the cap-js-community - Experience the latest additions to CAP by Oliver Klemenz

A focused technical update on the latest enhancements in the cap-js-community, with a deep dive into the WebSocket modules and the newly introduced common utilities module.

Recording link

AI-Assisted Security Hardening of CAP Applications by Matthias Braun

Matthias showed how AI-powered tools can help identify authorization gaps, generate comprehensive security tests, and detect attack vectors. This significantly reduces the effort required to build and maintain secure CAP applications.

Recording link

Event Queues Scheduling by Sebastian Van Syckel, Dietrich Mostowoj, Thomas Bonk, and Lars Plessing
A deep dive into Transactional Event Queues, which allow scheduling of events and background tasks for asynchronous, exactly-once processing with strong resilience.

Recording link

Automated Testing with HANA Cloud by Armin Hatting
Armin presented practical approaches to integrating database-supported testing in CAP applications, setting up realistic test environments, and ensuring the functionality of SAP HANA Cloud native logic.

Recording link

Did you know about infix filters and projection functions? by Nico Schoenteich

A live-coding overview of infix filters and projection functions (Node.js) and how they were applied in a recent project to reduce custom service.

Recording link

Thank You

A huge thank-you to all speakers, attendees, and community members who made reCAP 2026 such an inspiring day. 🙌 The energy, the ideas, and the conversations are exactly what makes the CAP community special.

If you missed any session, use the recording links above to catch up.

We look forward to seeing how you use what you learned at reCAP 2026. If you have any feedback, please let us know.

Happy coding! 😊