SAP Community - SAPUI5

Problems hiding and showing table columns

2026-02-12T15:00:28.444000+01:00

Hello experts, I have a problem.
I need to hide table columns based on certain conditions.
I get the table object by ID and then all the columns.
Then I use oColumn.setVisible(), and everything works. However, the problem is that in the table personalization, this column is marked as selected, with a check mark.
Is it possible to affect the table settings after changing the column properties?
All tables are described on the backend and Table Type

ResponsiveTable(sap.ui.mdc.table)

Gregor Wolf

2026-02-23T18:24:58.182000+01:00

About Gregor

Germany | SAP Mentor since 2007 | Follow Gregor on LinkedIn

I am an independent SAP solution architect, developer and SAP Mentor. I focus on SAP Business Technology Platform, SAP Cloud Application Programming Model (CAP), Node.JS, SAP Fiori Elements and Security. I've supported several customers during their SAP Cloud ERP Private Edition (S/4HANA On Premise) implementation. Since the end of 2024 I support the technical topics at an SAP Cloud ERP Public Edition Customer.

Topics of interest: SAP Business Technology Platform, SAP Cloud Application Programming Model (CAP), SAP Cloud ERP public and private, SAPUI5, OpenUI5, SAP Fiori, SAP HANA Cloud

Gregor, what inspired you to become an SAP Mentor?

A key influence early in my SAP Community journey was Mark Finnern. He is the father of the SAP Community. Mark encouraged me to move beyond answering questions and start sharing detailed technical how-to's but also event reports in blog posts. In 2007 Mark also founded the SAP Mentors program which gave me the opportunity to provide structured, experience-based feedback to SAP product teams and help bridge the gap between product vision and real-world implementation.

What advice would like to share with other SAP community members?

My advice to other SAP Community members is simple: contribute consistently and think long-term.

Start by answering questions and helping others solve real problems - but don’t stop there. Document your lessons learned, share architectural insights, and write about what worked and what didn’t. That’s how collective expertise grows. And you will be amazed how often you research years later and find your own answers and blog posts to solve a problem you're just facing. Despite all the new stuff SAP has quite a long tail that doesn't change quickly.

Engage constructively, challenge respectfully, and focus on signal over noise. The community is not just a support forum - it’s an ecosystem where practitioners can influence product direction, elevate standards, and shape the future of SAP together.

Configure Your SAP Fiori Elements Apps: Introducing Fine-Tuning in the SAP Fiori Development Portal

2026-02-24T13:45:32.257000+01:00

Throughout our blog series on the SAP Fiori development portal, we've explored how SAP Fiori elements leverages metadata and annotations to build enterprise-grade UIs following the Global UX design principles. But what happens when you need to adjust UI behavior in ways that aren't expressed through annotations? That's what we call configuration – and the Fiori tools are the best place for it. But we're excited to introduce a new feature in the SAP Fiori development portal that makes configuration discovery and experimentation easier than ever.

Understanding Fine-Tuning in SAP Fiori Elements

SAP Fiori elements applications are primarily driven by metadata and annotations - this is their superpower. Annotations define what data to display, how to structure it, and which features to enable. However, not every UI behavior can or should be controlled through annotations. Some aspects require configuration settings that fine-tune how building blocks render and behave.

Let's take the table building block as a perfect example. When you annotate your service with UI.LineItem, SAP Fiori elements automatically selects an appropriate table type based on your entity's capabilities and the Global UX design guidelines:

If your entity set is analytics-enabled, an Analytical Table is displayed, providing built-in aggregation and grouping capabilities
For standard use cases, the Responsive Table is shown by default - it's optimized for various screen sizes and delivers the best user experience across devices
But what if you need to display massive datasets where scrolling performance is critical? The Grid Table excels at rendering huge amounts of data efficiently

Here's the challenge: there's no annotation to switch between these table types. This is where fine-tuning comes into play. You configure these settings in your application's manifest.json or directly in the building block definition when using XML views. But how do you discover what's configurable? What are the available options? What values can you set?

Introducing the Fine-Tuning Panel in the SAP Fiori Development Portal

The SAP Fiori development portal now includes a dedicated Fine-Tuning panel that answers these questions interactively. When you open the code editor for any building block - let's use the table as our example - you'll notice two tabs at the top: "Code" and "Fine-Tuning."

Fine-Tuning Panel

The Fine-Tuning panel reveals all available configuration settings for the building block, complete with:

Clear descriptions explaining what each setting controls
The current value applied in the sample
A searchable interface to quickly find specific settings
Immediate visual feedback when you change values

Exploring Fine-Tuning: A Table Story

Let's walk through a practical scenario. Navigate to the Table Building Block in the SAP Fiori development portal and click "Show Code" to open the code editor. Now switch to the "Fine-Tuning" tab.

You'll see a comprehensive list of configuration options. Let's say you're working on an application that needs to display thousands of travel records, and scrolling performance is becoming an issue. You remember hearing about the Grid Table's superior performance with large datasets, but you're not sure how to enable it.

In the Fine-Tuning panel, use the search box and type "type." The list immediately filters to show the "type" setting, which controls the table visualization. You'll see:

A description explaining the table type setting
The current value: "ResponsiveTable" (the default)
A dropdown showing all available options: ResponsiveTable, GridTable and AnalyticalTable

Searching for settings

Change the value to "GridTable" and watch the magic happen. The preview immediately updates, showing your table rendered as a Grid Table.

Changing the table type

You can see the visual differences

the denser layout
the different scrolling behavior
the optimized rendering for large datasets

But here's where it gets even better. Switch back to the "Code" tab, and you'll notice the code has been automatically updated:

<core:FragmentDefinition
xmlns:core="sap.ui.core"
xmlns="sap.m"
xmlns:macros="sap.fe.macros">
   <macros:Table metaPath="/Travel/@com.sap.vocabularies.UI.v1.LineItem" type="GridTable"/>
</core:FragmentDefinition>

The `type="GridTable"` attribute has been added automatically. If you're using building blocks directly in your XML views, you can simply copy this code into your application. Perfect for custom page development!

From Exploration to Implementation

The Fine-Tuning panel serves as your bridge from exploration to implementation. You can experiment with different settings, understand their effects, and see the exact code needed - all in one interactive environment.

However, it's important to understand where these settings belong in your application architecture:

For Building Blocks in XML Views (like in custom pages): Apply the settings directly as attributes on the building block, just as shown in the code editor. The portal gives you the exact syntax you need.
For Standard Floorplans (List Report, Object Page, etc.): The table building blocks are already integrated into the page structure. To fine-tune them, you add configuration settings to your application's manifest.json file. The SAP Fiori tools Page Map provides a user-friendly interface for configuring these settings without manually editing JSON.

This two-path approach ensures you can fine-tune your application whether you're building custom pages with building blocks or extending standard floorplans.

The Fiori Development Portal as Your Fine-Tuning Laboratory

Think of the SAP Fiori development portal's Fine-Tuning panel as your laboratory for configuration experimentation. You can:

Discover settings you didn't know existed
Understand the purpose and impact of each configuration option
Test different combinations to find the optimal setup for your requirements
Learn the exact syntax needed for implementation
Make informed decisions backed by visual evidence

This interactive approach transforms configuration from a trial-and-error process into a guided, informed decision-making experience.

But keep in mind: SAP Fiori elements applies Global UX design principles automatically. Only fine-tune when you have specific requirements that justify deviating from the defaults.

What's Next

The Fine-Tuning panel represents another step in our commitment to making SAP Fiori elements development more accessible, efficient, and collaborative. But we're not stopping here. We have exciting enhancements planned that will further improve your development experience with the SAP Fiori development portal.

Stay tuned for upcoming blog posts where we'll introduce additional features that continue to bridge the gap between exploration and implementation, making your journey from concept to production even smoother.

To get the full overview of the SAP Fiori development portal, check out the following blog posts of the mini-series:

Customize SAPUI5 apps for business users – make an impact by joining our CEI project

2026-03-01T19:15:53.813000+01:00

SAP Customer Engagement Initiatives (CEI) on https://influence.sap.com allow you, as an SAP customer or partner, to gain early insights into SAP's product developments and work directly with SAP teams to shape future product directions. This project presents a unique opportunity to work with SAPUI5 flexibility product managers and engineering teams, leveraging your expertise customizing SAPUI5 apps with key user adaptation.

Join the upcoming CEI project to make an impact on how key users interact with key user adaptation

If you’re already convinced – join here. If not, read on 🙂

What is key user adaptation?

Key user adaptation is a mode that allows extending SAPUI5 applications for other users right in the browser. It is highly intuitive and requires no technical or programming skills. Just use drag and drop to make UI changes – no modification or copy of SAP standard coding necessary! Read more here.

What is the targeted improvement?

Although the product is mature and widely used, we actively evolve it by delivering new functionality and capability enhancements alongside continuous user experience improvements, informed by UI testing and direct customer feedback.

We are in the process of overhauling key user adaptation’s UI, simplifying the overall approach while making often-used scenarios more streamlined. We’ve taken a close look at the version history (of activated adaptations) and how our users interact with it, extended the “embed third-party content” feature, widened the scope of custom fields that can be added to the UI – and more.

To ensure that we are on the right way, we need your help!

Who should participate?

Users who want to adapt standard SAPUI5 apps for business users. Both key users and technical users are welcome.

Why should you participate?

Gain understanding of SAPUI5 flexibility
Chance to influence a central SAPUI5 feature
Early access to prototypes

How can you participate?

Don’t miss out on this opportunity to share your feedback and engage with SAPUI5 flexibility development teams. Register by March 15, 2026, and make a true impact on how you can customize SAP apps to your needs!

Click here to sign up for our project. (A short overview about how to get started on influence.sap.com can be found here).

After you register for a project, you will be invited to an introductory call where you will get more information. This call is followed by individual or grouped feedback sessions.

Thank you in advance for helping us shape the future of SAPUI5 flexibility!

UI5con Bengaluru 2026 - Community, Code, and the Future of SAP UI Development

2026-03-03T12:16:36.382000+01:00

UI5con Bengaluru 2026 brought together 400+ developers, architects, consultants, and students from across India for a full day of learning, hands-on exploration, and community connection. Held at the SAP Labs campus in Devanahalli as part of SAP Inside Track Bengaluru 2026, the event marked a historic double first — the first time UI5con has taken place in India in seven years, and the very first SAP Inside Track and UI5con held jointly at this location. The event covered everything from the cutting-edge world of AI-assisted development to the fundamentals of accessibility and enterprise UX — all through the lens of SAPUI5 and SAP Fiori.

This was more than a conference; it was a homecoming. With UI5con returning to India after seven years and joining forces with SAP Inside Track for the very first time, the energy in the room was something special — a community reunited and ready to build.

"It's my first SAP Inside Track session as an ABAP Fiori developer. I had a great session attending UI5con. Learned some amazing things during the session."
Participant, Deloitte USI

Kickoff: Agentic Coding with UI5 — From Idea to Inclusive App

Stefan Beck, Peter Muessig, and Rajashree Raghavendra opened the day with a keynote that was equal parts history lesson and vision statement — reminding the audience that UI5con Bengaluru began in 2018, grew to 400+ attendees, 28 sessions, and 41 speakers in 2019, and is now back after a COVID-forced pause of seven years. They traced SAPUI5’s journey from its 2012 enterprise foundations to its current form: TypeScript, Web Components, CI/CD, and a 90% accessibility score in the Web Almanac 2025. Two strategic bets anchored the roadmap: UI5 Web Components (framework-free, standards-based) and Legacy-Free OpenUI5/SAPUI5 (deprecated code removed, async by default).

The AI portion of the keynote charted the evolution from basic code completion in 2020 to the agentic coding era of today and introduced the UI5 MCP Server and Fiori MCP Server as the practical bridges between AI tools and SAP development best practices. A live demo closed the session — an inclusive app built from scratch using Fiori elements Building Blocks and Freestyle code, guided by agentic AI in real time. The vision set the tone for everything that followed: "UI5 in 2026 is where AI acceleration, inclusive design, and enterprise trust meet."

AI Takes Centre Stage

If there was one theme that ran through every session at UI5con 2026, it was AI — and not just as a buzzword. The hands-on session on the MCP Server for Fiori, led by Vinay Hospete, Ashish Anand, and Maheeth Reddy, introduced attendees to the Model Context Protocol — the emerging standard that connects AI coding agents to domain-specific tools and best practices. The demo pod on Vibe Coding with SAP UI5 brought this to life, showing how natural language prompts combined with Cline and SAP AI Core enable governed, auditable UI5 app generation — where AI accelerates the work, but the developer stays in control.

"Vibe coding: Using the MCP server, the code can be generated quickly and can be adapted for the demo & quick mockup."
Participant, Nokia

Deep Dives: Going Beyond the Basics

The deep dive track gave attendees space to go further. Merlin Beutlberger's UI5 in the World of AI showcased the UI5 MCP Server's 10 tools — from app creation and API reference lookups to Linter runs and TypeScript migration guides — with a live demo of an AI agent building a full UI5 app from a natural language prompt. Jitendra Kansal's MDK session addressed how to bring Fiori to mobile without a rewrite, with the MDK MCP Server intelligently transforming UI for smaller screens. Mohammed Sijas introduced the DataRepository library, a lightweight solution that brings OData-like CRUD convenience to plain REST APIs.

Sandeep R S and Vinay Hospete reinforced that ~90% of SAP's own SAPUI5 apps are built on Fiori elements, and that MCP-powered agentic AI is the natural next step. Syed's session on Fiori Applications Demystified gave backend developers and architects a grounding in MVC, bindings, and when to choose Freestyle over Fiori Elements.

"Good place to know what's new and what is the future scope. Hands-on sessions give good insight on the topics."
Participant, Cargill

Accessibility, Web Components, and More

Gergana Georgieva's session on UI5's Ever-Evolving Accessibility was a highlight for many attendees. She walked through SAP's commitment to WCAG 2.2 and ARIA 1.2 standards, covering everything from keyboard navigation and screen reader support to the new Target Size requirements. The key message: accessibility requires both framework support and developer discipline — it must become a habit, not an afterthought.

"I really liked the accessibility session."
Participant, Wipro

The demo pod on UI5 Web Components — presented by Rounak, Vignesh, and Dharshini — showcased the growing maturity of the framework-agnostic component library built on web standards. Web Components 2.0 was announced, with new components including the intriguing <ui5-ai-button>. For developers working with React, Angular, or Vue, this opens new doors.

"It was very interactive. Now they are releasing web components 2.0 which looks promising."
Participant, Adidas

The Suite Controls session from Ashwin Kumar Bolar, Vinay K N, and Santhosh covered enterprise-grade components for complex business applications: Network Graph, UploadSetWithTable, and the Gantt Chart — each purpose-built for the kind of rich operational dashboards that SAP customers depend on. Kotresh T M rounded out the day with a deep dive into cross-app navigation for Fiori microfrontends, making the case for intent-based navigation as the standard pattern for loosely coupled Fiori apps.

And for those excited about the future of AI in SAP applications, Arun Bharathi K's demo on Joule Frontend Actions showed how UI5 apps can expose capabilities directly to SAP's digital AI assistant — making Joule a conversational interface for everyday Fiori interactions.

"Got to know about the capability of Joule with the frontend actions. Would like to have a blog on this."
Participant, AMGBT

Hands-On Sessions: Learning by Doing

A major draw of UI5con has always been its hands-on sessions — and 2026 was no exception. Attendees rolled up their sleeves and built real UI5 apps, working through exercises on SAP Fiori elements V4, the Flexible Programming Model, and the UI5 Linter, with GitHub repositories shared so participants could take the work home. Volunteers circulated the room throughout, ensuring no one got stuck, and the atmosphere — equal parts focused and buzzing — was one of the highlights of the day.

“Attended 2 hands-on sessions of UI5con. Volunteers are always ready to help, amazing knowledgeable speakers. Loved the UI5con event.”
Participant, Deloitte

Ask the Expert: The Closing Highlight

The day closed with one of its most anticipated moments: the Ask the Expert panel. Peter Muessig, Vinod S Nair, Stefan Beck and Sandeep R S — some of the most prominent names behind UI5 and SAP Fiori — took to the stage together for an open, free-flowing conversation with the audience. The session was part Q&A, part fireside chat, and completely candid. Attendees asked about the roadmap, the future of legacy migrations, how best to adopt agentic AI in their own teams, and much more. It was exactly the kind of direct access to the people building the platform that makes UI5con special — and a fitting send-off for the day.

The Community Makes the Event

Across the feedback forms, one theme stood out as clearly as the technical content: people valued the community. Volunteers were praised for their patience, speakers for making complex topics accessible, and the hands-on format — with GitHub links, live demos, and side-by-side coding — gave participants something concrete to take home.

Looking Ahead

UI5con Bengaluru 2026 made one thing clear: seven years was too long to wait. The SAP UI5 ecosystem is moving faster than ever, the community is hungry for it, and Devanahalli proved it can host a world-class developer event. Thank you to every speaker, volunteer, and attendee who made this happen. See you at the next one.

"Looking forward for the next iteration of UI5con."
Participant, Volvo

How to Migrate UI5 Projects to the Latest UI5 Best Practices

2026-03-03T14:24:01.693000+01:00

In September 2025, the initial release of UI5 MCP server was published. In Give Your AI Agent Some Tools: Introducing the UI5 MCP Server by @merlin_beutlberger you’ll find a great overview of the available features and a detailed step-by-step guide. This blog post focuses on how UI5 MCP server can support you in migrating your UI5 project easily to the latest best practices with the help of GitHub Copilot Coding Agent. The results are really good.

Prerequisites:

The repository that you'd like to migrate must be hosted on GitHub.
Subscribe to a GitHub Copilot Pro license to use the GitHub Coding Agent feature.

Initial Setup

To use UI5 MCP server in GitHub Copilot Coding Agent, adjust the Coding Agent settings in your repository. Open your repository settings, select the Copilot item, and then select the Coding Agent.

On the right side, there's an empty input area where you enter your MCP configuration. Use a similar configuration to the one you already use in your local VSCode settings.

{
  "mcpServers": {
    "ui5-mcp-server": {
      "type": "stdio",
      "command": "npx",
      "tools": [
        "run_ui5_linter",
        "get_guidelines",
        "get_project_info",
        "get_version_info",
        "get_api_reference",
        "get_typescript_conversion_guidelines"
      ],
      "args": [
        "@ui5/mcp-server"
      ]
    }
  }
}

Important: Don’t forget to press the Save MCP configuration button.

Let’s start

Now your repository is ready. Create a new issue on your GitHub repository (see flovogt/openui5-sample-app #165) with the title "Migrate to latest best practices". You could also be more specific by writing "Migrate to latest UI5 best practices", but if you want to modernize the whole project, choose the more general variant.

After the issue is created, assign the GitHub Copilot user to the issue. Immediately, the Copilot user starts to analyze the issue and creates a draft PR flovogt/openui5-sample-app #166 to resolve the issue.

In the beginning, the PR description contains just a short recap of the issue to be fixed by this PR. However, in the background, the Copilot Coding Agent starts to create a plan to solve the issue. After a few more minutes (approximately two minutes), the PR description is updated with a detailed plan of what the Coding Agent does. UI5 MCP server plays a crucial role here. It uses UI5 linter and dedicated migration guides to make your project compliant with the latest best practices.

After the plan is made, the Coding Agent goes into execution. It commits the results to the corresponding branch and marks the steps as completed in the PR description.

After the job is done, the Coding Agent executes the tests to verify functional correctness. Having high code coverage is key here. Finally, the Coding Agent starts the project, creates a screenshot, and adds it to the PR description, plus summarizing the impact of all the steps.

The overall migration took only a few minutes, and the code quality is really good - at least when I tried it. Don’t blame me if you experience bad code - we're in the world of AI after all 😊 GitHub Copilot Coding Agent and UI5 MCP server work really well together.

JavaScript to TypeScript Migration

Enough of praising the AI. Let’s challenge Copilot and UI5 MCP server even further. You might have already read the blog post UI5 MCP Server's New TypeScript Migration Feature - Real-World Experience and Best Practices by @AndreasKunz. In this case, you're already aware that UI5 MCP server supports such a migration feature. But the overall experience, without checking out any code locally, is just amazing. I created another issue flovogt/openui5-sample-app #167 to ask GitHub Copilot to migrate the whole legacy project to TypeScript and let the Coding Agent do the work in PR flovogt/openui5-sample-app #168.

And the result is awesome! The whole legacy project was migrated to TypeScript in less than half an hour.

Summary

I was really surprised by how well the overall integration of UI5 MCP server works. The whole job would have taken me at least one day to do it right. The agent does most of the work, and I can focus on code review and other tasks still to be done by humans. Welcome to the world of AI, UI5!

SAP Fiori Elements: New Documentation Structure

2026-03-09T13:58:34.080000+01:00

We're excited to announce a complete restructure of the SAP Fiori elements documentation. We now provide separate entry points for OData V4 and OData V2, making it easier to navigate their different feature sets. The new structure reflects our focus on SAP Fiori elements for OData V4 and its building blocks, and it is aligned with the SAP Fiori development portal to ensure a consistent user experience.

Separation of OData V4 and V2 Documentation

Separated entry points for OData V4 and OData V2 make it easier to find your way around our many features. After choosing the right entry point, you can be sure that all the information you see is relevant to the version you use.

For OData V4, the revised documentation structure is centered around our building blocks. All related features are now placed together, reducing browsing time and helping you find what you need faster.

For OData V2, we've kept the documentation structure unchanged to ensure stability for our customers. You'll still find all topics exactly where you expect them. And while our focus going forward is on V4, we continue to support and update the V2 documentation as well.

Focus on Building Blocks at the Core

The new documentation structure organizes topics around building blocks, which are the foundation of both floorplans and custom pages.

You may notice that some features can be consumed in different ways depending on your context:

When a building block is used within a standard floorplan, you typically configure its features through annotations or manifest settings.
When the same building block is used on a custom page, you control its features through the properties and methods it exposes.

Our documentation highlights these differences with clear notes, helping you choose the right approach for your use case.

Harmonization Between Documentation & SAP Fiori Development Portal

The SAP Fiori development portal is our one-stop resource designed to help all project team members – from developers to business analysts – explore options, collaborate, and make informed decisions when building SAP Fiori apps. It supports the metadata-driven approach of SAP Fiori elements for OData V4, which offers two flexible paths:

Custom layouts using reusable building blocks, or
Standard floorplans for rapid development.

Both paths deliver consistent, enterprise-ready applications that follow the SAP Design System guidelines, ensuring harmonized user experience while allowing for configuration when needed.

You can immediately see the harmonization between the structure of the SAP Fiori development portal and our new documentation structure:

Ongoing Enhancements to Content

We’re continuously enhancing our documentation – not only with new features, but also by enriching the content with cross-references, linking related topics, and connecting you to relevant resources.

We also listen to your feedback, so please continue to provide us with ideas about how to further improve our content!

SAP Fiori Development newsletter issue #39 (March 2026)

2026-03-10T15:31:16.369000+01:00

As we get into the rhythm of 2026, it seems that AI is addressing more coding use cases than even a few months ago. This will be on full display at UI5con, where AI topics will likely comprise a higher percentage of the sessions than last year. Learn more about UI5con at https://openui5.org/ui5con/faq.html, including how to attend, sponsor, or propose a topic for a session.

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

Development News

Mastering filtering and search capabilities in SAP Fiori elements for OData V4

The filter bar is the primary component for data filtering in SAP Fiori elements applications. It appears at the top of list report page applications and provides users with an intuitive interface to narrow down large datasets. This article discusses search capability, support for the Clear button, custom filters, and of course, how the filter bar can leverage AI capabilities. Learn more.

Getting past the limitations of using AI for code generation

Dirk Roeckmann shares his perspectives on coding with AI agents based on transformer models. He starts with why he uses AI and then shares some limitations of AI models and how to get around these pitfalls. Read his insights.

UI5 MCP server in The Open Source Way podcast

This episode covers the intricacies of the Model Context Protocol (MCP) within the SAP ecosystem, a pivotal component designed to offer domain expertise to LLMs. Join Tim Back and Florian Vogt as we unpack the role and significance of MCP in the SAP ecosystem in the world of AI. (UI5 MCP server blog post, GitHub)

Spotify: UI5 & MCP - Navigating the Model Context Protocol in SAP
Apple Podcast: UI5 & MCP - Navigating the Model Context Protocol in SAP

UI5 MCP server extended for UI Integration Cards generation

The UI5 MCP Server now supports the development of UI Integration Cards. It includes three new tools to assist Large Language Models (LLMs) in creating new cards from scratch or editing existing ones, following the best practices for card development. See details.

Configure Your SAP Fiori Elements Apps: Introducing Fine-Tuning in the SAP Fiori Development Portal

Annotations in SAP Fiori elements applications define what data to display, how to structure it, and which features to enable. However, not every UI behavior can or should be controlled through annotations. Some aspects require configuration settings that fine-tune how building blocks render and behave. Learn more.

New geomap control for your SAPUI5 app

A new control in the MDC library has been released. It is displaying interactive maps — visualizing GeoJSON data, integrating vector and raster tiles from various providers, enabling features like clustering and selection, or handling user interaction — sap.ui.mdc.Geomap offers a native UI5 interface to Geomaps. See details.

Events

SAP UX Innovation Day

We are planning more SAP UX Innovation Days in 2026. This name replaces the SAP Fiori Innovation Day brand we used in 2024 and 2025. Watch your inbox for announcements about where and when we will be hosting these events. Most will occur in the fall, both before and after SAP TechEd.

New Customer Engagement Initiative (CEI project): "Customize SAPUI5 apps for business users" Provide feedback on new and planned features in SAPUI5 flexibility - Key user adaptation: Register here.

Back issues from the past year

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)

SAP FIori development newsletter May 2025 (Issue #34)

SAP Fiori development newsletter March 2025 (Issue #33)

Key User Adaptation: Powerful New Features & Seamless Transition to Developer Extensibility

2026-03-17T08:11:34.257000+01:00

With key user adaptation, you can change the user interface of SAP Fiori apps directly in the Fiori launchpad — intuitively and without having to write new code. The changes are upgrade-safe adaptations to SAP Fiori apps. Key users can open the UI Adaptation mode for a Fiori app directly from their user menu in the Fiori launchpad (menu entry Adapt UI).

A key user is a business expert who is authorized to make changes on behalf of other users — for example a team member who is interested in technology. The goal of key user extensibility is to empower business users to be able to adapt their working environment to suit their needs, without having to rely on system administrators.

What can key users change with key user adaptation?

Key users can perform the following changes in Fiori apps based on SAP Fiori elements:

Hide/show the information that shall be visible in the object page header
Hide/show tabs, sections, tables, or action buttons on the object page
Define the fields visible in forms on the object page
Set the configuration for tables (select all, selection mode, thresholds, view settings, export, etc.)
Set the configuration for the filter bar (clear button, usage of the semantic date range control)
Set the configuration for the complete list report / object page (variant management, initial load)
Change Text Arrangement (ID only, Text first, Text last, Text only)
Change Labels (global label changes)
Rename (only for a dedicated field – applies only locally to a form field)
Define the fields visible in the mass edit dialog. In the key user adaptation mode, all fields except static read-only fields are available.
And more

The scope was continuously enhanced. The bold items above are extremely powerful new features available since S/4HANA Cloud Public Edition 2508 / S/4HANA Cloud Private Edition 2025 / On-Premise 2025. They are described in detail in the following sections.

New feature: configuration for tables

The Configuration functionality is available in key user adaptation mode when the context menu entry Configuration is selected on a table, on the filter bar, or on page level. The context menu on a table contains — for example in Fiori elements V4 — the following entries:

Among other things, the following settings can be configured here:

Enable Table Export — configures whether the Export button is displayed in the table.
Frozen Column Count — configures the count of columns that are always visible when scrolling horizontally.
Personalization — configures whether the table personalization settings are enabled. To configure the listed settings individually, choose Own Settings.
Row Count — configures the number of rows to be displayed in the table.
Width Including Column Header — configures whether the column header label is considered when calculating the column width.
Enable Select All — configures whether the Select All option is displayed in the table.
Selection Limit — configures the maximum limit of the number of rows that can be selected at once (e.g., by using Select All).
Threshold — determines the maximum number of entries loaded when the application is started. Scroll Threshold determines the maximum number loaded during scrolling if new entries need to be fetched. Increasing these settings will lead to an increased initial load time but deliver a smoother scroll experience.

Note: Not all settings listed above are available for all table types and page types. Furthermore, there are differences between Fiori elements V2 and Fiori elements V4 (Fiori elements V2 offers fewer settings).

Example – List Report Grid Table in Fiori elements V4:

New feature: configuration for the filter bar

The Configuration context menu entry on the filter bar opens settings for the filter bar. Among other things, the following settings can be configured here:

Display Clear Button — configures whether the Clear button is displayed in the filter bar.
Enable Semantic Date Range menu options — configures that single date range filters offer semantic operators (like "Today", "This Month", "Last Year").

Example – List Report Filter Bar in Fiori elements V4:

New feature: configuration for the complete list report / object page

The Configuration context menu entry at page level opens settings for the entire List Report or Object Page. Among other things, the following settings can be configured here:

Variant Management (Table Variant Management) — configures how variant management is used on the List Report page or in tables on the Object Page.
Initial Load — configures how data is loaded initially when the app is opened.

Example – List Report in Fiori elements V4:

New feature: change text arrangement

The Change Text Arrangement functionality is available in key user adaptation mode when the context menu entry Change Text Arrangement is selected on a table, on the filter bar, or on a form.

This powerful new functionality allows changing centrally the text arrangement for all relevant fields in a Fiori app. A key user can decide for each field whether it shall be shown as:

Option	Example (Company Code "0001" / "SAP AG")
ID only	0001
Text only	SAP AG
Text first	SAP AG (0001)
Text last	0001 (SAP AG)

Note: These changes are independent of specific controls. You change the text arrangement for the underlying OData property. If a specific field or control does not use the text arrangement from the OData property, the changes will not be applied to that control.

New feature: change labels

The Change Labels functionality is available in key user adaptation mode when the context menu entry Change Labels is selected on a table, on the filter bar, or on a form.

This allows changing the labels centrally for all relevant fields in a Fiori app: if an identical label is available in the filter bar, in tables, forms, and charts of a Fiori application, then all places are changed consistently. This is the key difference from the existing Rename feature, which only applies locally to a form field.

Example: You can consistently change the text "Material" to "Product" across your entire Fiori app.

Note: These changes are independent of specific controls. You change the label for the underlying OData property. If a specific field or control does not use the text from the OData property, the changes will not be applied to that control.

Need more complex changes? Seamless Transition from Key User to Developer Extensibility.

If you need to make more complex changes — for example, adding fragments to visualize data as a chart, changing a responsive table to a grid table, or making the app available to different business roles, user groups, organizational units, and countries — you can extend an application by creating an SAPUI5 Adaptation Project (developer adaptation).

When creating an SAPUI5 Adaptation Project, you can select the brand-new option Import Key User Changes (available since S/4HANA Cloud Public Edition 2602; not yet available for S/4HANA Private Cloud / On-Premise) to import all key user changes made so far. This means key user changes will not be lost — they become part of the new SAPUI5 Adaptation Project.

For an introduction to Adaptation Projects, see Work with SAPUI5 Adaptation Projects to Make Changes and Extend the Source Code of an Application Variant of an SAP Fiori Application in SAP S/4HANA Cloud Public Edition.

For more detailed information, see Extending SAP Fiori Applications.

Prerequisites

Public Cloud:

The IAM app F5933_LRST_TRAN provides the relevant authorizations. It is included in the business catalog SAP_CORE_BC_EXT_FLX_CUS_PC (see Adapting SAP Fiori UIs at Runtime - Key User Adaptation).

Private Cloud / On-Premise:

Your administrator assigned you to the authorization role SAP_UI_FLEX_KEY_USER (see Enabling Key User Adaptation).

General requirements:

You run your SAPUI5 app on a desktop computer or laptop.
Your app is enabled for key user adaptation.
A minimum screen size of 800×600 is required for key user adaptation. Anything smaller can affect the toolbar elements, causing them to overlap.

Tips for Key User Adaptation for Fiori Apps in SAP S/4HANA

Where do I make Key User changes?

Key users typically make changes in the Development environment.

How do I transport Key User changes?

Active changes must be published to make them ready for transport.
To publish your changes for transport, you must be assigned a transport request by your technical team.
Your technical team manages the transports through to your Production environment.

Key takeaways

Key User Adaptation lets you make common changes to SAP Fiori apps directly in the Fiori Launchpad — no developer knowledge required.
Key User Adaptation is now extremely powerful with new options for:

Configuring important UI elements (tables, filter bar, complete list report / object page)
Changing the text arrangement of fields
Changing labels globally across an entire Fiori app

Changes are made in the Development environment and published for transport.
Published changes can be transported to other environments by your technical team.
Key User Adaptation changes can be imported when creating an SAPUI5 Adaptation Project for more complex changes (S/4HANA Public Cloud 2602+). This allows a seamless transition from key user to developer extensibility.

Where can I learn more about Key User Adaptation for Fiori Apps in SAP S/4HANA?

SAP Help – Key User Adaptation (S/4HANA Cloud Public Edition): Adapting SAP Fiori UIs at Runtime – Key User Adaptation
SAP Help – Key User Adaptation (S/4HANA Cloud Private Edition and On-Premise): Adapting SAP Fiori UIs at Runtime – Key User Adaptation
SAP Learning – Tutorials: Key User Adaptation for SAPUI5 Applications
SAP Help – SAP Fiori elements V4: Extending Delivered Apps With Key User Adaptation
SAP Help – SAP Fiori elements V2: Adapting the UI

Building a Scalable Micro-Frontend Dashboard with SAPUI5 Integration Cards

2026-03-17T10:56:08.588000+01:00

Introduction

Building an enterprise-grade analytics dashboard is challenging. When you add requirements like multi-team development, independent deployment cycles, and the need for extensibility, traditional monolithic approaches quickly become unmanageable.

This article shares our proposal building the Performance Dashboard at SAP—a micro-frontend architecture that supports dozens of independent KPI widgets, dynamic filtering, cross-widget interactions, and continuous deployment—all while maintaining team autonomy and code quality.

This article shares practical patterns for building a micro-frontend dashboard architecture that supports:

Dozens of independent KPI widgets
Dynamic filtering across all widgets
Cross-widget interactions
Continuous deployment with team autonomy

Whether you're building analytics dashboards, composable UIs, or exploring micro-frontend patterns, this deep-dive offers practical insights backed by real-world architectural decisions.

The Challenge: Complex Dashboard, Multiple Teams

An enterprise analytics dashboard that provides managers with real-time visibility into business metrics across multiple dimensions:

Requirements:

40+ KPI widgets across multiple views × multiple dimensions
Multiple teams developing widgets independently
Continuous deployment without blocking other teams
Dynamic filters affecting all widgets simultaneously
Cross-filtering when users click chart segments
Grid customization (drag-drop, resize, hide/show)

Why Traditional Approaches Fail:

Monolithic SPA: Every widget change requires full redeployment
Tight coupling: One broken widget blocks entire dashboard
Single pipeline: Multiple teams competing for deployment window

We needed true micro-frontend architecture.

Architecture Decision 1: Repository Structure

The Question

Should the dashboard shell and KPI widgets live in one repository or separate repositories?

Option A: Monorepo

analytics-dashboard/          ← Single repo
├── dashboard-shell/
│   ├── webapp/
│   └── ui5.yaml
└── widgets/
    ├── widget-a/
    ├── widget-b/
    └── ...

Pros: Simple setup, single CI/CD pipeline
Cons: Deployment coupling, merge conflicts, repository grows massive

Option B: Two Repositories - Selected

dashboard-shell/           ← Repo 1: Orchestration layer
├── webapp/
│   ├── config/layout.json
│   ├── controller/Dashboard.controller.ts
│   ├── model/LayoutManager.ts
│   └── view/Dashboard.view.xml

widget-registry/          ← Repo 2: All widgets
├── widgets/
│   ├── widget-a/
│   ├── widget-b/
│   └── ...
├── registry-service/
│   └── widget-registry.json
└── build.sh

Contract Between Repositories: Repository Exposes Consumes

Repository

Exposes

Consumes

widget-registry

GET /api/widget-registry

GET /[widgetName]/*

dashboard-shell

Discovers widgets

Loads assets dynamically

Why We Chose Two Repositories:

Independent deployment cycles:

Dashboard updates don't require widget releases
Widget teams deploy on their own schedule
Broken widget doesn't block dashboard

Clear ownership boundaries

Dashboard team owns orchestration
Widget teams own visualizations
Contract enforces decoupling

Scalable CI/CD

Two focused pipelines vs one massive pipeline
Faster builds (only changed repo rebuilds)
Parallel development without conflicts

Trade-off: Slightly more complex integration testing, but worth it for deployment flexibility.

Architecture Decision 2: Integration Strategy

The Question

How should the dashboard load and render independent widgets at runtime?

Evaluated Options

Option A: Iframe-Based

<iframe src="https://widgets.example.com/widget-a"></iframe>

Pros:Complete isolation
Cons: Performance overhead, difficult communication, styling inconsistency, accessibility issues

Option B: Native Web Components

customElements.define('analytics-widget', class extends HTMLElement {});

Pros: Browser-native, framework-agnostic
Cons: No SAPUI5 features, reinvent data binding/routing/i18n, steep learning curve

Option C: UI5 Components

import Component from "sap/ui/core/Component";

const oComponent = await Component.create({ name: "com.example.widget" });

Pros: Full SAPUI5 capabilities
Cons: Complex lifecycle management, no standard metadata format

Option D : UI5 Integration Cards - Selected

Manifest-based configuration:

{
    "sap.app": {
        "id": "com.example.ordervalue",
        "type": "card"
    },
    "sap.card": {
        "type": "Component",
        "header": {
            "title": "Order Value at Risk"
        },
        "content": {
            "componentName": "com.example.ordervalue"
        }
    }
}

Dashboard loads dynamically:

import Card from "sap/ui/integration/widgets/Card";

const oCard = new Card({
    manifest: "https://widgets.example.com/kpi-widget1/manifest.json",
    baseUrl: "https://widgets.example.com/kpi-widget1"
});
oCard.placeAt("container");

Why Integration Cards:

Standardized format - Official SAPUI5 specification

Support Two card types:

Component cards: Full custom code for complex widgets
Declarative cards: Manifest-only (List, Table, Analytical, ...)

Built-in features: Headers, data binding, actions, error handling

Parameter passing: card.setParameters() with auto-refresh

Framework alignment: Native SAPUI5, team expertise, Fiori guidelines

Architecture Decision 3: Communication Patterns

The Challenge: Bidirectional Communication

Two-way communication required:

Dashboard → Widgets: Apply filters to all widgets
Widgets → Dashboard: Handle user clicks (cross-filtering, navigation)

Evaluated Patterns

Pattern 1: Pure EventBus

import EventBus from "sap/ui/core/EventBus";

// SAP UI5 EventBus (pub/sub communication)
const eventBus = EventBus.getInstance();

eventBus.publish("filters", "changed", {
  timeRange: "last7days" // For example
});

Pros: Loose coupling
Cons: State scattered in events

Pattern 2: State-Driven Reactive

import JSONModel from "sap/ui/model/json/JSONModel";

// SAP UI5 JSON Model (client-side state)
const filterModel = new JSONModel({
  timeRange: "last7days"
});

Pros: Single source of truth
Cons: Integration Cards don't support reactive binding

Pattern 3: Host-Controlled

import Card from "sap/ui/integration/widgets/Card";

// SAP UI5 Integration Cards - trigger data refresh
cards.forEach((card) => card.refresh());

Pros: Centralized control
Cons: Tight coupling

Our Solution: Hybrid EventBus + State-Driven

Best of both worlds:

import JSONModel from "sap/ui/model/json/JSONModel";
import EventBus from "sap/ui/core/EventBus";

// SAP UI5 EventBus instance
const eventBus = EventBus.getInstance();

/**
 * 1. Centralized State (Single Source of Truth)
 * Shared JSONModel for filter state across the application
 */
const filterModel = new JSONModel({
  timeRange: null,
  category: [],
  status: []
});

this.getView().setModel(filterModel, "filters");


/**
 * 2. FilterBar → Update State + Publish Event
 */
onSearch() {
  const filters = this.getFilterValues();

  // Update centralized state
  this.getModel("filters").setData(filters);

  // Notify other components (no payload coupling)
  eventBus.publish("app.filters", "changed", {
    timestamp: new Date().toISOString()
  });
}


/**
 * 3. Dashboard → React to State Change
 */
onFiltersChanged() {

  // Always read from centralized state (source of truth)
  const filters = this.getModel("filters").getData();

  // Update all Integration Cards (widgets)
  this._cards.forEach((card) => {
    card.setParameters(filters);
    card.refresh(); // triggers data re-fetch + re-render
  });
}

Pros:

Single Source of Truth: Centralized filter state

Explicit Notifications: EventBus for change observation

Universal Support: Works with Component and Declarative cards

Debuggable: Inspect model state + trace events

Testable: Mock state and events independently

Widget-to-Dashboard Communication

Widgets fire action events on user interaction

{
  "sap.card": {
    "type": "List",
    "content": {
      "item": {
        "title": "{name}",
        "actions": [
          {
            "type": "Custom",
            "parameters": {
              "action": "viewDetails",
              "id": "{id}",
              "name": "{name}"
            }
          }
        ]
      }
    }
  }
}

Host (Dashboard) handle it

oCard.attachAction((oEvent) => {
  const action = oEvent.getParameter("action");
  const params = oEvent.getParameter("parameters");

  if (action === "Custom" && params.action === "viewDetails") {
    // handle widget interaction
    console.log("Item clicked:", params);

    eventBus.publish("widget.item", "selected", params);
  }
});

Flow:

User clicks item in widget
Widget fires action event
Dashboard receives event
Dashboard updates filter state
Dashboard publishes filter change
All widgets refresh with new filter

Lessons Learned

What Worked Well

Two-repository approach

True team independence
No merge conflicts

Deploy anytime without coordination

SAPUI5 Integration Cards

Standardized pattern
Supports Component and Declarative types
Built-in features reduce boilerplate

Hybrid communication

Centralized state = single source of truth
EventBus = loose coupling
Works with all card types

Contract-based development

Registry acts as interface definition
Tags enable dynamic filtering
Clear responsibilities

Results & Key Takeaways

Achieved:

40+ widgets by 10+ teams
Independent deployment cycles
Zero downtime deployments

Key Insights:

Micro-frontends are organizational—they're about team autonomy and deployment independence, not just technology.
Match patterns to constraints—we chose Integration Cards because teams knew UI5, not because it's universally "best."
Centralize wisely—filters are centralized (single source of truth), implementation is distributed (team autonomy).
Contracts are your API—treat the widget registry with the same rigor as REST APIs.

Resources

SAPUI5 Documentation:

Micro-frontend Patterns:

Micro Frontends by Martin Fowler

Running Hugging Face AI Models with SAPUI5 and CAPM

2026-03-19T15:59:27.461000+01:00

Hi everyone !

After spending several hours researching and experimenting, I finally found a simple way to answer a question that many SAP developers have started asking:

“Is it possible to run AI models inside SAP applications using SAPUI5 and CAPM?”

The short answer is:

Yes, absolutely!

In this blog, I will share how we can integrate Hugging Face AI models with SAPUI5 and CAPM, and how we can build a simple AI-powered application that can generate text responses and even images.

First Question: What is Hugging Face?

If you are new to AI development, you might wonder:

What exactly is Hugging Face?

Think of Hugging Face as GitHub for AI models.

It is a platform where developers and researchers publish and share machine learning models.

Currently, Hugging Face provides access to hundreds of thousands of AI models that can perform tasks such as:

Text generation
Chatbots
Image generation
Speech recognition
Translation
Code generation

The best part is that you can use these models directly through APIs without training your own model.

Another great advantage is that Hugging Face provides GPU infrastructure, which means you can run advanced models without owning expensive hardware.

And yes — if you build your own model, you can also publish it on Hugging Face and make it available globally.

Fig 1.1 Hugging Face Models sections

Now the Interesting Part: Can SAPUI5 Use AI?

When I started this experiment, my first question was:

Can SAPUI5 directly call an AI model?

The answer is yes, especially for text generation models.

To make this work, we only need three things:

- A Hugging Face account
- An HF API Token
- A model endpoint

Once you log in to Hugging Face, you can generate an HF Token from your account settings.

Then you can choose any model depending on your use case. Hugging Face provides model benchmarks and descriptions, so you can easily decide which one is best for:

Education
Coding
Reasoning
Chat
Content generation

Connecting Hugging Face with SAPUI5

Now let's talk about the implementation.

In the SAPUI5 controller, we can send a request to the Hugging Face API using JavaScript fetch().

The UI simply takes a user prompt, sends it to the AI model, and displays the response.

Example flow:

User enters a prompt:

"What is Hugging Face and SAPUI5?"

SAPUI5 sends the prompt to the Hugging Face model.

The model generates a response and returns it.

Then SAPUI5 displays the result directly on the UI.

This makes it very easy to build AI chat assistants inside SAP applications.

Fig 1.2 Output- Hugging Face Ai Chat

Sample Code:

Fig 1.3 sapui5 Controller.js - Hugging Face Ai Chat

Fig 1.3 sapui5 view.xml - Hugging Face Ai Chat

But What About Image Generation?

This is where things become interesting.

When I tried running image generation models directly in SAPUI5, I realized something important.

⚠️SAPUI5 works best with text-based AI APIs.

For image generation models, we need a backend service.

This is where CAPM (Cloud Application Programming Model) becomes very useful.

Using CAPM for Image Generation

To generate images, we can integrate fal.ai, which provides inference APIs for advanced image generation models.

Some examples include:

black-forest-labs / FLUX.1-dev
Tongyi-MAI / Z-Image-Turbo

These models can generate high-quality AI images from text prompts.

For example:

"Portrait of a futuristic astronaut with glowing blue eyes"

The system sends this prompt to the AI model, and the model generates an image.

How CAPM Handles This

Inside the CAPM Node.js service, we create a custom action such as:

"generateImage"

This action receives the prompt from SAPUI5.

Then CAPM calls the fal.ai API with that prompt.

The AI model generates the image and returns a URL of the generated image, which we send back to the UI.

This makes CAPM act as a bridge between SAPUI5 and AI models.

Why Use fal.ai Instead of Hugging Face Directly?

You might ask:

If we already use Hugging Face, why do we need fal.ai?

Good question.

Some models listed on Hugging Face are actually hosted through different inference providers, including fal.ai.

For example:

black-forest-labs / FLUX.1-dev

This model is often executed through fal.ai inference APIs.

So fal.ai becomes an easy way to run those models with strong GPU performance.

Sample Code:

Fig 1.4 Output – CAPM - Hugging face Image generation

Fig 1.5 service.js - first half- Hugging face Image generation

Fig 1.6 service.js - second half - Hugging face Image generation

Fig 1.7 Fal.ai API key Generation - Hugging face Image generation

Final Result

After connecting everything together, we get a simple AI application:

The application can:

- Generate AI text responses using SAPUI5
- Generate AI images using CAPM services
- Use Hugging Face models
- Run without training your own model

All of this can be done using free developer APIs, unless you need large-scale GPU workloads.

Conclusion

From this experiment, we can see that SAP applications can easily integrate with modern AI platforms.

The architecture becomes very simple:

SAPUI5
⬇
CAPM Service
⬇
Hugging Face / fal.ai AI Models

Using this approach, developers can build powerful applications such as:

AI chat assistants inside SAP
AI-powered knowledge systems
Image generation tools
Smart enterprise automation

And the best part is that you can even deploy your own AI model on Hugging Face and use it inside SAP applications.

I hope this small experiment helps other developers who are curious about AI + SAP integration.

Happy coding!

SAP User Experience Q1/2026 Update – Part 9: UI Design and Technology for Web and Mobile

2026-03-23T09:53:54.363000+01:00

This ninth and last post in my series gives an overview innovations in our UI tools and technologies, making it ever easier to design, build and integrate UIs, for both web and mobile applications. For designing apps, web and mobile, we have added AI content and more to the SAP Design System portal and UI Kits in Figma. For web developers, we have introduced the SAP Fiori development portal, as well as more AI support via MCP servers for SAPUI5 and for SAP Fiori elements, and Joule integration. Beyond that: have a look at how you can use AI to migrate to TypeScript, learn about the new Geomap control, and benefit from the new SAPUI5 runtime repository. Finally, discover the latest updates for mobile design and development with our SDKs and the mobile development kit.

Joule can also be seen as a technology for delivering a great user experience. To find out about recent innovations there, as well as for central entry points and services, have a look at this post, which also contains links to all the other parts of the series:

SAP UX Q3/2025 Update – Part 1: AI, Joule, SAP Build Work Zone, SAP Mobile Start.

In case you missed them, do have a look at my previous posts covering design and technology news, since what I mention here builds partly on what came before:

SAP User Experience Q1/2025 Update – Part 7: UI Design and Technology for Web and Mobile. This post has a lot of information about extensibility, especially for SAP S/4HANA Cloud Public Edition. Do also have a look at the new SAP Extensibility Explorer.
SAP UX Q3/2025 Update – Part 7: UI Design and Technology for Web and Mobile.

First, we’ll have a look at news for creating web UIs, before looking at what’s new for mobile design and development.

News for Creating Web UIs

I’ve compiled the news into these sections:

SAP Design System Portal and UI Kits – now with AI UI Elements.
SAP Fiori Development Portal.
Using AI to Develop UIs – MCP Servers, Joule.
SAP Fiori Tools News.

SAP Design System Portal and UI Kits – now with AI UI Elements

We recently introduced the new SAP Design System portal that brings together the product design guidelines SAP Fiori for web, SAP Fiori for iOS, and SAP Fiori for Android, as well as to the new digital design system guidelines. With its enhanced usability, simplified versioning and improved performance, designers (and developers!) get a better user experience compared with the previous SAP Fiori design guidelines.

End of last year we introduced these AI UI elements for web UIs, as you can see in Figure 1 below:

AI Acknowledgement.
AI Button.
AI Writing Assistant.

Figure 1: AI UI elements available in SAP Design System portal. Alt Text: Screenshot of the portal UI Elements page with a filter at the top containing “AI”, below that “3 results” showing three cards in a horizontal row for “AI Acknowledgement”, “AI Button” and “AI Writing Assistant”.

Get a complete overview of what’s new in the design system portal here

What’s New in the SAP Design System Portal?

UI Kits v8.0 and v9.0 – now with AI components

The new UI Kits available for designers in Figma make it easy for designers to design accessible UIs at enterprise scale, for web applications, mobile iOS and Android applications as well as wearables. The UI Kits provide reusable components for web and mobile, along with web floorplans, which give you what you need out-of-the-box.

In the meantime, we have released SAP Web UI Kit v8.0 which includes a full set of AI components: AI Button, AI Menu Button, AI Split Menu Button, AI Input, and AI Text Area.

The latest release, SAP Web UI Kit v9.0, continues to evolve the system with focused improvements that enhance visual quality, usability, and overall consistency across the kit. It brings:

Updated Icons:
All icons have been refreshed with a 1.5px stroke (down from 1.6px). This improves anti-aliasing and results in cleaner, sharper visuals across interfaces.
Busy Indicator Enhancements:
You now have two Busy Indicator options, static and animated, available on the same page. The new animated version is ready to use out of the box, saving time and implementation effort.
Redesigned Color Palette. Note that the previous color palette component has been removed in order to avoid confusion, and keep the kit cleaner and easier to navigate.

Find out more here:

New SAP Design System Portal for SAP Fiori Design Guidelines, and New UI Kits for Designers.

SAP Fiori Development Portal

I’m also happy to inform you about the new SAP Fiori development portal. It is designed to help developers maximize the benefits of SAP Fiori elements for OData V4, which is more than just a UI framework: it’s a metadata-driven approach that leverages the SAP Design System as its guiding principle, incorporating the most relevant design system options for typical business tasks.

Figure 2: The SAP Fiori development portal. Alt text: A screenshot showing the Introduction page. On the left a menu has entries Using the Portal, Building Blocks, Global Patterns, Floorplans, SAP Fiori Tools. The Introduction page has a full width card “Building Blocks” at the top, with a description and tiles representing various building blocks. Below that “Choose Your Option” heading above two side-by-side cards for “Floorplans” and “Customer Layout”, each with an image and description, and a “Learn More” button.

The SAP Fiori development portal puts building blocks front and center. These building blocks - such as tables, forms, filter bars, and charts - are orchestrated by SAP Fiori elements and form the basis of every OData V4 application. They provide standardized layouts and interaction patterns, ensuring UI consistency and boosting developer productivity. The great advantage of using building blocks is that you can use them to create a customer layout and yet still benefit from the advantages of the metadata driven approach: low code, built in enterprise-grade capabilities such as multi-language support, accessibility, security and performance, and design system consistency.

Find out more in this six-part series of blog posts, here is the first one, which contains links to the others:

Introducing the SAP Fiori Development Portal: Your Gateway to Rapid SAP Fiori App Creation (1 of 6).

We have also restructured our documentation for SAP Fiori elements, with separate entry points for OData V4 and OData V2, and better supporting the building block approach. Read more here:

SAP Fiori Elements: New Documentation Structure.

Using AI to Develop UIs – MCP Servers, Joule

The above posts from Q1/2025 and Q3/2025 introduced a number of powerful ways to accelerate UI development by using AI, such as:

Creating SAP Fiori elements apps from a sketch (in the Q1 post), now integrated in SAP Build Code and Joule (Q3 post)
Joule for SAPUI5 freestyle development (Q1 post)
AI-assisted auto-fix of coding errors with UI5 linter (Q3 post)

Recently, we have gone even further and introduced MCP servers for freestyle SAPUI5 development as well as for developing with SAP Fiori elements and the associated building blocks. These open-source Model Context Protocol (MCP) servers provide AI agents with comprehensive UI5 and SAP Fiori elements knowledge, including best practices and project-aware context information, and thus provide developers with valuable support. Figure 3 shows examples.

Figure 3: Examples of the UI5 MCP Server (on the left) and the MCP Server for SAP Fiori (on the right) in action. Alt Text: both images show screenshots of a CLINE console view with a task entered as text at the top, followed by a list of steps which the system proposes to do to solve the task.

Read about these new MCP servers in these blog posts:

Alternatively, you can listen to these podcasts involving Tim Back and Florian Vogt, talking about the intricacies of the Model Context Protocol (MCP) within the SAP ecosystem:

Spotify: UI5 & MCP - Navigating the Model Context Protocol in SAP.
Apple Podcast: UI5 & MCP - Navigating the Model Context Protocol in SAP.

Latest UI5 MCP Server Enhancements

The UI5 MCP server got extended to help migrate existing JavaScript code to TypeScript, as well as for generating UI Integration Cards.

New TypeScript Migration Feature

With the newest feature of the UI5 MCP server, UI5-specific TypeScript conversion assistance is now available to AI coding agents, making the task much easier. Find out more in this blog post:

UI5 MCP Server's New TypeScript Migration Feature - Real-World Experience and Best Practices

Generating UI Integration Cards

The UI5 MCP Server now supports the development of UI Integration Cards. In its latest version – v0.2.1 – it includes three new tools dedicated to UI Integration Cards:

Best practice guidance for your agent.
Scaffolding a new Integration Card.
Validating the Card’s manifest.

These tools assist Large Language Models (LLMs) in creating new cards from scratch or editing existing ones, following the best practices for card development. Find out more here:

UI5 MCP Server Got Extended for UI Integration Cards Generation.

AI News for SAP Fiori Tools and MCP Server for SAP Fiori

The Project Accelerator can now be launched directly from the SAP Fiori generator, streamlining the initial project creation flow. The previously required staging step has been removed, allowing new projects to be created directly in the selected workspace folder. For projects created using the Project Accelerator, the Application Modeler now offers advanced editing capabilities, such as creating new fields and properties end-to-end, updating the data model, exposing the service, and consuming the changes in the UI in one coherent flow.

AI support has also been extended to mock data generation. Developers can generate realistic mock data using AI directly in the Application Modeler, and this capability is available for all applications whenever the Project Accelerator is enabled.

In parallel, the MCP server for SAP Fiori continues to expand. The server now exposes @sap-ux/create commands as CLI functionality, enabling reliable execution in MCP-supported workflows. App generation has been extended to support CAP Java projects, and a new “search_docs” tool allows the LLM (Large Language Model) to query SAP Fiori elements documentation, annotations, SAP Fiori tools documentation, and SAP Fiori Development Portal resources to quickly find relevant guidance and code snippets.

Joule Enhancement: Create Freestyle SAPUI5 Apps in SAP Build Code

You can now use Joule in SAP Build Code to create new freestyle SAPUI5 apps according to your requirements. The feature is not absolutely groundbreaking, as there are other tools doing a similar job like the Easy-UI5 templates and the recently published UI5 MCP Server. But:

It brings the functionality right to the fingertips of developers using SAP Build Code – no other tools needed.
It extends the template capabilities beyond what the Easy-UI5 templates provide.
Implementing it within the Build Code Joule environment yielded interesting insights and further improvements.

Find out more about the feature, and in the second “making of” post, read about how Andreas Kunz went about building it, and what he learnt from doing it:

SAP Fiori Tools News

In addition to the AI-enhancements mentioned above, we now provide expanded support for SAP Fiori elements building blocks, a new connection manager for SAP Systems in VS Code, and a feature to preview SAP Fiori web apps on mobile devices.

Expanded Support for SAP Fiori Elements Building Blocks

The following enhancements make it easier to adapt applications and allow developers to work more confidently and efficiently with SAP Fiori elements–based UIs.

Developers can now add more building block types to their apps with the Page Editor, including

rich text editors within custom sections,
custom columns for table building blocks, and
the page building block itself.

Managing custom pages is also more intuitive, as building blocks can now be deleted directly from the editor.

To support experimentation and iteration, undo and redo actions are now available when working on custom pages.

New Connection Manager for SAP Systems in VS Code

We have introduced the Connection Manager for SAP Systems as a dedicated Visual Studio Code extension for managing connections to remote SAP systems. The Connection Manager allows developers to create, store, test, and edit connection information that can be reused by the SAP Fiori generator as well as by preview features in SAP Fiori tools.

Preview SAP Fiori Web Apps on Mobile

When developing SAP Fiori applications, simulating a mobile experience in a desktop browser often isn’t enough to fully validate real-world behavior. Touch interactions, performance characteristics, and device-specific rendering can differ noticeably on physical phones and tablets.

To address this, SAP Fiori tools now supports previewing applications directly on real mobile devices. You do this by using @sap/ux-ui5-tooling version 1.19.1 or higher and creating a new run configuration and enabling Remote Access. When you start the run configuration, the terminal provides connection details, including a URL and a QR code, which can be opened directly on a phone or tablet to access the running app.

Find out more here:

News for Mobile Designers and Developers

Let’s first look at updates in the design guidelines and the SDKs, and then look at news for the mobile development kit (MDK).

Mobile Design Guideline and SDK Updates

We have introduced numerous new and enhanced patterns and components this last half-year. I have selected a small number to highlight here, further below you’ll find links to get the full overview.

New for AI

The following two new patterns have been introduced for both the SAP Fiori for Android and the SAP Fiori for iOS design guidelines.

AI Insights Pattern: We have introduced a new AI Insights Pattern, which describes how to present AI insights optimally on mobile devices, as shown in Figure 4. It provides a standardized way to display a summary, analysis, or suggestion generated with AI. This pattern can be applied to a full-screen or a card depending on the scope of content generated by AI.

AI Handoff Pattern: We have created a new guideline describing the AI Handoff Pattern, which defines how a user should transition between contextual embedded AI features and the Joule conversational panel.

Figure 4: Two new AI patterns: AI Insights Pattern and AI Handoff Pattern. Alt Text: On the left two image for AI Insights Pattern, first a full mobile phone screen with title and subtitle at the top, followed by two insights sections, each with two slots for content, at the bottom a user feedback row with thumbs up and thumbs down icons, above a an AI generate button. On the right a diagram for the AI Handoff Pattern showing a schematic mobile module with arrow to and from a schematic Joule UI.

Further news

I have picked two stand-out updates, also made available for Android and iOS.

New Illustrations: We have introduced the new illustrations, that were also introduced in the web, to the mobile design system and the mobile SDKs. You can see a few examples on the left in Figure 5 below.

More flexible card layouts: We offer far more flexibility now in how you use cards to summarize information. For example, you can create wider cards that have the image on the left or the right, and the content block next to it. With the new flex item component, the card’s main header can now be customized to hold more content by adding tags and status info labels outside, on top, between, or below the title and subtitle. Two examples are shown in Figure 5 on the right.

Figure 5: New illustrations and more flexible card layout and content options. Alt Text: On the left three different-size “My Daily Tasks” cards, with images for “You’r all caught up”, “Oops” and “Congratulations”. On the right two card examples: at the top a slim wide card with title, subtitle and one line text on the left, image on the right; below that a larger card with image on the left, title and details with colored indicators and buttons on the right.

Find out more here:

Introducing SAP Fiori for Android/iOS 25.8: Innovative Enhancements for Android and iOS.

For an overview of all updates, have a look at the what’s new sections in the SAP Design System portal and the SAP Mobile Services Documentation

SAP Fiori for Android design: What's New for SAP BTP SDK for Android 26.1 and older.
SAP BTP SDK for Android: What’s New in Release 26.1.2 and earlier releases.
SAP Fiori for iOS design: What's New for SAP BTP SDK for iOS 26.1 and older.
SAP BTP SDK for iOS: What’s New in Version 26.1.2 and earlier releases.

Mobile Development Kit (MDK) News

The Mobile Development Kit, available as part of SAP Mobile Services, enables developers and technical business users to build cross-platform mobile applications. It allows you to build your application once, in an integrated development environment (SAP Business Application Studio / VSCode extension) and run it natively on Mobile Android and iOS devices.

Here I have chosen to highlight one area: enhancements to the calander control, which now supports date range selection as well as allowing you to highlight special events or statuses directly on the calendar.

The new date range selection displays the calendar in a month-view format and allows multiple months to be shown. Users can scroll vertically through the calendar months. This is ideal if you need to plan events or manage schedules over extended periods, since users can select a time period with a start date and an end date (see Figure 6 below):

The first date selected becomes the start date of the range.
The second date selected becomes the end date of the range.

Figure 6: Date range selection supported by the mobile development kit provided by SAP Mobile Service. Alt Text: An image of an iPhone and an Android phone next to each other. The iPhone with the light Morning Horizon theme and a date selection Sep 16 – Sep 29, 2025, the other with the dark Evening Horizon theme and a date selection Mon Sep 29 to Fri Oct 17 2025.

Find out more here:

Blog post: What’s new in Mobile development kit client 25.9.
Documentation: What’s New in Mobile Development Kit 25.9.1 and earlier releases.

Further Information

For creating web applications, do register for the upcoming UI5con virtual conference.

Learn more about it at https://openui5.org/ui5con/faq.html, including how to attend, sponsor, or propose a topic for a session.

For links to design and development tools and technology, have a look at the SAP Fiori topic page in the SAP Community, or go directly to these pages:

Final words

As you can see from all seven posts in the series, we continue to progress rapidly with the user experience of our product portfolio, especially with regards to AI-assistance.

Part 1 of the series lists all the parts, and links to those parts that have already been published:

SAP UX Q1/2026 Update – Part 1: AI, Joule, SAP Build Work Zone, SAP Mobile Start.

Do keep posting your experiences and recommendations yourself in the SAP Community, with the SAP Fiori and/or the User Experience tag! In case you are wondering how to get a list of the most recent blog posts on SAP Fiori and User Experience in our new SAP Community, use these links:

For general information on design at SAP and SAP Fiori, check out:

Removal of legacy sap.ui.webc.* Web Component UI libraries from SAPUI5/OpenUI5 1.147.0 onwards

2026-03-26T09:26:57.814000+01:00

Saying Goodbye to `sap.ui.webc.*` — How SAPUI5/OpenUI5 Now Integrates Web Components Natively

If you've used the sap.ui.webc.main, sap.ui.webc.fiori, or sap.ui.webc.common libraries in a SAPUI5 or OpenUI5 application, this post is for you. These libraries will be removed in version 1.147.0, one release before the next long-term support (LTS) version 1.148. They will not be available in the 1.148 LTS or any version after.

Here's what happened, what's changing, and what you should do.

The Short Version

The sap.ui.webc.* libraries were an experimental attempt to bring UI5 Web Components into the SAPUI5 programming model. They were introduced in version 1.92 (2021) as experimental, deprecated in version 1.120 (2023), and will be removed in version 1.147.0. They never left experimental status.

The new solution is a much better approach: native Web Components integration built directly into sap.ui.core, available since version 1.138. Instead of frozen wrapper libraries, you now consume Web Components from npm as first-class citizens of the framework.

What Were the `sap.ui.webc.*` Libraries?

The idea was straightforward: take each UI5 Web Component (like ui5-button, ui5-shellbar, ui5-table) and wrap it as a classic SAPUI5 ManagedObject-based control — complete with properties, aggregations, events, and data binding support.

Three libraries made up this approach:

Library Purpose

`sap.ui.webc.common`	Base infrastructure, bundled the UI5 Web Components runtime
`sap.ui.webc.main`	~70 controls wrapping `@ui5/webcomponents` (Button, Input, Table, Dialog, ...)
`sap.ui.webc.fiori`	~30 controls wrapping `@ui5/webcomponents-fiori` (ShellBar, Wizard, Timeline, ...)

This "retrofit" approach worked, but it came with significant drawbacks:

Frozen dependency. The libraries bundled @ui5/webcomponents v1.18.0 as static thirdparty files. When the UI5 Web Components project shipped v2.x with major improvements, the sap.ui.webc.* libraries stayed on v1.18 — forever.
Maintenance overhead. Every new Web Component or API change required manually updating the wrapper code and re-bundling the thirdparty files. This didn't scale.
Experimental lock. Because of these constraints, the libraries never graduated beyond @experimental status. They were always flagged with: "This API is experimental and might change significantly."

Why They Were Deprecated

In version 1.120 — the previous LTS release — all three libraries were marked @deprecated with the message:

"This Web Components consumption model has been discarded. An alternative consumption model is planned for the future."

That alternative has arrived a while ago.

The Better Approach: `sap.ui.core.webc.WebComponent`

Since version 1.138, SAPUI5 includes a new public base class — sap.ui.core.webc.WebComponent — that lives directly in sap.ui.core. This is not another wrapper library. It's a framework-level integration point.

Here's what's different:

1. Web Components come from npm, not from frozen bundles.

Instead of shipping a static copy of @ui5/webcomponents, the new approach uses ui5-tooling-modules to consume Web Components directly from npm packages at build time. This means your application stays on current Web Component versions — today v2.x — rather than being locked to a frozen v1.18 copy.

2. Integration is at the framework level.

The WebComponent base class in sap.ui.core handles property propagation, aggregation-to-slot mapping, event forwarding, and rendering integration generically. Individual Web Component wrappers are thin — generated metadata, not hand-maintained control code.

3. The framework is already using it internally.

The new integration approach is already used within the framework itself — for example, the Shell and Enterprise Search in the sap.f library consume Web Components through this mechanism. While these specific integrations are currently private/restricted APIs, they validate that the approach works at scale in production scenarios. Public Web Component-based controls built on sap.ui.core.webc.WebComponent will follow.

4. It's public API.

Unlike the sap.ui.webc.* libraries which stayed experimental for their entire lifecycle, sap.ui.core.webc.WebComponent is a public, stable API since 1.138.

What You Should Do

If you never used sap.ui.webc.*: Nothing changes for you. If you want to use Web Components in your SAPUI5 app going forward, read the Using Web Components documentation.

If you used sap.ui.webc.* in a prototype or experiment: Since these libraries were always experimental, now is the time to move to the new approach. The controls you were using (like sap.ui.webc.main.Button or sap.ui.webc.fiori.ShellBar) have no 1:1 migration path because the consumption model changed fundamentally. However, the underlying Web Components are the same — and better, since you now get v2.x instead of v1.18.

If you used sap.ui.webc.* in a productive application despite the experimental status: The libraries will be removed in version 1.147.0. We recommend starting the migration now. The Using Web Components guide is your starting point.

If you're on the 1.120 LTS and planning to upgrade to the next LTS: The previous LTS (1.120) still ships the deprecated sap.ui.webc.* libraries. The next LTS (1.148) will not — they are removed one version earlier in 1.147. If your application depends on these libraries, you must migrate before upgrading to 1.148 LTS.

Timeline

Version Event

1.92 (2021)	`sap.ui.webc.` introduced as experimental*
1.120 (2023)	`sap.ui.webc.` deprecated* — previous LTS
1.138 (2025)	`sap.ui.core.webc.WebComponent` introduced as public API
1.147	`sap.ui.webc.` libraries removed*
1.148	Next LTS release — `sap.ui.webc.*` not available

Summary

The sap.ui.webc.* libraries were an early experiment that taught us a lot about what Web Components integration in SAPUI5 should look like. The answer turned out to be: don't bundle frozen copies — integrate at the framework level and let developers consume Web Components from the ecosystem directly.

That's exactly what the new approach does, and it's available today.

Next step: Using Web Components in SAPUI5

Bringing AI Directly Into SAPUI5 Controls - AI UI5 Library

2026-04-01T07:23:19.699000+02:00

A lot of AI work in the SAP space focuses on agents, assistants, and orchestration. This post is about something smaller in scope: bringing AI directly into SAPUI5 as reusable controls, close to where users interact with data every day.

Users frequently work with text fields, writing descriptions, filling in notes, composing messages. Tasks like improving the tone of a text, fixing spelling mistakes, or translating a field value are small, well-defined, and a good fit for what LLMs do well. This post shares an experiment in packaging that kind of capability into a UI5 control library.

The idea: AI as reusable UI5 controls

The library (be.wl.ai) provides a set of AI-powered UI5 controls that can be dropped into any XML view. A consuming app developer doesn’t need to know anything about AI Core or set up any AI infrastructure, they reference the library, add a control and bind it to a model property:

<ai:AIPolishButton text="Polish" value="{/description}" />

The TextArea and the AI button are both bound to the same model property. When the user accepts the AI result, it flows back into the model and the TextArea updates automatically, standard UI5 two-way data binding, nothing custom required.

What’s in the library

The library provides 11 controls covering the most common AI text operations:

https://github.com/lemaiwo/ui5-ai-features

Text transformation (Accept/Reject dialog):

AIPolishButton — improves grammar, clarity, and professionalism
AIGenerateButton — generates text from a short description
AISpellCheckButton — corrects errors and shows a summary of changes
AIToneButton — rewrites text in a different tone (formal, casual, persuasive, etc.)
AITranslateButton — translates into 12 languages via a dropdown menu

Analysis (read-only results):

AISummarizeButton — produces a concise summary
AIExtractKeywordsButton — extracts keywords as tokens with copy-to-clipboard
AICompareTexts — compares two texts and shows differences in HTML
AISentimentIndicator — shows a positive/neutral/negative sentiment badge

Inline assistance:

AIInputSuggestion — opens a popover with an AI-suggested improvement
AIAutoComplete — completes partial text inline

Every control uses standard UI5 two-way data binding through a value property. Bind it to the same model property as your input field, and the AI result flows back automatically.

Architecture: simple on purpose

The controls connect to a CAP backend service that wraps SAP AI Core’s Orchestration Service. The library creates a single shared OData model internally, app developers never see it.

The key design decision: the controls own their connection to the AI service. The consuming app doesn’t need to configure a model, set up a destination or know anything about AI Core. Import the library, use the controls, done.

Under the hood, all button controls extend a shared AIBaseButton base class that handles the OData call, dialog lifecycle, busy indicators, and accept/reject flow. Building a new AI control takes about 50 lines of code, just override the prompt, icon, and event name.

Design decisions worth noting

A few choices shaped how this library ended up, and they’re worth explaining for anyone considering a similar approach.

The controls own their AI connection. Rather than requiring the consuming app to configure a model or destination, the library manages its own OData connection to the CAP backend internally. This keeps the integration surface small, an app developer just binds a value property, the same way they would with any other UI5 control.

Standard UI5 patterns throughout. The controls use properties, events, and data binding exactly as UI5 developers would expect. There’s no custom state management or framework-specific logic. This makes the controls easier to understand, debug, and extend.

Prompts are exposed as properties. Every control has a prompt property that overrides the default. This makes it straightforward to adapt a control’s behaviour for a specific domain or use case without forking the library.

No SAP-specific beta features. Everything here runs on generally available SAP technology, UI5, CAP, and AI Core Orchestration Service. There’s no dependency on preview APIs or experimental tooling.

Current status

This is a first version and a proof of concept of what’s possible. It works locally with cds watch and the controls are fully functional. The library is structured for deployment to SAP BTP (MTA with HTML5 repo host), but it hasn’t been tested deployed yet.

The code is intentionally kept simple. There’s no streaming, no conversation history, no RAG. Just a text in, text out pattern, which covers a surprising number of real use cases.

Try it yourself

Prerequisites

Node.js 20+
An SAP AI Core instance (extended plan) with access to the Orchestration Service
A deployment of a model like GPT-4o through SAP AI Core

Running locally

The AI controls call SAP AI Core’s Orchestration Service on the backend. To run this locally, you need to use the hybrid approach — your CAP server runs on your machine but binds to a real AI Core service instance on SAP BTP.

Clone the repository:

git clone https://github.com/lemaiwo/ui5-ai-features.git
cd ui5-ai-features 
npm install

cf login

Bind to your AI Core instance using the hybrid profile:

npm run bind

Start the dev server with the hybrid profile:

npm run watch-hybrid

Open the app at the URL shown in the terminal:

http://localhost:4004/be.wl.ai.aidemo/index.html

Using the library in your own app

The library lives in app/ai-lib and the demo app in app/aidemo. To use the controls in your own app, add the library as a dependency and start using them in your XML views:

<mvc:View xmlns:ai="be.wl.ai">
    <TextArea value="{/notes}" />
    <ai:AIPolishButton text="Polish" value="{/notes}" />
    <ai:AITranslateButton text="Translate" value="{/notes}" />
    <ai:AISpellCheckButton text="Spell Check" value="{/notes}" />
</mvc:View>

The controls use two-way data binding. Bind both the TextArea and the AI control to the same model property, when the user accepts the AI result, the TextArea updates automatically.

Takeaways

This started as an experiment to see how much AI functionality could be packaged into reusable UI5 controls without requiring app developers to understand the AI layer. The answer is: quite a lot, with a relatively small amount of code.

The text in, text out pattern is simpler than agent-based approaches, but it fits a wide range of real use cases that users encounter daily. It also sits comfortably alongside agent and MCP work, both approaches address different parts of the problem.

The code is available if you want to explore, fork, or adapt it. Feedback and ideas are welcome.

Result

Introducing UI5 Plugins for Claude: AI-Powered Development for SAPUI5 and OpenUI5

2026-04-01T08:43:13.601000+02:00

Introducing UI5 Plugins for Claude: AI-Powered Development for SAPUI5 and OpenUI5

We're introducing UI5 plugins for Claude, an open-source collection of plugins for Claude Code. These plugins are designed to enhance UI5 development workflows with AI assistance.

What Are Claude Code Plugins?

Claude Code is Anthropic's AI-powered CLI for software development. Its plugin system lets domain experts extend Claude's built-in capabilities with specialized knowledge, tools, and skills for a specific technology. With plugins, Claude Code becomes aware of framework-specific conventions, APIs, and best practices. This means developers get more accurate, context-aware assistance without having to explain the fundamentals every time.

Why We Built This

The UI5 framework has a rich but specialized programming model. Developers, especially those new to UI5 or returning after a break, often spend significant time looking up the correct patterns for class definitions, module loading, TypeScript typing, and toolchain configuration. AI assistance can save hours in these situations, but only if the AI has accurate, curated knowledge of the framework.

Rather than relying on the LLM's general training data, which can be outdated or incomplete for framework details, these plugins embed current, maintained guidelines directly into the development workflow. The result is that Claude Code provides UI5-accurate suggestions from Day One, so you don't have to paste documentation into every conversation.

Last year, we published the UI5 MCP server described in Give Your AI Agent Some Tools: Introducing the UI5 MCP Server. The introduction of agent skills over the last year makes some tasks easier to complete compared to using only the UI5 MCP server. MCP servers aren't going away; this just introduces a new way to distribute tasks between MCP servers or skills. The choice depends on the task: Skills work well for tasks described in free text, while MCP servers offer better support for tasks that require precise input and output.

What We Are Releasing

The initial release ships two plugins:

1. UI5 Plugin — Your UI5 Development Companion

The UI5 plugin equips Claude Code with deep knowledge of the SAPUI5 and OpenUI5 ecosystem. It helps you with the following tasks:

Create new UI5 projects: Create scaffolded project structures based on best practices without any manual setup.
Detect and fix UI5-specific errors: Claude understands UI5 linting rules and applies fixes based on the official guidelines.
Access UI5 API documentation: Get accurate, framework-aware answers about controls, modules, events, and APIs instead of generic JavaScript suggestions.

Technically, the plugin is a wrapper around the UI5 MCP server. Install it with a single command:

claude plugin install ui5@claude-plugins-official

Or from within Claude Code:

/plugin install ui5@claude-plugins-official

2. UI5 TypeScript Conversion plugin — Migrate to TypeScript with Confidence

Migrating a JavaScript UI5 project to TypeScript can be tricky. Generic AI tools often handle the required transformations incorrectly. These transformations are necessary for the UI5 class system, the sap.ui.define module loader, runtime-generated getter and setter methods on controls, and library-specific patterns. The UI5 TypeScript Conversion plugin provides Claude Code with a step-by-step conversion playbook.

Install it with:

claude plugin install ui5-typescript-conversion@claude-plugins-official

Get Started

Install Claude Code.
Install one or both plugins as shown above.
Start coding. For example, you can ask Claude Code to create a UI5 project, run UI5 linter, explain an API, or start a TypeScript migration.

The source code for both plugins is available on GitHub at UI5/plugins-claude under the Apache 2.0 license. We welcome contributions, bug reports, and feature requests via GitHub Issues.

You can also join the conversation in the #ai channel of the OpenUI5 Community Slack or ask questions on Stack Overflow using the ui5-plugins-claude tag.

Mastering SAPUI5 custom Filter Variants Without a Backend Table

2026-04-06T12:16:46.286000+02:00

Mastering SAPUI5 Filter Variants Without a Backend Table

Many SAPUI5 developers assume that filter variants require a backend table. You might have even thought: “How can I save user filter preferences without touching a database?”

Here’s the good news: you absolutely can, and it’s cleaner, faster, and fully Fiori-compliant. Using SmartVariantManagement (SVM) and a FilterBar, you can build full variant management entirely client-side, while supporting complex controls like MultiInput, MultiComboBox, and DateRangeSelection.

In this blog, we’ll walk through a real-world implementation with custom development in UI.

1️⃣ Why Backend Tables Are Not Always Needed

Most SAP examples integrate variants with OData services or SmartTables, which gives the impression that server-side storage is required.

But here’s the truth:

SmartVariantManagement can store variants for standalone apps.
If your app runs in Launchpad, variants are stored in the personalization service.
The only requirement is to connect your FilterBar to SVM programmatically.

2️⃣ The View Setup

Here’s a clean XML setup with SVM and a FilterBar:

<smartvariants:SmartVariantManagement
    id="svm"
    showExecuteOnSelection="true"
/>

<fb:FilterBar
    id="filterbarList"
    useToolbar="false"
    search=".onSearch"
    persistencyKey="evaluationFilterBar"
    showFilterConfiguration="true"
    afterVariantLoad=".onAfterVariantLoad"
/>

Key Points:

showExecuteOnSelection="true" ensures users can auto-execute searches when a variant is selected.
persistencyKey allows local persistence even without backend tables.
The FilterBar does not automatically connect to SVM; we handle that in the controller.

3️⃣ Wiring FilterBar to SVM in the Controller

3.1 Register Fetch and Apply Functions

this._oFilterBar = this.byId("filterbarList");
this._oSmartVariantManagement = this.byId("svm");
this._oFilterBar.registerFetchData(this._fetchVariantData.bind(this));
this._oFilterBar.registerApplyData(this._applyVariantData.bind(this));
this._oFilterBar.attachAfterVariantLoad(this._onAfterVariantLoad.bind(this);

_fetchVariantData() extracts all filter values into JSON.
_applyVariantData() restores values when a variant is selected.
afterVariantLoad ensures auto-search or other post-load logic runs.

3.2 Add FilterBar as Personalizable Control

const oPersInfo = new PersonalizableInfo({
    type: "filterBar",
    keyName: "persistencyKey",
    dataSource: "",
    control: this._oFilterBar
});
this._oSmartVariantManagement.addPersonalizableControl(oPersInfo);

PersonalizableInfo registers the FilterBar with SVM, enabling full variant management, including Execute on Selection.

3.3 Initialize SmartVariantManagement

this._oSmartVariantManagement.initialise(function () {}, this._oFilterBar);

Establishes the connection between SVM and FilterBar.
Variants are now fully functional, even without any backend storage.

4️⃣ Handling Complex Filter Controls

Fetch Variant Data : Explicitly fetches all tokens from MultiInput controls so multiple values are captured per filter.

_fetchVariantData() {
    const oData = {};
    this._oFilterBar.getAllFilterItems().forEach(item => {
        const oControl = item.getControl();
        if (!oControl) return;

        if (oControl.isA("sap.m.MultiInput")) {
            oData[item.getName()] = oControl.getTokens().map(t => t.getKey() || t.getText());
        }

        if (oControl.isA("sap.m.DateRangeSelection")) {
            oData[item.getName()] = {
                from: oControl.getDateValue(),
                to: oControl.getSecondDateValue()
            };
        }

        if (oControl.isA("sap.m.MultiComboBox")) {
            oData[item.getName()] = oControl.getSelectedKeys();
        }
    });
    return oData;
}

Apply Variant Data : Ensures all stored tokens are re-applied, supporting multi-value filter selection.

_applyVariantData(oData) {
    if (!oData) return;

    this._oFilterBar.getAllFilterItems().forEach(item => {
        const oControl = item.getControl();
        const vValue = oData[item.getName()];
        if (!oControl) return;

        if (oControl.isA("sap.m.MultiInput")) {
            oControl.removeAllTokens();
            if (Array.isArray(vValue)) {
                vValue.forEach(val => oControl.addToken(new sap.m.Token({ key: val, text: val })));
            }
        }

        if (oControl.isA("sap.m.DateRangeSelection")) {
            oControl.setDateValue(vValue?.from || null);
            oControl.setSecondDateValue(vValue?.to || null);
        }

        if (oControl.isA("sap.m.MultiComboBox")) {
            oControl.setSelectedKeys(vValue || []);
        }
    });

    // Trigger search automatically
    this.onSearch();
}

These functions serialize and restore all filter control values, making the variants robust and accurate.

5️⃣ How It Works (Visual Diagram)

Flow Explanation:

FilterBar registers fetch/apply logic for all controls.
PersonalizableInfo connects FilterBar to SVM.
Variants are stored in personalization.
Users can save, load, and auto-execute variants seamlessly.

6️⃣ Key Benefits

Fully functional variant management without a backend table
Supports complex controls: MultiInput, MultiComboBox, DateRangeSelection
upports complex controls and multi-value filters via tokens
Enables Execute on Selection
Works in standalone apps or Fiori Launchpad
Easy to extend for additional custom controls

7️⃣ Key Takeaways

FilterBar alone is not enough; manual SVM wiring is required.
PersonalizableInfo + addPersonalizableControl() + initialise() connects everything.
Added: Custom fetch/apply functions handle complex controls and **tokenized multi-value filters**.
Custom fetch/apply functions handle complex controls.
Variants can be fully stored client-side, making backend persistence optional.

Bonus: User-Specific Variants

One surprising feature is that these variants respect user profiles automatically. Even though the variants are stored client-side or in FLP personalization, each user sees their own saved variants. This means you can have multiple users using the same app, each with their own filter preferences, without any backend table or custom storage logic.

Key points:

Variants are automatically scoped per user in Fiori Launchpad or browser storage.
No extra coding is required to separate user preferences.
Works seamlessly with Execute on Selection and all complex controls.

With this approach, you give users a robust, professional, Fiori-compliant variant experience—without the overhead of backend tables.

More Power, New Name: The UI Flexibility Service Explained

2026-04-07T09:27:16.370000+02:00

SAPUI5 flexibility for adapting standard SAP apps

SAPUI5 is SAP’s strategic Web framework for SAP Fiori. SAPUI5 flexibility allows developers, key users, and end users to adapt standard apps with simple drag-and-drop tools. Discover all the capabilities here: SAPUI5 Flexibility - All You Need to Know.

Key user adaptation

Key user adaptation is built into SAP Fiori Launchpad / SAP Build Work Zone and is included commercially as part of the respective product. Outside these products, the same capabilities are available as a dedicated service, UI5 flexibility for key users, on SAP BTP, enabling key user adaptation for standalone apps, for example, for SAP partners building their own apps. The service is available via BTPEA, BTP Trial, and partner TD&D licenses. See details in the SAP Discovery Center.

What's new?

Some time ago, we added the end user personalization capability to the UI5 flexibility for key users service. This allows also business users to easily change the UI of standard apps, helping them work more efficiently. This created confusion, as the service name UI5 flexibility for key users no longer reflects the full range of benefits. We therefore decided to rename the service:

"UI5 flexibility for key users" ➔ "UI flexibility service"

You will see the name being changed now across all SAP assets, e.g.:

Apart from the name, nothing changes in the scope or functionality of the UI flexibility service.

Deep Entity Handling in SAP UI5 Using OData Service

2026-04-13T07:15:04.408000+02:00

Introduction:

A Deep Entity allows you to send and receive hierarchical data (parent + child) in a single request, making your application more efficient, cleaner, and closer to real business scenarios.

In this blog, we will build a complete end-to-end example of a Deep Entity, covering:

Backend implementation using SEGW (ABAP OData)
Frontend implementation using SAP UI5
Read (Expand) and Create (Deep Insert) operations

Architecture Overview:

SAP UI5 App

↓

OData Service (Gateway)

↓

Backend Logic (ABAP)

↓

Database Tables

Backend Implementation (ABAP - OData Service):

Step 1: Define Entities in SEGW:

Create:

Header Entity → Sales Order (VBAK)

Item Entity → Sales Order Item (VBAP)

Step 2: Create Association :

Association: Header → Item (1: N)

Navigation Property: znavigation.

Step 3: Create Deep Structure:

Go To: MPC EXT → Source Code-Based.
Create Deep Structure.

class ZCL_ZK_DEEP_ENTITY_MPC_EXT definition 
   public 
   inheriting from ZCL_ZK_DEEP_ENTITY_MPC 
   create public . 
public section. 
  types: 
     BEGIN OF ty_deep_str, 
               vbeln              TYPE  vbeln_va, 
               erdat              TYPE  erdat, 
               ernam              TYPE  ernam, 
               auart              TYPE  auart, 
               kunnr              TYPE  kunnr, 
               znavigation TYPE TABLE OF zcl_zk_deep_entity_mpc_ext=>ts_vbap WITH DEFAULT KEY, 
             END OF ty_deep_str . 
protected section. 
   PRIVATE SECTION. 
ENDCLASS. 

CLASS ZCL_ZK_DEEP_ENTITY_MPC_EXT IMPLEMENTATION. 
ENDCLASS.

Step 3: Redefine GET_EXPANDED_ENTITY, GET_EXPANDED_ENTITYSET, CREATE_DEEP_ENTITY.

Go to:

DPC_EXT Class → Method:

Method: /IWBEP/IF_MGW_APPL_SRV_RUNTIME~GET_EXPANDED_ENTITY.

METHOD /iwbep/if_mgw_appl_srv_runtime~get_expanded_entity. 
 
  DATA: ls_deep_str TYPE zcl_zk_deep_entity_mpc_ext=>ty_deep_str, 
         ls_vbak     TYPE zstr_vbak, 
         lt_vbap     TYPE STANDARD TABLE OF zstr_vbap. 
 
  DATA lv_vbeln TYPE vbeln_va. 
 
  "-------------------------------------------------- 
   " Read key 
   "-------------------------------------------------- 
   lv_vbeln = VALUE #( it_key_tab[ name = 'Vbeln' ]-value OPTIONAL ). 
   lv_vbeln = |{ lv_vbeln ALPHA = IN }|. 
 
  "-------------------------------------------------- 
   " Read Header (VBAK) 
   "-------------------------------------------------- 
   SELECT SINGLE 
          vbeln, 
          erdat, 
          ernam, 
          auart, 
          kunnr 
     FROM zdt_vbak 
     INTO _vbak 
     WHERE vbeln = _vbeln. 
 
  IF sy-subrc <> 0. 
     RETURN. 
   ENDIF. 
 
  "-------------------------------------------------- 
   " Read Items (VBAP) 
   "-------------------------------------------------- 
   SELECT 
          vbeln, 
          posnr, 
          matnr, 
          kwmeng, 
          vrkme 
     FROM zdt_vbap 
     INTO TABLE _vbap 
     WHERE vbeln = _vbeln. 
 
  "-------------------------------------------------- 
   " Explicit Header Mapping (IMPORTANT) 
   "-------------------------------------------------- 
   CLEAR ls_deep_str. 
 
  ls_deep_str-vbeln = ls_vbak-vbeln. 
   ls_deep_str-erdat = ls_vbak-erdat. 
   ls_deep_str-ernam = ls_vbak-ernam. 
   ls_deep_str-auart = ls_vbak-auart. 
   ls_deep_str-kunnr = ls_vbak-kunnr. 
 
  "-------------------------------------------------- 
   " Items Mapping 
   "-------------------------------------------------- 
   IF lt_vbap IS NOT INITIAL. 
     ls_deep_str-znavigation = CORRESPONDING #( lt_vbap ). 
   ENDIF. 
 
  "-------------------------------------------------- 
   " Return Deep Entity 
   "-------------------------------------------------- 
   copy_data_to_ref( 
     EXPORTING 
       is_data = ls_deep_str 
     CHANGING 
       cr_data = er_entity 
   ). 
 
  APPEND 'znavigation' TO et_expanded_clauses. 
 
ENDMETHOD.

Method: /IWBEP/IF_MGW_APPL_SRV_RUNTIME~GET_EXPANDED_ENTITYSET.

  method /IWBEP/IF_MGW_APPL_SRV_RUNTIME~GET_EXPANDED_ENTITYSET. 
 
      DATA : lt_vbak TYPE ZCL_ZK_DEEP_ENTITY_MPC_EXT=>tt_vbak, 
              lt_vbap TYPE ZCL_ZK_DEEP_ENTITY_MPC_EXT=>tt_vbap, 
              ls_deep type ZCL_ZK_DEEP_ENTITY_MPC_EXT=>ty_deep_str, 
              lt_deep TYPE STANDARD TABLE OF ZCL_ZK_DEEP_ENTITY_MPC_EXT=>ty_deep_str. 
 
 
        SELECT FROM zdt_vbak FIELDS VBELN, 
                                     ERDAT, 
                                     ERNAM, 
                                     AUART, 
                                     KUNNR INTO TABLE _vbak. 
 
          LOOP AT lt_vbak ASSIGNING FIELD-SYMBOL(<fs_vbak>). 

           clear  ls_deep . 
 
            ls_deep = CORRESPONDING #( <fs_vbak> ). 
 
            SELECT FROM zdt_vbap FIELDS VBELN, 
                                         POSNR, 
                                         MATNR, 
                                         KWMENG, 
                                         VRKME 
               WHERE vbeln = @<fs_vbak>-vbeln 
               INTO TABLE _vbap. 
 
              ls_deep-znavigation =  CORRESPONDING #( lt_vbak ). 
 
             APPEND ls_deep to lt_deep. 
 
          ENDLOOP. 

          copy_data_to_ref( 
             EXPORTING 
               is_data = lt_deep 
             CHANGING 
               cr_data = er_entityset 
           ). 

          APPEND 'znavigation' to et_expanded_clauses. 

  endmethod.

Method: /IWBEP/IF_MGW_APPL_SRV_RUNTIME~CREATE_DEEP_ENTITY.

  METHOD /iwbep/if_mgw_appl_srv_runtime~create_deep_entity. 
     DATA : ls_deep    TYPE zcl_zk_deep_entity_mpc_ext=>ty_deep_str, 
            ls_vbak    TYPE zcl_zk_deep_entity_mpc_ext=>ts_vbak, 
            ls_vbap    TYPE zcl_zk_deep_entity_mpc_ext=>ts_vbap, 
 
           ls_vbak2   TYPE zdt_vbak, 
            ls_vbap2   TYPE zdt_vbap, 
 
           lv_vbeln   TYPE zdt_vbak-vbeln, 
            lv_posnr   TYPE zdt_vbap-posnr, 
 
           lv_vbeln_n TYPE zdt_vbak-vbeln, 
            lv_posnr_n TYPE zdt_vbap-posnr. 
 
    io_data_provider->read_entry_data( 
       IMPORTING 
         es_data = ls_deep 
     ). 
 
    SELECT MAX( vbeln ) 
           INTO _vbeln 
           FROM zdt_vbak. 
 
    IF lv_vbeln IS INITIAL. 
       lv_vbeln_n = 1. 
     ELSE. 
       lv_vbeln_n = lv_vbeln + 1. 
     ENDIF. 
 
    lv_vbeln_n = |{ lv_vbeln_n ALPHA = IN }|. 
     ls_vbak-vbeln = lv_vbeln_n. 
     ls_vbak-erdat = sy-datum. 
     ls_vbak-ernam = sy-uname. 
     ls_vbak-auart = ls_deep-auart. 
     ls_vbak-kunnr = ls_deep-kunnr. 
 
    MOVE-CORRESPONDING ls_vbak TO ls_vbak2. 
 
    INSERT zdt_vbak FROM ls_vbak2. 
 
    CLEAR lv_posnr. 
 
    LOOP AT ls_deep-znavigation INTO DATA(ls_deep_item). 
       lv_posnr = lv_posnr + 10. 
 
      ls_vbap-vbeln  = lv_vbeln_n. 
       ls_vbap-posnr  = lv_posnr. 
       ls_vbap-matnr  = ls_deep_item-matnr. 
       ls_vbap-kwmeng = ls_deep_item-kwmeng. 
       ls_vbap-vrkme  = ls_deep_item-vrkme. 
 
      MOVE-CORRESPONDING ls_vbap TO ls_vbap2. 
 
      INSERT zdt_vbap FROM ls_vbap2. 
 
      CLEAR ls_vbap2. 
     ENDLOOP. 
     ls_deep-vbeln = lv_vbeln_n. 
     ls_deep-erdat = sy-datum. 
 
    copy_data_to_ref( 
       EXPORTING 
         is_data = ls_deep 
       CHANGING 
         cr_data = er_deep_entity 
     ). 

  ENDMETHOD.

UI5 Implementation:

Step 1: View – Binding Data and Preparing Navigation:

The view shows a list of sales orders by binding the table to the header entity (vbakSet). When the screen loads, it automatically fetches only basic data (like order number, date, customer). It does not load item data here, so the screen stays fast and simple.

Each row in the table is made clickable and shows a small arrow because of the navigation type. This tells the user that clicking a row will take them to another screen.

When a row is clicked, the view triggers an event and sends the selected row’s data to the controller. This includes the important key field (Vbeln), which is needed to identify the sales order.

From a deep entity point of view, the view does not load full data. It only shows header data and prepares the key, so that the next screen can use it to fetch complete data (header + items) together.

<mvc:View
    controllerName="project1.controller.View1"
    xmlns:mvc="sap.ui.core.mvc"
    xmlns="sap.m"
    xmlns:f="sap.f"
    displayBlock="true">

    <f:DynamicPage
        id="dynPage"
        toggleHeaderOnTitleClick="false">

        <!-- ================= TITLE ================= -->
        <f:title>
            <f:DynamicPageTitle>

                <f:heading>
                    <HBox alignItems="Center">
                        <Avatar
                            src="sap-icon://sales-order"
                            displayShape="Square"
                            class="sapUiTinyMarginEnd"/>

                        <VBox>
                            <Title text="Sales Orders" level="H2"/>
                            <Text text="Manage and track sales orders"/>
                        </VBox>
                    </HBox>
                </f:heading>

                <f:actions>
                    <Button
                        text="Create"
                        icon="sap-icon://add"
                        type="Emphasized"
                        press="onCreate"/>

                    <!--
                    <Button
                        text="Edit"
                        icon="sap-icon://edit"
                        press="onUpdate"
                        enabled="{= ${vbakTable>/selectedItems}.length === 1 }"/>
                    -->

                    <Button
                        text="Delete"
                        icon="sap-icon://delete"
                        type="Negative"
                        press="onDelete"
                        enabled="{= ${vbakTable>/selectedItems}.length > 0 }"/>
                </f:actions>

            </f:DynamicPageTitle>
        </f:title>

        <!-- ================= HEADER ================= -->
        <f:header>
            <f:DynamicPageHeader pinnable="true">

                <Toolbar design="Transparent">
                    <Label text="Search"/>
                    <SearchField
                        width="20rem"
                        liveChange="onSearch"
                        placeholder="Sales Order / Customer"/>
                </Toolbar>

            </f:DynamicPageHeader>
        </f:header>

        <!-- ================= CONTENT ================= -->
        <f:content>
            <Table
                id="vbakTable"
                items="{ path: '/vbakSet' }"
                growing="true"
                growingScrollToLoad="true"
                mode="MultiSelect"
                itemPress="onItemPress"
                sticky="ColumnHeaders"
                noDataText="No sales orders found"
                busyIndicatorDelay="0">

                <!-- ================= COLUMNS ================= -->
                <columns>
                    <Column width="11rem">
                        <Text text="Sales Order"/>
                    </Column>

                    <Column width="9rem" demandPopin="true" minScreenWidth="Tablet">
                        <Text text="Created On"/>
                    </Column>

                    <Column width="9rem" demandPopin="true" minScreenWidth="Tablet">
                        <Text text="Created By"/>
                    </Column>

                    <Column width="7rem">
                        <Text text="Type"/>
                    </Column>

                    <Column width="11rem" demandPopin="true" minScreenWidth="Desktop">
                        <Text text="Customer"/>
                    </Column>
                </columns>

                <!-- ================= ITEMS ================= -->
                <items>
                    <ColumnListItem
                        type="Navigation">

                        <cells>
                            <ObjectIdentifier
                                title="{Vbeln}"
                                titleActive="true"/>

                            <Text text="{Erdat}"/>

                            <Text text="{Ernam}"/>

                            <ObjectStatus
                                text="{Auart}"
                                state="Information"/>

                            <Text text="{Kunnr}"/>
                        </cells>

                    </ColumnListItem>
                </items>

            </Table>
        </f:content>

    </f:DynamicPage>
</mvc:View>

Step 2: Controller – Handling Row Selection and Parameter-Based Routing:

When the user clicks on a row, the controller takes that row and gets its data. From that data, it picks the Sales Order number (Vbeln), which is the main key.

After getting this key, the controller performs router-based navigation using parameter-based (dynamic) routing. It sends the user to the Detail page and passes the Vbeln as a parameter, so the next screen knows exactly which sales order to load.

In terms of deep entity, the controller is not loading all the data here. It is just sending the key, and using that key, the next screen will fetch full data (header + items) together.

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

        return Controller.extend("project1.controller.View1", {

            onInit: function () {

            },

            onCreate: function () {
                this.getOwnerComponent().getRouter().navTo("Create");
            },

            onItemPress: function (oEvent) {
                debugger;

                var sVbeln = oEvent
                    .getParameter("listItem")
                    .getBindingContext()
                    .getProperty("Vbeln");

                this.getOwnerComponent().getRouter().navTo("Detail", {
                    Vbeln: sVbeln
                });
            }

        });
    }
);

Output:

Step 3: View – Showing Header and Item Data:

The view is designed to show one sales order in detail. It displays both the header data (like order number, customer, date) and the item data (list of materials).

It uses a local model (detail) where data is divided into two parts:

Header → main sales order

Items → list of related items

The header section is bound to detail>/Header, and the table is bound to detail>/Items, so it can show parent + child data together.

<mvc:View
    controllerName="project1.controller.Detail"
    xmlns:mvc="sap.ui.core.mvc"
    xmlns="sap.m"
    xmlns:uxap="sap.uxap"
    displayBlock="true">

    <uxap:ObjectPageLayout
        id="ObjectPage"
        enableLazyLoading="true"
        showHeaderContent="true"
        showAnchorBar="true"
        upperCaseAnchorBar="false"
        isChildPage="true">

        <!-- ================= HEADER ================= -->
        <uxap:headerTitle>
            <uxap:ObjectPageHeader
                objectTitle="{detail>/Header/Vbeln}"
                objectSubtitle="Sales Order"
                objectImageURI="sap-icon://sales-order"
                objectImageShape="Square"
                isObjectIconAlwaysVisible="true">

                <!-- Header Actions (Fiori standard) -->
                <uxap:actions>
                    <Button
                        icon="sap-icon://nav-back"
                        type="Emphasized"
                        tooltip="Back"
                        press="onNavBack"/>

                    <Button
                        icon="sap-icon://edit"
                        text="Edit"
                        type="Attention"/>
                </uxap:actions>

            </uxap:ObjectPageHeader>
        </uxap:headerTitle>

        <!-- ================= HEADER CONTENT ================= -->
        <uxap:headerContent>
            <HBox
                justifyContent="Start"
                alignItems="Center"
                class="sapUiSmallMargin">

                <ObjectStatus
                    title="Document Type"
                    text="{detail>/Header/Auart}"
                    state="Information"/>

            </HBox>
        </uxap:headerContent>

        <!-- ================= SECTIONS ================= -->
        <uxap:sections>

            <!-- ================= GENERAL INFORMATION ================= -->
            <uxap:ObjectPageSection
                title="General Information"
                titleUppercase="false">

                <uxap:subSections>
                    <uxap:ObjectPageSubSection>

                        <VBox class="sapUiMediumMargin sapUiResponsiveContentPadding">

                            <HBox wrap="Wrap" class="sapUiSmallMarginBottom">

                                <VBox width="18rem" class="sapUiSmallMarginEnd">
                                    <Label text="Customer"/>
                                    <ObjectIdentifier title="{detail>/Header/Kunnr}"/>
                                </VBox>

                                <VBox width="18rem" class="sapUiSmallMarginEnd">
                                    <Label text="Created On"/>
                                    <Text text="{detail>/Header/Erdat}"/>
                                </VBox>

                                <VBox width="18rem">
                                    <Label text="Created By"/>
                                    <Text text="{detail>/Header/Ernam}"/>
                                </VBox>

                            </HBox>

                        </VBox>

                    </uxap:ObjectPageSubSection>
                </uxap:subSections>
            </uxap:ObjectPageSection>

            <!-- ================= ITEMS ================= -->
            <uxap:ObjectPageSection
                title="Items"
                titleUppercase="true">

                <uxap:subSections>
                    <uxap:ObjectPageSubSection>

                        <Table
                            items="{detail>/Items}"
                            growing="true"
                            growingScrollToLoad="true"
                            sticky="HeaderToolbar,ColumnHeaders"
                            class="sapUiResponsiveContentPadding">

                            <!-- Section Toolbar (Fiori pattern) -->
                            <headerToolbar>
                                <OverflowToolbar>
                                    <Title text="Order Items" level="H3"/>
                                    <ToolbarSpacer/>

                                    <Text text="Items: {= ${detail>/Items}.length }"/>

                                    <ToolbarSeparator/>

                                    <Button
                                        icon="sap-icon://add"
                                        text="Add Item"
                                        type="Transparent"/>
                                </OverflowToolbar>
                            </headerToolbar>

                            <columns>
                                <Column width="5rem">
                                    <Text text="Item"/>
                                </Column>

                                <Column>
                                    <Text text="Material"/>
                                </Column>

                                <Column hAlign="End" width="8rem">
                                    <Text text="Quantity"/>
                                </Column>

                                <Column width="6rem">
                                    <Text text="Unit"/>
                                </Column>
                            </columns>

                            <items>
                                <ColumnListItem>
                                    <cells>
                                        <ObjectIdentifier title="{detail>Posnr}"/>
                                        <Text text="{detail>Matnr}"/>
                                        <ObjectNumber number="{detail>Kwmeng}"/>
                                        <ObjectStatus text="{detail>Vrkme}"/>
                                    </cells>
                                </ColumnListItem>
                            </items>

                        </Table>

                    </uxap:ObjectPageSubSection>
                </uxap:subSections>
            </uxap:ObjectPageSection>

        </uxap:sections>

        <!-- ================= FOOTER (Fiori standard) ================= -->
        <uxap:footer>
            <OverflowToolbar>
                <ToolbarSpacer/>

                <Button
                    text="Edit"
                    icon="sap-icon://edit"
                    type="Emphasized"/>

                <Button
                    text="Cancel"
                    type="Transparent"
                    press="onNavBack"/>
            </OverflowToolbar>
        </uxap:footer>

    </uxap:ObjectPageLayout>
</mvc:View>

Step 4: Controller – Fetching Deep Entity Data:

The controller gets the Vbeln (Sales Order number) from routing when the screen opens.

Using this key, it makes one OData call with $expand, which fetches:

Header data

Item data

in a single request (deep entity).

After getting the data, it splits it into:

Header → stored separately

Items → stored separately

and sets it into the local model, which is then shown in the view.

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

        return Controller.extend("project1.controller.Detail", {

            onInit: function () {
                debugger;

                this.getOwnerComponent()
                    .getRouter()
                    .getRoute("Detail")
                    .attachPatternMatched(this._onObjectMatched, this);

                this.getView().setModel(
                    new JSONModel({
                        Header: {},
                        Items: []
                    }),
                    "detail"
                );
            },

            _onObjectMatched: function (oEvent) {
                debugger;

                var sVbeln = oEvent.getParameter("arguments").Vbeln;

                sVbeln = sVbeln.padStart(10, "0");

                var oModel = this.getOwnerComponent().getModel();
                var oDetailModel = this.getView().getModel("detail");

                oModel.read("/vbakSet('" + sVbeln + "')", {
                    urlParameters: {
                        "$expand": "znavigation"
                    },
                    success: function (oData) {
                        debugger;

                        oDetailModel.setProperty("/Header", oData);
                        oDetailModel.setProperty(
                            "/Items",
                            oData.znavigation.results
                        );
                    },
                    error: function () {
                        debugger;
                    }
                });
            },

            onNavBack: function () {
                this.getOwnerComponent()
                    .getRouter()
                    .navTo("RouteView1");
            }

        });
    }
);

Output:

Step 5: View – Entering Header and Item Data:

The view is designed to create a new sales order. It allows the user to enter both header data (like document type, customer) and item data (materials, quantity, unit) in the same screen.

It uses a local model (local) to store user input. The header fields are directly bound to this model, and the items table is bound to local>/Items, which holds multiple item entries.

The user can dynamically add or remove items, so the view supports multiple child entries under one header.

<mvc:View
    controllerName="project1.controller.Create"
    xmlns:mvc="sap.ui.core.mvc"
    xmlns="sap.m"
    xmlns:uxap="sap.uxap"
    xmlns:form="sap.ui.layout.form">

    <uxap:ObjectPageLayout
        id="CreateSalesOrderPage"
        showHeaderContent="true">

        <!-- ================= HEADER ================= -->
        <uxap:headerTitle>
            <uxap:ObjectPageHeader
                objectTitle="Create Sales Order"
                objectSubtitle="Header and Items"
                objectImageURI="sap-icon://sales-order"
                objectImageShape="Square">

                <uxap:actions>
                    <Button
                        text="Save"
                        icon="sap-icon://save"
                        type="Emphasized"
                        press="onSave"/>

                    <Button
                        text="Cancel"
                        icon="sap-icon://cancel"
                        type="Reject"
                        press="onCancel"/>
                </uxap:actions>

            </uxap:ObjectPageHeader>
        </uxap:headerTitle>

        <!-- ================= SECTIONS ================= -->
        <uxap:sections>

            <!-- ================= HEADER DATA ================= -->
            <uxap:ObjectPageSection title="Header Data">
                <uxap:subSections>
                    <uxap:ObjectPageSubSection>

                        <form:SimpleForm
                            editable="true"
                            layout="ResponsiveGridLayout"
                            labelSpanXL="3"
                            labelSpanL="3"
                            labelSpanM="4"
                            labelSpanS="12">

                            <Label text="Sales Document Type"/>
                            <Input
                                value="{local>/Auart}"
                                id="Aurat"
                                placeholder="AUART"
                                showValueHelp="true"
                                valueHelpRequest="onAuartValueHelp"/>

                            <Label text="Customer"/>
                            <Input
                                id="Kunnr"
                                value="{local>/Kunnr}"
                                placeholder="KUNNR"/>

                            <Label text="Created On"/>
                            <DatePicker editable="false"/>

                            <Label text="Created By"/>
                            <Input editable="false"/>

                        </form:SimpleForm>

                    </uxap:ObjectPageSubSection>
                </uxap:subSections>
            </uxap:ObjectPageSection>

            <!-- ================= ITEM DATA ================= -->
            <uxap:ObjectPageSection title="Items">
                <uxap:subSections>
                    <uxap:ObjectPageSubSection>

                        <Table
                            id="itemTable"
                            mode="MultiSelect"
                            growing="true"
                            items="{
                                path: 'local>/Items'
                            }">

                            <headerToolbar>
                                <Toolbar>
                                    <Title text="Sales Order Items"/>
                                    <ToolbarSpacer/>
                                    <Button
                                        icon="sap-icon://add"
                                        text="Add Item"
                                        press="onAddItem"/>
                                    <Button
                                        icon="sap-icon://delete"
                                        text="Remove Item"
                                        press="onRemoveItem"/>
                                </Toolbar>
                            </headerToolbar>

                            <columns>
                                <Column>
                                    <Text text="Item"/>
                                </Column>
                                <Column>
                                    <Text text="Material"/>
                                </Column>
                                <Column hAlign="End">
                                    <Text text="Quantity"/>
                                </Column>
                                <Column>
                                    <Text text="Unit"/>
                                </Column>
                            </columns>

                            <items>
                                <ColumnListItem>
                                    <cells>
                                        <Input
                                            value="{local>Posnr}"
                                            editable="false"/>

                                        <Input
                                            value="{local>Matnr}"
                                            placeholder="MATNR"/>

                                        <Input
                                            type="Number"
                                            value="{local>Kwmeng}"
                                            placeholder="Quantity"/>

                                        <Input
                                            value="{local>Vrkme}"
                                            placeholder="Unit"/>
                                    </cells>
                                </ColumnListItem>
                            </items>

                        </Table>

                    </uxap:ObjectPageSubSection>
                </uxap:subSections>
            </uxap:ObjectPageSection>

        </uxap:sections>

    </uxap:ObjectPageLayout>
</mvc:View>

Step 6:Creating Deep Entity (Header + Items):

The controller manages user input and stores all item data in the local model. When the user clicks save, it collects both header and item data.

It creates a single payload that contains:

Header data (Auart, Kunnr, etc.)

Item data (array of items)

Then it makes one create a call to backend, sending everything together.

After successful creation, it reads the latest sales order and navigates to the Detail page using the generated Vbeln.

sap.ui.define(
    [
        "sap/ui/core/mvc/Controller",
        "sap/ui/model/json/JSONModel",
        "sap/m/MessageToast"
    ],
    function (Controller, JSONModel, MessageToast) {
        "use strict";

        return Controller.extend("project1.controller.Create", {

            onInit: function () {

                // Local JSON model for dynamic items
                var oData = {
                    Items: []
                };

                var oLocalModel = new JSONModel(oData);
                this.getView().setModel(oLocalModel, "local");
            },

            /* =========================================================== */
            /* NAVIGATION */
            /* =========================================================== */

            onCancel: function () {
                this.getOwnerComponent()
                    .getRouter()
                    .navTo("RouteView1");
            },

            /* =========================================================== */
            /* VALUE HELP */
            /* =========================================================== */

            oAuartVh: null,

            onAuartValueHelp: function () {

                if (!this.oAuartVh) {
                    this.oAuartVh = sap.ui.xmlfragment(
                        "project1.Fragments.AuartVH",
                        this
                    );

                    this.getView().addDependent(this.oAuartVh);
                }

                this.oAuartVh.open();
            },

            onAuartCancel: function () {
                this.oAuartVh.close();
            },

            onAuartConfirm: function (oEvent) {

                var oItem = oEvent.getParameter("selectedItem");
                if (!oItem) {
                    return;
                }

                this.byId("Aurat").setValue(oItem.getTitle());
            },

            onExit: function () {

                if (this.oAuartVh) {
                    this.oAuartVh.destroy();
                    this.oAuartVh = null;
                }
            },

            /* =========================================================== */
            /* ADD ITEM */
            /* =========================================================== */

            onAddItem: function () {

                var oModel = this.getView().getModel("local");
                var aItems = oModel.getProperty("/Items");

                aItems.push({
                    Posnr: "",
                    Matnr: "",
                    Kwmeng: "",
                    Vrkme: ""
                });

                oModel.setProperty("/Items", aItems);
            },

            /* =========================================================== */
            /* REMOVE ITEM */
            /* =========================================================== */

            onRemoveItem: function () {

                var oTable = this.byId("itemTable");
                var oModel = this.getView().getModel("local");
                var aItems = oModel.getProperty("/Items");

                var aSelectedItems = oTable.getSelectedItems();

                if (aSelectedItems.length === 0) {
                    MessageToast.show("Select at least one item to delete");
                    return;
                }

                aSelectedItems.forEach(function (oItem) {
                    var sPath = oItem
                        .getBindingContext("local")
                        .getPath();

                    var iIndex = parseInt(sPath.split("/")[2]);
                    aItems.splice(iIndex, 1);
                });

                oModel.setProperty("/Items", aItems);
            },

            /* =========================================================== */
            /* SAVE (DEEP ENTITY CREATE) */
            /* =========================================================== */

            onSave: function () {
                debugger;

                var oModel = this.getOwnerComponent().getModel();
                var aItems = this.getView()
                    .getModel("local")
                    .getProperty("/Items");

                if (aItems.length === 0) {
                    MessageToast.show("Please add at least one item");
                    return;
                }

                var oPayload = {
                    Auart: this.byId("Aurat").getValue(),
                    Kunnr: this.byId("Kunnr").getValue(),
                    Erdat: new Date().toISOString().split("T")[0],
                    znavigation: aItems
                };

                oModel.create("/vbakSet", oPayload, {

                    success: (oData) => {

                        this._readLatestOrder();
                        MessageToast.show("Sales Order Created");

                        // Clear header fields
                        this.byId("Aurat").setValue("");
                        this.byId("Kunnr").setValue("");

                        // Clear items
                        this.getView()
                            .getModel("local")
                            .setProperty("/Items", []);
                    },

                    error: (oError) => {
                        MessageToast.show("Error while creating Sales Order");
                    }
                });
            },

            /* =========================================================== */
            /* READ LATEST ORDER */
            /* =========================================================== */

            _readLatestOrder: function () {

                var oModel = this.getOwnerComponent().getModel();

                oModel.read("/vbakSet", {
                    urlParameters: {
                        "$orderby": "Vbeln desc"
                    },

                    success: function (oData) {

                        if (oData.results.length > 0) {
                            var sVbeln = oData.results[0].Vbeln;

                            this.getOwnerComponent()
                                .getRouter()
                                .navTo("Detail", {
                                    Vbeln: sVbeln
                                });
                        }

                    }.bind(this),

                    error: function () {
                        MessageToast.show("Read failed");
                    }
                });
            }

        });
    }
);

Here view collects full data (header + items)

The controller sends full data in one call (deep insert)

This completes the deep entity flow for create scenario

Output:

Conclusion

Deep Entity simplifies handling header and item data in a single request, reducing multiple OData calls and keeping both backend and UI logic clean.

In this blog, we covered the complete lifecycle:

Backend setup using SEGW
Data retrieval using $expand
Deep insert (header + items in one call)
UI5 integration.

CSV Validator App Is Now Open Source

2026-04-17T10:06:11.296000+02:00

From Solution to Community Tool

A few weeks ago, I shared how CSVValidationApp helps solve data quality issues in SAP SuccessFactors Talent Intelligence Hub. The response surprised me. Many have built similar workarounds, spent hours cleaning data manually, or watched perfectly good imports fail because of stray HTML tags.

That's when I felt this shouldn't be "my tool." It should be our tool.

Today, CSV Validator App is officially open source and available on GitHub under the Apache 2.0 license: github.com/SAP/csv-validator

Why This Matters

I didn't build this tool because I love CSV files (I don't). I built it because I was tired of seeing good work derailed by preventable issues. An HR team prepares a skills library update, exports clean data, imports it into TIH—and suddenly descriptions are broken, special characters are corrupted, and they're troubleshooting instead of enabling their workforce.

It's frustrating. And it's common.

Making this open source isn't about recognition or downloads. It's about honesty: I don't have all the answers. You might be importing recruiting data with different quirks. You might support a region with specific character encoding needs. You might have found a validation rule I missed.

By opening the code, we can solve these problems together—transparently, collaboratively, and faster than any of us could alone.

What You're Getting

This is a complete SAP Fiori application you can run today:

Core Validation:

Detects encoding issues (UTF-8 compliance, BOM, null bytes)
Validates CSV structure (headers, delimiters, column consistency)
Identifies problematic content (HTML tags, entities, control characters, special characters)
Checks field lengths and data integrity

Auto-Correction:

Strips HTML tags while preserving content
Converts HTML entities to UTF-8 characters (  → space, ü → ü)
Properly escapes special characters
Generates a clean, download-ready corrected file

UI Features:

Drag-and-drop file upload
Interactive preview of your CSV
Filterable table showing issues by row and type
Side-by-side view of original vs. corrected content
One-click download of the corrected file

Privacy:

Everything runs locally in your browser
No uploads, no servers, no data leaves your machine

It's built with SAP UI5, follows SAP Fiori standards, and runs via npm. Five minutes from clone to validation.

Getting Started

git clone https://github.com/SAP/csv-validator.git
cd csv-validator
npm install
npm start

Open your browser to the app url, drop in a CSV file, and click Validate. That's it.
You can test by uploading your csv and press validate. Here is a sample screenshot of what you can expect:

Where We Go From Here

I have ideas for improvements—support for other SuccessFactors modules, batch processing, direct API integration. But I'm more interested in hearing yours.

If you use this tool and it helps, tell me what's missing. If it doesn't catch an issue it should, open a GitHub issue with an example. If you have a fix or enhancement, submit a pull request. If you just want to share your experience, leave a comment below.

This isn't a finished product. It's a starting point. I'm learning as much from your use cases as you might learn from the code.

An Honest Ask

If you work with SuccessFactors data imports—whether you're an administrator, consultant, or developer—try this tool with your real files. Not a sanitized demo file. Your actual data (with sensitive info removed, of course).

Then tell me:

Did it catch issues you would have missed?
Did it flag false positives that aren't actually problems?
What validation rule would make your life easier?

And if you've built something similar or have ideas for collaboration, let's talk. The goal isn't to centralize everything into this one tool—it's to raise the baseline for data quality across the community.

Resources:

GitHub Repository: github.com/SAP/csv-validator
Original Blog Post: Bridging Data Quality Gaps in TIH with CSVValidationApp
Issues & Feedback: github.com/SAP/csv-validator/issues
Contribution Guidelines: github.com/SAP/csv-validator/CONTRIBUTING.md

Data quality shouldn't be a bottleneck. Let's make it a strength—together.

How to Integrate UI5 Test Coverage with SonarQube in SAP UI5 Projects

2026-04-21T15:19:13.771000+02:00

When working with SAP UI5 applications, automated tests are already a good practice. But once the project grows, test execution alone is no longer enough. Teams want to see how much of the application is actually covered by tests, especially in pull requests and CI/CD pipelines.

In this post, I will show how I implemented test coverage reporting for a SAP UI5 application and integrated it with SonarQube so that coverage metrics are visible directly in the quality dashboard.

The solution is based on:

ui5-test-runner for running QUnit tests with coverage enabled
nyc for generating LCOV reports
a custom normalization step to include untested files
SonarQube for importing and displaying coverage metrics

This setup works especially well in CI pipelines and helps teams track both coverage on new code and overall project coverage.

Why This Is Needed

In many UI5 projects, unit tests exist, but coverage is not published anywhere centrally. As a result:

developers do not see how well new changes are covered
pull requests cannot be validated against coverage quality gates
SonarQube shows no meaningful UI coverage data
uncovered source files may be silently ignored

The main challenge is that in UI5 projects, coverage collection is not always straightforward when tests are executed in the browser. Even if coverage is enabled, the generated report may contain only files that were actually loaded during test execution. This creates an incomplete picture for SonarQube.

To solve this, I implemented an approach that not only generates LCOV coverage but also normalizes it so that all relevant source files are represented, including files with 0% coverage.

Solution Overview

The final flow looks like this:

ui5-test-runner runs QUnit tests with coverage instrumentation
nyc generates the LCOV report
a custom script normalizes the report and adds missing source files
SonarQube imports the LCOV file and displays the coverage metrics

This gives a reliable and CI-friendly setup for SAP UI5 applications.

Prerequisites

Install the required development dependencies:

npm install --save-dev ui5-test-runner nyc puppeteer

What each package is used for

Package Purpose

`ui5-test-runner`	Runs UI5/QUnit tests and supports code coverage
`nyc`	Istanbul-based coverage engine used under the hood
`puppeteer`	Runs tests in headless Chrome, useful for CI

Step 1. Configure `ui5-test-runner`

Create a ui5-test-runner.json file with the basic setup:

{
 "pageTimeout": 60000,
 "coverage": true,
 "coverageReportDir": "coverage",
 "reportDir": "report",
 "parallel": 2
}

What this configuration does

enables coverage collection
stores coverage artifacts in the coverage folder
defines a timeout for browser-based execution
allows parallel test execution for better performance

Step 2. Configure NYC

Even though ui5-test-runner handles much of the work, it relies on NYC internally.
That is why adding an explicit .nycrc.json file is important.

{
 "all": true,
 "sourceMap": false,
 "reporter": ["lcov", "text-summary"],
 "report-dir": "./coverage",
 "temp-dir": "./.nyc_output",
 "include": ["webapp/**/*.js"],
 "exclude": ["webapp/test/**", "webapp/localService/**"],
 "cwd": "."
}

Important points here

all: true is important because we want full project visibility
test sources are excluded from business code coverage
lcov is required because this is the format SonarQube imports

Step 3. Configure SonarQube

Now we need to tell SonarQube where the UI5 sources, tests, and LCOV report are located.

Create or update sonar-project.properties:

sonar.projectKey=your-project-key
sonar.projectName=your-project-name

# Source configuration
sonar.sources=webapp/
sonar.exclusions=webapp/localService/**,**/node_modules/**

# Test configuration
sonar.tests=webapp/test/
sonar.test.inclusions=webapp/test/**/*.js

# Coverage report path
sonar.javascript.lcov.reportPaths=coverage/lcov.info
sonar.coverage.exclusions=webapp/test/**,webapp/localService/**

# Encoding
sonar.sourceEncoding=UTF-8

At this point, the most important property is:

sonar.javascript.lcov.reportPaths=coverage/lcov.info

This is the file SonarQube reads to compute the coverage metrics.

Step 4. Add NPM Scripts

The next step is to automate local and CI execution.

In package.json:

{
"scripts": {
"test": "ui5 serve --config ui5-test.yaml --port 8080 & SERVER_PID=$!; sleep 3; ui5-test-runner --url http://localhost:8080/test/unit/unitTests.qunit.html --coverage --coverage-proxy; TEST_EXIT=$?; kill $SERVER_PID 2>/dev/null || true; exit $TEST_EXIT",
"test:ci": "ui5 serve --config ui5-test.yaml --port 8080 & SERVER_PID=$!; sleep 3; ui5-test-runner --url http://localhost:8080/test/unit/unitTests.qunit.html --coverage --coverage-proxy --ci; TEST_EXIT=$?; kill $SERVER_PID 2>/dev/null || true; npm run coverage:normalize; exit $TEST_EXIT",
"coverage:normalize": "node scripts/normalize-coverage.js"
}
}

Why `--coverage-proxy` is important

When UI5 tests are executed through a served application URL, --coverage-proxy enables on-the-fly instrumentation. Without it, coverage may be missing or incomplete.

Key flags

Flag Meaning

`--coverage`	Enables coverage collection
`--coverage-proxy`	Instruments files dynamically in browser-based execution
`--ci`	Uses CI-friendly non-interactive output

Step 5. Normalize Coverage for Untested Files

This was the most important part of the implementation.

The problem

When --coverage-proxy is used, only files that are actually loaded during the test run are instrumented.
That means if a source file is never loaded, it may not appear in lcov.info at all.

For SonarQube, this is problematic because missing files are not always treated the same way as explicitly uncovered files. As a result, the reported coverage can be misleading.

The fix

I added a normalization script that:

scans all source files in webapp
checks which files are already present in lcov.info
adds missing source files with 0% coverage
normalizes paths so that they match SonarQube expectations

Create scripts/normalize-coverage.js:

const fs = require('fs');
const path = require('path');

const lcovPath = 'coverage/lcov.info';
const webappDir = 'webapp';

// Get all JS source files (excluding test and localService)
function getAllSourceFiles() {
const files = [];
function walk(dir) {
const entries = fs.readdirSync(dir, { withFileTypes: true });
for (const entry of entries) {
const fullPath = path.join(dir, entry.name);
if (entry.isDirectory()) {
if (entry.name !== 'test' && entry.name !== 'localService' && entry.name !== 'node_modules') {
walk(fullPath);
}
} else if (entry.name.endsWith('.js')) {
const relativePath = path.relative(webappDir, fullPath).replace(/\\/g, '/');
files.push(relativePath);
}
}
}
walk(webappDir);
return files;
}

// Parse existing lcov.info to get covered files
function parseLcov(content) {
const covered = new Set();
for (const line of content.split('\n')) {
if (line.startsWith('SF:')) {
covered.add(line.slice(3));
}
}
return covered;
}

// Generate lcov entry for uncovered file
function generateUncoveredEntry(filePath) {
const fullPath = path.join(webappDir, filePath);
if (!fs.existsSync(fullPath)) return null;

const content = fs.readFileSync(fullPath, 'utf8');
const lines = content.split('\n');
const executableLines = [];

for (let i = 0; i < lines.length; i++) {
const line = lines[i].trim();
if (line &&
!line.startsWith('//') &&
!line.startsWith('/*') &&
!line.startsWith('*') &&
line !== '{' &&
line !== '}' &&
line !== '});' &&
line !== ']);' &&
line !== '};' &&
line !== '"use strict";') {
executableLines.push(i + 1);
}
}

if (executableLines.length === 0) return null;

let entry = `SF:${filePath}\n`;
entry += `FNF:0\nFNH:0\n`;
for (const lineNum of executableLines) {
entry += `DA:${lineNum},0\n`;
}
entry += `LF:${executableLines.length}\nLH:0\n`;
entry += `BRF:0\nBRH:0\n`;
entry += `end_of_record\n`;

return entry;
}

// Main
if (!fs.existsSync(lcovPath)) {
console.log('No lcov.info found, skipping');
process.exit(0);
}

let content = fs.readFileSync(lcovPath, 'utf8');
const lines = content.split('\n');
const normalized = [];

// Normalize paths (remove webapp/ prefix to match sonar.sources)
for (const line of lines) {
if (line.startsWith('SF:')) {
let filePath = line.slice(3);
const webappMatch = filePath.match(/[/\\]?webapp[/\\](.+)$/);
if (webappMatch) {
filePath = webappMatch[1];
}
filePath = filePath.replace(/\\/g, '/').replace(/^\//, '');
normalized.push('SF:' + filePath);
} else {
normalized.push(line);
}
}

// Get already covered files
const coveredFiles = parseLcov(normalized.join('\n'));

// Add uncovered files
const allFiles = getAllSourceFiles();
let uncoveredContent = '';

for (const file of allFiles) {
if (!coveredFiles.has(file)) {
const entry = generateUncoveredEntry(file);
if (entry) uncoveredContent += entry;
}
}

fs.writeFileSync(lcovPath, normalized.join('\n') + '\n' + uncoveredContent);
console.log('Coverage normalized for SonarQube');

A Critical Detail: Path Mapping Between LCOV and SonarQube

This part is easy to overlook, but it is often the real reason why SonarQube shows 0% coverage even when the LCOV file exists.

If SonarQube is configured with:

sonar.sources=webapp/

then SonarQube treats webapp/ as the root of the source tree.

That means:

webapp/model/messages.js is indexed by SonarQube as model/messages.js
therefore lcov.info must contain:

SF:model/messages.js

and not:

SF:webapp/model/messages.js

In other words

The path in SF: must be relative to sonar.sources.

That is exactly why the normalization script rewrites the paths.

CI/CD Integration

Once the local setup works, integrating it into the pipeline is straightforward.

SAP Piper example

In .pipeline/config.yml:

steps:
 npmExecuteScripts:
  install: true
  virtualFrameBuffer: false
  dockerImage: 'cypress/browsers:node-20.18.0-chrome-130.0.6723.69-1-ff-131.0.3-edge-130.0.2849.52-1'
  runScripts:
   - 'test:ci'
  sonarExecuteScan:
  serverUrl: 'https://sonar.tools.sap'

stages:
 Build:
  npmExecuteScripts: true
  sonarExecuteScan: true

GitHub Actions example

- name: Run tests with coverage
run: npm run test:ci

- name: SonarQube Scan
uses: sonarqube-scan-action@v1
with:
args: >
-Dsonar.projectKey=${{ env.PROJECT_KEY }}

Generated Coverage Artifacts

After running:

npm run test:ci

you should see:

coverage/
├── lcov.info
├── lcov-report/
│ └── index.html
└── cobertura-coverage.xml

What these files are used for

lcov.info → imported by SonarQube
lcov-report/ → human-readable HTML report for local inspection
cobertura-coverage.xml → optional integration with other tools

How Coverage Appears in SonarQube

After the scan, SonarQube usually shows two metrics that are especially important:

Metric Meaning

Coverage on New Code	Coverage only for changed lines in the branch or PR
Overall Coverage	Coverage across the entire project

This distinction matters a lot.

A project can have:

high coverage on new code, because the changed lines were properly tested
low overall coverage, because legacy parts of the application still have poor test coverage

That is not a contradiction. It is normal SonarQube behavior.

Troubleshooting

SonarQube shows 0% coverage

Check the following first:

coverage/lcov.info is generated successfully
sonar.javascript.lcov.reportPaths points to the correct file
SF: entries match the structure expected by sonar.sources

Useful check:

grep "^SF:" coverage/lcov.info

Some files are missing from coverage

This usually happens because only loaded files were instrumented during the browser run.

That is exactly why the normalization step is needed.

Without normalization, SonarQube may import only a partial coverage picture.

Coverage on new code is high, but overall coverage is low

This is expected and does not necessarily indicate a problem.

It simply means:

your recent changes are well tested
older application code still lacks coverage

Warning: “Unable to process all coverage”

This may appear when using ui5-test-runner with --coverage-proxy.

In practice, this warning means that not all source files could be discovered automatically during runtime instrumentation.

The custom normalization script compensates for this by adding the missing files manually.

Final Thoughts

For me, the key goal of this implementation was not just to execute UI5 tests with coverage enabled, but to make the results usable and trustworthy inside SonarQube.

The most important lessons from this setup were:

generating LCOV is only the first step
path alignment between LCOV and sonar.sources is critical
browser-based runtime instrumentation does not guarantee full project visibility
normalizing missing files makes the SonarQube result much more accurate

With this approach in place, SAP UI5 projects can benefit from the same quality visibility that backend projects usually already have: clear coverage reports, PR metrics, and enforceable quality gates.