SAP Community - SAP Build Code

SAP TechEd Berlin 2025: DA262-Enabling clean core development with SAP HANA Cloud and SAP Build Code

2025-10-15T11:51:18.065000+02:00

A couple of words about me:

My name is Shraddha Shetty and I’m a Product Manager on the SAP HANA Product Management team, with a focus on Developer Experience. I began my journey at SAP in 2021 as a Developer and later transitioned into Product Management.

Join My Session!
DA262 | Enabling Clean Core Development with SAP HANA Cloud and SAP Build Code
🗓️ Wednesday, Nov 5 | 3:30 PM – 5:30 PM CET

What you will learn about:

Join our hands-on workshop DA262 | Enabling Clean Core Development with SAP HANA Cloud and SAP Build Code to explore how side-by-side extensions can help you innovate without compromising your clean core.

In this hands-on session, you’ll explore how SAP HANA Cloud, the SAP Cloud Application Programming Model (CAP), and SAP Build Code work together to simplify and accelerate development. Through guided exercises, participants will learn to create full-stack applications, integrate business services, and extend SAP solutions with agility and intelligence. You’ll also get hands-on experience exploring HANA Cloud features such as adding native artifacts, and accessing data lake files to build smarter, data-driven applications.

By the end of the workshop, you’ll gain practical insights and skills to confidently build scalable, cloud-ready applications while maintaining a clean and extensible core. Don’t miss this opportunity to enhance your developer experience and unlock the full potential of SAP HANA Cloud and SAP Build Code.

Co-speakers:

Thomas Hammer – Lead Product Manager, SAP HANA Cloud, SAP SE
Christoph Morgen – Senior Product Manager, SAP HANA Cloud AI, SAP SE
Roman Belosludtsev – Product Manager, SAP HANA Cloud, SAP SE

Other related sessions I recommend:

DA261 | Unlocking AI-Driven Insights from Your Business Data in SAP HANA Cloud
Hands-on Workshop
When: Tue, Nov 4 | 12:30 PM – 2:30 PM CET

DA200 | Help Future-Proof Your Database Landscape with SAP HANA Cloud
Deep Dive
When: Wed, Nov 5 | 10:15 AM – 11:00 AM CET

DA202 | Extensibility at Scale: Build Intelligent Applications with SAP HANA Cloud
Deep Dive
When: Wed, Nov 5 | 1:15 PM – 2:00 PM CET

ST115 | SAP HANA Cloud: The Database for Business AI
Strategy Talk
When: Wed, Nov 5 | 2:15 PM – 2:40 PM CET

DA201 | Accelerating Your AI Strategy with SAP HANA Cloud
Deep Dive
When: Thu, Nov 6 | 9:00 AM – 9:45 AM CET

DA263 | SAP HANA Cloud: Advisors and Automation
Hands-on Workshop
When: Thu, Nov 6 | 9:00 AM – 11:00 AM CET

DA817 | What's Next for SAP HANA Cloud: Road Map and Innovation Highlights
Road Map
When: Thu, Nov 6 | 1:30 PM – 1:55 PM CET

DA904 | SAP HANA Cloud: A Database for SAP Business AI
Demo Station

Related community topic pages:

Best Practice collection working with Business Application Studio(BAS) and HANA Deployment Infrastructure(HDI)

Looking forward to seeing you! 👋✨🚀

Don’t miss this opportunity to get hands-on with SAP HANA Cloud and SAP Build Code, and learn how to extend your SAP landscape while keeping your core clean. Join us to gain practical skills, connect with experts, and see firsthand how to accelerate innovation in your applications. Register and be part of this interactive workshop.

💬Now let’s hear from you:

As you gear up for SAP TechEd 2025, we’d love to hear your thoughts and experiences with SAP HANA Cloud and clean core development. Share your insights, ideas, and challenges with us:

When building full-stack applications, do you prefer CAP services or other development approaches? Why?
How do you currently manage data modeling and business logic in your SAP HANA Cloud applications
What are your expectations for SAP TechEd 2025, and which hands-on topics excite you the most?

Drop your thoughts in the comments below

Joule in SAP Build Code can now create freestyle UI5 apps

2025-11-13T15:58:38.496000+01:00

Last year, we introduced the SAPUI5 extension for the Joule coding assistant in SAP Build Code and wrote about how to use it. Over time, it has received more features, like the AI-supported conversion of UI5 apps to TypeScript and setting up new pages and the respective navigation.

The latest improvement, available from November 2025, lets you create new freestyle UI5 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. More on this in my other article.

The feature

Joule makes specific features available using "slash commands". The new one is /ui5-create-app. When you open the Joule panel in SAP Build Code and start typing /ui5, you might see it suggested, as well as other UI5 features. But which commands appear depends on the context. While some are only available within UI5 apps, this new feature is only available when you are not in a UI5 app. It won't be available e.g. in a workspace which has a ui5.yaml at top-level, or when you have a UI5 controller open in the code editor!

Try it in a workspace with a CAP project at root level, so you see some of its magic immediately: as soon as you finish typing the slash command or select it from the suggestion list, another suggestion list with sample prompts comes up. These are based on the actual data structures of the CAP project.

This means you can simply select the desired entity and service, then the actual full prompt will automatically be entered into the field(but of course you can also write your own prompt!). This full prompt includes even more details than the short prompt in the suggestion list did.

Note that the prompt includes a concrete list of properties and the service URL. This information has been extracted from CAP using good old deterministic code—no Large Language Model (LLM) used. In fact, this is an area where AI would likely make up ("hallucinate") property names which do not actually exist. Acquiring all this information in advance in a deterministic way not only gives you the chance to review and adjust the prompt with little effort, but also leads to a more reliable functionality overall.

The paradigm: use LLMs (Large Language Models) where they excel—processing and "understanding" language—and use deterministic code for hard facts and well-defined operations, where possible.

The AI part starts soon enough, when you submit this prompt. It proposes a specific app setup, highlighting the key choices for you to review. For example, it will suggest a sensible name (if you didn't provide one) or suggest the best location inside the project structure (which it knows from its context).

But you can do more than just review those parameters. A suggested version of the app has already been created behind the scenes, so you can scroll through the 30+ files listed in the box at the bottom and click those you want to preview. If the result already looks fine to you—perfect. Just press the "Accept Application" button and the app will be set up in your workspace.

Refining the app

But of course you are free to continue the conversation and tweak the result. The LLM in Joule will put its true strength at work, mapping its understanding of your request to what the underlying template can do. No need to type "change parameter x to value y": LLMs also understand you when you are less formal and direct. Look at the below screenshot for an example: it responds almost too compassionately to the developer who is "hesitant about new technologies" and recreates the app with changed parameters—using JavaScript instead of TypeScript. The user did not even mention the programming language specifically, but still the LLM decided that changing it would be the best way to accommodate the app code to the user's preferences.

At this stage, you can refine the setup of the initial app—within the limits imposed by the application template used behind the scenes, which only has limited degrees of freedom. We want this initial app to be robust and follow best-practice code. We also want those 30+ files to be created in one fast step. Hence the code is not written by AI, but by using predefined template files we are back in the world of traditional deterministic coding here. You have plenty of opportunity for using AI later on to extend the app from this solid starting point.

Joule is aware of its limits in this step, so it will not say "yes" to every request you throw at it. Asking for "a trillion tables" or other features beyond the template scope will be politely rejected.

Accepting the app

When the preview looks good and you have pressed the button, the job of this /ui5-create-app assistant is done. After app setup has finished (which may take a while because the dependencies need to be installed), it concludes with hints how to continue, including instructions on how to start the app in your respective workspace setup.

The created application looks roughly like this, with a table and a detail form below. Note: only OData V4 services are supported at this time.

You get this kind of UI when you specify an OData V4 service and entity. If you don't, then there is just a generic "Hello World" success page instead.

Of course this UI structure might not be exactly what is desired in the app or even requested in the prompt, but this is what the template can do. When an OData service and entity but no properties are requested, then the tool tries to detect existing properties. If this fails, the table will be empty (no columns at all)—but Joule's success message should then mention this.

After creation

As the assistant suggests, please move to the other Joule assistants /ui5 and /ui5-create-page for developing the app further. In order to create more apps, reset the conversation with the button at the top of the Joule pane.

Because /ui5-create-app knows that it cannot modify the app or re-create it, it will politely guide you to the options you have, no matter what your request is. It may even give instructions on how to achieve the given goal within a UI5 app, but it will not be able to modify the code and it will make this clear when needed.

AI Learnings

While there is not much more to say about this feature—simply try it!—there are some facts and learnings about its implementation! If you are curious, head over to the second part of this blog post: Inside Joule: Lessons from building an AI coding assistant for SAP Build.

Inside Joule: Lessons from building an AI coding assistant for SAP Build

2025-11-13T16:00:38.750000+01:00

Flashback: the feature

This is a "making of" article about the implementation of the new /ui5-create-app slash command available within Joule in SAP Build Code. In short, this new feature enables a conversation between AI assistant and application developer about a new freestyle UI5 application to build, with a full-fledged best-practice application starting point as result.

To see screenshots of this feature in action and understand it better, feel invited to read my previous blog post. If you are just here for the background and AI-related learnings—go ahead!

General considerations

With open‑ended prompting, users aren’t restricted to predefined interactions. The user could ask for anything. In contrast to traditional programming, a prompt input field can’t be handled with a sprawling web of if/else logic trying to cover all possible use-cases. Attempting this will lead to a frustrating user experience where the user often gets an "I do not understand your request".

Some developers try to mimic this traditional programming pattern when crafting prompts and contexts for LLMs, telling an LLM "if the user asks for x, then answer y". Instead, as demonstrated below, tell the LLM what it can and cannot do and give it a goal to achieve. It's "smart" enough to figure out a suitable response to whatever the user will throw at it.

A fundamental choice

Looking at this specific feature in the specific environment, the implementation options on the table were (for a variety of reasons) these two:

Either just provide a system prompt (a prompt that is added behind the scenes in addition to what the user typed) without interfering with the specific prompts and replies entered during the conversation.
Or adopt a new way of creating an "agentic" multi-step execution plan. Similar to a guided activity, this would allow phases of data collection, possibly in different steps for different data, then an app creation step and so forth.

Surely "agentic" and "well-defined steps" sound good for app creation from a template, no? In fact, the initial implementation started like this, but it was soon apparent that this would neither provide the expected flexibility nor allow for a truly intelligent app creation experience. Defining phases in which to acquire specific information and having the application code created at a specific stage in this process did not feel right. The user would still feel like clicking through a traditional template creation process, as something specific was expected from the user at every stage, instead of giving the user the freedom to tweak every aspect at every stage. The true power of AI, on the other hand, would be totally underused.

But then again... just a system prompt and that's it? No file read access to explore the environment, no dynamically updated instructions? Is this enough for an intelligent coding assistant?

Creating an "AI agent" out of nothing

Consider the now common definition of an "AI agent" which has settled over the course of this year: it's nothing more than "an LLM with tools, called in a loop to achieve a goal". The chat conversation provided by Joule can be our loop, an application template with its parameters is the tool and the goal of assisting the developer to create an app can be stated in the system prompt. Of course a real autonomous agent would require the loop to run without user interaction, but for this feature a loop involving the user is just right.

The system prompt used for this feature literally includes: "You help users create new UI5 applications by analyzing their requirements and filling the project template parameters. [...] Your goal is to gather all necessary information to create a new UI5 application. The application will be generated from a template which has only one page and a hardcoded UI, but can optionally display data from an OData V4 service. [...] You cannot create the application yourself, but the user will see a preview...". There you have it: the goal and the tool!

It then goes on with some behavioral hints and of course a detailed description of what exactly the template parameters do. Finally, it requests each reply to contain a JSON object with the best choice of template parameters according to the current understanding of the user request. The JSON object could look like this example:

{

   "appNamespace": "com.myorg.myapp",

   "basePath": "/path/to/workspace",

   "createAppDirectory": true,

   "framework": "SAPUI5",

   "frameworkVersion": "1.136.0",

   "author": "John Doe",

   "oDataV4Url": "https://services.odata.org/TripPinRESTierService/(S(s5xrj1t51r41s3ooztsynysq))/",

   "oDataEntitySet": "Airports",

   "entityProperties": ["Name", "Address"],

   "runNpmInstall": true,

   "initializeGitRepository": true,

   "typescript": true

}

This JSON object is removed from the LLM response before displaying it, then the application is generated with these parameters, so the user can accept it or request changes. In an environment where tools with a well-defined interface like MCP servers are not enabled, this JSON object as part of the conversation is how the integration with the templating tool is achieved. It's basically a use-case-tailored alternative to MCP. A note to make this very clear: this environment is not the official SAP Joule assistant running inside end-user applications, as it is now also being enabled for development by customers. Instead, it is a sort of predecessor implementation specifically available in SAP Build Code since spring 2024 and about to be replaced by advanced solutions. So do not draw conclusions about SAP Joule based on this article.

Some of these parameters in the JSON object are more important than others with regards to the user explicitly influencing them or having to accept them. Whether the app code is generated as TypeScript or JavaScript is something the user should not be surprised with after accepting the app! On the other hand, the author name, which is only written into package.json, can be reliably defaulted to the logged-in user name and also very easily changed later on if needed. Hence, the parameter descriptions explain not only what they do, but also how much the user should be bothered with them. As result, Joule usually does not even mention half of the parameters, thus keeping the conversation focused.

How to stop the agent

Regarding the state after the app was accepted, the prompt explains "AFTER the user has generated the application, you **MUST NOT** continue discussing parameters for generation, but rather [...] in particular by referring the user to the '/ui5' command for most requests or '/ui5-create-page' for adding pages to the app, because they are much better than you in developing features, as they have the capability to automatically select a suitable context of files.".

This means the transition in the overall process between refining parameters and "no more changes possible" is not a hardcoded step or denoted by changing the system prompt, but rather explained up-front. That's enough. Can you talk Joule into proposing another set of parameters after the app was accepted? Maybe. But its normal behavior is just right: it will explain that the app can not be created again without restarting the conversation. Nevertheless, there are also non-AI guardrails in place to prevent the app from being generated again, thus causing trouble.

All in all, we shape Joule’s behavior by explaining the templating tool and its limits, by stating the goal and desired behavior towards this goal, and by explaining the general flow, in particular the state after app acceptance. This is enough to guide it to a suitable reaction for whatever the user requests.

Even if the user insists like this:

Context, context, context!

To make the entire feature really user-friendly, however, it is not sufficient to write a good prompt, but the context must also provide enough information to the LLM to allow for informed decisions. Hence, information like the list of project root files and folders, whether a Git repository is present, plus CAP service/entity/property info, and more, are gathered (e.g. using the @sap-ux/project-access package). This knowledge is provided as prompt context behind the scenes or used in another way (like as content of the suggested prompts). This makes Joule aware of the environment it acts in, leading to better responses, like automatically avoiding app names that would conflict with existing folder names.

Agentic coding assistants like Cline, GitHub Copilot, Cursor etc. usually have the ability to read files and execute shell commands as needed to understand their environment. In this pure user request + LLM response environment this might have been a bit harder to build. Basically, more tools could have been defined, e.g. by describing other JSON object structures for invoking them. But control would not so easily return to the LLM until after the user has entered another prompt. Or, there could have been one "preprocessor" LLM request asking for needed files, like it is done for the other /ui5* commands.

But for a narrow scenario like app creation this wasn't necessary. Collecting the most relevant information up front not only provides sufficient context, but also improves performance and reliability by avoiding repeated tool calls and unpredictable LLM loops.

In-response prompting

The real-world context, however, changes over time. Specifically, once the app is created and accepted, there are new additional files present.

When developing the UI5 MCP server, we observed that the agentic AI tool (e.g. Cline) using the MCP server often decided to inspect the new app directory tree after creation, causing several LLM roundtrips which cost time and tokens. Or it would run "npm install" again, even though it had already been executed. Or it would make specific coding errors very often in subsequent modifications.

To avoid this, we extended the response of the MCP server after creating the app. Normally, it contains just the success message. But now it includes a full list of generated files, it states that "npm install" was already executed and it instructs how to prevent those coding errors. Basically, the MCP server response added further updated instructions to the conversation context.

Exactly the same principle was applied in this new Joule feature. While there is no autonomous agent loop in this case which would inspect the new files, the knowledge which files were created can be valuable for the conversation with the user. And while the/ui5-create-app command doesn't modify any code after app creation (thus avoiding the coding issues), facts like whether "npm install" was already executed, or whether the created UI5 Table in the MainView is lacking any columns, are useful for giving the user hints how to continue. Therefore, the context is extended by adding a hidden message to the conversation history.

Traditional coding has its place(s)

In addition to the process of context collection, deterministic coding is also used after the app has been accepted by the user for making the app consumption as smooth as possible. When inside a CAP project, it for example ensures that the cds-plugin-ui5 is added as dependency. This allows the UI5 tooling, including TypeScript transpilation of the UI5 app when needed, to run as part of the "cds watch" or "npm start" script of the CAP project itself.

Also, this dependency and all the UI5 app dependencies need to be installed. Unfortunately, there is a wide range of options and specific setups which might be used for dependency management in the already existing app. Probably npm? With or without workspaces? yarn? pnpm? Others? The code detects what is used and tries to cover the 95% case. The initial setup might not be complete in every scenario, but for most users it will “just work,” providing a good developer experience.

AI is fine and all, but sometimes one has to go the extra mile and do some coding.

Key takeaways

Use deterministic code where reasonable (because the space of possibilities is bounded and a deterministic and quick result is beneficial) .
Use LLMs for language understanding or dealing with an unpredictable range of possible requests.
Don't try to "program" the LLM with an if/else prompt, but treat it like an intelligent human: state the goal, options and boundaries—and let it decide on its own.
Provide solid pre-collected context so the LLM can make good decisions reliably.

P.S.:

For those who prefer graphics over text to gain an understanding of something, here is a depiction of the overall information flow inside this feature.

The Art and Science of SAPUI5 in SAP Build: Insights from SAP TechEd 2025

2025-11-17T05:35:29.369000+01:00

At SAP TechEd Berlin 2025, we had the opportunity to present “The Art and Science of SAPUI5 in SAP Build.” The deep dive session explores how SAPUI5, SAP’s strategic UI framework, is transforming user experiences and developer efficiency across SAP. This blog post shares key takeaways from the session and questions from the audience.
If you’ve missed it, watch the session recording in AD106v | The art and science of SAPUI5 in SAP Build.

The Art of SAPUI5 in SAP Fiori User Experience

SAP’s approach to user experience (UX) centers on making applications easier and more enjoyable to use, helping users accomplish their tasks with greater efficiency and satisfaction. The framework enables the SAP Fiori design system to evolve seamlessly across SAP solutions, providing flexible tools for developers to efficiently build apps using SAP Build Code.

SAP Web Components: Bridging Frameworks and Enhancing Extensibility

SAP Web Components extend the capabilities of SAPUI5, to other programming model, such as Angular, React, or Vue. This interoperability supports a consistent and streamlined UX throughout the SAP portfolio. SAP Web Components can now also be easily consumed in SAPUI5 apps just like regular controls. Going forward, SAP plans to provide new UI elements as SAP Web Components, minimizing the effort required for adopting new standards and ensuring compliance with SAP guidelines and modern Web standards.

SAPUI5 is leading is the Way in Accessibility

SAPUI5 is at the forefront of accessibility, with recent implementations (SAPUI5 1.136 and UI5 Web Components 2.9.0) aligned to the latest Web Content Accessibility Guidelines (WCAG) 2.2. This commitment ensures that applications built with SAPUI5 are inclusive and accessible to users worldwide, meeting diverse needs and regulatory requirements.

The Science of SAPUI5 in SAP Build

SAP Build is SAP’s unified solution to build apps and extensions, automations, agents and digital workspaces. SAP Build helps to increase developer productivity and to future-proof IT investments by leveraging proven technologies like SAPUI5, SAP Fiori elements, CAP and ABAP Cloud.

Extending SAP standard apps with SAPUI5 flexibility and Clean Core

SAPUI5 flexibility enables upgrade-safe, clean core extensions with intuitive low-code/no-code tools for different personas: end users, key users, and developers. New capabilities include consistent text changes for field labels and a “What's New” / “UI Adaptation Tour” for key users. Developers creating adaptation projects benefit from a "Replace original tile option and coding efficiency with TypeScript and Joule.

The new SAPUI5 runtime repository accelerates patch updates, improves startup performance, and supports zero-downtime deployments.

Future-Proofing apps with UI5 best practices and UI5 linter

Technical debt and legacy code can slow down innovation within SAP Fiori projects. Here the UI5 linter helps finding and fixing the usage of deprecated APIs and making your code is ready for upcoming SAPUI5 versions. The new SAPUI5 / OpenUI5 legacy-free version helps validating how compliant your code is to UI5 best practices, i.e. ensuring your code is state of the art and future-proof.

AI-Powered Development: Joule Copilot and MCP server

AI is revolutionizing SAPUI5 development. The Joule copilot accelerates app creation, view and control addition, code formatting, migration to TypeScript and much more. The UI5 MCP server enables agentic AI app development in SAP Build, combining generative AI with algorithmic logic if the UI5 linter.

Key Takeaways

SAPUI5 delivers a streamlined, consistent UX across SAP Business Suite, driving both user satisfaction and business outcomes.
SAP Build and SAPUI5 flexibility empower organizations to extend SAP standard apps efficiently, future-proofing their investments.
AI-powered tools accelerate development and let you future-proof your apps with UI5 best practices.

Selected questions from the audience

Q: Is Using VS code still recommended or the SAP Build for development

A: In addition to the turnkey solution of SAP Build running on SAP BTP, SAP plans to focus on releasing development tools on the VS Code marketplace. VS Code is the number-one IDE worldwide, especially among web, cloud, and full-stack developers. Investing more in VS Code helps SAP meet developers where they are, making it easier for new developers to adopt SAP technologies (such as CAP, SAP BTP, SAPUI5, ABAP Cloud).

Q: New controls will be components from now on?

A: Exactly, SAP plans to deliver most new UI components as Web Components, which can be use across any Web framework, including SAPUI5.

Q: How AI compatibilities work in more complex application

A: Beyond Generative AI capabilities, agentic development tool (e.g. with the UI5 MCP server) offer impressive results for developing complex (fullstack) apps, from design up to deployment. You might want to check out Inside Joule: Lessons from building an AI coding assistant for SAP Build for an inside view.

Q: What is the benefit of using the Web Components from the example compared to sap.m.Input?

A: Please continue using SAPUI5 controls if they fulfil your needs. There is no change to that. Most upcoming, new UI elements will be provided as Web Component, serving *all* technology stacks, including SAPUI5.

Q: What are Components bringing when compared to Classic controls if we are using UI5 only approach

A: see above

Q: how will be the future scope of Fiori elements applications over ui5, do both will have same scope

A: SAP Fiori elements is an option to develop SAPUI5 app more efficiently. SAP recommends using as much SAP Fiori elements as possible and as much freestyle SAPUI5 as needed. This is what we do in SAP as well. Check out the SAP Fiori Development Portal on more details.

Q: What would be best approach to extend freestyle standard Fiori apps? Also, will adaptation projects have more extension powers?

A: SAPUI5 flexibility to the strategic way to extend/adapt SAPUI5 apps. The UI5 team continues to invest a lot in this area, as it is top priority for many partners/customers. SAPUI5 flexibility covers freestyle SAPUI5 as well as apps built with SAP Fiori elements. Adaptation projects offer best capabilities to create future-proof app extensions.

Q: Will the Build Code Joule CoPilot also support the Vibe Coding with MCP in the future?

A: Yes, SAP plans for vibe coding tools (incl. MCP servers) in SAP Build to empower business users to create application prototypes and start new SAP solutions without heavy coding knowledge.

Q: SAP develops SAPUI5 while promoting low-code tools like RAP, CAP, and key user adaptations. Isn’t it inconsistent to advance the core framework while encouraging less direct UI5 development?

A: Key user adaptation as well as metadata- / annotation-driven apps on RAP/CAP (using SAP Fiori elements) all use SAPUI5 as their UI technology. Innovations ‘in the UI’ are built in SAPUI5, benefitting all these models. Also, there remains a strong use case for a freestyle SAPUI5 implementation approach for apps which cannot follow the patterns of SAP Fiori elements.

Q: As a partner, if we build an SAPUI5 application and deploy it to customer systems, can SAPUI5 flexibility be used to create customer specific adaption projects for it?

A: This is planned for Q4/2025: Developer adaptation: enabling customer and partner applications for adaptation projects (As always with forward-looking statements, this is subject to change.)

Q: The build errors just prove you are really building live and not faking it. 🙂

A: Right. Not sure though whether Tommy enjoyed the moment 😉

Q: Now that CDS support UI annotations will UI5 become obsolete?

A: Definitely not. SAPUI5 remains SAP’s strategic UI framework. SAP Fiori elements with its annotations is built on SAPUI5. The annotations control what SAPUI5 is showing.

Discover the insights of your SAP BTP extension with SAP LeanIX

2025-11-17T17:10:00.036000+01:00

When joining SAP LeanIX in Q2 this year, the mission I was sent on was creating transparency on your custom-built applications and extensions on SAP BTP. As SAP LeanIX helps you not only to plan your landscape transformation, but as well to proactively identify and manage obsolete technology in your IT landscape, you need to have as much transparency as possible. That’s not only true for your standard software, but also the artefacts which make your company unique.

I’d like to bring together the story of what the great team I work with has provided throughout the year in the context of SAP BTP and combine it with what was already available in regard to self-build software, as all now comes together:

See what’s going on in SAP Build,
Know what has been deployed in SAP BTP, Cloud Foundry environment,
Dig into the tech stack of these deployments

See below how you can follow along.

Create an application with SAP’s Cloud Application Programming model

This is nothing new in the world of SAP BTP developers and inside this community. Thus, I simply followed https://developers.sap.com/tutorials/hana-cloud-cap-create-project..html which gave me an application based on https://cap.cloud.sap/docs/about/. Two things I did which are important for moving along:

I synced the artifacts to github.com,
I deployed the CAP application to SAP BTP, Cloud Foundry runtime.

Both should bring this closer to reality of non-tutorial-based developments. So far, for the typical SAP BTP consumer, this is an old hat, right? Therefore, I’d like to bring in the angle of the enterprise architects (EA), who want to see what custom applications are built and which technologies are being used, so that it’s easier to keep track of these details. This is where SAP LeanIX Application Portfolio Management (APM) comes into the picture.

Keep track easily

Your EAs want to keep track of what’s going in your company's technology stack. Continuing on the flow, connect your SAP Build instance which is used for production-related extensions to SAP LeanIX APM. This will provide you transparency on what SAP Build projects exist and will suggest modeling your SAP BTP account structure along LeanIX’s BTP modeling best practices.

The SAP Build Code project is suggested to being created as an “Application” fact sheet. It is based on SAP Build Code, hence two related “IT Component” fact sheets are suggested. SAP BTP, your global account, and the subaccount are recommended as 3-leveled ”Platform” fact sheets. Let’s wait with its creation though.

While this is nice, it won’t give you any insights into the actual Cloud Foundry applications and the SAP BTP services you use. This is where you want to connect SAP BTP, Cloud Foundry environment of your global account to SAP LeanIX APM. The good news is that you only need to setup one integration per global account to APM and it will enable you to crawl all the Cloud Foundry spaces and organizations inside of it. As long as you use the same platform user + IAS certificate + password, the integration will fetch details about deployed applications and their bound SAP BTP services.

Following the above tutorial, the discovery inside my Cloud Foundry space looks like this:

Diving into one application, it reveals you

the deployed CF application,
if it’s part of a multi-target-application, the recommendation is creating a fact sheet for that too,
the bound SAP BTP services suggested as IT components
the Cloud Foundry buildpack including its version.

Go ahead and create the two “application” fact sheets and the IT components. The fact sheet for the actual deployment will be of the subtype “Microservice” and its MTA will be the “Business Application” subtype.

To combine the SAP Build Code “application” fact sheet with the MTA, you can edit the suggested line item of the SAP Build Code discovery item to point to the MTA fact sheet. That will give you the transparency of the used SAP BTP services as part of your deployment and the SAP Build project details.

After creating the other two applications of the CF MTA to your inventory and linking it to the MTA-fact-sheet, you have the insights into your CF-based & SAP-Build-Code-created application:

Knowing the inside

This takes you already quite far when it comes to making your SAP BTP, Cloud Foundry deployments transparent for the enterprise architecture team. With this modeling, it’s easy to identify which applications across all deployments in BTP use which build pack version. Once the build pack ages, application owners can be asked to update.

This might not be enough though for mitigating technology risks and compliance upfront. An add-on to SAP LeanIX APM addresses exactly this gap. Let’s explore how to extend the above use case with SAP LeanIX Technology Risk and Compliance.

Add the Software Bill of Materials (SBOM) to the mix

“Software Bill of Materials (SBOM) files play a vital role in managing and understanding dependencies among microservices. These files, typically adhering to the widely-used System Package Data Exchange (SPDX) or CycloneDX format, provide a comprehensive inventory of all software components, libraries, and modules used by a microservice.” (source)

Let’s blend these into the above Node.js tutorial. For the three deployments, I used CycloneDX to generate three individual SBOMs (there are more open source tools to check out):

for “MyHANAApp-srv” one in the folder “gen/srv”,
for “MyHANAApp-db-deployer” in “gen/db”, and
for “MyHANAApp” in “app/router”.

In the end, the mta.yaml tells you where to generate these SBOMs. Run cyclonedx-npm -o sbom.json in each folder to store the SBOMs in separate JSON files. After setting up your LeanIX workspace for the self-build software use case, you can push it to the fact sheets of each application created beforehand with the path:

https://{SUBDOMAIN}.leanix.net/services/technology-discovery/v1/factSheets/{factSheetId}/sboms

The exact details are well documented. Pushing these to your fact sheets will give you insights into which libraries and frameworks are being used inside every application (see details in the tech stack discovery documentation). This allows you to proactively address technical risks. Here is how it looks like for the above “MyHANAApp” in the LeanIX relations explorer:

It blends the SAP BTP services, the used Cloud Foundry buildpack, and used libraries inside the deployment. All the details of the Node.js dependencies can be listed in the SBOM explorer:

Update (20.11.25): Tracking the CAP-versions

This might be telling the obvious, but I want to highlight it after my first discussions on the blog post: when you follow along this tutorial and you analyze the SBOM components e.g. of “MyHANAApp-srv”, you can see the version of CAP. In the side panel, you can then see which other microservice applications are based on that version, hence identify who's still using outdated CAP versions. Just saying...

Mission accomplished

That’s it. It’s quite a bit indeed, but now I have the full insight into

where did I create the CF MTA app,
where is the app deployed, and
which tech stack is this built on.

For regular updates of the SBOMs, you can integrate their generation and push to the API endpoints in your CI/CD pipeline. For CI/CD, use the SAP BTP CI/CD service or create a Github-actions-based flow and the transparency of your tech stack will stay up-to-date.

Let me know of your comments and feedback here in the community! The team and I are now looking into the same storyline for SAP BTP, Kyma runtime. Furthermore, I want to bring in the transformation flow for classical on-stack extensions.

For both, I’d love to hear your thoughts!

SAP Fiori development newsletter November 2025 (issue #37)

2025-11-19T15:59:31.079000+01:00

We are in the midst of “conference season”, so this means lots of great announcements about new innovations. See the events section below for details on the European and U.S. iterations.

If you are looking to try the latest AI-powered development tools, such as MCP servers, please join us at our next SAP Fiori Innovation Day in Walldorf on December 9. This is a great way to learn about where to focus your learning resources in 2026 and what tools you can use to accelerate your development projects.

For ongoing updates, I encourage you to join our monthly SAP Fiori development roundtable. Register online or email me for an invitation.

If you prefer to receive this in your inbox, please subscribe to the SAP Fiori development newsletter.

Development news

Introducing the SAP Fiori Development Portal
In this 6-part series, Katrin Polloczek and Marcel Waechter provide a thorough look at the new SAP Fiori development portal, which replaces the Flexible Programming Model Explorer. The series covers building blocks, floor plans, extension options, custom pages, and how all these pieces fit together. Read more.

Installing SAPUI5 patches is now better in every respect
For years, the MIME repository has been the standard location for storing SAPUI5 runtime artifacts for SAP S/4HANA and SAP S/4HANA Cloud Private Edition. Although the MIME repository has served its purpose, many customers working with SAPUI5, especially system operators installing new SAPUI5 patches, face challenges. Now, the UI5 team introduces the SAPUI5 Runtime Repository to improve this in every respect: Angelika Kirilin explains.

Goodbye UI5 tooling - Hello UI5 CLI
Over the last decade, UI5 Tooling became the best-in-class tool to develop UI5 projects. It offers a range of features to make your life as a developer easy when serving and building projects. It turned out that the name UI5 Tooling led to much confusion and even support requests. The UI5 team settled for a new name "UI5 CLI" to align with industry best practices. See details.

Start your SAPUI5 coding journey in the SAPUI5 Demo Kit
The SAPUI5 SDK, or the Demo Kit, is the one-stop shop for modern developers who want to build state-of-the-art enterprise-grade SAP applications. Discover the features.

Streamlining local app previews: virtual endpoints for seamless development
In traditional app development setup, local app previews and testing rely heavily on physical sandbox files. While this method provides a level of consistency and stability, it often falls short in terms of up-to-dateness and maintenance effort. This post explores a new approach to local app previews and testing, which can now be virtually served by middleware. Learn more.

Events

Register for SAP Fiori Innovation Day in Walldorf (customers and sponsoring partners only):
https://events.sap.com/eur-fiori-innovation-day-walldorf-2025/en_us/home.html

In case you missed it

SAP TechEd summary articles
ASUG Tech Connect in Louisville, Kentucky, USA, had lots of great content on vibe coding, the evolution of SAP Fiori, and lots of hands-on sessions to test SAP’s latest development tools and technologies.

The art and science of SAPUI5 in SAP Build
If you’re an SAPUI5 developer and couldn’t attend SAP TechEd in Berlin, here’s one highlight you can watch as a replay: A deep dive session on “The art and science of SAPUI5 in SAP Build”: https://www.sap.com/events/teched/virtual/flow/sap/tev25/catalog-virtual/page/catalog/session/1752166265407001r3vW

Back issues from the past year

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)

SAP Fiori development newsletter January 2025 (issue #32)

SAP Fiori development newsletter November 2024 (issue #31)

TechEd Recap: Creating AI-Enhanced UX for Your Own Applications with SAP Design System

2025-11-20T15:55:07.560000+01:00

By Sophia Levens and Thomas Reiss

We were thrilled to speak at this year’s TechEd conference in Berlin on how the SAP Design System is powering the next generation of AI-led product design. Our Deep Dive talk entitled “Creating AI-enhanced UX for your own applications with SAP Design System” focused on three key areas: an introduction into the SAP Design System, new AI patterns for the design system and SAPUI5, and our AI-powered tools for our UI technologies. We then closed the session with an overview of the resources available to designers and developers today.

Below we’ll share a recap of the major points and announcements from the session. You can also watch the recorded session here.

Introduction to the SAP Design System

The overall mission of the SAP Design System is to unify and advance the SAP user experience. We achieve this in two ways:

Unify: The SAP Design System serves as the central hub of ready-to-use assets, guidance and standards for building delightful experiences that are consistent across the SAP portfolio. This is how we directly contribute to SAP’s Suite-First strategy.
Advance: The SAP Design System provides the essential patterns and tools to embed transformative AI experiences across all products and touchpoints. This is how we directly contribute to the AI-First goal.

What exactly is a design system?

In order to deliver consistent and inclusive UX, the SAP Design System is made up of the following elements:

Design Language: The most foundational elements that go into any brand. For example, color, type, iconography, illustrations, etc.
Components: The building blocks for creating user interfaces, like buttons, drop down menus, or input fields.
Patterns: Covers a use case or user flow, things like exporting data to PDF or a search workflow.
Floorplans: A full UI layout. Typically, floorplans are a complete page or even span several pages.

The SAP Design System extends across SAP. It helps to unify all touchpoints across the SAP brand including our products, our digital experiences like sap.com, and other marketing and communications including interactive events like TechEd. And because the system is open source, our customers can also use the design system to build upon and customize our products and platforms.

What UI technologies are supported with the SAP Design System?

For each element in the SAP Design System, we build reusable components in code that developers can leverage to accelerate their workflow. There are two ways to leverage SAP technologies—via “floorplans and building blocks” or “freestyle”.

Build “freestyle” with SAPUI5 and SAP Web Components: Freestyle allows you full control of every element on the screen.
Use “floorplans and building blocks” with SAP Fiori Elements: This lets you accelerate development when the desired app or workflow is close to one of the out-of-the box floorplans or building blocks.

Because both of these choices are based on SAPUI5, you don’t have to choose one or the other, you can mix both ways of developing leveraging each when needed.

New AI Patterns for the SAP Design System and SAPUI5

SAP is proud to offer AI components and patterns for web and mobile. We’re investing in making it easy to design and build great AI experiences that are responsible, flexible, and work across ecosystems. Our AI experience principles are built on the following six pillars: design for clarity, earn trust, give control, design fairly, boost flow, fail-safe.

Find the latest AI patterns and components:

Our AI components and patterns have gone through the process of reviews and testing by our experts in user assistance, accessibility, user research, and are compliant with SAP’s legal and ethical AI standards. These are patterns you and your users can trust.

Using our AI-powered UI Technologies to Help You Build Faster

We have introduced powerful AI tools to help you build UIs and applications faster.

SAP Joule for Developers is a collection of embedded AI capabilities for SAP Build as well as for ABAP, delivered through Joule, that accelerates development of apps and extensions, reduces costs, and improves developer proficiency.

The SAP Fiori tools project accelerator, which can be started from Joule in SAP Build Code, enables developers to create CAP-based (Cloud Application Programming model based) SAP Fiori elements applications directly from an image of the intended outcome. These images can be high fidelity Figma models, lower fidelity screenshots or a sketch on paper. Simply upload the image and use AI to generate the data models, services and the UI. Find out more in this blog post: From idea to app: using AI-powered Project Accelerator to develop SAP Fiori apps.

Generate a complete CAP-based application from a sketch with SAP Fiori tools project accelerator: data models, services and UI.

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 equip developers with valuable support by providing AI agents with comprehensive UI5 and SAP Fiori elements knowledge, including best practices and project-aware context information.

Read about the new MCP servers in these blog posts:

Key Takeaways

This deep dive session gave an overview of how customers and partners can create AI-enhanced UX for their own applications with the SAP Design System and SAP’s UI technologies. Find everything you need to get started designing and developing:

Get started with the SAP Design System portal.
Use SAP's UI kits with the new AI patterns.
Use SAPUI5.

Driving Extensibility, Innovation and Automation with SAP Build's Clean Core

2025-11-21T13:53:48.961000+01:00

Below you'll find a summary of what was discussed during our latest Clean Core webinar, led by NTT Data, looking into ways to extend SAP environments and accelerate innovation through SAP Build's Clean Core methodology.

🗓Agenda Highlights and session recap 🗓

Current context: The importance of Clean Core in SAP S/4HANA modernization
A Clean Core strategy keeps the SAP S/4HANA system free from heavy customizations that complicate upgrades. By reducing technical debt and streamlining updates, organizations gain more stability and agility. This approach lays the foundation for continuous innovation and smooth cloud adoption.
Overview of SAP’s Side-by-Side extensibility strategy: Pro-Code and Low-Code/No-Code
SAP's side-by-side extensibility allows organizations to innovate without modifying the core system. It offers both pro-code development for complex scenarios and low-code/no-code tools for business users. This ensures fast, secure innovation while keeping extensions isolated and easy to maintain.
Tools and frameworks for Pro-Code and Low-Code/No-Code developers
SAP BTP provides a unified set of tools supporting both professional developers and low-code/no-code creators. Pro-code users access advanced IDEs and SDKs, while business users work with visual development tools. Together, these frameworks accelerate development, enhance collaboration, and ensure secure, scalable extensions.
Main components: Build Apps, Build Process Automation, and Build Work Zone
The SAP Build suite includes three main elements that empower users across the organization. Build Apps enables rapid app creation, Build Process Automation streamlines workflows, and Build Work Zone centralizes access to applications and information. Combined, they create a cohesive digital workplace experience.
Basic principles of SAP Build Apps
SAP Build Apps focuses on visual, intuitive development to make app creation accessible to more users. It provides drag-and-drop tools, pre-built templates, and seamless integration with SAP and non-SAP systems. With cloud-native deployment and Fiori-aligned design, it supports user-friendly, governed, enterprise-ready innovation.

You can find in the link below the slides shared during the presentation with all of the content presented today by NTT Data.

Link to presentation

⁉️Still curious about clean core? ⁉️

✅Contact your BTP Customer Success Manager for further discussion

✅ Visit SAP Discovery Center Missions on BTP

Is AI Just a Power Tool for Enterprise Software?

2025-11-21T14:03:48.290000+01:00

We all remember that feeling – watching our friends build a little wood house next to the sandbox, marveling at how quickly they could assemble it with all the power tools available. Similarly, we can build a small tool shed in a weekend – a quick project with readily available resources. But try to build a 2-car garage, and suddenly the reality hits: it’s a vastly more complex undertaking. Even with every tool imaginable, you'd spend countless hours watching YouTube videos, improvising solutions, and inevitably missing crucial details – resulting in a structure that doesn’t meet the family council's standards.

That’s precisely how AI currently operates in enterprise software development. It can be an amazing “power tool” – accelerating routine tasks and suggesting code snippets. But it fundamentally cannot build a complex, robust software system on its own.

Let’s break down why. The garage analogy is a powerful one because it illustrates the difference between rapid assembly and true, lasting construction. AI can certainly suggest a quick solution for a simple function – like generating boilerplate code or completing a basic API endpoint. However, building a 2-car garage requires deep understanding of structural engineering, material science, and local building codes. Similarly, complex enterprise software projects demand architectural judgment, a comprehensive understanding of business requirements, and meticulous attention to detail – qualities that currently reside firmly with human developers.

AI coding assistants speed up routine tasks (boilerplate, suggestions, small functions) but lack long‑range architectural judgment, project context, and ownership required to run an entire project end-to-end. AI is used for bigger, more complex tasks, is introducing architectural anti‑patterns, duplication which result in maintainability and accelerating technical debt.

Responsibility of the code and using AI at the right time is still the coders responsibility. An expert knows "when to use what tool to get the right result.” Treating AI as a simple productivity booster – not an autonomous architect – is crucial.

Ultimately, building complex software requires a deep understanding of the business problem and a commitment to maintainability and scalability – qualities that are currently beyond the capabilities of AI. Just as you need a structural engineer to design a garage (or a house), developers need architectural expertise and rigorous testing to ensure the long-term success of any software project.

Don’t expect AI to build your garage (or House)– or your enterprise software system. Instead, view it as a valuable tool that can significantly enhance the productivity of skilled developers, but not replace them.

Building Pro-Code Extensions for SAP Mobile Start leveraging mobile native functionalities

2025-11-27T15:04:08.058000+01:00

We just concluded this year's SAP TechEd with two very insightful in-person events – SAP TechEd 2025 in Berlin (Nov 4–5) and SAP TechEd on Tour Bangalore (Nov 25–26). As depicted in the announcement blog post of my colleague Thilo Berndt, the mobile topics were again very well covered in various sessions and activities. As part of which, we were conducting a Hands-on Workshop both in Berlin and Bangalore called "CA260 – Learn how to build your own app and use it in SAP Mobile Start", which we would like to recap in this blog post and highlight the most interesting technical aspects.

Overview

SAP Mobile Start is the native entry point to the SAP Business Suite, to all relevant business processes, data, and content. It provides access to native or web-responsive business apps along with other content and critical business information. This includes notifications and consolidated views on tasks, approval workflows, and SAP S/4HANA situations. SAP Mobile Start provides business information from SAP Start, SAP Build Work Zone, standard edition, and SAP Build Work Zone, advanced edition. Non SAP content can be integrated as well. It runs on iOS, iPadOS and Android devices, on watchOS and Wear OS devices, and on Apple Vision

While one significant aspect of SAP Mobile Start is to provide access to SAP’s role-specific standard content, such as business applications and tiles exposed from SAP S/4HANA via SAP Build Work Zone, this year’s SAP TechEd Hands-On Workshop CA260 centered on the ease of building pro-code extensions using SAP Build and specifically SAP Build Code with the SAP Cloud Application Programming Model (CAP). Participants were able to experience the necessary steps in building and deploying such a pro-code extension, as well as how to specifically utilize mobile native capabilities within that extension, such as Widgets (e.g. on the iOS Home and Lockscreen) and (Push) Notifications.

The session material and exercises are available on Github within the repository SAP-samples/teched2025-CA260. We do highly recommend checking out the exercises and trying them out on your own development system environment. This blog post will provide a brief overview of the most important steps and technical activities.

Please note that the session material on Github as well as some screenshots and code snippets in this blog post will contain usages of "###" as a placeholder for the participant number that was assigned in the hands-on workshop. Participants were instructed to replace these occurrences with their own participant number.

Building and Deploying the base version of the extension

The exercises started by building and deploying an initial version of the extension that the workshop is using as an example. As the initial version provided to participants, we are using a slightly modified version of the "Incidents Management" CAP sample application. The provided full-stack application and its dependencies are defined in the Multitarget Application descriptor (mta.yaml) which is being built and packaged into an mta archive (.mtar) during the build operation, which eventually gets deployed to the SAP Business Technology Platform (BTP), specifically SAP BTP Cloud Foundry environment. While the workshop is making use of SAP Build Code and its productivity tooling for developing full-stack applications with CAP, building the MTA project and deploying the build artifact to the SAP BTP, you can as well use your IDE of choice such as Visual Studio Code.

Screenshot: Overview of the project structure

With the deployment, the CAP application (in terms of the server logic) is running an application container on the Cloud Foundry Runtime. The UI of our full-stack application is realized using SAP Fiori Elements, which is generating the User Interface based on standard floorpans and UI annotations as part of the service definitions using CDS. The Fiori frontend application lives within the HTML5 Repository of the SAP BTP. While this would already be sufficient to expose our extension to SAP Build Work Zone and SAP Mobile Start as an application tile and run the frontend within the shell of SAP Build Work Zone using its managed Approuter, we want to have more control over the visual representation.

Frontend deployed to the HTML5 Repository; backend application deployed to Cloud Foundry

We can achieve this greater control by leveraging SAP Build Work Zone's content definition format – the Common Data Model (CDM). The definition of which is documented here and represents a standardized data structure for defining business apps, their visual representation, the required roles, and the logical hierarchical structure in which business apps shall be organized using a concept called "Spaces & Pages". Such CDM structure can be supplied to the HTML5 Repository during deployment of our extension. In the workshop's repository, this definition resides in the /workzone/cdm.json file.

Integrating the app into SAP Build Work Zone & SAP Mobile Start

For integrating our extension into SAP Build Work Zone, which makes it automatically available to SAP Mobile Start, we leverage a relatively new feature of the SAP Build Work Zone Channel Manager – defining a HTML5 Business Solution. While we could also create a regular Content Provider, using the new Content Channel type "HTML5 Business Solution" further simplifies the process as we are not required to manage any design-time destination. The HTML5 repository is merging all deployed HTML5 applications and their CDM definition from a common "Business Solution", making it available for selection as a joint Content Channel by the "Business Solution" dropdown.

Creation of a HTML5 Business Solution Content Channel in SAP Build Work Zone

This value used for merging multiple HTML5 application belonging to the same business solution is done via a dedicated property ("service" under "sap.cloud") in the web applications manifest.json. If you want to read more about HTML5 Content Consumption capabilities of SAP Build Work Zone, we can recommend this excellent blog post from our colleague Rupam who is part of the SAP Build Work Zone team.

{
  "_version": "1.65.0",
  "sap.app": {
    "id": "com.sap.ca260.###",
    "type": "application",
    [...]
  },
  [...]
  "sap.cloud": {
    "public": true,
    "service": "ca260###"
  }
}

After adding the Content Channel's role to our Site and making sure we have the role assigned to our desired users, we can see it exposed in SAP Build Work Zone using the browser as well as in SAP Mobile Start – Nice! As defined in the /workzone/cdm.json file, the application tile of our built extension is placed onto a Page with the title "Apps from Participant CA260-000", which itself is available under a Space named "Extensions from CA260".

Deployed application visible in SAP Build Work Zone and SAP Mobile Start

Extending the app to make use of Widgets on your mobile device

The steps to extend now our application in order for it to be configurable as a Widget, for example on the iOS Homescreen or the Lockscreen, are actually much easier than you might think. SAP Mobile Start offers multiple types of Widgets. The one we will be using here is the "Business Info Widget", which can be configured to display any KPI that is available to SAP Mobile Start. In technical terms this means that we need to enhance the application tile of our extension to become a "Dynamic App Launcher". In the simplest case, these are tiles showing a number coming from a connected data service. In more complex scenarios, these can also display criticalities, trend and more information around the selected KPI.

The process to transform our basic tile into a Dynamic App Launcher is fairly simple. Within our web application's manifest.json file, we can add the required definition to make it such a dynamic tile and connect it to our OData service for incidents available in our CAP application. For our example, let's point to the OData count of incidents and filter for incidents that are not in status closed using the status_code property. The needed configuration resides within the inbound definition under the node "indicatorDataSource". In order to make this change visible on our environment, the updated version needs to be deployed and the Content Channel needs to be synced.

Transforming the application tile into a DynamicAppLauncher

As a result, our application now appears a KPI tile on our Site and in SAP Mobile Start and we can monitor the automatically updated value both inside of SAP Mobile Start – for example when accessing the Page or by adding the app into my favorites on the Start tab of SAP Mobile Start. This fact allows us to configure the same Dynamic App Launcher tile as a Widget, for instance to our iPhone's Homescreen.

Pro tip: Why not mirroring your iOS Widget of open incidents to your Mac or configure the same on your Apple Watch as a watch face complication?

The Dynamic App Launcher tile appearing in SAP Build Work Zone and SAP Mobile Start

Implementing our own (push) notifications

Let's now go one step further and implement our own notifications from our CAP application. The beauty of the integration via SAP Build Work Zone and SAP's notification framework leveraging the SAP Alert Notification Service on BTP is, that such notifications will automatically appear on our SAP Build Work Zone Site in the browser, in SAP Mobile Start under the notification bell as well as be delivered as a mobile native push notification to the mobile devices on which you use SAP Mobile Start. That's a game changer for informing your users about a time critical situation directly from your pro-code extensions.

For CAP based extensions, we can make use of the @cap-js/notifications plugin. The plugin communicates with the necessary APIs using a Destination that needs to be created in the SAP BTP Subaccount in which the application will run. By default it expects the name for the Destination to be SAP_Notifications if not configured differently. The values for this Destination can be retrieved from the Settings of SAP Build Work Zone (Administrator role required).

For sending actual notification from our CAP service, we need to define our desired NotificationTypes first in the /srv/notification-types.json. These defined types represent the blueprint for the actual notifications to be sent. They include the texts for the actual notifications in all the languages that shall be supported with dedicated placeholders which will be filled when the notification is actually triggered in the service logic. Below you can see an example for such a type:

{
    "NotificationTypeKey": "IncidentCreated",
    "NotificationTypeVersion": "1",
    "Templates": [
      {
        "Language": "en",
        "TemplatePublic": "New Incident created",
        "TemplateSensitive": "New incident created by {{customer}}",
        "TemplateGrouped": "Incident Status Update",
        "TemplateLanguage": "mustache",
        "Subtitle": "{{description}}"
      },
      {
        "Language": "de",
        "TemplatePublic": "Neuer Vorfall eingegangen",
        "TemplateSensitive": "Neuer Vorfall von {{customer}}",
        "TemplateGrouped": "Vorfall Status Änderungen",
        "TemplateLanguage": "mustache",
        "Subtitle": "{{description}}"
      }
    ]
  }

Sending actual notification is fairly easy and can be done with very few lines of code. We first need to initialize the notifications plugin with cds.connect.to('notifications'), which creates a handle with which we can send notifications later. Sending notifications can be done with the function alert.notify. Here, we reference the desired NotificationType (defined before), recipients and further properties and data related to this specific notification we intend to send.

Coding used to send notification when incidents are created and closed.

As a result, we receive a push notification at the event of incident creation and closure. Already in the push notification displayed by the mobile operating system, we see the defined texts from our NotificationType with the specific values filled for the specific incident object. When tapping on this push notification, SAP Mobile Start shows the full notification in the dedicated area of the mobile app. Using "Open in Browser" brings us to this specific incident in our SAP Fiori Elements application where we could take further action. This is achieved by supplying the Intent Based Navigation (IBN) information of our app – consisting of the Semantic Object and Action defined in our web application's manifest. This allows SAP Mobile Start and SAP Build Work Zone to open the right application as a navigation target from the exposed content – in our case, the SAP Fiori Elements application running the HTML5 Repository and exposed to SAP Build Work Zone using the HTML5 Business Solution Content Channel. The deep link to the specific incident object is achieved by supplying a special navigation target parameter that SAP Fiori Elements supports for opening the desired "Inner App Route" – in our example, the Object Page of a specific incident using its ID. Feel free to check out how this was done for this specific example in the repositories' code.

The notification details visible in SAP Mobile Start and the deep-link navigation to the SAP Fiori Elements application

Outlook

We hope we were able to show, how easy it is to create pro-code extensions, deploy them to the SAP BTP, integrate them into SAP Build Work Zone & SAP Mobile Start. The demonstrated examples of mobile native widgets and push notifications hopefully showed the ease of leveraging the mobile native device capabilities. Beyond the content of the CA260 Hands-On Workshop of SAP TechEd 2025, we would like to give you an outlook to what else would be possible with this basis.

The beauty of using the HTML5 Business Solution Content Channel Exposure in SAP Build Work Zone is that we have the flexibility and feature set of the Common Data Model (CDM) available. We could further extend the /workzone/cdm.json file to make use of even richer visualization capabilities – for example by defining a declarative UI Integration Card. Such cards allow to achieve UI richt micro-experiences right on the Page's structure, for example displaying a short list of incidents with the most important information to get a brief overview as a processor. In the browser when consuming the page via SAP Build Work Zone, the card is rendered as a regular SAP UI5 UI Integration Card. In SAP Mobile Start, declarative cards are supported as mobile native UI elements. With a single declarative definition of such a card using the UI Integration Card framework, we can achieve native cross-platform support with a high quality user experience directly within SAP Mobile Start.

Having a UI Integration Card added to the Page in SAP Build Work Zone and SAP Mobile Start

For further information on SAP Mobile Start related features and topics, please check our SAP Mobile Start documentation. Visit SAP Mobile Experience Community Page and click “follow” to get the latest development and innovation of our solutions. We look forward to hearing about your experience with these hands-on exercises; please do share your thoughts and comments below.

From MCQs to Real Skills: My Experience with SAP’s New Certification Format

2025-11-28T10:13:00.521000+01:00

What Exactly has changed ?

SAP is gradually moving selected certifications away from multiple-choice questions to a scenario-based, practical, hands-on evaluation model.

Instead of selecting the right choice in a MCQ pattern, you now :

Configure or Build something
Work on real scenarios
Receive a defined input and produce an output that is automatically validated against the expected outcome
Submit the output
Get evaluated automatically through AI-driven checks

Why I personally liked the format

✔️It rewards real experience

✔️No more memorizing dumps

✔️Open-book = Realistic

✔️Dumps are meaningless now

Who will benefit from this change ?

Experienced professionals
New learners
Employers
SAP ecosystem

Which certifications supports this New Format ?

SAP has rolled out the practical, scenario-based exam to six certifications:

Certification Portfolio with Practical Exam

Tips If You're Preparing for This New Exam

Practice hands-on tasks
Build small end-to-end examples
Use SAP Help effectively
Focus on solving problems, not memorizing

Conclusion

This new certification format is a huge step forward. It is fair, practical, and aligned with modern SAP project work. Focus on practice, not memory.

Bridging Data Quality Gaps in SAP SuccessFactors TIH with CSVValidationApp and Vibe Coding

2025-12-03T16:06:10.964000+01:00

Introduction

Data quality challenges in SAP SuccessFactors Talent Intelligence Hub (TIH) often go unnoticed until they impact user experience. When thousands of attributes are imported without proper validation, issues like HTML tags, broken formatting, and unescaped characters can disrupt Growth Portfolios and compromise analytics/employee experience. This blog introduces CSVValidationApp, a solution designed to bridge this gap using functional expertise and modern development practices like Vibe Coding—and opens the door for community collaboration on similar innovations.

Why This Matters

SAP Talent Intelligence Hub is a strategic enabler for skills-based workforce planning. It helps organizations create dynamic career paths, leverage AI-driven skill recommendations, and empower employees through Growth Portfolios. These capabilities unlock smarter talent decisions and a more agile workforce.

To fully realize these benefits, data integrity during imports is critical. According to SAP Help Portal, importing entities like attributes, tags, and behaviors into TIH requires strict adherence to structure and format. Common issues include:

Incorrect headers or missing mandatory fields in CSV files
Improper encoding (non-UTF-8) causing character display errors
Unescaped quotes or HTML tags in descriptions, which can truncate or break content
Large file sizes impacting performance (recommended limit: 25,000 records per file)
Incorrect date formats for proficiencyAssignedDate when updating Growth Portfolio attributes

These challenges can lead to incomplete or inaccurate data in the Attributes Library and Growth Portfolio, affecting AI-driven recommendations and user experience. Adding a validation step before import ensures clean, consistent data—reducing manual troubleshooting and enabling HR teams to focus on strategic initiatives.

My Perspective and Approach

Having worked extensively across implementations, integrations, and functional solution design in SuccessFactors, I’ve seen how small data issues can create big challenges downstream. This experience shaped my approach: build a tool that doesn’t just validate data but actively improves it before it enters TIH.

I chose Vibe Coding as the development approach because it accelerates delivery through real-time collaboration, instant previews, and iterative design—all within SAP Business Application Studio. This allowed me to focus on business logic and user experience rather than boilerplate coding, ensuring the solution was delivered quickly without compromising quality.

How CSVValidationApp Fits into the TIH Workflow

CSVValidationApp acts as a data quality gatekeeper in the integration process. In the following example workflow after data is exported from Integration Center, the file passes through CSVValidationApp for cleansing and validation. Once clean, the data is transformed and mapped to TIH-compatible attributes before being imported back into the system.

This workflow ensures that what enters TIH is not just valid but optimized for rendering and usability. The result? A clean, enriched skills library that supports AI-driven recommendations and future enhancements.

What Makes CSVValidationApp Powerful

CSVValidationApp performs comprehensive checks tailored for SuccessFactors Integration Center requirements. It detects encoding issues, validates structure, identifies problematic characters, and removes HTML tags and entities. Beyond validation, it offers auto-correction, generating clean content with proper quoting and escaping. A preview feature and detailed statistics give administrators confidence before import.

By automating these steps, CSVValidationApp transforms a tedious, error-prone process into a seamless experience—empowering HR teams to focus on strategic tasks rather than data cleanup.

Looking Ahead: Unlocking the Full Potential of TIH

SAP Talent Intelligence Hub is continuously evolving to help organizations stay ahead in a skills-based economy. Upcoming innovations include AI-driven skill inference, integration with external taxonomies, expanded APIs, and advanced analytics for workforce agility. These capabilities will empower HR teams to make smarter decisions and deliver personalized employee experiences.

Clean, validated data is the foundation for these advancements. By ensuring data integrity from the start, organizations can confidently leverage AI recommendations, predictive insights, and future integrations without disruption.

CSVValidationApp supports this vision by acting as a proactive data quality gatekeeper. Future enhancements will include AI-powered attribute correction suggestions, direct SAP API integration for one-click imports, and support for additional modules like Learning and Recruiting—making the process even more seamless and intelligent.

Getting Started

CSVValidationApp is built as an SAP Fiori application using SAP Business Application Studio. To run it locally, simply clone the ***REMOVED BY MODERATION***, install dependencies, and start the app.

Here is an example screen shot from the application. The Attribute text file I validate below had many data rows with competency description such as:
"1000009","de_DE","BUSINESS & TRANSFORMATION..","Sie planen Ihre Vorhaben, definieren herausfordernde Ziele und entscheiden mutig.Herausforderungen im &bdquo;VUCA“-Umfeld (Volatilität – Unsicherheit – Komplexität – Ambiguität) begegnen Sie aktiv und entwickeln eine klare Vision für Ihren Verantwortungsbereich.<a href= xyzurl target=_blank>Kriterien und Verhaltensanker</a> anzeigen.","COMPETENCY"

This description gets corrected to:

"1000009","de_DE","BUSINESS & TRANSFORMATION..","Sie planen Ihre Vorhaben, definieren herausfordernde Ziele und entscheiden mutig. Bei der Umsetzung agieren Sie lösungsorientiert, bewerten Ergebnisse und Prozesse und nehmen notwendige Anpassungen vor. Herausforderungen im „VUCA\"-Umfeld (Volatilität - Unsicherheit - Komplexität - Ambiguität) begegnen Sie aktiv und entwickeln eine klare Vision für Ihren Verantwortungsbereich. ","COMPETENCY"

Final Thoughts & Community Ask

Data quality may seem like a technical detail, but in reality, it’s a strategic enabler. By combining functional expertise with modern development practices, CSVValidationApp delivers a solution that not only solves today’s challenges but positions organizations for tomorrow’s opportunities.

I’d love to hear from the SAP Community:

Have you built similar tools using Vibe Coding or other rapid development approaches?
What other gaps do you see in data validation for SuccessFactors integrations, and how can we bridge them together?

Share your thoughts, examples, and ideas in the comments. Let’s collaborate to make data quality a strength, not a challenge.

Prompt-Driven Development: Building Full-Stack SAP CAP Apps from User Stories

2025-12-11T15:10:42.876000+01:00

Introduction

What if you could translate a business requirement into a functional, full-stack application with a single prompt?
How much faster could you deliver value if the foundational code and project scaffolding were generated for you in seconds?

This is the new reality powered by SAP Build Code and its integrated AI copilot, Joule.

As a turn-key environment on the SAP Business Technology Platform, it unifies the entire development lifecycle, from coding to deployment.

This post demonstrates how to build a full-stack SAP CAP application directly from a user story, showcasing how

generative AI is fundamentally reshaping the developer experience.

Business Requirement

Build an SAP CAP application based on the requirements in the user story below:

User Story

As a contract administrator, I want to create and manage contracts and ‘parties involved’ information in the system,

so that I can effectively track and handle legal agreements and ‘parties involved’ interactions.

Contracts can cover a vast range of agreements, such as sales contracts, service agreements and employment contracts.

Party involved: A ‘party involved’ is an individual, organization, or entity that purchases goods, products, or services from another party,

typically a business or seller.

Common attributes of a contract might include:

Contract ID: A unique identifier for the contract.
Party involved Identification Number: A unique identification number for the party involved.
Contract Type: The type of contract (e.g. sales, service, employment).
Start Date: The date on which the contract becomes valid.
End Date: The date on which the contract expires (if applicable).
Status: The current status of the contract (draft, active, expired, terminated, etc.)

A typical ‘party involved’ has the following attributes:

Party involved Identification Number
Party involved Name: It refers to the given name of a person or entity, or a label by which they are addressed or identified.
Party involved Address: It refers to a physical location where an individual, business, or entity is situated or can be reached.
Party involved Contact Information

Acceptance Criteria

Scenario 1: List All Contracts

Given I am logged into the contract management system, when I launch the SAP Fiori application to maintain contracts,

then I should be able to view the list of all the contracts in a list without pressing the GO button.

The list of all the contracts should have : Contract ID, Party involved Identification Number, Contract Type and Start Date.

The list of filters should include Contract Type, Contract Status and Start Date.

Scenario 2: View Contract Details

Given I am logged into the contract management system, when I select a specific contract from the list of SAP Fiori application,

then I should be able to view the contract details and parties involved information.

Joule's Generative AI-based SAP CAP App Development

Prerequisites

1. Create a New Project using SAP Build Lobby

Create a Project

Click the Application Tile

Full-Stack

Full-Stack Node.JS

Contract Management

Project Created

2. Build a Full-Stack CAP Application via Prompt

Click the created project to open it in SAP Business Application Studio

Open Joule From the Activity Bar and select the ’/cap-gen-app` slash command

Generate a CAP Application

Prompt the user story description(refer to Business Requirement section above) to Joule and click send.

Joule tackles complex tasks by breaking them into steps, each with a suggested prompt.

Diffrerent Steps

To simplify the process and provide full context, replace the content of each step with the complete user story prompt.

Then, save and run to generate each step's artifacts.

Accept the Code.

Accept the Code

Generated Artifacts

3. Add UI to the Application

Create a new Fiori elements Application.

Fiori Elements Application

3. Preview the Application

Click run to preview the Application.

Run the Application

The application’s preview is displayed.

Application Preview

Launch the contract management app.

Contract Management

Select a contract from the list to view its details.

Select Contract

Contract details

Conclusion

The journey from user story to a functional, full-stack application—once a multi-day endeavor—is now accomplished in minutes.

With SAP Build Code and its AI copilot, Joule, this dramatic acceleration signals a fundamental paradigm shift.

The developer's role is being elevated from the meticulous craft of writing code to the strategic art of guiding its creation.

Joule operates as the quintessential collaborator, executing the foundational groundwork to liberate developers to focus

on high-value business logic and innovation.

SAP Build Code is therefore more than a tool; it's the dawn of an era where the speed of technology finally

matches the ambition of business.

Further Information

SAP Build Code

#SAPBuildCode #Joule #SAPBTP

______________________________________________________________________________________________

Best Regards,
Anuradha Dhingan

SAP Fiori tools 2601 update – Mobile Device Preview, Building Blocks, and AI-Driven Productivity

2025-12-17T17:29:22.331000+01:00

With the latest SAP Fiori tools update 2601, we continue our focus on improving developer productivity, openness, and real-world usability. This release brings meaningful enhancements across previewing applications, managing system connections, building SAP Fiori elements–based UIs, and accelerating development with AI-powered tooling. At the same time, we’ve continued to refine the fundamentals in security, modelling, and extensibility.

Preview SAP Fiori Apps on Real Mobile Devices

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 when using @sap/ux-ui5-tooling version 1.19.1 or higher. By creating a new run configuration and enabling Remote Access, developers can expose the local preview. When the run configuration is started, 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.

This makes it significantly easier to validate layouts, navigation, and interactions exactly as end users will experience them without leaving the development environment.

Showcase for previewing a SAP Fiori elements app on iPhone

A New Connection Manager for SAP Systems in VS Code

Managing connections to remote SAP systems is a foundational task when working with SAP Fiori tools. With this release, we introduce the Connection Manager for SAP Systems as a dedicated Visual Studio Code extension. This new extension succeeds the previously integrated saved systems panel from the Application Modeler and provides a focused, extensible solution for handling system connections in Visual Studio Code.

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. Storing passwords is optional, and if stored, they are protected by the security policies of your operating system's credential manager.

By making this capability standalone and open source, it is now accessible to other extensions such as the Service Catalog extension, and open for community contributions.

Connection Manager

Expanded Support for SAP Fiori Elements Building Blocks

SAP Fiori tools continues to enhance the support for the building blocks which shape the framework of SAP Fiori elements for OData V4 and its flexibility you can use. It makes it easier to create and adapt applications using a structured, metadata-driven approach while keeping flexibility in design. In this update, the Page Editor gains additional capabilities that improve developer convenience when working with custom pages and sections.

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.

Together, these enhancements reduce friction when adapting applications and allow developers to work more confidently and efficiently with SAP Fiori elements–based UIs.

Rich Text Editor building block support in Page Editor

Enhancements Across the AI-Toolchain

AI capabilities continue to evolve across SAP Fiori tools, with a strong focus on usability and enabling deeper end-to-end changes from within the tooling.

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.

Continuous Improvements and Refinements

Beyond the headline features, this release includes a range of continuous improvements that strengthen the overall development experience. Newly created CAP applications now use NPM workspaces by default, establishing best practices out of the box and enabling the use of @sap/ux-ui5-tooling middlewares when previewing CAP-based applications.

The Application Modeler has been enhanced with additional SAP Fiori elements for OData V4 features, including support for hidden draft mode, improved configuration options for table create dialogs, and create support for custom fields in form sections. These additions give developers more control over application behavior without leaving the modeling environment.

Security and user management have also been strengthened. The ABAP Cloud connection type in the Connection Manager has been consolidated around re-entrance ticket authentication, moving away from service key–based authentication. This eliminates long-lived shared credentials and ties system access directly to the signed-in user, improving both security and maintainability.

Looking Ahead

We are already working on the next set of enhancements for SAP Fiori tools. Planned improvements include a rework and enhancement of OPA5 test generation, with added support for value help services and mock data generation. Project validation will be extended with new domain-specific ESLint rule sets, visualized directly in the Application Modeler, alongside support for ESLint 9.

Support for additional SAP Fiori elements building blocks, such as form and field, is also on the roadmap. On the AI side, we continue to improve the robustness and usefulness of responses from the MCP server, while the Project Accelerator will be extended to support RAP service creation.

As always, we look forward to your feedback and contributions as we continue to evolve SAP Fiori tools together with the community.

Tribute to Thomas Volmering

2025-12-23T11:06:24.578000+01:00

📢 Today is @thomas_volmering's last day at SAP.

Thomas joined SAP 26 years ago, and I met him when he was head of Product Management for SAP Build Process Automation, before he became Head of Product for SAP Build. Together we worked on many communication projects for SAP Build, including technical blog posts that you can read here. 📰

Let me just say that it has been a great pleasure and also some fun working with him, and I thank Thomas a lot for that. 🙏🏻

Please join me in wishing Thomas the very best for what's to come! 👍🏻

Enhancing SAP HANA Database Development with Generative AI Support for HDI Artifacts

2026-01-05T11:48:26.474000+01:00

Introduction

Authoring HDI (HANA Deployment Infrastructure) artifacts—such as tables, views, roles, and synonyms—often starts with a specification and ends with carefully structured definitions. This update streamlines the journey by adding a Joule icon directly in the editor. One click opens Joule with the /hdi-gen slash command preselected, so you can describe what you need in natural language and receive a ready-to-use HDI artifact definition.

What’s new

Joule icon in the editor: Visible when a supported HDI artifact file is active
One-click, context-aware start: Opens Joule with /hdi-gen preselected for HDI generation
Natural language to HDI: Describe the artifact you want and receive a valid HDI definition
Clear, safe application: Options to append to your file or replace its content

How it works

Open a supported HDI artifact file (for example, a table, view, role, or synonym).
Click the Joule icon in the editor title bar.
Joule opens with /hdi-gen preselected.
Describe what you want (for example: “Create a ROW table CUSTOMERS with ID INTEGER primary key and NAME NVARCHAR(100)”).
Joule returns a definition aligned with HDI best practices and your current file context.
Apply the result:
- Append adds content to the end of your file
- Replace substitutes the entire file content

The experience covers a broad range of HDI artifacts, including (but not limited to) tables, views, roles, synonyms, sequences, structured privileges, triggers, table data (hdbtabledata/csv), logical schemas, virtual tables, and related configuration files. The icon appears only when a supported file type is active and is opened in Code Editor.

Built-in guardrails

Native HDI syntax: No CREATE/DROP statements; output follows HDI file conventions
Identifier style: Uppercase identifiers by default, unless you specify otherwise
Table data: For hdbtabledata/csv, sample rows are generated without header lines

Why this matters

Reduce time from requirement to definition using natural language
Keep control: You decide when and how the result is applied
Maintain clarity: Generated content is visibly sectioned for quick review and versioning
Improve consistency: Definitions follow HDI best practices

Getting started

Open a supported HDI artifact file in your editor
Click the in-editor Joule icon(appears on top-right corner of the editor)
Describe your requirement and apply the result

This enhancement brings conversational HDI generation directly into your editor. With the Joule icon and /hdi-gen preselected, you can move from intent to artifact faster—without sacrificing clarity, safety, or control.

Supported artifacts

csv, hdbapplicationtime, hdbcollection, hdbconstraint, hdbdropcreatetable, hdbeshconfig, hdbfunction, hdbgraphworkspace, hdbgrants, hdbindex, hdblibrary, hdblogicalschema, hdblogicalschemaconfig, hdbmigrationtable, hdbprocedure, hdbprojectionview, hdbprojectionviewconfig, hdbpublicsynonym, hdbresultcache, hdbrole, hdbroleconfig, hdbsequence, hdbstatistics, hdbstructuredprivilege, hdbsynonym, hdbsynonymconfig, hdbsystemversioning, hdbtable, hdbtabledata, hdbtabletype, hdbtrigger, hdbview, hdbvirtualprocedure, hdbvirtualtable, hdbvirtualtableconfig, hdinamespace, properties

New Course Extending SAP Sales Cloud and SAP Service Cloud Version 2 using SAP Build Code

2026-01-12T16:39:44.616000+01:00

Happy new year SAP CX Community! Fernando here, checking in and kicking off a new SAP CX Integration and Extensibility blog post.

From last year onwards, our learning production focus is on SAP Sales and Service Cloud Version 2 extensibility and integration topics. Today, I'm delighted to announce in this blog post the next major learning milestone for those looking to master the extensibility of SAP Sales and Service Cloud version 2 with SAP Build Code.

So, please, join me in welcoming our newest addition to the SAP's learning platform:

New Course Extending SAP Sales Cloud and SAP Service Cloud Version 2 using SAP Build Code

If you're an extensibility developer looking to enhance SAP Sales and Service Cloud version 2 with mashups and microservices using your custom business logic, you've come to the right place. Here, you'll gain the practical knowledge needed to manage the entire end-to-end extensibility project.

We've structured our learning content to ensure that, after finishing this course developers and consultants will have the skills to code, deploy and configure mashups and microservices for SAP Sales and Service Cloud Version 2 using SAP Build Code.

Here's a glimpse of what it looks like:

Audience
The course is meant to be helpful for:

Developers
Technical Consultants
Architects

Learning Objectives
This course teaches how to build side by side extension apps with SAP Build Code to enhance SAP Sales Cloud and SAP Service Cloud Version 2. You’ll follow a practical development workflow covering app architecture, integration patterns, authentication, data mapping, testing, deployment, and maintenance.

Learning Content
The course consists of 3 units and provides more than 2 hours of content:

Exploring the Basics of Extending SAP Sales Cloud and SAP Service Cloud Version 2 with SAP Build Code
Introduces side-by-side extensibility, the core extensibility features, SAP BTP account types, creating a BTP subaccount with a booster, configuring the Cloud Foundry environment, and setting up the SAP Build Code development environment.
Creating a Mashup Webapp with SAP Build Code for SAP Sales Cloud and SAP Service Cloud Version 2
Guides through creating, deploying, configuring, and testing a mashup webapp from building a simple webapp and deploying it to SAP BTP Cloud Foundry, developing the mashup webpage, configuring the mashup within Sales and Service Cloud, and validating the integration,
Creating a Microservice with SAP Build Code for SAP Sales Cloud and SAP Service Cloud Version 2
Teaches how to create and integrate microservices covering developing, configuring, and testing a custom logic microservice and a custom key-metric microservice.

After completing successfully this course you'll be granted with a digital badge like this one which could be shared and linked to your social networks:

Try it today! we’re launching an exciting new series of extensibility learning content for SAP Sales and Service Cloud Version2, join us to boost your team’s skills and share feedback to help shape even better lessons.

Additional Resources
You can find a related live session on Extending SAP Sales Cloud version 2 with SAP Build. For additional free learning journeys and courses, visit the SAP Learning site for Integration and Extesibility to build in-demand SAP skills on a variety of topics, for the SAP CX Solutions portfolio. If you enjoy quick video learning, explore our Integration and Extensibility videos for SAP Customer Experience for the newest updates on integration and extensibility for SAP Customer Experience solutions.

SAP Fiori Development newsletter January 2026 (issue #38)

2026-01-15T15:50:00.034000+01:00

Happy New Year. If 2025 was the year of AI, what will 2026 bring? Likely more AI.

Some predictions:

Vibe coding will become more mainstream with MCP servers and LLMs working together to deliver more predictable and consistent results.
We will start to see the emergence of the “post-app” era in enterprise software. I don’t think it will be entirely chat-based, but I do expect some parts to be generated on demand.
The knowledge gap between developers who use AI and those who don’t will continue to grow. Now, the early adopters have a 1-year head start. For those who choose to remain on the sidelines, that will continue to grow. Don’t be that person – you need to start experimenting with AI, even if you don’t include the results in your production code

What are your predictions for 2026? Let us know or add to the comments below. If you want to discuss your thoughts with your fellow developers, I encourage you to join our monthly SAP Fiori development roundtable. Register online or email me for an invitation.

Development News

The complete 6-part SAP Fiori Development Portal blog series
In this 6-part series, Katrin Polloczek and Marcel Waechter explore the SAP Fiori development portal and how to use it. Topics include SAP Fiori elements, building blocks, extension options, custom pages, and how all these pieces fit together. Read part 1 – with links to all the posts.

SAP Fiori tools 2601 update – Mobile Device Preview, Building Blocks, and AI-Driven Productivity
SAP Fiori tools 2601 includes enhancements for previewing applications, managing system connections, building SAP Fiori elements–based UIs, and accelerating development with AI-powered tooling. In parallel, we continue to refine the fundamentals in security, modeling, and extensibility. See details.

Joule in SAP Build Code can now create freestyle UI5 apps
Last year, we introduced the SAPUI5 extension for the Joule coding assistant in SAP Build Code Over time, it has evolved to support conversion of UI5 apps to TypeScript and setting up new pages and the respective navigation. The latest improvement lets you create new freestyle UI5 apps according to your requirements, bringing the functionality right to developers using SAP Build Code—no other tools needed. Discover how it works.

Inside Joule: Lessons from building an AI coding assistant for SAP Build
This is a "making of" article about the implementation of the new /ui5-create-app slash command available within Joule in SAP Build Code. This new feature enables a conversation between an application developer and their AI assistant about building a new freestyle UI5 application. Learn more.

UI5 MCP Server's New TypeScript Migration Feature
The new UI5 MCP server will give you a massive head start on converting your existing JavaScript UI5 apps to TypeScript. A multi-day manual conversion becomes an hour of agent work plus several hours of polishing. The time savings add up with each project. Learn more.

Harmonizing UI5 URLs: Convenient URLs for SAPUI5/OpenUI5 CDN
When accessing the UI5 Demo Kit and when using UI5 in cloud scenarios, you use URLs like https://ui5.sap.com/. We are harmonizing these URLs to make them future-proof. See more details.

Events

SAP Fiori Innovation Day 2025 is a wrap. The final event in Walldorf included an overview of AI capabilities in SAP Cloud ERP, two hands-on exercises, and some great insights from the sponsoring partners. Learn the details.

We are planning more SAP Fiori Innovation Days in 2026. Watch your inbox for announcements about where and when we will be hosting these events.

Call for papers is open for SAP Sapphire 2026Call for Proposals open for 2026 SAP Sapphire & ASUG Annual Conference Orlando.
Share your success story or lead an interactive discussion with your peers.
Submit your proposal.

Back issues from the past year

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)

SAP Fiori development newsletter January 2025 (issue #32)

SAPUI5 – Pagination in Table on button click using S/4 Hana cloud oData service

2026-01-29T05:36:26.980000+01:00

Hi, in this blog I’m going to explain the pagination in Table with S/4 Hana cloud oData service with flexibility to control number of visible rows per page.

In this example, I am using S/4 Hana cloud oData service through destination. I have 621 records in Product entity set and by default, I have to display 10 records per click and user can change number of visible rows. So, I have placed four nav buttons for First page, Previous page, Next page and Last page with page count information and drop down for number of visible rows and then some magical code.

Firstly, create new front end web and mobile application with zproducts name.

In the canvas, give title as Products and remove bottom text.

Add Integration:

Go to Integrations tab and select add integration and then select BTP destinations under sap systems.

In BTP destinations, select our S/4 Hana cloud service destination i.e., S4HANA_Joule_Product and select A_Product entityset. Now Select install integration and enable data entity. You can browse real data by selecting browse real data. Click on save at top right corner.

Add Variables:

Now go to Variables tab and go to page variables and select add page variable and choose from scratch.

Add variable noOfVisibleRows with value type Number with initial value 10.

Similarly add variables totalNoOfRows with value type Number,

Variable currentPage with value type Number with initial value 1,

totalPages with value type Number with initial value 1 and

variable isRefresh with value type true/false with initial value false and Click on save at top right corner.

User Interface:

In User Interface, we install table with data adaptor from marketplace and assign our entity set to it to fetch the data and we will add new property to make table to load the data at each time when user clicks on nav buttons or change number of visible rows.

Go to User Interface tab and select marketplace and search for basic table with data adapter and install it. Drag and drop the basic table with data adapter to canvas and select configure and select A_product and add the required columns and in properties tab, at pagination in Object with properties, assign noOfVisibleRows page variable to page size, assign currentPage page variable to Page Number and click on save. Click on save and exit and save at top right corner.

Go to open in component template editor at bottom in properties tab and select properties and in properties, add new property Refresh of type true/false. Go to view and select add logic to Basic table with data adapter at bottom right corner. Drag and drop Receive event and select Internal property 'Refresh' changed and connect end of the receive event to start of get record collection. Click on save and exit. You can see Refresh property in properties tab.

Assign Refresh property with isRefresh page variable

Now select at page level and open logic canvas. Drag and drop record collection and connect to Page Mounted and assign A_Product to resource and for pagination make Include total count as true by selecting binding type as static values true/false.

Now drag and drop set page variable and select variable name as totalNoOfRows and assign formula outputs["Get record collection"].totalCount for value and connect end of get Record Collection top node to start of Set Page Variable node.

Similarly, drag and drop another set page variable for totalPages and assign formula CEIL(outputs["Get record collection"].totalCount / pageVars.noOfVisibleRows).

Add Nav Buttons:

Now drag and drop container at bottom of table and select layout as horizontal.

Drag and drop button inside the container and name it as First. For disabled, add formula IF(pageVars.currentPage > 1, false, true) and in logic convas, add two set page variables. One for currentPage and set the value to 1 and another for isRefresh and assign formula NOT(pageVars.isRefresh).

Similarly add another button inside the container and name it as Previous. For disabled, add formula IF(pageVars.currentPage > 1, false, true) and in logic convas, add two set page variables. One for currentPage and assign formula pageVars.currentPage – 1 and another for isRefresh and assign formula NOT(pageVars.isRefresh).

Add another button inside the container and name it as Next. For disabled, add formula IF(pageVars.currentPage < pageVars.totalPages, false, true) and in logic convas, add two set page variables. One for currentPage and assign formula pageVars.currentPage + 1 and another for isRefresh and assign formula NOT(pageVars.isRefresh).

Add another button inside the container and name it as Last. For disabled, add formula IF(pageVars.currentPage < pageVars.totalPages, false, true) and in logic convas, add two set page variables. One for currentPage and assign formula pageVars. totalPages and another for isRefresh and assign formula NOT(pageVars.isRefresh).

Drag and drop text after Previous button and for content add formula pageVars.currentPage + " / " + pageVars.totalPages.

Drag and drop Dropdown and give label text as No of Rows and select option list -> List of values and add value and give values 10, 25, 50, 100 and save. Make Placeholder text as empty.

In Logic pane of dropdown field, drag and drop set page variable and assign variable name to noOfVisibleRows and add formula IF(self.value, NUMBER(self.value), pageVars.noOfVisibleRows ) for value.

Similarly, drag and drop another page variable and assign currentpageno to it and value as 1.

Another page variable with totalpages and formula for value is CEIL(pageVars.totalNoOfRows / pageVars.noOfVisibleRows) and save at the top right corner.

Add another page variable with isRefresh with formula for value NOT(pageVars.isRefresh).

Preview Application:

Save at top right corner and click on preview and select open web preview. Now, you can see our application with pagination and flexibility to control number of visible rows per page.

By doing this, we can easily add pagination in Table on button click by consuming S/4 Hana cloud oData service with flexibility to control number of visible rows per page.

That’s it!!!

SAP Build Code – Technical Series – Feature Flags Service

2026-02-04T10:33:49.039000+01:00

The landscape of application development on the SAP Business Technology Platform (SAP BTP) has evolved significantly. With SAP Build Code, developers have a unified, AI-powered environment specifically tailored for SAP Cloud Application Programming Model (CAP), SAP Fiori, mobile, and SAPUI5 development.

However, SAP Build Code is more than just a IDE or a single tool. It is a cohesive bundle of services that streamlines the entire application lifecycle. From coding and testing to deployment and management. For many developers, the challenge isn't just learning how to write code; it is understanding how these various interconnected services fit together to create enterprise-grade solutions.

I am launching this blog series to demystify the different services around SAP Build Code offering. We will visit each service individually to understand its specific role, how it integrates with the core development environment, and why it matters for your projects.

Chapter 1: Features Flag Service

In traditional application development, "deploying code" and "releasing a feature" were often the same event. If you pushed code to production, the feature was live. If something broke, you had to scramble to rollback the deployment or push a hotfix.

As we move into the world of cloud-native development on SAP BTP, we need to separate these two concepts. This is where the SAP Feature Flag Service becomes essential. It provides the ability to toggle functionality on or off without changing a single line of code or restarting your application.

In this installment of these SAP Build Code series, we explore how Feature Flags can help in your application's rollout strategy.

What is the SAP Feature Flag Service?

At its core, the SAP Feature Flag service is a control mechanism that allows you to enable or disable new features at runtime.

The critical distinction here is runtime. Unlike configuration changes that might require a restart, feature flags happen instantly. This capability allows you to:

Control Code Delivery: Merge code into the main branch without exposing it to users immediately.
Synchronize Rollouts: Coordinate the release of a feature that spans multiple microservices.
Fast Rollback: If a bug is discovered in a new feature, you can disable it instantly via the dashboard rather than redeploying a previous version of the application.

Why is it critical for cloud native application scenarios? Because there is a specific challenge in cloud development: Synchronization.

In a monolithic application, you deploy everything at once. In a microservice architecture (common in projects on BTP), a single business process might rely on three different services running in separate containers.

Scenario: Service A is updated with new logic, but Service B isn't ready yet.
Without Flags: You have to hold back the deployment of Service A.
With Flags: You deploy Service A with the feature toggled "Off." Once Service B is deployed and agreed that it is ready for end users to be used, you flip the switch, releasing the feature across the entire landscape simultaneously.

Knowing what a feature flag does is simple: it is an on/off switch. However, knowing how to use that switch to improve your software delivery lifecycle is where the real value lies.

Before we dive into the code implementation, it is crucial to understand the different delivery strategies available. These techniques allow you to move from a "Big Bang" deployment model to a more nuanced, risk-averse approach suitable for modern enterprise environments on SAP BTP.

Here are the four key delivery techniques you can leverage:

1. Latent Code Delivery

This technique involves deploying fully functional code to production but keeping it hidden from the end-user.

How it works:

You implement a toggle point in your application code that wraps the new functionality.
This toggle point is associated with an inactive feature flag.
The code resides in the production environment, ready to go, but remains dormant until you decide to switch the flag on at runtime.

Why use it? The primary benefit here is risk reduction. The development and delivery of new features do not put the stability of the whole product at risk.

2. Synchronized Delivery

In the world of microservices and distributed services, a single business process often spans multiple distinct services. Releasing a feature that requires updates to three different services simultaneously can be a logistical nightmare.

How it works:

Different teams (e.g., Development Team 1 and Team 2) work on their respective components independently.
Both teams wrap their new logic in toggle points that check the same feature flag.
Each component is deployed to production as "Latent Code" whenever it is ready.
Once all components are live and verified, you activate the single shared feature flag.

Why use it? This decouples deployment from release. Team 1 is not blocked by Team 2. Developers can plan their tasks better, and the feature is only "released" when the entire distributed system is ready to support it.

3. Direct Delivery

Sometimes you don't want to release a feature to everyone, but rather to a specific group of trusted users. This is the foundation of "Beta Testing" or "Internal Access."

How it works:

You build logic in your application to identify different sets of users.
In the Feature Flag service, you configure a direct shipment strategy.
You use identifier query parameters to map specific users or groups to the enabled feature.

Why use it? This is ideal for validating functionality in production with a controlled audience. You can grant access to your internal QA team or a friendly set of "Beta" customers to gather feedback before opening the floodgates to the general public.

4. Percentage Delivery

When you are confident in the feature but unsure about the load it might generate, or if you simply want to perform A/B testing, percentage delivery is the technique of choice.

How it works:

You release the feature to a specified percentage of your user base (e.g., 5% or 10%).
The service randomly (but consistently) assigns users to the "On" or "Off" group.
You can even manage Variations, where you deliver Implementation A to 10% of users and Implementation B to another 10% to see which performs better.

Why use it? This is the ultimate risk mitigation tool. If the new feature causes a performance regression, only a small fraction of your users are affected, and you can dial it back instantly. It also provides data-driven insights, allowing you to choose the implementation that receives the most positive feedback.

---

Example:

We start with our Shop Service (Service A). It is currently running in production and doing exactly what it was designed to do: it takes a user ID and calculates a checkout for the user. (Remember that we are here to talk about feature flag service, so for simplicity, the code developed in CAP is a very basic one).

The service.cds file looks like this:

service ShopService {
    // Define the structure of the response
    type CheckoutResponse {
        userId : String;
        finalPrice : Decimal;
        message : String;
    }

    // Function now returns the Object defined above
    function checkout(userId: String) returns CheckoutResponse;
}

The service.js file looks like this:

const cds = require('@sap/cds');

module.exports = async function () {

    this.on('checkout', async (req) => {
        const { userId } = req.data;
        const randomAmount = Math.floor(Math.random() * 1000) + 1;

        return {
            userId: userId,
            finalPrice: randomAmount,
            message: `Checkout successful for user ${userId} with amount ${randomAmount}`
        };
    });
}

And when we hit the checkout endpoint, the following is retrieved:

{
  "@odata.context": "$metadata#ShopService.CheckoutResponse",
  "userId": "1",
  "finalPrice": 538,
  "message": "Checkout successful for user 1 with amount 538"
}

Now, the business has introduced a new requirement: Loyalty Discounts. We want specific users to receive a percentage off their total bill. However, the logic for determining who is a VIP and how much discount they get is complex. It involves checking history, tier levels, and region.

To keep our architecture clean, we decided not to build this logic inside the Shop Service. Instead, we are creating a dedicated microservice: The Loyalty Service (Project B).

We are now facing a classic distributed system problem:

Shop Service (A) needs to call Loyalty Service (B) to get the discount.
The Loyalty Service is being developed by a different team (or is simply not ready yet).
We cannot deploy the updated Shop Service until the Loyalty Service is live, or the Shop will crash when it tries to call a non-existent API.

This is the perfect use case for Latent Code Delivery.

We are going to update the Shop Service right now to include the orchestration logic. It will try to call the Loyalty Service. However, we will wrap that call in an SAP Feature Flag.

Flag OFF: The Shop Service acts exactly as it does today (Standard Price). It ignores the Loyalty Service completely.
Flag ON: The Shop Service calls the Loyalty Service, gets the discount, and calculates the new total.

This allows us to deploy the updated Shop Service today, even if the Loyalty Service doesn't exist yet. We are decoupled.

Now, let’s create a new feature flag:

With the flag created and disabled, now, let’s check the code being developed. In this implementation, we are modifying the existing checkout logic to support a new "Loyalty Discount" feature. However, we are wrapping this new logic in a Toggle Point so that we can control its release without redeploying the application.

We adapt the cds and js files:

service ShopService {
    // Define the structure of the response
    type CheckoutResponse {
        userId : String;
        originalAmount : Decimal;
        discountPercentage : Integer;
        finalPrice : Decimal;
        message : String;
    }

    // Function now returns the Object defined above
    function checkout(userId: String) returns CheckoutResponse;
}

const cds = require('@sap/cds');

module.exports = async function () {

    // 1. Connect to External Services
    const featureFlagService = await cds.connect.to('FeatureFlagService');
    const loyaltyService = await cds.connect.to('LoyaltyService'); // Connect to Service B

    this.on('checkout', async (req) => {
        const { userId } = req.data;

        // --- STANDARD LOGIC ---
        // 1. Calculate the base price (simulated random amount)
        let randomAmount = Math.floor(Math.random() * 1000) + 1;
        
        // 2. Default state (Standard Pricing)
        let finalPrice = randomAmount;
        let discountPercentage = 0;
        let message = "Standard price applied.";

        // --- THE TOGGLE POINT ---
        const flagName = 'loyalty-discount';
        let isFeatureEnabled = false;

        try {
            // Check the Flag status for this user
            const response = await featureFlagService.send({
                method: 'GET',
                path: `/evaluate/${flagName}?identifier=${userId}`
            });
            
            if (response && response.variation === 'true') {
                isFeatureEnabled = true;
            }
        } catch (error) {
            console.error(`[Feature Flag] Check failed: ${error.message}`);
        }

        // --- LATENT CODE BLOCK ---
        if (isFeatureEnabled) {
            console.log(`[Orchestration] Feature ON. Calling Loyalty Service for ${userId}...`);

            try {
                // >>> REAL CALL TO SERVICE B <<<
                // We ask Service B: "What is the discount for this user?"
                const loyaltyResponse = await loyaltyService.send({
                    method: 'GET',
                    path: `/getDiscount(userId='${userId}')`
                });

                // If Service B responds, we use ITS data
                if (loyaltyResponse && loyaltyResponse.percentage) {
                    discountPercentage = loyaltyResponse.percentage;
                    
                    finalPrice = randomAmount - (randomAmount * (discountPercentage / 100));
                    message = `Loyalty Applied! Service B gave you ${discountPercentage}% off.`;
                }

            } catch (error) {
                // FALLBACK: 
                // If Service B is down (or not created yet), we log it but don't crash.
                // This is crucial for "Synchronized Delivery".
                console.error(`[Orchestration] Failed to contact Loyalty Service: ${error.message}`);
                message = "Standard price applied (Loyalty Service unavailable).";
            }
        } else {
            console.log(`[Orchestration] Feature OFF. Skipping Loyalty Service call.`);
        }

        // --- FINAL RESPONSE ---
        return {
            userId: userId,
            originalAmount: randomAmount,
            discountPercentage: discountPercentage,
            finalPrice: parseFloat(finalPrice.toFixed(2)),
            message: message
        };
    });
}

At the very beginning, we establish connections to the two external services defined in our package.json.

FeatureFlagService: The service instance on SAP BTP Feature Flag Service that holds our flag configuration.
LoyaltyService: The new remote microservice (Project B) that calculates discounts.

Before executing any new logic, we ask the Feature Flag service if the loyalty-discount feature is active for the current user.

We send a GET request to the /evaluate endpoint, passing the userId as the identifier. This allows for Direct Delivery (e.g., enabling the feature only for specific users).
Notice the try/catch block around the flag check. If the Feature Flag service is down or unreachable, we catch the error and default isFeatureEnabled to false. This ensures the Shop Service never crashes just because the flag service is having a hiccup.

This is the core of the "Latent Code" delivery technique. The code inside the if (isFeatureEnabled) block is deployed to production but remains dormant until the flag is switched on.

If the flag is ON, we attempt to make a real HTTP call to the Loyalty Service.
We send the userId to Service B and wait for a calculated discount percentage.
If the Loyalty Service is down (or not even deployed yet), the catch block handles the error gracefully. The user simply gets the standard price, and the error is logged. This allows us to deploy Service A before Service B is ready.

Finally, the service returns the response.

If the flag was OFF, the user sees the originalAmount and a standard message.
If the flag was ON (and succeeded), the user sees the finalPrice and a loyalty message.

Now, with the flag off, we can see the following answer from our Shop Service.

{
  "@odata.context": "$metadata#ShopService.CheckoutResponse",
  "userId": "1",
  "originalAmount": 888,
  "discountPercentage": 0,
  "finalPrice": 888,
  "message": "Standard price applied."
}

If we enable our flag, it is expected that the process will fail, because service B is not developed yet. It is important that you enable the flags at the proper moment.

{
  "@odata.context": "$metadata#ShopService.CheckoutResponse",
  "userId": "1",
  "originalAmount": 220,
  "discountPercentage": 0,
  "finalPrice": 220,
  "message": "Standard price applied (Loyalty Service unavailable)."
}

Now, let’s develop Service B. In a separate project, we define the services and the logic.

service LoyaltyService {

    type DiscountResponse {
        userId : String;
        percentage : Integer;
        tier : String;
    }

    // The endpoint Service A will call
    function getDiscount(userId: String) returns DiscountResponse;
}

const cds = require('@sap/cds');

module.exports = async function () {

    this.on('getDiscount', async (req) => {
        const { userId } = req.data;

        // Default State
        let percentage = 0;
        let tier = 'Bronze';

        // Simulation Logic
        if (userId) {
            const id = userId.toLowerCase();

            if (id.startsWith('vip')) {
                percentage = 20;
                tier = 'Platinum';
            } else if (id.startsWith('a')) {
                percentage = 10;
                tier = 'Gold';
            }
        }

        console.log(`[Loyalty Service] Calculated discount for ${userId}: ${percentage}% (${tier})`);

        return {
            userId: userId,
            percentage: percentage,
            tier: tier
        };
    });
}

Now, after deploying our application, and knowing that we are confident enough to provide this new functionality to our end users, then we enable the feature flag.

After enabling it, and executing our checkout process, we can see that the new functionality is released.

{
  "@odata.context": "$metadata#ShopService.CheckoutResponse",
  "userId": "vip",
  "originalAmount": 889,
  "discountPercentage": 20,
  "finalPrice": 711.2,
  "message": "Loyalty Applied! Service B gave you 20% off."
}

Instantly—without restarting the Shop Service—the application behavior changes.

Shop Service detects the flag is active.
It opens the communication channel to Loyalty Service.
Loyalty Service receives the request, identifies the user as a VIP, and returns a 20% discount.
Shop Service calculates the final price and returns the "Loyalty Applied" message.

What we have just demonstrated is Synchronized Delivery.

In a real-world SAP BTP landscape, you might have the "Shop Team" and the "Loyalty Team" working on different sprints.

The Shop Team deployed their code (with the flag OFF) on Monday.
The Loyalty Team deployed their service on Wednesday.
On Friday, the Product Owner clicked "Enable" in the dashboard.

Both services started working together instantly, with zero downtime and zero code rollbacks. This is the power of decoupling deployment from release.

Enhancing our rollout experience:

We have successfully orchestrated our services, but right now, the feature is either ON for everyone or OFF for everyone.

In a real-world scenario, you rarely roll out a major new feature to 100% of your users immediately. You want to test it with a trusted group first—perhaps your internal team or a set of "Beta" customers. This is where Direct Delivery comes in.

We don't need to change a single line of code to achieve this. Our code is already sending the identifier (userId) to the service.

So, let’s open our feature flag in our feature flag instance and let’s define a Direct Delivery Strategy, in which we define that only users vip01, and a01, will be able to experiment this new feature.

Now, if we try to apply a discount for vip02, it will not even reach/call service B, because the toggle is OFF for that user. Even if the Service B contemplates all kind of users that start with “vip”.

{
  "@odata.context": "$metadata#ShopService.CheckoutResponse",
  "userId": "vip02",
  "originalAmount": 498,
  "discountPercentage": 0,
  "finalPrice": 498,
  "message": "Standard price applied."
}

{
  "@odata.context": "$metadata#ShopService.CheckoutResponse",
  "userId": "vip01",
  "originalAmount": 445,
  "discountPercentage": 20,
  "finalPrice": 356,
  "message": "Loyalty Applied! Service B gave you 20% off."
}

You can also perform a percentage delivery. In my case, I have defined a 50/50 percentage, so the half of my users will take advantage of my new feature, meanwhile others will not be able to use it.

For example, vip06 is not being able to use this new feature, but vip33, can access to it.

{
  "@odata.context": "$metadata#ShopService.CheckoutResponse",
  "userId": "vip06",
  "originalAmount": 725,
  "discountPercentage": 0,
  "finalPrice": 725,
  "message": "Standard price applied."
}

{
  "@odata.context": "$metadata#ShopService.CheckoutResponse",
  "userId": "vip33",
  "originalAmount": 635,
  "discountPercentage": 20,
  "finalPrice": 508,
  "message": "Loyalty Applied! Service B gave you 20% off."
}

---

Personal Thoughts:

Let me share some personal thoughts from using the SAP Feature Flag Service and while redacting this blog post.

Regarding the setup and initial steps to get this service up and running. Consider that it is already available under the Build Code plan. This accelerates the process of incorporating it into your projects. The documentation is very accurate, and with the quick start guide, you can begin using the service in minutes. The only advice I can give, if you really want to take advantage of this service, is to take the time to understand its capabilities and how to adapt them to your needs. This is key to be fully aware of the benefits. The documentation is well-structured, is fast to read, and clearly explains many of the topics involved in using the service. You will find straightforward explanations about the different release methods, what you can achieve, how to perform the setup and how to maintain the feature flags.

Regarding the usage. I really think this is a very powerful tool. It helps developers and business experts agree on the release, coordinating efforts so everyone knows exactly when a feature is ready to go live. One of the most important aspects of releasing new features is the confidence of the project members prior to the launch of a new enhancement. In distributed systems, many factors must be considered during deployment. Even with unit tests, integration tests, and manual tests in place, there are always some concerns when releasing enhancements. Having flags that can enable and disable these features reduces those concerns significantly. By configuring the proper feature flags, you can test with end users before the official release. This ensures you get feedback on time and can improve the tool before everyone else sees it, increasing the confidence prior launch (and reducing possible issues in production).

Another important aspect that all project members should consider is the "next steps" after using these flags. Be careful, having too many blocks inside conditional statements can lead to complicated code (and nesting feature flags can also lead to complicated debugging sessions). Hence, the decommissioning of feature flags is an important step in the enhancement lifecycle. In my opinion, removing the flags in the code becomes a mandatory task if you want to keep your project clean and maintainable. So, do not underestimate the cleanup steps after releasing a new enhancement with this service.

---

Wrap Up:

We have journeyed from a simple, standalone "Shop Service" to a sophisticated, distributed system that orchestrates pricing logic with a "Loyalty Service."

By introducing the SAP Feature Flag Service, we didn't just add a toggle; we fundamentally changed how we deliver software.

Decoupling: We deployed Service A's orchestration logic before Service B was even ready.
Safety: We ensured that if Service B fails, Service A degrades gracefully to standard pricing.
Targeting: With Direct Delivery and Perncetage Delivery, we rolled out the new feature exclusively to a set of users, testing in production with zero risk to the end users.

This is the essence of modern cloud-native development on SAP Build Code. It is not just about writing code; it is about controlling when and how that code provides value to your users.

The SAP Feature Flag Service has even more depth, including complex rule sets and other capabilities that can be check in the following guide. If you find this topic interesting, let me know in the comments, and we can dedicate a future "Deep Dive" post to check more capabilities.

I hope you find this post useful.

Kind regards,

Nata.

SAP Community - SAP Build Code

SAP TechEd Berlin 2025: DA262-Enabling clean core development with SAP HANA Cloud and SAP Build Code

💬Now let’s hear from you:

Joule in SAP Build Code can now create freestyle UI5 apps

The feature

Refining the app

Accepting the app

After creation

AI Learnings

Inside Joule: Lessons from building an AI coding assistant for SAP Build

Flashback: the feature

General considerations

A fundamental choice

Creating an "AI agent" out of nothing

How to stop the agent

Context, context, context!

In-response prompting

Traditional coding has its place(s)

Key takeaways

P.S.:

The Art and Science of SAPUI5 in SAP Build: Insights from SAP TechEd 2025

The Art of SAPUI5 in SAP Fiori User Experience

SAP Web Components: Bridging Frameworks and Enhancing Extensibility

SAPUI5 is leading is the Way in Accessibility

The Science of SAPUI5 in SAP Build

Extending SAP standard apps with SAPUI5 flexibility and Clean Core

Future-Proofing apps with UI5 best practices and UI5 linter

AI-Powered Development: Joule Copilot and MCP server

Key Takeaways

Selected questions from the audience

Discover the insights of your SAP BTP extension with SAP LeanIX

Create an application with SAP’s Cloud Application Programming model

Keep track easily

Knowing the inside

Add the Software Bill of Materials (SBOM) to the mix

Update (20.11.25): Tracking the CAP-versions

Mission accomplished

SAP Fiori development newsletter November 2025 (issue #37)

Development news

Events

In case you missed it

Back issues from the past year

TechEd Recap: Creating AI-Enhanced UX for Your Own Applications with SAP Design System

Introduction to the SAP Design System

New AI Patterns for the SAP Design System and SAPUI5

Using our AI-powered UI Technologies to Help You Build Faster

Key Takeaways

Driving Extensibility, Innovation and Automation with SAP Build's Clean Core

Is AI Just a Power Tool for Enterprise Software?

Building Pro-Code Extensions for SAP Mobile Start leveraging mobile native functionalities

Overview

Building and Deploying the base version of the extension

Integrating the app into SAP Build Work Zone & SAP Mobile Start

Extending the app to make use of Widgets on your mobile device

Implementing our own (push) notifications

Outlook

From MCQs to Real Skills: My Experience with SAP’s New Certification Format

Configure or Build something

Work on real scenarios

Receive a defined input and produce an output that is automatically validated against the expected outcome

Submit the output

Get evaluated automatically through AI-driven checks

Experienced professionals

New learners

Employers

SAP ecosystem

Practice hands-on tasks

Build small end-to-end examples

Use SAP Help effectively

Focus on solving problems, not memorizing

Conclusion

Bridging Data Quality Gaps in SAP SuccessFactors TIH with CSVValidationApp and Vibe Coding

Introduction

Why This Matters

My Perspective and Approach

How CSVValidationApp Fits into the TIH Workflow

What Makes CSVValidationApp Powerful

Looking Ahead: Unlocking the Full Potential of TIH

Getting Started

Final Thoughts & Community Ask