SAP Community - JavaScript

1/2 Performance Tuning in SAPUI5

2025-07-02T14:07:47.915000+02:00

Why Performance Tuning Matters

Performance optimization is a critical aspect of SAPUI5 application development. In enterprise apps, users often deal with large datasets and complex UIs – without tuning, these can make the app sluggish or unresponsive . For example, displaying thousands of table rows or multiple complex charts can significantly slow down both loading and runtime response. Such sluggish performance leads to user frustration and lower productivity . Therefore, it’s important to understand why performance can degrade (large data volume, heavy UI components) and proactively address it. The goal is to ensure a fast, fluid user experience, even as the app’s data and UI complexity grow.

Why do SAPUI5 apps slow down? Two common reasons are: (a) Loading or rendering too much data at once, and (b) Using very complex UI controls or deep component trees. If an app tries to fetch and show all available data in one go, or if the UI creates hundreds of DOM elements upfront, the browser can become overwhelmed. The result is long initial load times (sometimes tens of seconds) and laggy interactions. Users today expect snappy responses, so we must optimize SAPUI5 apps to meet those expectations. In the next sections, we’ll look at key areas to focus on for performance tuning.

Key Areas for Performance Optimization

To improve SAPUI5 app performance, we should focus on several strategies in the app’s design and implementation. Below are the main areas to address:

Lazy Loading for Data-Heavy Controls – Load data or UI components on demand instead of all at once.
Optimizing OData Requests – Fetch only what you need (projection) and reduce round-trips (batching).
Caching Data and Models – Reuse already loaded data/models and leverage caching to avoid redundant fetches.
Minimizing DOM Operations – Use efficient data binding and avoid excessive direct DOM manipulation.
Performance Measurement & Tools – Continuously measure performance using available tools to catch bottlenecks.

Let’s dive into each area with practical tips and examples.

1. Lazy Loading for Data-Heavy Controls

When dealing with large collections of data, lazy loading is essential. Instead of rendering hundreds of items upfront, load only what’s needed and fetch more on demand. SAPUI5 provides a built-in mechanism for this via the “growing” feature on list and table controls. As the official documentation states: “A growing list has a loading mechanism that requests data from the model in a lazy way,” fetching additional items only as necessary . This means the app initially loads a small set of records, and as the user scrolls or requests more, additional data is loaded, improving initial load performance.

For example, you can enable lazy loading on a table by setting the growing property:

<!-- Example: A table that loads 20 items at a time, loading more as needed -->
<Table id="productTable" 
       growing="true" 
       growingThreshold="20" 
       growingScrollToLoad="true" 
       items="{/Products}">
    <!-- Define columns ... -->
    <items>
        <ColumnListItem>
            <cells>
                <Text text="{Name}" />
                <Text text="{Price}" />
                <!-- other cells ... -->
            </cells>
        </ColumnListItem>
    </items>
</Table>

In the snippet above, the table will initially display 20 items (the growingThreshold). As the user scrolls down (with growingScrollToLoad="true", it will auto-load more; if set to false, a “More” button is shown instead). This lazy loading approach dramatically improves performance by not loading all data at once. It’s especially beneficial for very large datasets – the app remains responsive by only fetching data “as and when necessary” instead of upfront.

Lazy loading isn’t limited to tables; you can also lazy load views, fragments or components. For instance, deferring the loading of a view until the user navigates to it can speed up the initial app load. In SAPUI5 routing, you might use asynchronous loading of views or the ComponentContainer with dynamic component loading on demand. The principle is: load heavy content only when needed, keeping the initial payload light.

2. Optimize OData Requests (Batching and Projection)

Frequent or heavy OData calls can be a major performance bottleneck. Each network request has overhead, and pulling large payloads (with many fields or records) slows down the app. To optimize data requests in SAPUI5, consider these techniques:

Batch multiple OData calls into one: If your page needs data from several OData endpoints, use OData $batch to combine them into a single HTTP request. This reduces the number of round trips to the server. In OData V2 Model, you can enable batch mode by setting useBatch:true when creating the model. In fact, SAPUI5’s OData V4 model does this by default – it “collects all requests made to the OData service in a batch request to reduce the number of roundtrips” . Fewer requests mean less latency and quicker overall data retrieval.

// Initializing an OData V2 model with batch mode enabled and other optimizations
var oModel = new sap.ui.model.odata.v2.ODataModel("/sap/opu/odata/sap/YourService/", {
    useBatch: true,               // combine multiple calls into one batch
    defaultCountMode: "None"      // disable $count calls if not needed for lists
});
this.getView().setModel(oModel);

In the code above, we enable batch mode. We also set defaultCountMode:"None", which prevents automatic $count requests for list bindings (since counting all records can be expensive on the backend ). These settings help cut down unnecessary network calls.

Use projection ($select) to limit fields: Only request the data you actually need. By default, an OData entity request might return all properties, many of which your UI might not display. This wastes bandwidth and parsing time. Instead, specify a $select query option to retrieve only the necessary fields (projection). For example, if you only need product name and price, don’t fetch the entire product entity including large descriptions or images. As a best practice, “ensure that you only retrieve the necessary data… utilize OData services efficiently by specifying $select and $expand options.” . This avoids over-fetching data that will never be used on the client.

// Example: fetching only specific fields using $select
oModel.read("/Products", {
    urlParameters: { "$select": "Name,Price,Stock" },
    success: function(oData) { /* ... */ }
});

In the snippet above, the OData request will only return the Name, Price, and Stock properties of each Product, rather than the full product data structure. This leaner payload can significantly improve network performance.

Filter and paginate on the server: Similar to lazy loading on the UI, use OData query options like $filter, $top, and $skip to have the server send only a slice of data. For instance, if a user needs to see records for a specific category, using $filter on the OData request means the server does the heavy lifting and sends back only relevant records, reducing client work. Likewise, implement server-side paging: request the first N records with $top, and load more on demand (many SAPUI5 controls with growing support will automatically append $skip/$top parameters when bound to an OData list). By filtering at the source and paging results, you minimize data transfer and client-side processing .
Consider OData Model version: If possible, use the OData V4 model for new developments, as it has performance improvements over V2 . OData V4 not only batches requests by default, but also handles $expand more efficiently and has a reduced memory footprint on the client. If you are using OData V2, apply the above suggestions and also ensure metadata loading is optimized (see caching below).

In summary, treat your OData calls with care: batch them, narrow them (select only needed fields), and avoid pulling huge datasets in one go. Your app will load faster with fewer and lighter requests.

3. Caching Data and Models

Caching is a powerful technique to enhance performance. By caching, we mean reusing data that has already been loaded, instead of fetching it again from the source. There are a few layers of caching relevant to SAPUI5 apps:

OData Metadata Caching: When an SAPUI5 app starts, the OData service’s metadata (the $metadata XML) is usually fetched. This is needed to understand the data model but can be a bulky request. To speed up app launch, SAP Fiori Launchpad and SAPUI5 support metadata caching using cache tokens. “OData metadata is cached on the web browser using cache tokens,” which append a sap-context-token to the metadata request URL . This ensures that after the first load, subsequent loads use the cached metadata, avoiding repeated downloads of the service definition. If you run your app standalone, you can still leverage this by enabling caching on the server or using the manifest property "preload": true for models to preload metadata at startup . Always check via browser dev tools that metadata requests are returning HTTP 304 (not modified) or using cache tokens appropriately.
Model and Data Caching: For data payloads, consider caching frequently used data in a client-side model. For example, if you have lookup data or reference lists that rarely change, load them once and store them in a JSONModel or in the ODataModel so it can be reused across views. SAPUI5’s models typically cache data by default (the ODataModel keeps an in-memory cache of fetched entities). You can further take advantage by reusing model instances. Instead of creating a new ODataModel for each view or component, instantiate one ODataModel at application startup (in your Component.js) and share it across the app (set it on the core or component). This way, if View A already loaded some data, when View B requests the same data, it can be served from the model’s cache without another round trip. Also, when navigating back to a view, the data is still present.
Browser Caching for static resources: Ensure that app resources (JS/CSS files, theme assets, libraries) are served with caching headers so that the browser caches them. SAPUI5 framework resources are usually served with cache-busting hash parameters (to invalidate the cache on new versions). You as a developer should also bundle and minify your own resources (e.g., use the UI5 build tooling to create Component-preload.js). By bundling and minifying, you reduce the number of requests and size of files, which the browser can then cache for subsequent visits . This dramatically decreases load times on repeat visits because most files are loaded from cache rather than network.

In practice, caching is often handled for you (browser caching static files, ODataModel caching data in memory, etc.), but you should be mindful to enable it and leverage it. For example, don’t unnecessarily reload data that you already have. If you know a particular dataset changes rarely, you might even cache it in window.localStorage for persistence. By utilizing both client-side and server-side caching, you can decrease load times for repeat visits significantly .

4. Minimize DOM Operations with Efficient Data Binding

Manipulating the DOM (Document Object Model) is one of the most expensive operations in a web app. Each time you add, remove, or change a UI element, the browser may re-compute layouts and paint updates, which can be slow if done excessively. In SAPUI5, you should let the framework’s data binding mechanism handle as much of the UI update work as possible, and avoid direct DOM manipulation or heavy re-rendering in your code.

Here are some best practices to reduce DOM overhead:

Use Aggregation Binding vs. Manual DOM Updates: When displaying lists or tables of data, use aggregation binding (bindAggregation) to let SAPUI5 create and manage list items for you. This is far more efficient than manually creating controls in a loop and inserting them into a container. For example, rather than writing a loop to append ColumnListItem controls to a table, define the binding in the XML view (as shown in the earlier snippet) or via oTable.bindItems(...) in JS. The framework will template the items and only render what’s needed. Using bindAggregation for lists ensures that UI5 can reuse templates and handle diffing, reducing the amount of DOM manipulation. In contrast, bindProperty is used for individual property binding on an existing control (e.g., binding a text field’s value). As a rule of thumb: use bindProperty for simple, singular values, but use bindAggregation for collections. This way, you avoid manually touching the DOM for each data entry – the framework does it in bulk efficiently.
Batch UI updates: If you need to make multiple changes to the UI, try to batch them in one go rather than many small updates. For instance, if you have to hide or show multiple controls, it’s better to wrap them in a single container and hide/show the container, instead of toggling each control individually. Or use a model property to bind the visible property of several controls and change that one property – the framework will update all the UI states in one logical re-render. Excessive incremental DOM updates can thrash the browser’s rendering engine. Minimizing such changes leads to smoother performance .
Avoid heavy computations in bindings: Data binding is powerful, but don’t abuse it by putting expensive calculations in formatter functions or property bindings that trigger frequently. Keep formatter logic lightweight. If a computation is heavy, consider pre-calculating it in the model data instead of in a formatter that runs on every digest cycle.
One-Time vs. Two-Way Binding: If you have content that does not change after initialization (static text, labels, etc.), use one-time binding ({= ... , mode:'OneTime'} or in XML {path: '...', mode: 'OneTime'}). This way, the framework will not keep observing that property for changes – it binds once and is done, reducing runtime overhead . One-time binding is great for things like form labels or initial view title that won’t update. Similarly, if two-way binding is not needed, prefer one-way binding (the default) which is less overhead than two-way (which has to propagate changes back to the model).
Keep the DOM lean: Try to avoid creating an excessively deep or large DOM structure. For example, in list items, using multiple nested Layouts (Horizontal/Vertical Layouts) and Containers can blow up the number of DOM nodes for each item. Multiply that by 100 items and it can degrade performance. Favor simpler structures or use CSS for spacing instead of extra markup. The SAPUI5 guidelines suggest keeping views “short and simple” – meaning a shallower control hierarchy where possible, especially in repeated elements.

In summary, every extra element or reflow counts. Excessive manipulation of the DOM can slow down your UI5 app , so lean on data binding to handle UI updates and avoid direct DOM hacking. By using the right binding strategies (aggregation vs property binding, one-time where applicable) and keeping the UI structure efficient, you minimize the work the browser has to do.

Conclusion

Optimizing SAPUI5 performance requires a deliberate approach—lazy load data/UI, optimize OData requests, leverage caching, and minimize DOM manipulation. By applying these practices proactively, you deliver SAPUI5 applications that scale efficiently, meeting user expectations and ensuring smooth performance.

Stay tuned for Part 2, where we’ll dive deep into performance measurement and quality assurance.

Find the Bug 🐞 Formatting dates and times in Build Apps

2025-07-07T17:10:26.360000+02:00

Someone sent me a problem they were having in a private message, that made me chuckle.

To be honest, after 2 years of war and 2 weeks of intense war, and having to live out of a suitcase for a week in Athens because my plane was diverted and could not enter my country -- this was a fun, amusing diversion (it actually made me laugh).

Here's the message I received:

FORMAT_DATETIME_WITH_TIMEZONE(DATETIME("2025-04-03T02:00:00.000Z"), "MMM d, yyyy", "America/Chicago")

"I am using formula to format the date. Actually the output should be Apr 2, 2025, 9 pm. But I am getting Apr 3, 2025, 9 pm. How to solve this? I tried multiple ways. It's only changing time but not date. I used other timezone format as well. Please help. This is an issue in production."

After running the formula in my Build Apps and getting the same result, I assumed it was a bug in the tool (@Mari and @Pekka_Aaltonen, please forgive me). For the programmer, the obvious thing to think was that you asked for the date in the format April 2 (because it had to give the day before because the time zone they gave was minus 6 hours from UTC) and instead it was giving April 3. Why? Probably because the formula was too stupid to return the previous day's date.

It was supposed to show this:

But kept showing this:

But, alas, there was a perfectly logical explanation, but it was hidden because of the actual date and time used in the example. Another case of all-too-human error.

Can you find the bug in the function code?

P.S.: If you like this puzzle, wait for Devtoberfest in October. We'll have plenty more.

Exploring SAP Generative AI SDK: Python, JavaScript, and Java Libraries 🎁

2025-07-11T20:59:21.243000+02:00

SAP's Generative AI SDK offers powerful tools for integrating AI capabilities into your business applications.

This blog will guide you through the libraries available for Python, JavaScript, and Java, and how to use them effectively.

1.🔵 SAP Generative AI SDK for Python

The SAP Generative AI SDK for Python allows developers to leverage generative models from the SAP AI Core. This SDK supports models from providers like OpenAI, Amazon, and Google, and integrates with LangChain for enhanced functionality.

Documentation and Examples : https://help.sap.com/doc/generative-ai-hub-sdk/CLOUD/en-US/index.html

Installation: To install the SDK, use the following command:

pip install sap-ai-sdk-gen[all]

You can also install specific model providers:

pip install "sap-ai-sdk-gen[google, amazon]"

Configuration: Set up your environment variables or configuration file to authenticate and connect to SAP AI Core:

export AICORE_CLIENT_ID="your_client_id"
export AICORE_CLIENT_SECRET="your_client_secret"
export AICORE_AUTH_URL="your_auth_url"
export AICORE_BASE_URL="your_base_url"

Usage: Here's a simple example to generate text using the OpenAI model:

from sap_ai_sdk_gen import OpenAI

client = OpenAI()
response = client.generate_text(prompt="Hello, world!")
print(response)

2.🔵 SAP Generative AI SDK for JavaScript

The JavaScript SDK enables Node.js applications to interact with SAP AI Core, providing seamless integration with generative models.

https://github.com/SAP/ai-sdk-js

Installation: Install the SDK via npm:

npm install -ai-sdk/ai-api

Configuration: Ensure your environment variables are set up correctly:

export AICORE_CLIENT_ID="your_client_id"
export AICORE_CLIENT_SECRET="your_client_secret"
export AICORE_AUTH_URL="your_auth_url"
export AICORE_BASE_URL="your_base_url"

Usage: Here's a basic example to generate text:

import { OpenAI } from '@sap-ai-sdk/ai-api';

const client = new OpenAI();
client.generateText('Hello, world!').then(response => {
  console.log(response);
});

3.🔵 SAP Generative AI SDK for Java

The Java SDK integrates AI capabilities into Java-based applications, leveraging the SAP AI Core's generative models.

https://github.com/SAP/ai-sdk-java

Installation: Add the SDK to your Maven project:

<dependency>
  <groupId>com.sap.ai</groupId>
  <artifactId>sap-ai-sdk</artifactId>
  <version>5.6.0</version>
</dependency>

Configuration: Configure your application properties:

aicore.client.id=your_client_id
aicore.client.secret=your_client_secret
aicore.auth.url=your_auth_url
aicore.base.url=your_base_url

Usage: Here's an example to generate text:

import com.sap.ai.sdk.OpenAI;

public class Main {
    public static void main(String[] args) {
        OpenAI client = new OpenAI();
        String response = client.generateText("Hello, world!");
        System.out.println(response);
    }
}

Conclusion

SAP's Generative AI SDKs for Python, JavaScript, and Java provide robust tools for integrating AI into your applications. By following the installation, configuration, and usage examples provided, you can start leveraging the power of generative AI in your projects.

Feel free to reach out if you have any questions or need further assistance! Happy coding!

Connect to Public Cloud API in Node.js via Authorisation Code

2025-07-22T13:54:57.292000+02:00

Connecting to a Public Cloud API (from Business Accelerator Hub) via Node.js CAP application can be challenging. I hope this blog helps others attempting the same task.

Prerequisites

• SAP BTP subaccount (Cloud Foundry)
• Service key for the target Public Cloud API
• XSUAA instance bound to your CAP app
• SAP BTP Destination service instance
• Bruno installed for manual testing

1. Confirm the API's Auth Options

First, check which authentication methods are available for the API you plan to consume.

In my example I connect to the Specification Management API, but the steps apply to any Public Cloud API.

If the OAuth 2.0 Access Code Flow is listed under “Authentication Methods”, the API supports the authorization-code flow. That flow confirms a user context and usually grants wider authorisations, such as update and POST requests.

(OAuth 2.0 Application Flow corresponds to the client-credentials flow.)

2. Connect manually with Bruno (Good blog on Bruno)

Because our API supports the auth-code flow, we first prove we can log in by calling it via Bruno.

Create a new collection and paste the base URI of your Public Cloud API instance (you’ll find it in the service key in your service instance of the saas application your connecting to).

When you send a test GET request you will probably receive an authorisation error. Configure OAuth 2.0 on the Auth tab

Select Grant type Authorisation Code

Then fill in the below fields using your service key from your service instance

Callback URL: <your Public Cloud API hostname>
Auth URL:** https://<subdomain>.authentication.<region>.hana.ondemand.com/oauth/authorize
Access-Token URL: https://<subdomain>.authentication.<region>.hana.ondemand.com/oauth/token
Client ID / Secret: from the uaa section of the service key

Request the token, pick your identity provider, and Bruno will return an access token. Inspect the scopes there to see what you can do.

3. Connect to the API from Node.js

After the manual check we can now automate the flow in a Node.js service.

3.1 Destination setup

Create a destination that points to the same API endpoint and bind it to your app.

The required scopes and the audience (aud) value are visible inside the Bruno access token.

the Audience should start with the client id of your CAP application on BTP

Once the destination is saved, ensure your application is bound to the Destination service.

3.2 xs-security.json

Add every scope your service needs so the approuter, it will forward it in the user’s JWT: in my example i needed this scope.

{
  "name": "$XSAPPNAME.Spc_Write",
  "description": "Allow modification of specifications."
}

Also reference the scope in authorities (and role templates, if used) and assign the resulting role collection to your user.

3.3 Connect in code

Now time to connect to the API in the code itself.

First, obtain the user’s JWT. This helper below tries every possible source and falls back to LOCAL_USER_JWT in local development:

/** Try every source for a JWT and fall back to LOCAL_USER_JWT. */
function getJwt(capReq) {
  // CAP ≥ 7.3 keeps the raw token here
  if (capReq.user?.jwt) return capReq.user.jwt;

  // Plain HTTP / WebSocket headers
  const hdrs = capReq.http?.req?.headers || {};
  const token =
        hdrs['x-approuter-authorization'] ||   // CF WebSocket
        hdrs.authorization;                    // CF HTTP

  if (token) return token.replace(/^Bearer\s+/, '');
  // Last resort for local dev
  return process.env.LOCAL_USER_JWT;
}

3.3.1 Testing locally

When testing locally we don't have access to the user JWT so we can add it manually to the environment file so we can still test locally, below is the process to get the JWT for user testing (each token lasts about 7 to 8 hours)

Step 1 – Get an auth code

https://<instance>.eu10.authentication.eu10.hana.ondemand.com/oauth/authorize
?response_type=code
&client_id=<XSUAA client id of your deployed app>
&redirect_uri=http://localhost
&state=xyz

Paste your version into your browsers address bar, after login you will land on http://localhost/?code=<AUTH_CODE>&state=xyz. Copy the value of AUTH_CODE.

Step 2 – Exchange the code for a JWT

I made the Curl Request inside BAS itself. it will return a number of tokens, we only need the first and biggest one.

curl -v -X POST \
-u '<same client id>' \
--data-urlencode grant_type=authorization_code \
--data-urlencode code=<AUTH_CODE> \
--data-urlencode redirect_uri=http://localhost \
https://<instance>.eu10.authentication.eu10.hana.ondemand.com/oauth/token

Save the token from the response into .env:

LOCAL_USER_JWT=<paste JWT here>

3.3.2 Call the destination with the JWT

const jwt = getJwt(req);
if (!jwt) req.reject(401, 'No user token found.');

const dest = await getDestination({
  destinationName: '<DestinationName>',
  jwt
});

await executeHttpRequest(dest, {
  method: 'POST',
  url: `/odata/v4/api/specification/v1/${EntityName}`,
  data: v
});

If you reach the destination but receive 401 Unauthorized, your JWT is missing the correct scope—ask the product team which one you need.

Other common pitfall is using the different XSUAA instances to get your JWT for the local run. use your applications XSUAA client since this is the same one your application will check the token against

And that’s it! You should now be able to read from and write to the Public Cloud API. For read-only workloads the client-credentials flow is usually simpler.

If I missed anything or you’d like more details, please comment below—happy to help.

## Frequently Asked Questions

### What’s the difference between authorization-code and client-credentials flows?
The authorization-code flow runs in a user context, so it can carry user-level scopes (read, write, update). The client-credentials flow operates with a technical user—perfect for background jobs or read-only integrations.

### Why do I get “401 Unauthorized” after deployment?
Your user’s JWT is probably missing the required scope (e.g., `Spc_Write`). Make sure the scope is listed in xs-security.json, mapped to a role template, and assigned via a role collection in the BTP cockpit.

### Which audience value belongs in my destination?
Use the client ID of your CAP application’s XSUAA instance; it usually starts with `sb-<appName>!t<number>`.

Node.js SAP Cloud Identity Services API SAP Authenticator SAP Fiori Cloud SAP Cloud Application Programming Model SAP Business Application Studio SAP Business Technology Platform SAP S/4HANA Cloud Public Edition Extensibility SAP Business Accelerator Hub JavaScript API Management

Easy way to move zeroes in SAP BTP ABAP(Steampunk), JS & Python

2025-08-10T15:27:33.552000+02:00

Introduction

This is part of the Easy way to write algorithms in ABAP: Series 01. For more algorithms, please check the main blog-post.

Problem

Given an integer array nums, move all 0's to the end of it while maintaining the relative order of the non-zero elements.

Note that you must do this in-place without making a copy of the array.

Example 1:

Input: nums = [0,1,0,3,12]
Output: [1,3,12,0,0]

Example 2:

Input: nums = [0]
Output: [0]

Constraints:

1 <= nums.length <= 104
-231 <= nums[i] <= 231 - 1

Follow up: Could you minimize the total number of operations done?

Solution

Time Complexity: O(n)
Space Complexity: O(1)

ABAP

CLASS zmove_zeroes DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC .

  PUBLIC SECTION.
    INTERFACES if_oo_adt_classrun.

  PROTECTED SECTION.
  PRIVATE SECTION.
    " Define a table type for integers
    TYPES ty_nums TYPE STANDARD TABLE OF i WITH EMPTY KEY.

    " Method to move zeroes in-place
    METHODS moveZeroes
      CHANGING lt_nums TYPE ty_nums.

ENDCLASS.

CLASS zmove_zeroes IMPLEMENTATION.

  METHOD if_oo_adt_classrun~main.
    " Initialize the number array with some zeroes and non-zeroes
    DATA(lt_nums) = VALUE ty_nums( ( 0 ) ( 1 ) ( 0 ) ( 3 ) ( 12 ) ).

    " Output the array before moving zeroes
    out->write( |Array before moving zeroes: | ).
    LOOP AT lt_nums INTO DATA(lv_num).
      out->write( lv_num ).
    ENDLOOP.

    " Call the method to move zeroes to the end
    moveZeroes( CHANGING lt_nums = lt_nums ).

    " Output the array after moving zeroes
    out->write( |Array after moving zeroes: | ).
    LOOP AT lt_nums INTO lv_num.
      out->write( lv_num ).
    ENDLOOP.

  ENDMETHOD.

  METHOD moveZeroes.

    DATA(lv_count) = 0. " Counter for non-zero elements

    " First pass: Move all non-zero elements to the front
    LOOP AT lt_nums ASSIGNING FIELD-SYMBOL(<lf_num>).
      IF <lf_num> <> 0.
        " Place the non-zero element at the next available position
        lt_nums[ lv_count + 1 ] = <lf_num>.
        lv_count += 1.
      ENDIF.
    ENDLOOP.

    " Second pass: Fill the rest of the array with zeroes
    WHILE lv_count < lines( lt_nums ).
      lt_nums[ lv_count + 1 ] = 0.
      lv_count += 1.
    ENDWHILE.

  ENDMETHOD.

ENDCLASS.

JavaScript

function moveZeroes(nums) {
    let left = 0;
    for (let right = 0; right < nums.length; right++) {
        if (nums[right] !== 0) {
            // Swap nums[left] and nums[right]
            let temp = nums[left];
            nums[left] = nums[right];
            nums[right] = temp;
            left++;
        }
    }
    return nums;
}

Python

def moveZeroes(nums):
    left = 0
    for right in range(len(nums)):
        if nums[right] != 0:
            nums[left], nums[right] = nums[right], nums[left]
            left += 1
    return nums

N.B: For ABAP, I am using SAP BTP ABAP Environment 2309 Release.

Happy Coding! 🙂

☁️ Real-time Weather Display on SAP BTP with OpenWeatherMap API — Step-by-Step Fiori Application

2025-08-11T12:01:26.753000+02:00

🔍 Introduction

This article I will show you step by step how to display real-time weather data in a Fiori application using the OpenWeatherMap API on SAP BTP. The application will request city information from the user and display information such as current temperature, humidity, and wind speed in a table format.

Output:

🛠️ 1. Obtaining an OpenWeatherMap API Key

Go to https://openweathermap.org/api.
Sign up and then create a new API key from the API keys tab.
Alternatively, an example request would look like this:
https://api.openweathermap.org/data/2.5/forecast?lat=44.34&lon=10.99&appid=e21c9996e2801f22e2bd0f7d11d1b367

💡This API key: e21c9996e2801f22e2bd0f7d11d1b367 can be used for testing. If it doesn't work, you can create a free one.

When we send a request with the link, it returns a JSON list like this:

🧱 2. Creating a UI5 Project in SAP Business Application Studio

A. Start a new Fiori application
SAP Business Application Studio > “Create Project from Template”
Template: SAP Fiori Application
Data Source: “None”
Project Name: weather-app
B. Project folder structure:
weather-app/
├── webapp/
│ ├── controller/
│ │ └── View1.controller.js
│ ├── model/
│ │ └── cityData.json
│ ├── util/
│ │ └── formatter.js
│ ├── view/
│ │ └── View1.view.xml
│ └── index.html
└── manifest.json

🌍3. Defining City Data as JSON

webapp/model/cityData.json:

{
    "cities": [
    { "name": "İstanbul", "lat": 41.0082, "lon": 28.9784 },
    { "name": "Ankara", "lat": 39.9208, "lon": 32.8541 },
    { "name": "İzmir", "lat": 38.4192, "lon": 27.1287 },
    { "name": "Bursa", "lat": 40.195, "lon": 29.06 },
    { "name": "Antalya", "lat": 36.8969, "lon": 30.7133 },
    { "name": "Trabzon", "lat": 41.0014, "lon": 39.7178 },
    { "name": "Gaziantep", "lat": 37.0662, "lon": 37.3833 },
    { "name": "Samsun", "lat": 41.2867, "lon": 36.33 },
    { "name": "Kayseri", "lat": 38.7348, "lon": 35.4676 },
    { "name": "Eskişehir", "lat": 39.7667, "lon": 30.5256 }
  ]
}

🎯4. View1.view.xml — UI Development

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

  <VBox id="IDVBoxMain" class="sapUiMediumMargin sapUiResponsiveContentPadding" alignItems="Center">

    <!-- Şehir Seçimi -->
    <HBox id="IDHBoxCitySelect" class="sapUiSmallMarginBottom" alignItems="Center">
      <Label id="IDLabelCity" text="Şehir Seçin:" labelFor="IDComboCitySelect" class="sapUiSmallMarginEnd"/>
      <ComboBox id="IDComboCitySelect"
                items="{/cities}"
                selectionChange=".onCityChange"
                placeholder="Şehir seçin"
                width="220px"
                editable="true">
        <items>
          <core:Item id="IDComboItemCity" key="{lat},{lon}" text="{name}" />
        </items>
      </ComboBox>
    </HBox>

    <!-- Anlık Hava Durumu Tablosu -->
    <Table id="IDTableCurrentWeather"
           items="{weatherModel>/Forecast}"
           inset="false"
           width="100%"
           class="sapUiResponsiveTable"
           growing="true"
           growingScrollToLoad="true">

      <headerToolbar>
        <Toolbar id="IDToolbarWeather">
          <Title id="IDTitleWeather" text="📡 Hava Durumu Tahmini" level="H2"/>
        </Toolbar>
      </headerToolbar>

      <columns>
        <Column id="IDColDate"><Text id="IDColTextDate" text="📅 Tarih Saat"/></Column>
        <Column id="IDColTemp"><Text id="IDColTextTemp" text="🌡 Sıcaklık (°C)"/></Column>
        <Column id="IDColFeels"><Text id="IDColTextFeels" text="🤒 Hissedilen (°C)"/></Column>
        <Column id="IDColDesc"><Text id="IDColTextDesc" text="🌤 Hava Durumu"/></Column>
        <Column id="IDColHumidity"><Text id="IDColTextHumidity" text="💧 Nem (%)"/></Column>
        <Column id="IDColWind"><Text id="IDColTextWind" text="🌬 Rüzgar (m/s)"/></Column>
      </columns>

      <items>
        <ColumnListItem id="IDRowWeatherItem" type="Active">
          <cells>
            <Text id="IDCellDate" text="{weatherModel>dt_txt}" class="sapMTextStrong"/>
            <ObjectNumber id="IDCellTemp"
                          number="{path: 'weatherModel>temp', formatter: '.formatter.formatKelvinToCelsius'}"
                          unit="°C"
                          state="Success"/>
            <ObjectNumber id="IDCellFeels"
                          number="{path: 'weatherModel>feels_like', formatter: '.formatter.formatKelvinToCelsius'}"
                          unit="°C"
                          state="Warning"/>
            <Text id="IDCellDesc" text="{weatherModel>weather_desc}"/>
            <Text id="IDCellHumidity" text="{weatherModel>humidity}"/>
            <Text id="IDCellWind" text="{weatherModel>wind_speed}"/>
          </cells>
        </ColumnListItem>
      </items>
    </Table>

  </VBox>
</mvc:View>

🎮5. View1.controller.js — API Consumption

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

  return Controller.extend("weatherapp.controller.View1", {
    formatter: formatter,

    onInit: function () {
      const oCityModel = new JSONModel();
      oCityModel.loadData("model/cityData.json");
      this.getView().setModel(oCityModel);

      oCityModel.attachRequestCompleted(() => {
        const aCities = oCityModel.getData();
        if (aCities?.length > 0) {
          const firstCity = aCities[0];
          this.loadCurrentWeather(firstCity.lat, firstCity.lon);
        }
      });
    },

    onCityChange: function (oEvent) {
      const sKey = oEvent.getParameter("selectedItem").getKey();
      const [lat, lon] = sKey.split(",");
      this.loadCurrentWeather(lat, lon);
    },

    loadCurrentWeather: async function (lat, lon) {
      const apiKey = "e21c9996e2801f22e2bd0f7d11d1b367";
      const url = `https://api.openweathermap.org/data/2.5/weather?lat=${lat}&lon=${lon}&appid=${apiKey}&lang=tr`;

      try {
        const response = await fetch(url);
        const data = await response.json();

        const row = {
          dt_txt: new Date(data.dt * 1000).toLocaleString("tr-TR"),
          temp: data.main.temp,
          feels_like: data.main.feels_like,
          humidity: data.main.humidity,
          wind_speed: data.wind.speed,
          weather_desc: data.weather?.[0]?.description || ""
        };

        const oWeatherModel = new JSONModel({ Forecast: [row] });
        this.getView().setModel(oWeatherModel, "weatherModel");
      } catch (err) {
        console.error("Anlık hava durumu alınamadı:", err);
      }
    }
  });
});

📄6. formatter.js

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

  return {
    formatKelvinToCelsius: function (kelvin) {
      const k = parseFloat(kelvin);
      return isNaN(k) ? "N/A" : (k - 273.15).toFixed(1);
    }
  };
});

Now, with this UI5-based Fiori application developed on SAP BTP, users can instantly view real-time weather data for their selected city. By developing projects like this using the OpenWeatherMap API, you can integrate external data sources into your system.

For more content, you can also find me on Medium (username: tekin.ilker24).

Build A Web App and Connect to S/4HANA with SAP Integration Suite

2025-08-13T12:45:21.973000+02:00

A big part of the magic behind AI, advanced analytics, and {insert tech buzzword here} is the humble API!

I remember the excitement about service-oriented architecture in the late 1990s and early 2000s. Back when most organisations had 'fat' ERPs with extensive customisation, the idea that we could split things up into different apps and connect in a standardised way was refreshing.

I recently noticed a SAP CodeJam on the SAP community events calendar that involved connecting systems to S/4HANA using SAP Integration Suite.

I thought it might be fun to build a web app and see if I could successfully connect it to S/4HANA.

A basic understanding of frontend to enterprise backend via cloud architecture is useful for everyone; business experts, technology experts, and people experts

The article is broken into three parts: an introduction, a step-by-step explanation for generalists, and my build/test notes for anyone working on something similar. The third section includes details on all the test tools, and configuration settings.

A couple of quick disclaimers:

I'm not an integration expert:
- I don't look at integration suite vs. other solutions
- I don't cover best practices, typical challenges, good use cases
My solution here is likely not optimal:
- It's just a vanilla HTML, CSS, JS frontend

---

Part 1: introduction

From web app to S/4HANA

The plan:

The frontend is a web page to search for data from within S/4HANA
The web server handles communication between the frontend and SAP Cloud
SAP Integration Suite will route and format the message for S/4HANA
S/4HANA is the source of data.

Tools/technology:

Utilise the free trial account for SAP BTP and Integration Suite
Build the frontend and web app ourselves
We can't access S/4HANA. However, the CodeJam provides a S/4HANA mock server that mimics the behaviour of an API within S/4HANA.
If we use a mock system, we will need to run it locally. So, adjusting the architecture.

This adds SAP Cloud Connector which allows an "on-premise" application to connect with SAP Cloud.

The front end

The completed app offers a summary view and a detailed view. Here's a short screen recording

Summary view

This is a screenshot from the web browser (firefox).

The top part of the page has a search form that allows you to search for a business partner. The bottom part of the page shows the results with a selection of key fields in a card style layout.

The mock system we are using allows for four different search possibilities:

Search for a single business partner by number
Search for all business partners
Search for a single business partner by number, including address details
Search for all business partners, including address details.

Detail view

The detail view shows the results in a table. This table has a horizontal scroll bar, which can be adjusted to view all the fields. The table includes 'raw' results, so there are some 'technical' entries like `[object Object]` and some blanks, which I think is fine for this mock up stage.

Responsive view

For tablets and mobile, the card view resizes with the browser window.

![the front end - summary view on mobile](/assets/images/blog/integration/integration-5.png)

I'll come back to how this front end was built after running through the integration flow.

S/4HANA

The value of this flow is being able to design and build a frontend to access real-time, trusted business data from S/4HANA in a standardised way. In a real-world example, our frontend could be an employee portal or supplier portal.

S/4HANA is:

SAP's enterprise software for large organisations. It handles processes such as purchasing, manufacturing, sales, shipping, finance, etc.
An evolution from their earlier ERP products (R/1, R/2, R/3, ECC).
A complex platform comprising thousands of programs, tables, and customisations used by many large enterprises.

S/4HANA already comes with a web frontend called Fiori, which includes thousands of apps. However, in this example imagine we are building something for a casual user that does not require the full capability of Fiori. Or, just consider it's for fun.

Business partner

The mock server simulates one of the business partner APIs for S/4HANA.

A business partner is a reference or master data record that represents a third party that an organisation works with. This includes customers, suppliers, and employees.

Business partner master data is organised by key fields such as "category" and "role".

All business partners have general data such as name, address, etc., then they have role-specific data, which may include, but are not limited to:

Purchasing data
Sales data
Accounting data
And so on.

To understand how business partner data is used, consider a typical ERP process like order-to-cash:

This is a summary of the order to cash process. During sales, deliveries, and billing, information from the business partner master record is utilised.

The business partner master stores long-term stable information about the customer. It's used for both reference and validation during transaction entry.

This ensures there is consistency across transactions over time in terms of how they reference business partners. This is critical for reporting. Consider comparability, aggregation, etc.

S/4HANA Architecture

The mock server simulates an S/4HANA API. Let's look inside S/4HANA.

Starting from the top right, S/4HANA has two primary ways for users to interact. The traditional SAP graphical user interface (GUI) and the modern Fiori web-based user interface.

I've drawn APIs to the left of these. The APIs allow applications to interact with S/4HANA.

Consider the data model in S/4HANA in two separate parts. The first is the traditional HANA database. This is where master data and transactional data are stored. On top of this is the virtual data model. This consists of core data services views. This is a way to define different sets of data to meet the needs of APIs and Fiori Apps.

In this example, we are using a business partner data API. Behind the scenes, the API sources data from CDS views, which in turn connect to the HANA DB tables.

---

Part 2: step by step walkthrough (for everyone)

In this section, I'll summarise the process and technology involved at each step.

Point 1: Web communication

Building an integration flow between web connected applications relies on protocols and standards for web communication. Let's run through the main concepts.

Client/server

The terms client and server are used to describe the requester and receiver. For example, the web browser on a computer is a client, and google search is a server.

Internet communications use the HTTP protocol.

![HTTP communication](/assets/images/blog/integration/integration-10.png)

Hypertext Transfer Protocol (HTTP) is a standard protocol for communication between clients and web servers. Web pages are written in Hypertext Markup Language (HTML).

The term Uniform Resource Locator (URL) is used to describe an address.

The structure of a URL

URLs have five key parts:

Protocol: `http://`
Domain: `www.example.com`
Path: `/pages/`
Query string: `?id=1&cat=test`
Fragment: `#article` (an internal page reference, often not present)

When it comes to APIs, the query string provides the ability to specify parameters for search and filter. In this case, the query string could include a business partner number.

HTTPS

HTTPS uses the HTTP protocol, but it adds a secure transport layer. HTTPS means the HTTP message is encrypted before transmission.

The only part that isn't encrypted is the domain name.

Internet protocol (IP) address

While URLs are designed to be human-readable. An IP is a numerical label like "192.0.2.1" that identifies a computer or network.

URLs are used for navigation. IPs are used for routing and communication. They identify a specific device on a network (laptop, server, etc.).

An IP address can be used in place of a domain name with HTTP and HTTPS

"http://192.0.2.1"

While an IP address represents a computer. The term "port" is used to specific a specific input/output location.

Ports are identified using 4 digits.

"http://{server}:{port}"
"http://192.0.2.1:1000"

A server is often referred to by 'host'

"http://{host}:{port}"

You can access ports on your own computer by using its IP or "localhost"

"http://localhost:1000"

From domain to IP

The web browser uses a domain lookup service to translate a URL into an IP address.

"http://www.example.com" becomes "http://192.0.2.1"

This is called the Domain Name System (DNS). Popular look up services include: Cloudflare, Google DNS, and OpenDNS.

Messages

The communications themselves can be thought of as messages. They contain a header and a body.

The header includes:

The URL
The method, most commonly GET and POST
GET sends a request without a body
POST sends a request with a body
Additional information on the content type and authorisation

The body includes detailed content. For example:

If you fill in a form on a web page, it would include the form data
If a server returns a web page, it would include the web page.

Server Responses

When a server receives a request, it responds with a status code and a body. Status codes include '200' representing "ok" and '404' representing 'Not Found'.

(404 has definitely reached meme levels of fame!).

The body that's returned depends on the status and the server's purpose.

Real life examples

Consider visiting the BBC website from a web browser, a simple GET request would return the home page.

On the other hand, consider logging into the BBC website. In this case, the browser sends the login name and password. Therefore, a POST request is used, and the request includes a body.

Web connectivity and SAP

Most SAP applications can use HTTPS communication. This is possibly one of the simplest ways we could define "Cloud" strategy.

S/4HANA Cloud Public and S/4HANA Cloud Private can both utilise HTTPS
SAP BTP which includes SAP Integration Suite can utilise HTTPS

Outside the SAP Cloud, we have systems like S/4HANA On-Premise. This is usually at an SAP customer's data centre or their 3rd party hosting service provider's data centre. On premise systems are usually not directly connected to the public internet. This is where SAP provide Cloud Connector to create a secure tunnel between on-premise and SAP Cloud.

HTTP data transfer standards

There are further standards as to how data is transferred using HTTP.

There are multiple standards for data transfer with HTTP. One of the earlier and more common standards is REST (Representational State Transfer).

Many SAP APIs utilise OData (Open data transfer protocol).

Point 2: S/4HANA business partner API mock server

Purpose: Mimic the business partner API of an S/4HANA system.

What is it: A simple JavaScript server that can be run locally.

The mock server provided by the SAP community provides a simple way to simulate the design and test of an S/4HANA API.

The mock server mimics the business partner (A2X) API
This is one of the S/4HANA APIs (programmed inside S/4HANA)
In the case of the mock server, it's a JavaScript server
The mock server has limited functionality, it supports:
- Sample data for a few business partners
- Retrieve all business partners
- Retrieve a single business partner
- Include additional address data in the response.

Installing and running the mock server is simple. The instructions are in part 3. When we run it our computer a local address is returned.

On my computer, it runs on "http://localhost:3005/"

This is the address for the Business Partner API. Entering this address in the web browser gives the following response:

The first item refers to the business partner API. This is the first point in the exercise where we can see the path for the Business Partner API:

"/sap/opu/odata/sap/API_BUSINESS_PARTNER"

The API path is just appended to the host, so:

"http://localhost:3005/sap/opu/odata/sap/API_BUSINESS_PARTNER"

Clicking on the link in the browser shows additional information about the API. Note that the only services listed are A_BusinessPartner and A_BusinessPartnerAddress.

When building an integration flow, the mix of host names, port names, and paths can quickly become confusing. It's useful to track these as we go.

Point 3: Application programming interface (API

Purpose: Provide a standard way to define and operate services for an application that can be consumed by other applications.

What is it: SAP have a large catalogue of standard APIs that come with S/4HANA.

The Business partner API

The API that was introduced under the S/4HANA business partner mock server is called 'business partner (A2X)'. It is a SAP standard API that uses the OData V2 standard.

While HTTP is the communication protocol. OData is an open standard related to the data.

When viewing the API details in the web browser, the display was JSON. This is JavaScript Object Notation, which is used in Odata. Point 5. in the flow will show more detail on this API.

Point 4: Business technology platform (BTP)

Skipping Cloud Connector for now, brings us to BTP. Details from BTP are needed to set up Cloud Connector.

Purpose: Enable customers to manage and build on SAP applications.

What is it: A set of tools encompassing various capabilities and environments.

SAP offer a free trial for BTP, which can be used to build and test integration flows. Instructions on how to register and set up BTP are included in part 3.

The BTP cockpit is where we can search for and set up different services.

It supports multiple infrastructures and runtimes so you can manage/build various types of applications from traditional SAP ABAP to web apps.

Supports multiple infrastructures/runtimes & languages, including:
- Cloud Foundry: develop new apps/services, multiple languages, runtimes
- ABAP: extend ABAP based products (S/4HANA)
- Kyma: Kubernetes to develop/run cloud-native apps
- Neo: HTML5, Java, and HANA extended apps

BTP has multiple regions and infrastructure providers

Regional deployment
- Provided by SAP or Infrastructure-as-a-Provider (IaaS)
- AWS, Azure, Google Cloud, Alibaba Cloud
The key features of BTP include managing and building:
- Compose business processes
- Application development and automation
- Build and extend SAP applications
- Integrate data
- Analytics
- Intelligent technologies

SAP Integration Suite utilises the Cloud Foundry environment. After we set up Business Technology Suite and SAP Intelligent Suite, a Cloud Foundry API endpoint will be provided in BTP.

In my case, this is "https://api.cf.ap21.hana.ondemand.com"

Point 5. Business Accelerator Hub

Purpose: Provides a central source of information on SAP's APIs

What is it: A web page with API details. Highly integrated with BTP.

Business Accelerator hub is a web resource from SAP. I've drawn it inside BTP as it closely relates to BTP content. It's a central repository for APIs from SAP & selected partners.

api.sap.com

Main features

Discover, explore, and test APIs
Consume integration and workflow content

The Business Partner (A2X) API that is tested here can be viewed on Business Accelerator Hub.

Login to business accelerator hub
Search 'business partner (A2X)'
Click on the entry in the results

Some features of business accelerator hub:

Try out the APIs (sandbox environment)
- Useful to view a sample of the response
View the API capabilities:
- 'API Reference' tab, scroll down to 'Business Partner' and click on it
- This shows the list of capabilities of the API
View the API specification
- 'Overview' tab, scroll down to 'API Specification' and click on it
- Download OpenAPI JSON
- View in web browser, text editor to see extensive details

The API hub is a useful resource in terms of discovering and designing potential API use.

From the mock server specification, we know it's limited to only a few capabilities. We can find the path names for each of these on API hub:

This confirms the mock server only has a small fraction of the full business partner (A2X) capabilities. This makes sense given how extensive business partner data is in SAP. It's noteworthy that the mock server only supports 'read' activities. We can't test creating or changing a business partner.

The details of each of these requests can be viewed by clicking into them.

While there are three request paths. The address path can be added to the "all business partners" or "single business partner", so there are four possibilities:

All business partners
- "/A_BusinessPartner"
All business partners with address
- "/A_BusinessPartner/to_BusinessPartnerAddress"
Single business partner
- "/A_BusinessPartner('{BusinessPartner}')"
Single business partner with address
- "/A_BusinessPartner('{BusinessPartner}')/to_BusinessPartnerAddress"

These paths describe services of the API and are appended to the base URL.For example:

"http://localhost:3005/sap/opu/odata/sap/API_BUSINESS_PARTNER/A_BusinessPartner('{BusinessPartner}')/to_BusinessPartnerAddress"

The correct terminology for these URLs:

Base URL/host: http://localhost:3005
Base path: /sap/opu/odata/sap/API_BUSINESS_PARTNER
Entity set: /A_BusinessPartner
Key Access: ('1234567')
Navigation property: /to_BusinessPartnerAddress

"('{business partner}')" in the example is a placeholder for a business partner number.

Updating the flow diagram with these details:

Point 6: SAP Integration Suite

Purpose: Design and manage communications between applications.

What is it: A service of SAP BTP.

SAP Integration Suite is one of the services available in Business Technology Platform. Therefore, a prerequisite is to register for the BTP free trial.

SAP Integration Suite can then be found under 'Services Marketplace'.

SAP Intelligent suite can be used for Cloud, on-premise, and hybrid scenarios. It includes pre-built, best-practice integration packs

Technically, it's a Java based app, and utilises the Apache Camel framework.

The steps to install and set up are covered in part 3. After the initial set up you can navigate to the application.

For this demo/test, the two key menus within Integration Suite are:

Design > Integrations and APIs
Monitor > Integrations and APIs

The design area allows us to create an integration flow which involves:

Specifying source or 'sender' system
Specifying target or 'receiver' system
Adding flow steps
Modify message header
Modify message contents
Route steps between sender and receiver.

Within design, there is a graphical editor to build the integration flow.

Business Partner Integration Flow

Creating the integration flow involves setting the sender details and designing the required transformations to meet the receiver (API) requirements.

As we work through this keep in mind the API expects one of four paths depending on the search scenario:

The sender

The sender represents the address that SAP Integration Suite will listen on. This is the address we send a message to from our upstream app. In this case a web app.

This address is built up in three parts:

A base which is provided when we deploy the integration flow
An 'Address' that we specify in the integration flow
Further path details from the web app.

The base of the endpoint is something along the lines of:

https://{trial-account-specific-details}-rt.cfapps.ap21.hana.ondemand.com/http/

For the address name, this demo/test uses the path `/request-business-partners/*` The "`*`" at the end allow us to send requests with additional details that can be utilised in the flow logic.

The web app will send four different types of message to match the four API scenarios, for the demo/test I will use:

"/api/bp/single"
"/api/bp/all"
"/api/bp/single/add"
"/api/bp/single/all"

The web app will also include the BP number in the message body.

We don't need to specify these in the Integration Flow as the `*` will allow them all to pass as long as they are preceded by "request-business-partners/"

Adding this information to the mapping table.

Routing and Transformations

The integration flow routes and transforms the received messages to meet the API requirements at the receiver. This involves:

Routing of messages from receiver to sender based on their content
1:1 relationship for each of the four scenarios
Transform the URLs
A part of the transformation is extraction of the business partner number from the received message and the placement of it into the API format URL.

The receiver

The receiver is set up to match the S/4HANA business partner mock server.

More detail on the settings of each step are in part 3.

At this point, the integration flow is:

As an alternative, the web app could have been programmed to send messages that already fit the API requirements. However, in some scenarios sender systems may be inflexible or difficult to develop on, making these transformation capabilities in Integration Suite important.

Further reading on SAP Integration Suite:

- Help - What is integration suite
- Apache Camel

Point 7. Cloud Connector

Purpose: Allow SAP BTP to communicate to On-Premise SAP.

What is it: An application that can provide a secure connection between SAP Cloud and On-Premise applications.

In the previous part, we defined the address details of the S/4HANA business partner mock server as:

Base URL/host: http://localhost:3005
Base path: /sap/opu/odata/sap/API_BUSINESS_PARTNER
Entity set: /A_BusinessPartner
Key Access: ('1234567')
Navigation property: /to_BusinessPartnerAddress

If you paid attention to the screenshot of the receiver configuration in Intelligent Suite, you will note that it was set to

`http://s4-mock:3006/sap/opu/odata/sap/API_BUSINESS_PARTNER/A_BusinessPartner('${property.employee_id}')`

The domain was "s4-mock:3006" not "localhost:3005".

This is because we can't connect SAP Cloud directly to an on-premise system. The S/4HANA business partner mock server is a JavaScript server that runs locally on desktop/laptop and is hence considered 'on-premise' or outside the SAP Cloud.

SAP provides "SAP Cloud Connector" to connect on-premise applications to the SAP Cloud.

It's a JavaScript application that can be installed and run locally. Part of the set-up involves entering authentication details from BTP.

After it's set-up, Cloud Connector will accept messages from Integration Suite and forward them to the S/4HANA business partner mock server.

The detailed set-up is covered in part 3.

The screenshot above shows the "Cloud to On-Premise" mapping. A virtual host "s4-mock:3006" is mapped to the S4/HANA business partner mock server running locally on "localhost:3005".

Updating the integration flow:

Point 8: Web app

The web app is an application that uses JavaScript as a programming language. Web browsers have JavaScript engines and can run JavaScript code.

There are two parts to the web app. The frontend and the backend.

Think of JavaScript in two categories. frontend JavaScript and server (backend) JavaScript.

Frontend JavaScript

Runs in the web browser, utilising the browsers JavaScript engine
Is oriented towards manipulating web documents (HTML documents), for example:
Retrieve fields from HTML (e.g. sign up form)
Update HTML (e.g. show results, dynamically add a new page)
The JavaScript engine in the browser has limitations.

Server JavaScript

Installed on a server (can also be run on a desktop/laptop)
A popular engine is Node.js
Is oriented towards messaging, connectivity, security, authentication
Has a lot less limitations than the web browser.

We could try to send a request from the frontend to SAP Integration Suite, but because it comes from a browser, it will likely result in errors.

I did try sending a message to Integration Suite from the browser, but received various CORS errors. CORS, or Cross-Origin Resource Sharing, is a browser security feature that controls whether a web page on one domain can access resources from a different domain.

Therefore, the frontend will send a request to the backend, which will then prepare the message and send it as a request to SAP Integration Suite.

Let's look at the frontend first, then the backend.

Point 8.1 Web app: frontend

Purpose: Search for and display business partner details on a web page.

What is it: A simple web app based on HTML, CSS and JavaScript.

The frontend can be built with plain HTML, CSS and JavaScript.

HTML: Used to define the content of the web page
CSS: Used to apply styles to the web page (layout, colours, font, etc.)
Javascript&colon; Use for programming logic, for example:
- Get input field values from HTML
- Fetch data from the server
- Restructure data for display

HTML, CSS, and JavaScript are written in their own files. They are typically in the same folder.

```
frontend/
├── index.html
├── styles.css
└── script.js
```

The HTML file includes references to the 'styles.css' and 'script.js' documents. These can all be written in simple text editors, but applications like 'visual studio code' help with syntax highlighting and formatting.

For demo/test these files can simply be kept on a computers hard drive. Or they could be hosted on a static web server like Netlify or GitHub pages.

Point 8.2: Web app - HTML

Web pages are written with HTML, they are hierarchically structured documents where 'tags' are used to denote different types of element which contain content.

As a simple illustration, the following would create a web page with a title, a text input field, a submit button and a space for results.

<header>
<p>This is the page title</p>
<body>
<article>
  <form>
    <label>Enter business partner number
      <input type="text" />
    </label>
    <button type="submit">Submit</button>
  </form>
  <div id="js-results">
    // Results go here
  </div>
</body>

This would display:

A simple element such as paragraph is denoted by
- `<p>enter paragraph</p>`
A more complex element, an input field is denoted by
- `<input type="text" />`
- In this case, `type` is an attribute set to `text` for text field

Getting HTML to talk to CSS and JavaScript**

There are two attributes that allow them to work together:

"id": for example id="bp-input" (where bp-input is a variable name)
"class": for example class="bp-input" (where bp-input is a variable name)

These attributes can be added to HTML elements to allow us to access those elements with CSS and JavaScript. The difference between the two is a single "id" value is unique and should only be used once in an HTML document, while a class can be applied to multiple HTML elements.

The body of the web app frontend is:

<body>
<header class="header">
<div class="header-title">
<img class="logo" src="assets/team.png">
<p class="title">Employee portal: business partner search</p>
</div>
<nav class="nav">
<a href="/index.html">Home</a>
</nav>
</header>
<article class="bp-article flow">
<h2>Search</h2>
<div class="divider"></div>
<form id="bp-form" class="bp-search">
<label for="bp-inp-number">Business partner number:</label>
<p class="text-small">(Enter 7 digit number or leave blank to return all)</p>
<input id="bp-inp-number" class="bp-inp-number" name="bp" type="text" />
<p id="bp-error" class="bp-error"></p>
<p class="options">Options:</p>
<div>
<input id="bp-inp-address" value="add" type="checkbox" />
<label class="text-small" for="bp-inp-address" name="bp-input-address">Include address details</label>
</div>
<div>
<input id="bp-inp-tab" value="tab" type="checkbox" />
<label class="text-small" for="bp-inp-tabulate" name="bp-inp-tabulate">Show results in table</label>
</div>
<button id="js-inp-sub" type="submit">Submit</button>
</form>
<h2>Results</h2>
<div class="divider"></div>
<div id="js-bp-results" class="bp-results">
</div>
</article>
</body>

It's not very complex. Most of the complexity is in the CSS styling and the JavaScript programming to return the results.

This segregation of content (HTML), styles (CSS), and programming logic (JS) makes working with frontend well structured.

The web app initial HTML includes:

A header bar with the logo, page name and home link
A search section with search field options
- BP number
- Checkbox to get address
- Checkbox to show results in detail view

This is how this looks without styling.

The version with styling was shown at the start of the article.

Here is the HTML file

Point 8.3: Web app - CSS

Cascading style sheets (CSS) are used to apply styles to HTML documents. Consider an HTML document with three lines of text:

<p id="line-one">This is text line one</p>
<p class="other-lines">This is text line two</p>
<p class="other-lines">This is text line three</p>

These can be styled with CSS as follows:

#line-one {
color: red;
font-size: 1.2rem;
}

.other-lines {
color: blue;
text-decoration: underline;
}

This would show:

The complete CSS for the demo/test web app is lengthy. Around 200 lines. Here is a snippet to get an idea of what it looks like:

CSS is easy to pick up, but challenging to master!

Looking at the class "bp-search". This applies to the area of the HTML document where the search fields are collected. The CSS here does things like orient those search fields in a column "flex-direction:column" and apply a border and a shadow.

This is how our page looks with styling.

Here is the full CSS file

Point 8.4: Web app - JavaScript

Frontend JavaScript is able to retrieve, edit and add elements to the HTML document. Writing the JavaScript is possibly the most challenging part of this demo/test, so I'll just summarise what the code does:

Listen for a click of the 'submit' button
Get the value of the form input elements
- The Business partner number
- The status of the 'include address details' checkbox
- The status of the 'show results in table' checkbox
Check the business partner value is valid
- It has to be blank or a 7-digit number
Create a variable object called 'request' to track the request type
The variable includes:
- request URL
- request method
- request body
- (The ability to track multiple values in an Object is a key JS feature)
Based on the input fields, identify the request type & update the 'request' object.
- The combinations are:
  - If bp number is blank and get address isn't checked
  - If bp number is blank and get address is checked
  - If bp number is entered and get address isn't checked
  - If bp number is entered and get address is checked.

At this point, the request object will store a set of values based on the input selections. The values will be one of the four options listed in the earlier tables.

The JavaScript now has what it needs to send a request to SAP Integration Suite. The rest of the JavaScript handles various things:

Use the JavaScript method 'fetch()' to send requests to the server
Handle security and authorisation
Getting a token if needed
Sending a token with requests
Handling errors
If successful, capturing the returned data
Working through the returned data and updating the HTML
Creating cards for the summary view
Creating a table for the detailed view

Here is the JavaScript.

Point 9. Web app: backend server

Purpose: Allow a web frontend to communicate with SAP BTP.

What is it: A JavaScript web backend server for message formatting and routing.

The backend server is locally hosted on our computer for this test/demo, but in reality would be on a web server somewhere.

It's written in express, which is a framework on Node.js. It's quite different from frontend JavaScript.

The logic of the backend is:

Listen for communication from the frontend
If a message is received:
- Do some manipulation of the message related to authorisations
- Using fetch() try sending a request to SAP Integration Suite
- More authorisation/security handling
- If successful, return the response back to the browser
- If unsuccessful, log and return the error.

Here is the backend JavaScript code. This needs to be set up as part of a Node.js server.

The JavaScript server is a bit more complex than the frontend. The server folder contains:

```
web-app-server/
├── node_modules/ # created by npm install
├── package-lock.json # created/updated by npm install
├── package.json # you write this (or generate with `npm init`)
└── server.js # your server code
```

server.js contains the actual JavaScript code for the server.
package.json defines project settings, dependencies, and scripts.
node_modules/ and package-lock.json are automatically generated when dependencies are installed using npm install.

The port can be specified in 'server.js'. I choose port 5000.

This means the server will run on 'http://localhost:5000'.

After writing package.json and server.js, the following steps are required in terminal to initialise the server, install express, and then start the server.

cd web-app-server
npm init -y
npm install express
node server.js

We can now update the flow diagram with the details for the frontend.

One flow, many messages

Looking at the diagram, a click on the search button triggers a message that passes through four stages:

From the frontend (browser) to the backend web server
From the web server to SAP Integration Suite
From Integration Suite to Cloud Connector
From Cloud Connector to the S/4HANA system

JavaScript doesn’t normally “wait” for things to happen — it’s designed to keep running while other operations (like network requests) complete in the background.

However, the fetch() function is asynchronous, which means it starts a request and immediately returns a kind of “promise” — a placeholder that will eventually be resolved when the response comes back (or if it fails).

When testing this flow, there are multiple layers where errors can occur:

The browser console (frontend logs)
The backend server console (Node.js logs)
Integration Suite’s monitoring tools

The message can fail at any step, and it sometimes takes a bit of detective work to figure out where it failed and why.

If everything works, and S/4HANA returns a successful response (status code 200), that response flows automatically back through the same chain — each layer staying in a “waiting” state until the result is passed back to the frontend and displayed to the user.

Don't worry if it's not 100% clear, it took me a while to figure this out.

Conclusions to the walkthrough

It's really fun to build your own frontend and connect it to a real enterprise grade system.

A few important considerations:

Precision is needed with the integration configuration:
- Host names, types, routing, transformation are all sensitive to mistakes
The JavaScript is a little complex, but it is all well established
A JavaScript and Node.js course and some googling could enable anyone to create this.
Using the S/4HANA business partner mock server is a quick and fun way to test out a potential integration with S/4HANA. However, it is just a mock server with limited features and a build and test with a real S/4HANA system would be required.

However, it's easily achievable with a little study and practice and it opens the possibility to develop a wide range of things.

The APIs brings together:

Real-time fast access to a wide range of business data thanks to S/4HANA.
Extreme flexibility on the frontend side thanks to modern HTML, CSS and JS.

This integration could have been much simpler by just having the frontend deliver a URL in the format required for the API. We don't really need the complexity of Integration Suite for this.

---

Part 3: building the integration flow (for IT people)

In this section I'll share my rough notes from the process of building this front end and integration flow. This is a copy and paste of my original notes in markdown so I apologise for the lack of formatting. I do list all the required tools which may be helpful for people trying this out.

Before starting, I'd recommend working through the CodeJam:

SAP CodeJam
The instructions are on a GitHub repository.

Information sources & tools

SAP Accounts: BTP and Integration Suite

A trial account for business technology platform is required.

[BTP trial](https://developers.sap.com/tutorials/hcp-create-trial-account.html)

And a a trial for Integration Suite

[Integration Suite trial](https://developers.sap.com/tutorials/cp-starter-isuite-onboard-subscribe.html#f55ec71c-2853-4b83-8092-4e3031f8d6e6)

See the pre-requisites [pre-requisites](https://github.com/SAP-samples/connecting-systems-services-integration-suite-codejam/blob/main/prerequisites.md) document in the CodeJam repository.

Containerisation & Docker

When running the S/4HANA business partner mock server locally, one option is to install the necessary JavaScript runtime environment and run it manually. Another option is to run it inside a container.

Containers are a key concept in Cloud architecture.

A container packages an app and all it's dependencies together so that it can run independently of the underlying computer (server, laptop, etc.).

This is a key concept for Cloud as it allows applications to run on different hardware and operating systems with minimal set up effort.

Docker is a platform to build and manage containers.

Docker and container features:

- Package an app and all it's dependencies
- A container is like a lightweight virtual machine
- Key terms
- image: blueprint (.zip) containing app, dependencies, and OS
- container: running instance of an image
- dockerfile: instructions to build image
- volume: how to persist data outside the container
- port mapping: expose internal port to machine (e.g. 8080 to 3001).

I'll come back to this in the section on running the BP mock server.

Data basics

The following data standards/formats are used in this exercise:

JSON (JavaScript Object Notation)

- A lightweight, human-readable format for storing and sharing structured data
- Looks like nested key-value pairs (like a shopping list with categories)
- Commonly used in web apps and APIs for sending data between systems.

For example:

```JSON
{
"employee_id": "1234567",
"employee_name": "Alexander"
}
```

XPATH

- A query language used to navigate and extract data from XML or HTML documents
- Lets you point to specific elements using a path-like syntax
- Example: find the third paragraph inside a section
- Used in tools like web scrapers and automation scripts.

For example:

```XPATH
//title[contains(text(), 'Programming')]
```

XML (eXtensible Markup Language)

- A flexible, tag-based format for representing structured data
- Similar to HTML in appearance
- But used for data storage and exchange, not page display.

For example:

```XML
<book id="bk01">
<author>Roan, Alexander</author>
<title>Front end to S/4HANA</title>
```

HTML (HyperText Markup Language)

- The standard language for building web pages and displaying content in browsers
- Uses tags to define elements like headings, paragraphs, links, and images
- Focused on structure and layout, not data exchange.

Terminal

I worked through this demo/test on Mac so I used Terminal, which is the Mac default command line interface (CLI).

The CLI is necessary for activities such as setting up and starting servers or working with docker containers.

Terminal basics

- Open a folder `cd <folder name>` (change directory)
- `cd` on it's own will go to the home directory
- (Note that `~` represents home directory in terminal)
- `cd ..` will go up a folder
- List folders `ls` (list files in the current directory)
- Open a file `open <file name>` (open a file)
- Quit sub-screen and return to terminal `q`
- Stop a running process hold control and c
- Clear terminal `clear`

To run JavaScript servers, JavaScript runtime is required. It's easier to install and manage things like this using a package manager in Terminal. Homebrew is a popular package manager for Mac.

Homebrew

- A package manager for Mac
- To install homebrew homebrew:
- Launch terminal (launchpad > other > terminal)
- Visit [Homebrew](https://brew.sh/) in your web browser
- Copy the installation command
- Paste it into terminal press enter.

Java/JavaScript

To complete the demo/test a few different JavaScript things are needed.

Node.js

- This is a JavaScript that can be installed locally to create and run web-servers and web applications
- Install using Homebrew
- In terminal, enter: `brew install node`
- Test the installation of Node.js
- In terminal, enter: `node -v`, it should return the node version number.

NPM

- NPM is the node package manager
- It's installed with Node.js
- It's used to run a server
- Install it in any directory a Node.js server sits in
- To check the installation of NPM
- In terminal, enter: `npm -v`, it should return the npm version number

Java development kit (JDK)

- Cloud Connector is a more complex application and requires JDK
- More notes in the Cloud Connector section.

API client (Bruno/Postman)

The CodeJam utilised [Bruno](https://www.usebruno.com/) for API testing.

For the CodeJam a folder of pre-configured settings for Bruno is provided. However I'd suggest to start experimenting without the pre-configuration to build a solid understanding of the basics.

I'll include more notes in later sections.

Building and testing an integration flow

Set up the S/4HANA business partner mock server

Start by setting up the S/4HANA business partner mock server

- Download the mock server from [GitHub](https://github.com/SAP-archive/cloud-s4-sdk-book/tree/mock-server)
- Scroll down to the readme
- Either download the archive linked under 'How to run this server'
- Or if using GitHub clone the repository and checked the branch 'mock-server'
- Move it to a convenient folder of your choice
- I set it a `users/<username>/projects/integration/cloud-s4-sdk-book`

Run the server: option 1: use NPM

Node.js and the node package manager (NPM) can be used to run the server directly on a computer.

- Open terminal
- Navigate to `users/<username>/projects/integration/cloud-s4-sdk-book`
- (or wherever you saved the folder)
- Enter: `npm install` (install node package manager in the folder)
- Enter: `npm start` (start the server)
- This should return something like:

```shell
> bupa-mock-odata@1.0.0 start
> node server.js
Mock server started on port 3000 after 1 ms, running - stop with CTRL+C (or CMD+C)...
```

Terminal tells us which port the server is running on. Port "3000" is accesible in the browser or an API client via "http://localhost:3000".

To stop the server in terminal use `ctrl+c`.

For the curious, you can look at the files that make up the mock server in the above folder. Check out:

- server.js
- This includes the JavaScript code for the server
- The code references other files such as app.js
- package.json
- This is like a configuration file for a node.js server
- business partner > business-partner-data.json
- This contains the demo test business partner data.

Theoretically you could use this Node.js server as a template to simulate other SAP Odata APIs with some adjustments to these files.

Run the server: option 2: use Docker

The mock server can also be run as a Docker container. This is a little more convenient as after the first run we can stop and start it from the Docker desktop app.

Note the server already has a Dockerfile, so it's already set up to run as a container.

If we run something inside a docker container we need to interact with it via ports on the container. The application is really running contained inside a container. When we run a docker container we provide a mapping between a local port on the computer and the container port. We can then access the docker application via this mapping.

To run as a Docker container:

- Launch the docker app
- Open terminal
- Enter `docker run -p 3005:8080 bp-mock-server`
- 3005 is the local port
- 8080 is the docker container port
- Local port can be any free port on your computer. I choose 3005
- The container port is 8080
- View the status of the container in the Docker app
- Use the browser to check `http//localhost:3005`

Note if there wasn't already a dockerfile we would need to create one and build the app before running it.

**A simple docker demo**

This was my first time using docker, so I experimented by creating a simple "Hello, World!" style server from scratch. Here it is if you want to try:

- Create a JS file "index.js"
- Add `console.log("hello from docker");`
- This just prints text to the console (Terminal)
- Create a package file "package.json"
- Add the following JSON to "package.json"

```json
{
"name": "hello-docker",
"version": "1.0.0",
"main": "index.js",
"scripts": {
"start": "node index.js"
}
```

- Create a dockerfile "dockerfile"
- Add the following to "dockerfile"

```Dockerfile
FROM node:18

WORKDIR /usr/src/app

COPY package*.json ./
RUN npm install

COPY . .

CMD ["npm", "start"]
```

You can see Docker uses NPM, in the same way we would with a manual run, but it's installing and running NPM inside the container, not on the computer.

To build and run:

- Build docker container `docker build -t hello-docker .`
- Run docker container `docker run hello-docker`

Testing with the web browser

The simplest way to test the API is running locally is to put the local address in the web browser.

- For NPM it was "http//localhost:3000"
- For docker image it was "http//localhost:3005"

The main domain should return the API details including the links such as:

"http://localhost:3000/sap/opu/odata/sap/API_BUSINESS_PARTNER"
"http://localhost:3005/sap/opu/odata/sap/API_BUSINESS_PARTNER"

To access the service to return the general data of all business partners we add A_BusinessPartner

"http://localhost:3005/sap/opu/odata/sap/API_BUSINESS_PARTNER/A_BusinessPartner"

In the browser, this should return a JSON document containing the list of business partners.

We can pick a business partner number from the list and use it with the path to select a specific business partner:

"http://localhost:3005/sap/opu/odata/sap/API_BUSINESS_PARTNER/A_BusinessPartner('1003764')"

Testing with an API client (Bruno)

Rather than just using the web browser to check the API an API client can be used, this has a few benefits:

- We can build the URLs through a selection of 'input fields'
- We can save different requests for easy and quick re-testing
- We can pass data in the request body

To test with Bruno:

- Launch Bruno
- Use the '...' menu to create a collection
- Name it 'bp-mock'
- Specify a location. I used "users/{username}/projects/integration"

Create a request for all business partners

- Use the '...' menu next to bp-mock and select 'new request'
- Enter request name 'All business partners'
- Under URL select 'GET' and enter the URL that returns all business partners
- `http://localhost:3005/sap/opu/odata/sap/API_BUSINESS_PARTNER/A_BusinessPartner`

Run a request

- Look to the right of the 'GET' line on the main page and click the '->' to run
- The right panel will show the JSON response
- The same response as shown earlier in the web browser.

Create a request for a single business partner (1003765)

- Use the '...' menu next to bp-mock and select 'new request'
- Enter request name 'Specific business partners'
- Enter the same URL details as above.
- In the 'params' tab click '+ param' and enter
- Name: `&filter`
- Path: 'BusinessPartner eq '1003766'
- Run the request. A single business partner should be returned.

Note as the params are entered the URL dynamically updates.

Basics on OData API URLs

- The base for the API is "/API_Business_Partner"
- A service of the API is then appended "/A_BusinessPartner"
- Queries can then by added, OData queries include:
- Filtering: `/A_BusinessPartner?$filter=Name eq 'Max'`
- Selecting fields: `/A_BusinessPartner?$select=Name,City`
- Pagination: `/A_BusinessPartner?$top=5&$skip=10`
- Accessing nested data: `/A_BusinessPartner?$expand=Address`
- When working with OData:
- Field names are case sensitive
- String values in single quotes

Keep in mind the S/4HANA mock business partner server only includes limited functionality. The above filters and selects won't work.

Java SDK for SAP Cloud Connector

The next step is to set up SAP Cloud Connector

Recall Cloud Connector will provide a secure tunnel allowing SAP Cloud to talk to the S/4HANA business partner mock server.

Cloud Connector requires a full Java Development Kit (JDK).

- You can use "javac -version" in terminal to check if you already have JDK
- There is a SAP Help page for [Cloud Connector](https://help.sap.com/docs/connectivity/sap-btp-connectivity-cf/cloud-connector?locale=en-US)
- Check the [prerequisites](https://help.sap.com/docs/connectivity/sap-btp-connectivity-cf/prerequisites?locale=en-US#jdks) section, it lists the JDK options
- I choose SAP machine 21 JDK
- You can download this from [GitHub](https://sap.github.io/SapMachine/)
- I have a dev folder for items like this in my home folder
- "Users/{username}/dev"
- Use Homebrew to install
- Open terminal and enter "brew install openjdk@21"

It's likely you may run into version, compatibility, authorisation issues. These are all very common and a web search should help.

Install Cloud Connect

Next install Cloud Connector.

Cloud connector is listed under the SAP development tools page under [Cloud](https://tools.hana.ondemand.com/#cloud).

- Download the cloud connector file for your OS
- My Mac is Apple Silicon so I chose 'sapcc-2.18.1.2-macosx-aarch64.tar.gz'
- Unzip and move it to a folder of your choice
- Navigate inside the downloaded folder in terminal
- Check contents with 'ls', you should see a 'go.sh' file
- Enter: './go.sh' this will run Cloud Connector
- Cloud connector should now be running, note the address in the terminal log
- Login with default account: 'Administrator' and password: 'manage'
- Change password
- Keep a note of the account and password.

I received authorisation issues on the first attempt to run it:

- Click through them, then goto apple > settings > privacy&security
- Scroll down to security and click 'allow anyway'
- Try: './go.sh' again.

Install and set up SAP Integration Suite

To continue from here SAP Integration has to be installed and active as per the earlier instructions.

Connect SAP Cloud Connector to SAP Integration Suite

As Cloud Connector bridges between SAP Cloud and the S/4HANA business partner mock server we need to set it up to connect to SAP Cloud. We get the security/authentication data to do this from our SAP BTP trial account.

- After logging into Cloud Connector click '+Add Subaccount'
- Hit 'next' to skip the HTTPS settings
- Select 'Configure using authentication data'
- Select 'Add subaccount authentication data from file '
- In your browser got to your SAP BTP trial homepage
- Click on your subaccount
- On the left menu expand Connectivity and select Cloud Connectors
- Click on 'download authentication data'
- Return to Cloud Connector
- Click browse and select the downloaded file 'authentication.data'
- Click next
- Leave location ID blank
- (This would be relevant if there were multiple Cloud Connectors)
- Click finish.

Double check the settings in the subaccount overview:

- BTP trial region = Cloud Connector region
- BTP Subaccount ID = Cloud Connector Subaccount
- The region host in Cloud Connector = Cloud Foundry API Endpoint in BTP.

Cloud Connector to Mock BP Server

There's no security on S/4HANA business partner mock server so it is simply a matter of adding the address.

- In Cloud Connector, on the left sidebar click 'Cloud to On-Premise'
- To the right of 'Mapping Virtual to Internal Systems' click `+`
- Select back-end, enter: "Non-SAP system", click 'next'
- Select protocol: "HTTP", click 'next'
- For internal host enter "localhost"
- For internal port enter: "3005"
- For virtual host: "s4-mock"
- For virtual Port: "3006"
- Uncheck allow principal propagation
- Click through to finish.

Replace the internal port name with the one your mock server is running on locally. You are free to choose the virtual host and port.

It's critical to select "Non-SAP system" and HTTP, not HTTPS.

A new entry will appear under 'Mapping Virtual to Internal Systems'

- Make sure your mock bp server is still running on the host and IP you entered
- From the icons on the right, click on 'check availability..'
- You should see status 'reachable'

At this stage `https://localhost:3005` is now mapped to `https://s4-mock:3005` in the SAP Cloud.

You can also check in integration suite to see if Cloud Connector is connected.

- In the left hand menu select connectivity > cloud connectors.

Errors at this stage are likely related to

- Mistakes in the host name, port name, or system type
- The mock server or cloud connector is not running.

Design integration flow

Create an integration flow

- Login to BTP trial home
- From the left hand menu expand Services and select Instances and subscriptions
- Under 'Subscriptions' click on 'Integration Suite'
- On the left menu select expand 'Design' and select 'Integrations and APIs'
- Choose 'Create' on the top right to create a new package.
- Give it a name
- Shift to the 'Artifacts' tab
- Select 'Add' and choose 'Integration Flow' from the list
- Give it a name
- Click add
- Click on the newly created integration flow

The integration flow screen is read-only by default, click edit.

Set up the sender

Define an 'address' for the SAP Integration Suite endpoint.

- Click on sender
- Click connector arrow
- Drag to start event
- In adapter type pop-up select HTTPS
- To configure the adapter click on the drawn line (if not selected)
- The settings are in the bottom panel, drag it up to expand it
- Navigate to 'connection' tab, enter the following:
- Address: `/request-business-partners`
- Authorisation: `User Role`
- User Role: `ESBMessaging.send`
- CSRF Protected: `Unchecked` (Cross-site request forgery).

Add flow elements

The CodeJam has excellent instructions for walking through different flow steps as per their exercises.

I will summarise a few elements I used in my design.

Router

![Router](/assets/images/blog/integration/Integration-23-A.png)

- The router allows you to split the flow based on a condition.
- This example splits the flow into 4 based on the incoming URL
- For example where the incoming URL ends in "single/add"
- Re-call our integration flow address was "request-business-partners"
- In this case a message arrives to "request-business-partners/single/add"
- Intelligent Suite assigns the last part to the variable CamelHttpPath
- Which is part of the message header hence: header.CamelHttpPath.

The route path we are looking at in this example is the one that returns a single business partner with address data.

Content modifier - case 1

Case 1:

- The content modifier allows us to modify the message header or body.
- In the above screenshot a content modifier is added directly after the routing.
- This deletes the CamelHttpPath, in this case "single/add"
- After routing we no longer need this part of the URL in the message header.

JSON to XML converter

- This converts the JSON in the message body to XML.
- In the case of searching for a single BP the message body includes JSON:

```JSON
{
"employee_id": "1234567"
}
```

- This will be converted to XML

```XML
<root>
<employee_id>1234567</employee_id>
</root>
```

Content modifier - case 2

![Content modifier](/assets/images/blog/integration/Integration-23-B.png)

- In this case the content modifier gets "employee_id" from the message body
- And assigns it to a new variable
- XPath can be used to access the XML value
- "/root/employee_id"
- The variable name is set as employee_id
- The data type is set as a Java string.

Request Reply

Request reply let's us send a request to a server.

- Click on the Set employee_id
- Click add flow step on the canvas
- Select 'Request Reply' under call > external call
- Click on 'Request Reply'
- Click on 'connector' and drag to the receiver
- Select adapter type 'HTTP'
- Under 'HTTP' in the connector properties, select 'Connection'
- Enter the address of the cloud connector:
- The path for a single business partner with address data involves updating:
- Address: "http://s4-mock:3006/sap/opu/odata/sap/API_Business_Partner/A_BusinessPartner('${property.employee_id}')"
- Query: "$expand=to_BusinessPartnerAddress"
- Proxy Type: `On-premise`
- Method: `GET`
- Authentication: `None`
- Save
- Deploy

To check deployment status go to Monitor > Integration and APIs. On this page the endpoint to access the service is shown:

"https://{your trial}-cpitrial03-rt.cfapps.ap21.hana.ondemand.com/http/request-business-partners"

Test Cloud Integration with API client

At this point we can test consuming the API through SAP Integration Suite.

Unlike testing the local mock server, we need to deal with authentication and security. The way this works is:

- We pass a "client id" and "secret" to a "token URL"
- BTP passes back a "token" which is valid for a certain period of time
- This "token" has to be attached to any requests to the API in Intelligent Suite.

Accessing security details

- Navigate to your BTP trial account
- Expand services and click on 'instances and subscriptions'
- Scroll down to instances and look for your integration flow instance
- Integration Suite uses Cloud Foundry so the runtime will be cloud foundry
- It will likely be named 'default_it-rt_integration-flow'
- Scroll down to service keys and click on the service key, note the values for:
- "clientid"
- "clientsecret"
- "url"
- "tokenurl"

For local testing we can hardcode these values in our test tools, but be careful not to upload or share these anywhere.

In production, never hardcode secrets or tokens. Use environment variables or a secure credential store.

**Request a token with Bruno**

In Bruno create a new request:

- Name: `TOKEN`
- Method: `POST`
- URL: enter the "tokenurl" from above
- Navigate to the Params tab:
- Select 'Add Param'
- Enter name: `grant_type` path: `client_credentials`
- Navigate to Auth
- Switch 'Inherit' to 'Basic Auth' and enter:
- Username: `client_id`
- Password: `client_secret`
- Save

Send the request. This should return a JSON document with a long value in "access_token". There should also be a expiry time e.g. 4199 seconds.

When sending a request, if the token is not valid Integration Suite will return a 401 error code. This means we need to request a new token.

Within Bruno we can save this token value to a variable. This saves us from copying and pasting it into other requests.

- Goto Environments > Configure > Create Environment
- Name: 'integration-flow'
- Click '+ Add Variable'
- Enter name: 'access_token'
- For value, leave it blank
- Save and close

Navigate to 'scripts' under the TOKEN request. Under Post Request enter:

```JS
if (res.status == 200) {
const token = res.body.access_token;
bru.setEnvVar("access_token",token);
}
```

- If the request receives a response (status 200)
- Get the access_token value from the response
- Assign to environment variable "access_token".

Save and run the TOKEN request.
Goto the environment and click 'configure'. You should see the access_token variable updated with the value from the response.

**Test the API with a request with for a single BP**

- In Bruno create a new request
- Name: "BP via integration suite"
- URL: "https://{your-trial}.it-cpitrial03-rt.cfapps.ap21.hana.ondemand.com/http/request-business-partners"
- Replace the above with your actual endpoint from Intelligent Suite.
- Navigate to the 'Auth' tab
- Click on 'Inherit' and change to 'Bearer Token'
- In Token enter: `{{access_token}}`
- This eferences an environment variable in Bruno
- Add the request body
- The JSON with our employee ID

```JSON
{
"employee_id": "1003764"
}
```

Building and testing a frontend

At this point a request to SAP Integration Suite should be successfully routed and transformed to the S/4HANA business partner mock server.

The next part would be building and testing the web app. However, there is too much to cover in building and testing the frontend to cover in this post. I may produce a video on this if anyone is interested.

Final thoughts

This technology stack is definitely a bit overkill for a simple 'search' portal, but it is fairly easy to put together as long as you are careful when specifying paths, hosts and port names.

If you'd like to discuss further please feel free to connect on LinkedIn - Alexander Roan

Give Your AI Agent Some Tools: Introducing the UI5 MCP Server

2025-09-03T09:45:00.056000+02:00

We are happy to announce the release of the UI5 MCP server – an open-source Model Context Protocol (MCP) server that provides AI agents with comprehensive UI5 knowledge. By combining best-practice guidelines, project-aware context information, templates for creating new projects, and access to the rich set of UI5 CLI tools, the UI5 MCP server transforms AI agents into UI5 development experts.

In parallel to this release, our colleagues from CAP and SAP Fiori elements have also introduced dedicated MCP servers:

Why Use the UI5 MCP Server?

Large Language Models (LLMs) sometimes lack information on the latest best practices and APIs recommended for UI5 development.

They might recommend the use of UI5 APIs that do not exist in the version used by your project, or of APIs that have been marked as deprecated.

By facilitating UI5 linter, your coding agent can validate the changes it has made, ensuring they follow current best practices.
Scaffolding can help agents kickstart new projects faster and with established patterns, saving token costs.

Setup

Installing the UI5 MCP server is easy. Head over to the project page and follow the instructions for your code editor (your MCP client): https://github.com/UI5/mcp-server#setup.

Some IDEs (like VS Code) allow you to add MCP servers directly from npm. In that case, choose this option and provide the package name "@ui5/mcp-server" as shown here:

Once installed, the AI agent in your IDE will automatically gain access to the UI5 MCP server and can start using the tools at its own discretion. Depending on your IDE and settings, you may need to approve the first tool calls.

Try It!

The UI5 MCP server works well for everyday tasks in UI5 projects. It can help you refactor your code and add new features.

In your UI5 projects, try out some prompts like the following:

"Explain the difference between the sap.ui.require and sap.ui.define APIs"

"Should I use sap.ui.table.Table or sap.m.List? What is the difference?"

"How can I style an sap.m.Button to appear as a "reject" action?"

Ask questions about your code:

"Does this UI5 view apply best practices?"

"Should I update the UI5 version of this project?"

"Help me migrate any deprecated UI5 API usage in this UI5 controller"

Tools

This release of the UI5 MCP server includes the following six tools, which can be accessed by your AI agent:

Best Practice Guidance for Your Agent: get_guidelines

Provides curated UI5 development guidelines specifically formatted for AI consumption, ensuring that it follows fundamental concepts and that the generated code adheres to current best practices.

Project Scaffolding: create_ui5_app

Creates a foundation to start new UI5 projects. The tool comes with templates for both JavaScript and TypeScript UI5 applications. They can be generated as standalone apps or integrated into an existing CAP application.

The templates feature pre-configured OData model setups and follow current best practices.

Search the UI5 API Reference: get_api_reference

Allows the AI agent to search the UI5 API reference and learn about API descriptions, signatures, and deprecation information. You may have encountered AI agents hallucinating about UI5 APIs that do not exist. This tool will effectively overcome such problems.

The UI5 MCP server ensures that the version of the API reference matches with the UI5 version configured in your project, so you always get relevant information.

Let the Agent Fix Your Code: run_ui5_linter

This tool exposes functionality of UI5 linter, allowing the AI agent to scan a UI5 project for problems such as the use of deprecated UI5 APIs, and to apply any fixes provided by UI5 linter.

Beyond these basic linting capabilities, the tool also provides rich contextual information, including rule descriptions, extracts of relevant API references, and even entire guides for the manual migration of certain deprecated APIs that can’t be fixed automatically by UI5 linter. These guides offer step-by-step instructions that guide the agent through complex refactoring, for example when replacing a deprecated, synchronous UI5 API with its modern, asynchronous successor.

Project Insights: get_project_info

Provides selected metadata for your UI5 project. This includes the relevant configuration, the framework version and libraries used, and current information regarding the version’s support status. All this allows the AI agents to quicky gain important insights about the project.

UI5 Version Overview: get_version_info

Delivers real-time information about UI5 framework versions, including the support status and upgrade paths.

2026 Update: New Tools for UI Integration Cards

In its latest version, the UI5 MCP server now also supports the development of UI Integration Cards. The new tools include:

get_integration_cards_guidelines: Provides dedicated guidelines for the development of UI Integration Cards
create_integration_card: Creates new UI Integration Cards based on parameters
run_manifest_validation: Validates the manifest.json, not only for UI Integration Cards, but also of regular UI5 applications and libraries!

For more information on the new tools, see the blog post: UI5 MCP Server Got Extended for UI Integration Cards Generation

Dive Deeper

If you’re interested in learning more about the inner workings of the UI5 MCP server, check out the code at github.com/UI5/mcp-server and read the architecture document.

Don’t hesitate to reach out if you should run into any trouble using this new tool. Simply create an issue on GitHub, and we’ll be happy to help. You can also propose new features through this method.

As always, we’re looking forward to your feedback!

SAP Fiori: Adding Field Validation Based on Other Field Values Using Controller Extensions OData V2

2025-11-03T14:13:25.458000+01:00

In many project use cases, we often encounter situations where the validity of one field depends on the value of another. For example, when a flag is updated or a key date is modified, the user must provide additional comments before saving the record.

In this blog post, I’ll walk you through how I implemented such conditional validations in a Fiori Elements Object Page using Controller Extensions.

Scenario

I had a requirement where:

If the Last Working Date (LWD) was changed, then the Additional Comments (ARD Comments) field must not be empty.
If certain flags or dropdown values were set to specific conditions (like “Y” or a specific code), corresponding comment fields were required before allowing the user to save.

Instead of modifying the generated metadata or annotations, I handled these validations using the Controller Extension’s beforeSaveExtension hook, which is triggered before the save action.

Implementation

1. Adding controller extension :- Add the controller extension file in app/webapp/ext/controller as ObjectPageExt.controller.js

2. Add the controller file in manifest.json

"sap.ui5": {
    "flexEnabled": true,
    // other fields
    "resources": {
      "css": []
    },
    "routing": {
      "config": {},
      "routes": [],
      "targets": {}
    },
    "extends": {
      "extensions": {
        "sap.ui.controllerExtensions": {
          "sap.suite.ui.generic.template.ObjectPage.view.Details": {
            "controllerName": "app.ext.controller.ObjectPageExt"
          }
        }
      }
    }
  },

3. ObjectPageExt.controller.js

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

    return ControllerExtension.extend("offboardingdashboard.ext.controller.ObjectPageExt", {
        override: {
            beforeSaveExtension: function () {
                const oContext = this.getView().getBindingContext();
                if (!oContext) return Promise.resolve();

                const oModel = oContext.getModel();
                const sPath = oContext.getPath();
                const oNewData = oContext.getObject(); // Current draft data

                // --- Step 1: Get the original (active) entity data ---
                const oOriginalData = oModel.getOriginalProperty
                    ? oModel.getOriginalProperty(sPath)
                    : null;

                // --- Step 2: Detect change in Last Working Date ---
                let bLwdChanged = false;
                if (oOriginalData && oOriginalData.cust_lastworkingdate && oNewData.cust_lastworkingdate) {
                    const dNew = new Date(oNewData.cust_lastworkingdate);
                    const dOld = new Date(oOriginalData.cust_lastworkingdate);
                    bLwdChanged = dNew.getTime() !== dOld.getTime();
                } else if (oOriginalData && oOriginalData.cust_lastworkingdate !== oNewData.cust_lastworkingdate) {
                    bLwdChanged = true;
                }

                // --- Step 3: Apply validation rules ---
                const aMessages = [];

                if (oNewData.cust_rehire === "Y" && (!oNewData.cust_rehirecomments || oNewData.cust_rehirecomments.trim() === "")) {
                    aMessages.push("• Rehire comments are required when rehire flag is set to 'Yes'.");
                }

                if (bLwdChanged && (!oNewData.cust_ardcomments || oNewData.cust_ardcomments.trim() === "")) {
                    aMessages.push("• ARD comments are required when Last Working Date has been changed.");
                }

                // --- Step 4: Show error message and prevent save ---
                return new Promise(function (fnResolve, fnReject) {
                    if (aMessages.length > 0) {
                        const sMessage = "Please address the following issues before saving:\n\n" + aMessages.join("\n");
                        MessageBox.error(sMessage, {
                            actions: [MessageBox.Action.OK],
                            onClose: fnReject
                        });
                    } else {
                        fnResolve();
                    }
                });
            }
        }
    });
});

How It Works

The beforeSaveExtension method is triggered automatically before the Save action on the Object Page.
We first read the current draft data and the original active entity.
We compare fields like cust_lastworkingdate to detect changes.
Based on certain conditions (like flag = ‘Y’ ), we push validation messages into an array.
If there are validation errors, a MessageBox appears with all issues listed, and the save action is prevented.

UI Screenshots

When both the conditions are met :
-> last working day is changed and rehire flag is set to 'Y'

-> only last working day is changed

-> only rehire flag is set to 'Y'

Key Takeaways

Always perform value-dependent validations in the beforeSaveExtension hook for extensibility.
Use getOriginalProperty to safely compare values between draft and active entities.
Consolidate all validation messages for a better user experience rather than showing multiple alerts.

How to Reduce Prompt Token Costs Using Toon = Save Money

2025-11-12T17:34:51.069000+01:00

As you already might know prompt tokens are the backbone of communication with large language models (LLMs). However, as usage scales, token costs can quickly become a significant expense. If you’re using Toon—a tool designed for optimizing prompt workflows—you can dramatically cut down on these costs without sacrificing performance.

Why Token Costs Matter

Every interaction with an LLM consumes tokens. These tokens represent:

Input tokens: The text you send to the model.
Output tokens: The text generated by the model.

The more tokens you use, the higher your bill. For businesses running thousands of prompts daily, even small inefficiencies can lead to big costs.

Example:

Original prompt: “Please summarize the following text in a clear and concise manner, highlighting the key points and provide a RACI Matrix for S/4 HANA”
Compressed prompt: “Summarize key points.”

What is TOON?

TOON is a compact, human-readable serialization format designed for passing structured data to LLMs with significantly reduced token usage. It acts as a lossless, drop-in representation of JSON, optimized for token efficiency.

Why Use TOON?

Token-efficient: Saves 30–60% tokens compared to formatted JSON for large uniform arrays.
LLM-friendly: Explicit lengths and fields improve parsing and validation.
Minimal syntax: Removes redundant punctuation (braces, quotes).
Tabular arrays: Declare keys once, stream data as rows.
Optional key folding: Collapses nested chains into dotted paths for fewer tokens.

Benchmarks

TOON uses 39.6% fewer tokens than JSON while improving retrieval accuracy (73.9% vs 69.7%).
For uniform tabular data, TOON is slightly larger than CSV (+6%) but far smaller than JSON (-58%).

When NOT to Use TOON

Deeply nested or non-uniform structures → JSON may be better.
Pure tabular data → CSV is smaller.
Latency-critical apps → Benchmark first; compact JSON might be faster.

How to Use TOON

NPM Lib
npm install -format/toon

Python
https://github.com/xaviviro/python-toon

https://github.com/toon-format/toon

https://github.com/toon-format/spec

Why TOON Matters while your working for different SAP Product LoBs

Token Cost Reduction
- SAP S/4 HANA systems handle large datasets (e.g., thousands of line items in a purchase order).
- JSON representation of these datasets is expensive in token terms.
- TOON compresses this data by 30–60%, reducing LLM API costs significantly.
Performance Gains
- Smaller prompts mean lower latency and faster response times.
- This is critical for real-time SAP applications like Joule for procurement or HR assistants.
Improved Accuracy
- TOON’s explicit structure (e.g., tabular arrays with declared keys) helps LLMs parse data better.
- This reduces hallucinations in SAP workflows like financial reconciliation or compliance checks.

High Level Flow

Integration Approach

Middleware Layer: Convert SAP OData/JSON responses to TOON before sending to LLM.
SAP BTP Extension: Implement TOON conversion in CAP, Cloud Foundry apps or Kyma runtime or SAP Databricks, AI Core Models you have selected.
Prompt Wrapping: Always wrap TOON in fenced code blocks for LLM clarity

Best Practices

Use tab-delimited rows for extra token savings.
Benchmark TOON vs JSON for your specific SAP dataset.
Cache static context to avoid repeated token costs.

Conclusion

TOON offers a simple yet powerful way to reduce LLM costs in your SAP landscape environments. By compressing structured data without losing meaning, SAP teams can achieve:

Up to 60% cost savings
Faster response times
Improved AI accuracy

As SAP continues its AI journey, adopting TOON can make intelligent automation more scalable and cost-effective.

Understanding Regex in JavaScript - A Beginner-Friendly Guide

2025-11-28T11:44:51.979000+01:00

Quick Introduction:

When working with JavaScript, we will often find ourselves needing to search, validate or modify text. That’s where Regex comes in.

In this blog, we will break down what regex is, why it’s useful, and how to start using it with simple examples.

What is Regex?

Regex is a powerful & smart search tool that lets you find patterns in text almost like giving your code a mini detective to look for clues inside a string.

Regex (short for Regular Expression) is a special pattern used to search, match and replace text.

In other words, regex is a pattern-matching language used in many programming languages, including JavaScript to:

Search for text
Match specific patterns
Replace parts of a string

For example, we might need to check if a sentence contains a word, extract all numbers from a paragraph or validate an email address. Regex makes these tasks fast, efficient and reliable.

Why do use Regex in JavaScript?

Because normal search is limited. With regex, we can do so much. Regex lets you write dynamic, flexible patterns to handle more advanced text operations. Here’s what you can do with it:

Validate patterns
Modify text based on matching patterns.
Example: Remove extra spaces or replace characters.
Extraction Text
Check if a string follows a specific format.
Example: Is this a valid email address?
Replace text
Pull out numbers, words or custom text patterns.
Example: Find all digits in a message.

Simple and Practical Examples

Let’s look at how we can use regex in JavaScript with just a few lines of code.

Check if a word exists

const sText = "I love JavaScript";

const bResult = /JavaScript/.test(text);

console.log(bResult); // true

Find all numbers in a string

const sText = "My score is 95 out of 100.";

const sNumbers = sText.match(/\d+/g);

console.log(sNumbers); // ["95", "100"]

Replace spaces with dashes

const sResult = "hello world js".replace(/\s/g, "-");

console.log(sResult); // "hello-world-js"

How regex patterns are structured & how it works

Regex patterns in JavaScript are written between forward slashes:

/pattern/

Here are some common symbols:

Symbol	Meaning
\d	digit (0–9)
\s	whitespace (space, tab, etc.)
\w	word character (letters, numbers, _)
+	one or more
*	zero or more

Based on our requirement, we can combine these symbols to create almost any pattern we need.

In simple words, Regex is a smart text-searching tool in JavaScript. It helps us work with text faster, cleaner, and more efficiently, especially when dealing with patterns. Whether you're searching, matching or validating text, regex makes the process powerful, flexible and easy.

Thank you for taking the time to read this blog! I hope this helps you. If you found this helpful, please feel free to share your thoughts, feedback or questions in the comments. Let's keep learning and growing together!

Stay tuned for more in-depth knowledge on regex tool in future blogs. Happy coding!

Dear experts, I’m new to blogging, please feel free to correct me if any information is inaccurate.

Harnessing Reporting Potential, by Thinking outside of the Box – Part 1/3 SAC Jump & Run Blog series

2025-12-04T10:44:32.333000+01:00

Harnessing Reporting Potential, by Thinking outside of the Box - Part 1/3 SAC Jump & Run Blog series

Solving Reporting needs in SAP Analytics Cloud by passing limitations with workaround

After years of experience within the area of SAC reporting, I cannot count how often I heard colleagues, business partners, or customers complain about SAC limitations which eventually hinder the reporting potential. Like every software, the limitations in SAC stem from focus in a certain area which will result in the underdevelopment of another area. While this statement is partly true, it has shown that almost every obstacle can be overcome by thinking outside the box. Instead of being frustrated about the straight path which is blocked, users find creative tricks and workarounds and share them with the community. To prove my point, I have created a Jump & Run demo in SAC! Although such games are not part of the tool’s scope, the implementation was still easy, if one is willing to make some compromises.

Part 1 – the Game

Let me introduce you to my demo, which I will use to explain how I was able to use the potential of SAC to my advantage and discuss certain features which helped me to do so:

Figure 1: Overview SAC Jump & Run

The demo I have created is a playable, though not very complex, jump & run game. It allows the player to control their character (1) by using buttons (2). These buttons trigger the character to automatically run in two different directions, jump, or stay still.
Throughout the game, a moving enemy (3) creates constant tension, as it can cost the player valuable lives (4). The player is expected to use platforms in order to collect coins (5). Once all coins are collected, the level is completed by reaching the portal (6).

Figure 2: Jump & Run Gameplay

The most important features, which were not only helpful in creating this game, but also in fulfilling reporting requirements, are the following:

Panels
Scripting, especially Events & Timer
Images & Animations

In this blog series, I will discuss all mentioned features and explain why all of them are powerful tools for responsive reporting and, additionally, helpful when creating a jump & run game. The first blog will focus on Panels.

Part 2 - Panels & the responsive (play-)world

Why “everything” should be in a panel

What are panels?

Panels are containers used to organize and group objects by placing them inside. What makes them such a powerful tool for responsive dashboards is the relative positioning and sizing of these objects. This means that objects are set in a proportional ratio to each other and the panel, which makes the whole group automatically responsive.

Dashboards are often supposed to work on various devices and screen sizes, such as conference room screens, desktops, tablets, or phones. Responsive stories in combination with nested panels are a crucial factor for achieving the desired adaptability. Hence, they should provide the whole structure of the dashboard. As mentioned before, every part can be put in relation to each other, except the highest layer of panels. They provide the overall structure and require a fixed number of columns or rows in the grid system. In responsive stories this step can be handled rather easily, as the lanes of a story can be configured based on the end-device. The SAC user interface allows to adjust how much of the grid every lane can use. Another useful feature of responsive stories is the automatic transformation of components, such as charts and filters. They will show up in their mobile form, when the dashboard is opened on a mobile device. Even outside of responsive stories, panels are a powerful tool for structuring and grouping.

Note: Although a panel’s official unit weight is 0.1 according to “Best Practices for Performance Optimization in Story Design”, they do not impact story performance.

How Panels were used in the Jump & Run

Before diving into the application of panels in the classic reporting sense, I will explain how they were used in the Jump & Run. Note that the game was only developed for desktop and has not yet been adapted for mobile devices.

Figure 3: Simplyfied panel structure in the SAC Jump & Run

Applying the logic described above, the whole content of the game is nested in one panel. This “outer panel” (Panel_Game) is only used to provide structure and does not directly contain any visible elements. Within this panel are three other panels, referred to as “inner panels” (Panel_PlayerInformation, Panel_Playfield, Panel_Ground) which provide structure for the game and include visible content. One panel represents the header, containing information about the player status and the controls. The middle panel includes the playable world in which the player can move, and one panel is used for the ground. All inner panels are responsive and adapt to changes in the outer panel.

Inside these panels are panels which are supposed to fulfil a specific task. As shown by the fields outlined in red, one panel provides images of the collected coins and remaining lives, while the other includes the control panel which allows to move the player. Similar to the other panels, these are responsive as well and only require rework when the screen size falls below a certain value. In addition, it makes rearranging specific parts, such as the controls, fairly easy. As all necessary parts are grouped within the panel, they can be rearranged with one "click" without altering the proportions.

Panels in responsive Reporting

Checking the latest updates on the phone while waiting for the next flight to catch, diving into details from the desktop, or discussing current trends with others by accessing the data on a tablet. These and many others are typical examples of use from dashboards. By using responsive stories, lanes, and panels, modern dashboards can be created which can cover these applications.

Achieving this level of responsiveness can be challenging and requires creative conceptualisation. One key component is what I call “Tiles” in this blog. They are a specific way of using panels to structure responsive layouts. While they can differ in size, form, and nested objects, they all follow a common structure. This allows them to be replaces easily with other tiles.

Figure 4: Structure Tile Figure 5: Example Tile (Data from BestRunJuice Sample)

The basic structure was already looked at in the paragraph above, however, I will now shed light on how to structure them for effective reporting. As known already, an invisible outer panel provides the overall positioning and sizing in the grid and lanes. The inner panel adds a visible structure, such as background colour and borders. Nested in there are panels which contain specific elements. In the example provided, I used a title/text, created an area for numeric charts, which again is split in two separate parts with their own subpanels, and left space for a big chart with visualisations. Using this approach results in a fully responsive tile which could look similar to the last figure I provided (Figure 5). It is important to note that all panel and chart positions and size properties are expressed as a percentage of their parent elements, except for the font-size of the title.

Outlook

In the next part of this blog, I will discuss the scripting behind the game, the utilization of global variables, functions, events and especially timer to make the panels and images playable.

Building Secure SAPUI5 Applications: Best Practices for Developers

2025-12-10T08:16:09.335000+01:00

Introduction

In today’s enterprise landscape, security is fundamental, not optional. As the user-facing gateway to SAP systems, SAPUI5 apps must be built with security in mind from the start.

This blog shares practical, developer-focused techniques to help you secure your SAPUI5 applications from input validation and Cross-Site Scripting (XSS) prevention to using ESLint and safe communication practices. By adopting secure coding habits early, you can ensure your UI remains clean, efficient, and resilient against modern threats.

Why Security Matters in SAPUI5

The UI layer is where users interact, input data, and access sensitive information.
Even a small oversight like an unsanitized binding or debug log can lead to security exposure or data misuse.

By following secure UI5 coding standards, developers can:

Maintain data integrity and confidentiality
Prevent unauthorized access
Build user trust through reliable and safe design

Secure Coding Practices for SAPUI5 Developers

1. Validate and Sanitize User Input

Always validate what users enter before sending it to your backend.

Use data types in input fields for built-in validation:

<Input value="{path: 'age', type: 'sap.ui.model.type.Integer'}" />

Add custom formatters or validators for domain-specific logic.
Reject invalid inputs early, don’t rely on the backend to catch them.

2. Prevent Cross-Site Scripting (XSS)

XSS attacks occur when untrusted input is rendered as executable code in the browser.
To prevent it in UI5:

Use Text control instead of FormattedText unless the content is sanitized.
Escape dynamic strings using encodeHTML().
Avoid direct DOM manipulation like innerHTML or jQuery .html().
Never include untrusted HTML in views or models.

3. Protect Sensitive Information

Do not store tokens, passwords, or system URLs in localStorage or sessionStorage.
Avoid exposing business logic or identifiers in console logs.
Remove debug logs before deployment as they often reveal internal system details.

4. Use ESLint for Secure and Consistent Code

Static code analysis helps detect vulnerabilities and enforces coding standards.

Install and configure ESLint with SAP’s recommended rules:

npm install eslint eslint-config-ui5 --save-dev

Create a .eslintrc.json file:

{
  "extends": ["eslint-config-ui5"]
}

Benefits:

Detects unsafe DOM access or unused imports
Prevents insecure practices like eval statements
Promotes consistent, readable, and maintainable code

Run ESLint regularly as part of your build or CI pipeline:

eslint .

5. Secure Communication with Backend

Even though backend services handle authentication, the UI must communicate securely.

Always use HTTPS for service endpoints.
Avoid hardcoding URLs use destination configurations or environment variables.
Enable Cross-Site Request Forgery (CSRF) protection in your ODataModel configuration:

let oModel = new sap.ui.model.odata.v2.ODataModel("/odata/service", {
  tokenHandling: true
});

Developer Mindset: Security as a Habit

Security isn’t a one-time setup, it’s an ongoing practice.
Adopt a security-first mindset by:

Reviewing code with security in mind
Regularly updating libraries and dependencies
Integrating linting and vulnerability scans in CI/CD

When security becomes part of your coding routine, your applications naturally grow more resilient and trustworthy.

Conclusion

Building secure SAPUI5 applications isn’t just about backend policies, it starts right in your controllers, bindings, and XML views.
By validating inputs, preventing XSS, protecting sensitive data, and using tools like ESLint, you strengthen your application’s defense without compromising usability or performance.

Extending an SAP Sample Sankey Custom Widget in SAP Analytics Cloud to Deliver Top-N Hierarchical In

2025-12-23T08:37:05.630000+01:00

Introduction

SAP Analytics Cloud (SAC) does not provide a native, built-in Sankey chart as part of its standard visualization catalog. As a result, Sankey-style visualizations in SAC are typically implemented using custom widgets.

In mid-2024, while working on an enterprise analytics engagement, I encountered a requirement to visualize:

Top N parent entities (for example, service providers)
And, for each parent, the Top M child entities independently ranked per parent (for example, services offered)

All of this needed to be displayed within a single Sankey visualization, enabling users to immediately understand concentration and distribution patterns without navigating multiple charts.

To address this requirement, I explored SAC’s Custom Widget framework and extended an existing SAP-provided sample Sankey custom widget into a production-ready solution.

I have intentionally included the development and deployment steps in detail so that consultants or developers who are completely new to Sankey custom widgets in SAP Analytics Cloud can deploy and validate the solution end-to-end by following this blog.

SAP Sample Sankey Custom Widget as the Starting Point

Since SAP Analytics Cloud does not include a native Sankey chart, I referred to a sample Sankey custom widget implementation shared by SAP through the SAP Community. This SAP-provided sample demonstrates how a Sankey diagram can be rendered using the SAC Custom Widget framework and served as a technical starting point for my work.

The SAP sample was very helpful as a technical reference, as it illustrated:

Custom widget structure and lifecycle
Binding SAC model data to a widget
Rendering a Sankey diagram using JavaScript

During mid-2024, while actively working on this requirement, I engaged in the comments section of that SAP Community blog (SAP Analytics Cloud: Custom Widget & Widget Add-Ons Samples Preview) under my SAP Community user@GovindaRaoBanothu45 , discussing feasibility and implementation boundaries.

While the sample clarified the basic rendering approach, it also highlighted functional gaps when applied to enterprise-scale analytical requirements.

Why the SAP Sample Sankey Widget Was Not Sufficient

The SAP-provided Sankey custom widget was intentionally designed as a generic sample. Its behavior was to render all nodes and all links returned by the bound dataset.

However, the sample widget did not support the enterprise analytical requirement I was addressing, specifically:

No Top-N filtering at the parent level
No independent ranking of child nodes per parent
No data trimming prior to Sankey rendering
Limited usability for large, real-world datasets

As a result, while the SAP sample demonstrated how to render a Sankey chart, it did not meet the analytical or usability needs of an enterprise dashboard.

This gap required extending and enhancing the SAP sample Sankey custom widget with additional, original logic to reshape the dataset before rendering.

High-Level Architecture of the Extended Sankey Widget

The Sankey rendering mechanism remains aligned with the SAP sample, while the data-transformation layer represents the core extension.

Development Environment and Prerequisites

Prerequisites

To get started, ensure that you have:

Access to SAP Analytics Cloud with Optimized Design Experience enabled
Node.js installed on your local machine
Visual Studio Code (VS Code) installed
Basic understanding of JavaScript and JSON

Development Environment Setup

Install Node.js

Download Node.js from: https://nodejs.org
Verify installation:

node -v
npm -v

Install Visual Studio Code

Download VS Code from: https://code.visualstudio.com
Use VS Code as the primary editor for developing and maintaining the custom widget files.

Set Up the Project Folder

Create a project folder (for example, SankeySAPcode).
Open the folder in Visual Studio Code.
Create the following files:

main.js – core widget logic and Sankey rendering
index.json – metadata and resource configuration
hash256.js – Node.js script for integrity key generation

Sankey Custom Widget – Standard Project Structure

For the standard Sankey implementation, I created a dedicated project folder (for example, SankeySAPcode or any relevant project name). This folder contains all the supporting and required files needed to build and deploy the Sankey custom widget in SAP Analytics Cloud.

The project folder includes:

main.js
The web component JavaScript file that contains the core widget logic and Sankey rendering code (mandatory).
index.json
The metadata file that defines the custom widget, its properties, and resource references (mandatory).
sankeyChartStyling.js
An optional styling component used to expose styling options in the widget’s styling panel (optional).
build/ folder
Contains the helper script hash256.js, which is used to generate SHA-256 integrity keys for the JavaScript files.

Note: Styling files (Styling.js, sankeyChartStyling.js, or xxxxStyling.js) are optional and may not be required for all custom widgets.
However, the web component JavaScript file (main.js or equivalent) and the metadata file (index.json) are mandatory for every SAP Analytics Cloud custom widget. The build folder is included purely for maintainability and ease of understanding.
Technically, the hash256.js file can also be placed directly in the main project folder. Including it in a separate subfolder is optional and does not impact deployment, as long as the final ZIP file complies with SAP Analytics Cloud’s upload requirements.

Creating Integrity Keys and Deploying the Code

SAP Analytics Cloud supports SHA-256 integrity validation to ensure uploaded JavaScript resources are not modified.

Generating Integrity Keys

Open a Node.js command prompt
Navigate to the folder containing hash256.js
Execute the script

Example output:

main.js: sha256-6134FFLCQYpH7x8gx29H1xJyRbitpf/guj5UGKhJ25Q=
sankeyChartStyling.js: sha256-AR0uDO+9h8nu9EyJotSinZ2APDWD5Ja2JmdFcZCH1Xo=

Note: If additional JavaScript resource files are included, their corresponding sha256- integrity keys must also be added to the index.json file under the resources section.

Similarly, the file names must be updated in hash256.js before generating integrity keys for those files.

Core Enhancement: Top-N Parent and Top-M Child Logic

The following snippets are representative excerpts from the working implementation.
Full scripts are intentionally not published, as this widget was delivered as part of an enterprise engagement.

In the widget, the SAC data binding is first normalized into an array (data) containing parent node, child node, and measure value fields.

Step 1: Aggregate Measure by Parent

const parentTotals = {};
data.forEach(row => {
  parentTotals[row.parentNode] =
    (parentTotals[row.parentNode] || 0) + Number(row.measureValue);
});

Step 2: Rank and Retain Top-N Parents

const topParents = Object.entries(parentTotals)
  .sort((a, b) => b[1] - a[1])
  .slice(0, TOP_N_PARENT_NODES)
  .map(entry => entry[0]);

Step 3: Rank and Retain Top-M Children per Parent

const filteredLinks = [];
topParents.forEach(parent => {
  const children = data
    .filter(row => row.parentNode === parent)
    .sort((a, b) => b.measureValue - a.measureValue)
    .slice(0, TOP_N_CHILD_NODES);

  children.forEach(child => {
    filteredLinks.push({
      source: parent,
      target: child.childNode,
      value:  child.measureValue
    });
  });
});

Step 4: Rebuild Nodes

const nodes = [...new Set(
  filteredLinks.flatMap(l => [l.source, l.target])
)].map(name => ({ name }));

Step 5: Render Sankey

sankey.nodes(nodes).links(filteredLinks).layout(32);

The rendering follows the SAP sample approach; the innovation lies in the data-transformation logic.

Once all required files and script updates are ready, let’s deploy the custom widget into SAP Analytics Cloud.

Deploy the Custom Widget

Create a ZIP File:

Include main.js, index.json, and optional styling files in a .zip file.

Upload to SAP Analytics Cloud:

Navigate to the Custom Widgets section in SAC.
Upload the .json and .zip files.

Test the Widget:

Add the custom widget to a story and configure data sources.

Select the JSON metadata file from your local system.

Next, select the resource file that is .zip file of main.js, index.json and styling.js or any other file related to this chart.

Now you can the widget in "Custom Widgets" section.

Observe the warning messages below with and/without integrity checks in the list of custom widgets

We have done custom widget deployment and will use the same in stories. Let's see how to access this in story 2.0.

From the builder panel, select your data model, set measure, set a hierarchical dimension and edit the default colors of the different depths from the Styling panel.

Below screenshot show the usage of the Styling.JS file.

In case the java script files get modified / tampered you get the below error while creating chart using custom widget in SAC story.

Validated Sankey Variants - Let's validate 3 different scenarios

SAP sample Sankey (baseline):

Top 1 parent + Top 5 child nodes:
- This is the custom code and the main.js file is completely different than standard code with the key components are the below conditions below.

Result of the above changes,

Top 3 parents + Top 5 children:

Result of the above changes,

This incremental approach helped validate correctness before applying the logic to larger Top-N configurations.

Acknowledgment

I would like to thank @marouferchichi for actively engaging in the SAP Community blog comments and helping clarify the capabilities and boundaries of the sample Sankey custom widget.

The final implementation described here represents my independent extension and delivery of that sample to meet enterprise-level analytical requirements.

Conclusion

This blog demonstrates how a SAP sample Sankey custom widget can be extended into a production-grade Top-N hierarchical Sankey visualization using SAP Analytics Cloud’s Custom Widget framework.

For similar enterprise scenarios, this approach provides a reusable and scalable pattern.

SAP UI5 - QUnit-Testing

2026-01-11T23:36:30.594000+01:00

In this post, I share practical experience with QUnit tests from my UI5 projects.
This post is aimed at developers who are already familiar with SAP UI5 and just getting started with QUnit. It was originally intended as an onboarding guide, but I noticed that information on this topic is quite scattered.
The examples in this post are kept close to real project code and can also be used as a reference when implementing similar test cases.

1. Setup

1.1 Installing the required libraries

To implement and execute QUnit tests in a UI5 application, just a few libraries are needed.
We just add them to the dependencies section of the application's package.json.

Depending on the project, either a specific version or simply latest can be used.

For later test coverage analysis (see section 3. Running Tests & Coverage), an additional library should be included:

This library also needs to be added to the ui5.yaml under "server>customMiddleware>".

After adding the required libraries, they can be installed using:

npm install

1.2 Folder structure

The folder structure for the unit tests is quite simple and is set up as follows:

- webapp
   - test
      - unit
         AllTests.js
         unitTests.qunit.html
         unitTests.qunit.js

The actual test files should ideally follow a structure similar to the application itself.
This not a rule -> just for readability
For example, if unit tests are required for BaseController.js, a corresponding folder controller and a file BaseController.js should be created inside the test directory:

- webapp
   - controller
      BaseController.js

   - test
      - unit
         - controller
            BaseController.js

1.2.1 AllTests.js

All QUnit tests to be executed are included in the define section of this file.
It is a central place where we can enable or disable tests for execution.

sap.ui.define([
    "./controller/BaseController",
    // "./controller/OtherController",
    // "./controller/OtherController2",
    // "./services/SampleService",
    // "./util/SampleFormatter",
], function () {
    "use strict";
});

(Tip)

When working on unit tests for a specific controller an running them frequently, tests for other controllers can be commented out here, so they are not executed each time.

1.2.2 unitTests.qunit.html

Short and simple: we start our tests using this file.
All required libraries for test execution are included here.

<!DOCTYPE html>
<html>
<head>
    <title>Unit tests for Template</title>
    <meta charset="utf-8">

    <script id="sap-ui-bootstrap"
        src="../../../../resources/sap-ui-core.js"
        data-sap-ui-resourceroots='{
            "app.unittester": "../"
        }'
        data-sap-ui-async="true"
        data-sap-ui-preload="async">
    </script>

    <link rel="stylesheet" type="text/css" href="../../../../resources/sap/ui/thirdparty/qunit-2.css">

    <script src="../../../../resources/sap/ui/thirdparty/qunit-2.js"></script>
    <script src="../../../../resources/sap/ui/qunit/qunit-junit.js"></script>
    <script src="../../../../resources/sap/ui/thirdparty/sinon.js"></script>
    <script src="../../../../resources/sap/ui/thirdparty/sinon-qunit.js"></script>

    <script src="../../../../resources/sap/ui/qunit/qunit-coverage-istanbul.js"
        data-sap-ui-cover-only="app/unittester/"
        data-sap-ui-cover-never="app/unittester/test, app/unittester/localServices, app/unittester/services">
    </script>

    <script src="../../../../resources/sap/ui/thirdparty/sinon.js"></script>
    <script src="../../../../resources/sap/ui/thirdparty/sinon-qunit.js"></script>

    <script src="unitTests.qunit.js"></script>
</head>

<body>
    <div id="qunit"></div>
    <div id="qunit-fixture"></div>
</body>
</html>

Just a few notes on the most important scripts that are included here (because we will use them later).

QUnit

<link rel="stylesheet" type="text/css" href="../../../../resources/sap/ui/thirdparty/qunit-2.css">
<script src="../../../../resources/sap/ui/thirdparty/qunit-2.js"></script>
<script src="../../../../resources/sap/ui/qunit/qunit-junit.js"></script>

(Roughly summarized) The actual QUnit framework is included here.

sinon and sinon-qunit

<script src="../../../../resources/sap/ui/thirdparty/sinon.js"></script>
<script src="../../../../resources/sap/ui/thirdparty/sinon-qunit.js"></script>

These libraries enable spying, stubbing and mocking dependencies.

qunit-coverage-istanbul.js (Code Coverage Integration)

<script src="../../../../resources/sap/ui/qunit/qunit-coverage-istanbul.js"
        data-sap-ui-cover-only="app/unittester/"
        data-sap-ui-cover-never="[
           app/unittester/test, 
           app/unittester/localServices, 
           app/unittester/services
        ]">
</script>

This is required later for code coverage.

(Note) In this post, we use Istanbul for code coverage.
Of course, other options such as Karma can also be used if desired.

Important attributes:

data-sap-ui-cover-only
files to be included in the coverage
data-sap-ui-cover-never
files and directories to be excluded from coverage

1.2.3 unitTests.qunit.js

This is the central entry point for the unit tests.
Here we only include the tests from AllTests.js in the define section and start the test run.

QUnit.config.autostart = false;

sap.ui.getCore().attachInit(function () {
    "use strict";

    sap.ui.require([
        "app/unittester/test/unit/AllTests"
    ], function () {
        QUnit.start();
    });
});

2. Implementing unit tests

In this example, we will look at some unit tests for the BaseController as well as the basic structure.
In addition, we will see how sinon can be used to handle dependencies.

2.1 Basic structure of a test module

Each module has its own tests and provides lifecycle hooks such as beforeEach and afterEach.
The modules can be structured freely, depending on the requirements.

We start with a test module for BaseController.js and implement the module in the test file.
(webapp>test>unit>controller>BaseController)

sap.ui.define([
	"app/unittester/controller/BaseController",
	"sap/ui/thirdparty/sinon",
	"sap/ui/thirdparty/sinon-qunit",
], function(BaseController) {
	"use strict";
	
	/**
	* Module
	*/
	QUnit.module("Module", {
	   beforeEach: function() {
		  this.oBaseController = new BaseController();
	   },
	   afterEach: function() {
		  this.oBaseController.destroy();
	   }
	});
	
});

First, we include the actual BaseController and the two sinon libraries in the define statement.

After that, the module itself:
The lifecycle functions of the module are executed before and after each test.
In order to test the functions of the BaseController, we instatiate it before the test and destroy it afterwards.

2.2 Simple Test using sinon.stub and sinon.spy

In our first test, we will take the getRouter function from our BaseController.

getRouter: function() {
	return this.getOwnerComponent().getRouter();
},

We only want to test whether the function can be executed.

However, it has two dependencies:
this.getOwnerComponent and its function getRouter.

In order to test getRouter without having to instantiate all dependencies, we will "simulate" them with sinon.

This would look like the following:

sap.ui.define([
	"app/unittester/controller/BaseController",
	"sap/ui/thirdparty/sinon",
	"sap/ui/thirdparty/sinon-qunit",
], function(BaseController) {
	"use strict";
	
	/**
	* Module
	*/
	QUnit.module("Module", {
	   beforeEach: function() {
		  this.oBaseController = new BaseController();
	   },
	   afterEach: function() {
		  this.oBaseController.destroy();
	   }
	});
	
	/**
	* BaseController - Check getRouter
	*/
	QUnit.test("BaseController - Check getRouter", function(assert) {
	   sinon.stub(this.oBaseController, "getOwnerComponent").returns({
		  getRouter: sinon.stub()
	   });

	   const fnSpy = sinon.spy(this.oBaseController, "getRouter");
	   this.oBaseController.getRouter();
	   assert.ok(fnSpy.calledOnce, "Check getRouter successful");
	});
	
});

The function flow:

In line 24, we create a stub for this.oBaseController (our controller instance) and listen for calls to the getOwnerComponent function.
As soon as this function is executed, a return value is "simulated" that provides another simulated function, getRouter.

After that, we create a spy for this.oBaseController, that listens for calls to the getRouter function.

Then comes the actual function call in line 29.

Finally, we use an assertion where we check (via fnSpy.calledOnce) whether getRouter was executed at least once within the function.

And that's basically it. Every following test has the same structure (sometimes more or less complex).

Running the test:
If we look at the coverage here now (more on this later), we can see that the function was executed exactly once:

2.3 Testing functions with Return Values or Promises

Many controller methods are asynchronous and return a Promise.

These tests are implemented using async and await.
Using await ensures that the test waits properly for execution to finish.

Example: onStartEditMode

onStartEditMode: async function () {
	try {
		this._fireSetViewBusy(true);
		await this.oDraftManager.onEdit();
	} catch (oError) {
		this.evaluateException(oError);				
	} finally {
		this._fireSetViewBusy(false);				
	}						
},

The corresponding test:

QUnit.test("BaseController - Start edit mode", async function (assert) {
	sinon.stub(this.oBaseController, "_fireSetViewBusy");
	sinon.stub(this.oBaseController, "evaluateException");

	this.oBaseController.oDraftManager = {
		onEdit: sinon.stub().returns(Promise.resolve(true))
	};		

	const fnSpy = sinon.spy(this.oBaseController, "onStartEditMode");
	await this.oBaseController.onStartEditMode();
	assert.ok(fnSpy.calledOnce, "onStartEditMode executed successfully");
});

2.4 Testing error cases and exceptions

Error cases are just as important as successful scenarios.

In this example, we provoke an error by not stubbing any dependencies, so the function runs into the error path.
This verifies that the error handling logic is executed correctly.

Example function onFullScreenPressed:

onFullScreenPressed: function() {
	try {
		this._fireSetLayout("MidColumnFullScreen");
		this.getOwnerComponent().getModel("util").setProperty(`/ViewControl/Layout`, "MidColumnFullScreen");
		return true;
	} catch (oError) {
		this.evaluateException(oError);
		return false;
	}
},

The test:

QUnit.test("BaseController - Check onFullScreenPressed Exception", async function(assert) {
	assert.notOk(await this.oBaseController.onFullScreenPressed(), "Check onFullScreenPressed Exception successful");
});

2.5 Larger example with more branches

A slightly larger example is the onCancel function, which is a bit more complex.

The function checks whether changes exist in the current draft.

Several paths (branches):
Changes exist: the user is shown a dialog, where they can decide whether to discard the draft
No changes: the draft is discarded
Error case: an error message is shown

onCancel:

onCancel: async function(oEvent) {
	try {
		const oData = this.getView().getBindingContext().getObject();

		//are there changes?
		if (oData.DraftEntityCreationDateTime.toString() !== oData.DraftEntityLastChangeDateTime.toString()) {
			const oSource = oEvent.getSource();
			this._openDiscardDraftDialog(oSource);
			return true;
		} else {
			//no changes, so discard the draft
			return Promise.resolve(await this.onDiscardDraft());
		}
	} catch (oError) {
		this.evaluateException(oError);
		return false;
	}
},

We will now test all paths to achieve full coverage.

1. onCancel with draft changes

/**
 * BaseController - Check onCancel (with draft changes)
 */
QUnit.test("BaseController - Check onCancel - with draft changes", async function(assert) {
	this.oBaseController.onDiscardDraft = sinon.stub().returns(Promise.resolve(true));
	sinon.stub(this.oBaseController, "_openDiscardDraftDialog");
	sinon.stub(this.oBaseController, "getView").returns({
		getBindingContext: sinon.stub().returns({
			getObject: sinon.stub().returns({
				DraftEntityCreationDateTime: 1,
				DraftEntityLastChangeDateTime: 2
			})
		})
	});
	const oMockButton = new Button();
	const oEvent = {
		getSource: function() {
			return oMockButton;
		}
	};

	assert.ok(await this.oBaseController.onCancel(oEvent), "Check onCancel (with draft changes) successful");
});

2. onCancel without changes

/**
 * BaseController - Check onCancel (no draft changes)
 */
QUnit.test("BaseController - Check onCancel - no changes", async function(assert) {
	this.oBaseController.onDiscardDraft = sinon.stub().returns(Promise.resolve(true));
	sinon.stub(this.oBaseController, "getView").returns({
		getBindingContext: sinon.stub().returns({
			getObject: sinon.stub().returns({
				DraftEntityCreationDateTime: 1,
				DraftEntityLastChangeDateTime: 1
			})
		})
	});

	assert.ok(await this.oBaseController.onCancel(), "Check onCancel (no draft changes) successful");
});

3. onCancel error case

/**
 * BaseController - Check onCancel Exception
 */
QUnit.test("BaseController - Check onCancel Exception", async function(assert) {
	assert.notOk(await this.oBaseController.onCancel(), "Check onCancel Exception successful");
});

When we now run the tests, we can see that we have covered all paths (branches):

3. Running tests and coverage

Unit tests can be executed in different ways.
In practice, running them via an npm script has proven to be the most convenient option.

3.1 Running tests

Unit tests can be started using a script defined in package.json:

The test run is then started using the following command:

npm run unit-tests

Once the tests are started, the browser opens and all tests (that are not commented out in AllTests.js) are executed automatically.

3.2 Test results in the QUnit interface

After the tests have been executed, an overview is displayed in the browser showing which tests were successful an which were not.
This is also indicated by colors and shown together with an error message.

Example:

Failed tests can also be inspected in the browser console.

3.3 Enabling code coverage

Code coverage can be enabled using the checkbox "Enable coverage" in the QUnit toolbar.

Once enabled, tests are re-run automatically and an interactive coverage overview is displayed below the test results.

In the coverage overview, we can see the tested controllers and the information about the coverage itself.

statements and lines
Shows which lines of code were executed during the tests.

functions
Indicates which functions were called at least once.

branches
Shows whether different execution paths (e.g. if/else, try/catch) were actually tested.

3.4 Detailed view of individual files

Clicking a file opens a detailed coverage view.

green lines were executed
red lines were not covered

3.5 Coverage reports

In addition to the browser view, a coverage report is generated under:
tmp/coverage-reports/html/index.html

Alternatevly, it can also be found in the IDE's project folder:

The report is updated automatically, can be opened in the browser independently.

4. Conclusion

With QUnit, we mainly focus on isolated controller logic and function behavior.
Therefore keeping functions cleanly encapsulated and dependencies low during development leads to much easier unit tests

A note on coverage:
I know that coverage percentages are often defined as targets.
I have also seen that the temptation to push these numbers can be quite high by starting to test trivial functions (e.g. getters or setters). This usually backfires sooner or later.
It makes much more sense to focus on testing critical logic, error cases and especially different paths and branches.

SAP UI5 - Draft Handling in FreeStyle Applications

2026-01-14T23:43:12.458000+01:00

1. Creating a DraftManager Class

In this post, I would like to share some of my experience with draft handling in FreeStyle applications.
After we decided in one of our projects to implement draft handling and at the same time had to consider our new component-based architecture, we encapsulated SAP’s DraftController (sap.ui.generic.app.transaction.DraftController) in a way that made sense for our use case.

I describe one possible encapsulation of the DraftController in a service class called "DraftManager", which (depending on the project) can be integrated and used across FreeStyle applications.
This approach worked very well for us, especially since official documentation was quite limited at that time.

Important: In our application we use an OData V2 service (with CDS views) that is already prepared accordingly for draft handling.

1.1 Initialization

The DraftManager is a service class used to encapsulate the DraftController.
The following basic structure has proven itself in our projects and can be used as is or adapted and extended as needed.

When initializing the DraftManager in the controller, we only pass the component instance and the view’s binding context.

(Example)

this.oDraftManager = new DraftManager(this.getOwnerComponent(), oContext);

The binding context is stored internally within the class for further processing and can be accessed or modified if required using the helper functions getActiveContext and setActiveContext.

Basic structure:

sap.ui.define([
  "sap/ui/generic/app/transaction/DraftController"
], function (DraftController) {
  "use strict";

  const DraftManager = function (oComponent, oContext) {
    this.oModel = oComponent.getModel();
    this.oDraftController = new DraftController(this.oModel);
    this.oActiveContext = oContext;
    this.oDraftContext = null;
  };

  DraftManager.prototype.setActiveContext = function (oContext) {
    this.oActiveContext = oContext;
  };

  DraftManager.prototype.getActiveContext = function () {
    return this.oActiveContext;
  };

  return DraftManager;
});

1.2 Draft Functions in the DraftManager

The DraftManager can be extended as needed, but in this post I would like to focus in particular on the main draft handling functions (Activate, Edit, and Discard).

Determine or Create a Draft

The DraftController itself is relatively easy to use.
However, there are operations, such as Edit, that always require multiple steps.
If a draft already exists, a new one cannot be created and an error will occur.

To avoid having to implement the same check in every controller, this logic is encapsulated.
This way, only a single function needs to be executed.

In this example code, we first check whether a draft exists for the active view context.
If so, it is returned and the controller can rebind the view accordingly.
If not, a new draft is created.

If needed, success and error messages can also be handled inside the function (for example, if they should be consistent across several applications). We use our own separate error handling in this case.

DraftManager.prototype.getOrCreateEditDraft = async function () {
  const oExistingDraft = await this.oDraftController.getDraftForActiveEntity(this.oActiveContext);

  if (oExistingDraft && !oExistingDraft.context.getObject().IsActiveEntity) {
    this.oDraftContext = oExistingDraft.context;
    return this.oDraftContext;
  }

  const oDraft = await this.oDraftController.createEditDraftEntity(this.oActiveContext);

  this.oDraftContext = oDraft.context;
  return this.oDraftContext;
};

Activate a Draft

Activating a draft is pretty straightforward in this case. Here as well: The function can be extended as needed (error + success handling e.g.)

DraftManager.prototype.activateDraft = async function () {
  await this.oDraftController.activateDraftEntity(this.oDraftContext);
  this.oActiveContext = this.oDraftContext;
};

Discard a Draft

Discarding a draft is also easy to implement in this case.

DraftManager.prototype.discardDraft = async function () {
  await this.oDraftController.discardDraft(this.oDraftContext);
  this.oDraftContext = null;
};

2. Instantiating the DraftManager in the Controller

As mentioned at the beginning, the DraftManager can be instantiated quite easily.

Example: We have a master/detail application with an onRouteMatched function in the detail controller.
Assume we have a SmartTable on the master page and navigate to the detail page after clicking on an entry.
Here, we pass the corresponding bound id (or guid) of the list item and the HasActiveEntity property.

Using this properties, we now create a raw context (helper function _loadContext) and start instantiating the DraftManager .

onRouteMatched: async function (oEvent) {
  const sId = oEvent.getParameter("arguments").UUID;
  const bActive = oEvent.getParameter("arguments").HasActiveEntity;

  try {
	const oContext = await this._loadContext("/EntitySet", { "UUID": sId, "IsActiveEntity": bActive });
	this.oDraftManager = new DraftManager(this.getOwnerComponent(), oContext);
  } catch (oError) {
	//error handling
  }  
}

_loadContext: async function (sEntity, oContextParameters) {
	const oModel = this.getView().getModel();
	await oModel.metadataLoaded();
	const sKey = oModel.createKey(sEntity, oContextParameters);
	const oContext = new sap.ui.model.Context(oModel, sKey);
	return Promise.resolve(oContext);
},

After that, the DraftManager is instantiated and can be used.

3. Using the DraftManager in the Controller

From this point on things become much more relaxed, as encapsulating the draft logic significantly reduces the number of operations in the controller.

I will keep the following examples to a minimum. Depending on the requirements, these can of course become more complex.

For rebinding/refreshing the view, we're using the following helper function:

_bindView: async function (sId, bIsActiveEntity) {
  return new Promise((resolve) => {
    this.getView().bindElement({
      path: `/EntitySet(UUID=guid'${sId}',IsActiveEntity=${bIsActiveEntity})`,
      parameters: {
        expand: "DraftAdministrativeData"
      },
      events: {
        change: (oEvent) => {
          resolve(oEvent.getSource().getBoundContext());
        }
      }
    });
  });
};

3.1 Start Editing

Editing has now become a fire-and-forget function, as everything is nicely encapsulated.
After each draft operation, the view should be updated (in this case using _bindView).

onEdit: async function () {
	try {	
		const oDraftContext = await this.oDraftManager.getOrCreateEditDraft();  
		await this._bindView(
			oDraftContext.getProperty("UUID"),
			oDraftContext.getProperty("IsActiveEntity")
		);		
	} catch (oError) {
		//error handling...
	}
}

3.2 Save

After activating the draft, the view is rebound to the active entity.

onSave: async function () {
	try {	
		await this.oDraftManager.activateDraft();  
		await this._bindView(
			this.oDraftManager.getActiveContext().getProperty("UUID"),
			this.oDraftManager.getActiveContext().getProperty("IsActiveEntity")
		);	
	} catch (oError) {
		//error handling...
	}
}

3.3 Cancel

When canceling, the draft is discarded and the view is rebound to the active context.

onDiscard: async function () {
	try {	
		await this.oDraftManager.discardDraft();
		await this._bindView(
			this.oDraftManager.getActiveContext().getProperty("UUID"),
			this.oDraftManager.getActiveContext().getProperty("IsActiveEntity")
		);
	} catch (oError) {
		//error handling...
	}
}

4. DraftHandling and MERGE lock errors

One important learning from our projects was dealing with MERGE lock errors.
As soon as draft handling is applied to larger views with many form fields and especially rich text editors, you will sooner or later run into locking issues, as we did.

This happens because the DraftController triggers a MERGE request on every change in the view (which is correct behavior).
However, if too many changes are performed too quickly, multiple MERGE requests can be sent at the same time and end up locking each other.

This can easily be reproduced with a rich text editor in the view by pressing the Enter key very quickly. The result is a large number of lock errors (The draft itself is still updated correctly, but this can become quite annoying when working with messaging).

Our solution for this was to work with deferredGroups and changeGroups.

In order to get this to work with the DraftController and the service class, we use the merge timer provided by SAP.

First we start by setting the deferredGroup and changeGroup in the onInit function of the view controller.

this.getOwnerComponent().getModel().setDeferredGroups(["Changes"]);
this.getOwnerComponent().getModel().setChangeGroups({
  "*": {
    groupId: "Changes",
    changeSetId: "Changes",
    single: false
  }
});
this.getOwnerComponent().getModel().attachPropertyChange(this.onEnqueueSubmitChanges.bind(this, 1));

After that we define the propertyChange handler function onEnqueueSubmitChanges.

onEnqueueSubmitChanges: function (nIntervalInSeconds) {
  const mParameters = this.getOwnerComponent().getModel("util").getProperty("/ViewControl/batchParameters");
  this.oDraftManager.triggerSubmitChanges(nIntervalInSeconds, mParameters);
}

And finally, we define a new DraftManager function triggerSubmitChanges, which bundles the requests using the merge timer and submits them accordingly.

oDraftManager.prototype.triggerSubmitChanges = function (nIntervalInSeconds, mParameters) {
  const oDraftMergeTimer = this.oDraftController._oDraftMergeTimer;
  if (!oDraftMergeTimer.nTimeoutID) {
    oDraftMergeTimer.nTimeoutID = setTimeout(() => {
      oDraftMergeTimer.nTimeoutID = null;
      if (this.oModel.hasPendingChanges()) {
        this.oDraftController.triggerSubmitChanges(mParameters)
          .catch((oError) => {
            console.error("Error during submit changes:", oError);
          });
      }
    }, (nIntervalInSeconds || 0) * 1000);
  }
};

5. Conclusion

I have reduced the examples to the basics, as they can be extended as needed. We had very good experience with this service class, and draft handling in FreeStyle applications in combination with an OData V2 service worked very well.

The DraftController can of course also be used directly in the controller.
However, as mentioned before, encapsulating it is worthwhile when working with a larger application architecture, especially when testing is relevant in the project.

Code Connect 2026 is Coming – Mark Your Calendars!

2026-01-16T10:17:39.514000+01:00

We’re excited to announce the return of Code Connect for its third edition, bringing together three dynamic events - UI5con, reCAP, and HANA Tech Con - under one roof. Mark your calendars for July 13 to 16, 2026, and join us in St. Leon-Rot, Germany, or online.

What is Code Connect?

Code Connect creates a unique opportunity to experience three specialized events in one location: UI5con, reCAP, and HANA Tech Con, allowing you to dive deep into different aspects of SAP development. Code Connect is designed for developers at every level: Whether you're an SAP veteran or just starting out, this is your chance to connect, learn, and innovate alongside a vibrant community of developers.

Your Week at Code Connect

July 13: Code Jam Sessions and Warmup

Kick things off with our Code Jam sessions - a hands-on way to sharpen your skills before the main event. Afterward, join us for a pre-conference networking event to meet fellow attendees in a relaxed setting.

July 14: UI5con

The official program kicks off with UI5con, bringing together UI5 enthusiasts to share insights, explore the latest innovations, and build new connections. Expect expert sessions, interactive workshops, and plenty of opportunities to engage with the UI5 community.

Learn more about UI5con.

July 15: reCAP

The next day focuses on the SAP Cloud Application Programming Model (CAP). At reCAP, developers, customers, and partners meet the CAP Product Team to discuss technical concepts, share project experiences, and explore future possibilities.

Learn more about reCAP.

July 16: HANA Tech Con

The week concludes with HANA Tech Con. Delve into the HANA universe and join development experts, users, and partners to exchange knowledge and ignite new ideas. If you've ever had questions about HANA that you haven't found answers to, this is your chance to get them resolved.

Learn more about HANA Tech Con.

Early Bird Process

Planning a longer trip? We offer a limited number of early bird tickets for attendees who need to arrange travel well in advance.

Check our FAQ document for details on how to secure your ticket.

Sponsorship Opportunities

Be a part of Code Connect 2026 and become a sponsor to support the developer community at UI5con, reCAP, and HANA Tech Con. By sponsoring Code Connect, you gain access to a diverse audience spanning front-end developers, backend specialists, and database experts – all in one event.

Read our sponsorship prospectus to check our sponsorship opportunities.

Call for Proposals

Our Call for Speakers runs from 26 January to 13 March. As a speaker, you’ll be an active part of Code Connect, shaping the conversation, sharing your expertise, and inspiring the developer community. Don’t wait and submit your session proposal by 13 March at the latest.

Important Dates

Call for Proposals: January 26, 2026 to March 13, 2026.
Registration Opens: April 10, 2026
Agenda Published: Early June 2026
Code Connect Week: July 13 to 16, 2026

Ready to Connect?

Code Connect 2026 represents more than just learning opportunities. It's about building relationships, sharing knowledge, and being part of a community that's shaping the future of SAP development.

Join us at Code Connect 2026 and be part of a community driving the future of technology. We can't wait to see you there!

UI5 MCP Server Got Extended for UI Integration Cards Generation

2026-01-22T13:54:47.553000+01:00

Following the recent announcement for the release and availability of the UI5 MCP server, we are pleased to announce that the UI5 MCP Server now supports the development of UI Integration Cards. In its latest version – v0.2.1 – it includes three new tools dedicated to UI Integration Cards. These tools assist Large Language Models (LLMs) in creating new cards from scratch or editing existing ones, following the best practices for card development.

Infuse Creativity Into Your UI Integration Cards

The updated UI5 MCP Server version v.0.2.1 enhances card development with AI Agents like Cline. Fostering creativity and efficiency, this approach makes it easy for both developers and non-developers to create UI Integration Cards smoothly.

Usage of the UI5 MCP Server in Cline.

Why Use the UI5 MCP Server for Integration Cards Development?

The reasons for initially using UI5 MCP Server are similarly applicable to developing Integration Cards:

LLMs might lack information on the latest best practices and APIs recommended for UI Integration Cards development.
LLMs might suggest using the properties of UI Integration Cards or APIs that are not available in your project's version or have been marked as deprecated.
Scaffolding can help agents kickstart new projects faster and with established patterns, saving token costs.

and furthermore:

Encouraging the use of cards of type Declarative to make the card also compatible with Mobile Native platforms.
Providing specific knowledge for each card type to the LLMs, such as the available chart types in Analytical cards, and enabling the LLMs to suggest the best chart type for your data.
And more…

Tools

Best practice guidance for your agent: get_integration_cards_guidelines
Scaffolding a new Integration Card: create_integration_card
Validating the Card’s manifest: run_manifest_validation

Setup & Use

Install the UI5 MCP Server v.0.2.1 in your AI agent, as described here. Once this version or later is installed, your AI Agent should automatically gain access to the new tools. Once you define your prompt for generating a Card the AI Agent will offer you as first step to run the get_integration_cards_guidelines, then will scaffold the very coding project with dynamically created Card, and finally will run the manifest schema validation tool. Enjoy your Card!

What’s Next?

We plan to further enhance the existing tools to handle more complex scenarios, such as creating or editing child cards, pagination in list and table cards, a more advanced configuration editor for the generated card, and more.

Practical SAPUI5 Form Validation: Name, Email & Password Fields

2026-01-28T14:21:49.330000+01:00

Introduction

Form validation plays a critical role in SAPUI5 applications. It ensures clean data entry, improves user experience, and adds an extra layer of security.

In this blog, In this article, we build a simple employee registration form that focuses on practical, real-world basic validation scenarios as follows:

Allow only alphabets in the Name field
Validate Email format as the user types
Block copy, cut, and paste for the Password field
Show clear, real-time validation feedback

If you are unfamiliar with regex, please refer to my previous article Understanding Regex in JavaScript - A Beginner-Friendly Guide for a better understanding before proceeding.

Let's discuss, along with the use case basic employee registration screen where data quality matters from the start:

Names should not contain numbers or special characters
Email addresses must be structurally valid
Passwords should be typed manually to avoid reuse or weak stored values
Users should immediately know what is wrong and how to fix it

SAPUI5 provides built-in support for this through value states and event handling.

Form.view.xml

<mvc:View
  controllerName="demo.controller.Form"
  xmlns:mvc="sap.ui.core.mvc"
  xmlns="sap.m">

  <VBox class="sapUiSmallMargin">

    <Input
      id="nameInput"
      placeholder="Full Name (Alphabets only)"
      liveChange=".onNameChange" />

    <Input
      id="emailInput"
      placeholder="Email Address"
      liveChange=".onEmailChange" />

    <Input
      id="passwordInput"
      type="Password"
      placeholder="Password (Copy/Paste Disabled)"
      paste=".onPasteBlock"
      copy=".onCopyBlock"
      cut=".onCutBlock" />

    <Button text="Submit" press=".onSubmit" />
  </VBox>
</mvc:View>

Please Note: Using liveChange allows us to validate input as the user types, rather than waiting until submission.

Name Validation (Alphabets Only)

Names typically contain letters and spaces. A following simple regular expression helps enforce this rule.

Form.controller.js

onNameChange: function (oEvent) {
  var sValue = oEvent.getParameter("value");
  var oInput = oEvent.getSource();

  var oRegex = /^[A-Za-z ]+$/; //Alphabets Regex

  if (!oRegex.test(sValue)) {
    oInput.setValueState("Error");
    oInput.setValueStateText("Only alphabets are allowed.");
  } else {
    oInput.setValueState("None");
  }
},

//Accepted: John, Anna Marie
//Rejected: John123, Anna!

Email Validation (Structural Check)

Instead of allowing any string, we validate whether the email follows a basic, widely accepted format.

Form.controller.js

onEmailChange: function (oEvent) {
  var sValue = oEvent.getParameter("value");
  var oInput = oEvent.getSource();

  var oRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/; //Email Regex

  if (!oRegex.test(sValue)) {
    oInput.setValueState("Error");
    oInput.setValueStateText("Invalid email format.");
  } else {
    oInput.setValueState("None");
  }
},

//Valid example: test@example.com
//Invalid example: test@, name@mail

Please Note: This doesn’t verify whether the email exists, but it prevents clearly invalid entries early.

Password Security: Blocking Copy, Cut & Paste

For sensitive fields like passwords, allowing paste can lead to reused or insecure credentials. Here, we explicitly block copy, cut and paste actions.

Form.controller.js

onPasteBlock: function (oEvent) {
  oEvent.preventDefault();
  var oInput = oEvent.getSource();
  oInput.setValueState("Error");
  oInput.setValueStateText("Pasting is disabled for security reasons.");
},

onCopyBlock: function (oEvent) {
  oEvent.preventDefault();
},

onCutBlock: function (oEvent) {
  oEvent.preventDefault();
},

Final Submit Check

Before submission, we verify that no field is in an error state.

Form.controller.js

onSubmit: function () {
  var sNameInput = this.byId("nameInput");
  var sEmailInput = this.byId("emailInput");
  var sPasswordInput = this.byId("passwordInput");

  if (
    sNameInput.getValueState() === "Error" ||
    sEmailInput.getValueState() === "Error" ||
    sPasswordInput.getValueState() === "Error"
  ) {
    sap.m.MessageToast.show("Please fix the errors before submitting.");
    return;
  }

  sap.m.MessageToast.show("Form submitted successfully!");
},

This keeps the logic simple and ensures only valid data moves forward.

Conclusion:

With minimal code, we have achieved a clean and secure SAPUI5 form featuring:

Cleaner and more reliable user input
Immediate feedback using SAPUI5 value states
Better password handling for sensitive fields
A smoother and more professional user experience

This approach significantly improves data quality and user experience in SAPUI5 applications.

This is basic form validation using regex, but if you have alternative methods, improvements, or insights, please feel free to share them. I would love to learn from your experience too!

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

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

Declarative UI Integration Cards - Consistent Framework With Flexible Content Capabilities

2026-02-02T16:34:17.547000+01:00

Introduction

Since the early announcement of the UI Integration Cards paradigm (as described in this article), we have been busy expanding the functionality of Cards, resulting in an ever-growing adoption across almost all SAP products.

Today, Cards are utilized in a range of solutions and scenarios, from the SAP S/4HANA home page with “To-Do” and Insights Cards, to SAP Build Work Zone, where Cards from any SAP product can be easily assembled together, to Joule, and also on mobile-native screens.

The fundamental principles that underpin this technology, as detailed on our Card Explorer landing page, are that it is designed to be Declarative, Easy to consume, and Consistent.

Declarative: configured by a manifest.json ==> Low to No-code skills required (AI-gen@UI5 MCP server)
Easy to consume: product and UI-technology agnostic ==> Mobile-ready / Integration-ready via configuration
Consistent: predefined card types in Fiori/Horizon design ==> Thoughtfully designed / Product Standards covered

Key Concepts and Capabilities

In this article, we’ll detail the key qualities and advantages of the Declarative Integration Cards. Declarative Card types offer a range of display options and minimalist interactions, including List Card, Table Card, Timeline, Calendar, Analytical, and Object Card with input elements.

Declarative Card types enable the fast and easy creation of “Home page” and “Overview” pages, where Card developers can integrate data from various sources to display relevant business data for any SAP or non-SAP product.

Declarative and Consistent

Integration Cards are straightforwardly defined using a single JSON descriptor file called manifest.json. This file is all you need to get a fully functional and nicely rendered representation of business data in the form of a Card. Once you have this descriptive manifest.json file, our Card Runtime can process it and render the card in a web browser or any mobile-native device, regardless of the UI framework. Hence – declarative!

Anatomy of Declarative UI Integration Cards

Examining the Card's structure, we can identify three separate parts:

The Card Header provides the card's identity, typically represented by a title, subtitle, and icon or avatar/image attributes. It can also display more dynamic or complex data, such as the special Numeric Header, which prominently features a key numeric indicator, or an extended Header.

The Content / Data is the main part of the card that displays relevant business data in a selected type of view. These data types can be List, Table, Object, Analytical, Timeline, or Calendar.
The Footer area is usually designated for intended Card interaction elements, such as action buttons or links for navigation.

The general structure of a declarative manifest.json looks like this:

{
  "sap.app": {
    "id": "my.card.id",
    "type": "card",
    "applicationVersion": {
      "version": "1.0.0"
    }
  },
  "sap.card": {
    "type": "List",  // Card type: List, Table, Object, Analytical, Timeline, Calendar
    "header": {
      // Header configuration
    },
    "content": {
      // Content configuration specific to card type
    },
    "footer": {
      // Optional footer with actions
    }
  }
}

The Card Header

The card header displays essential information about the card by grouping a set of card attributes and presenting them at the top of the card. The "sap.card"/header section is mandatory. Providing it together with the title is essential for proper screen reader support and other functionalities.

Integration Cards support three header configurations:

Default Header - Standard header with title, subtitle, icon, status
Numeric Header - KPI-focused header with prominent numeric indicators
Extended Header with Info Section - flexible layout within either kind of header, capable of accommodating various components

All headers support actions, data timestamps, visibility control, and text wrapping options.

Default Header

The standard header displays general information about the card.

"header": {
	"title": "An example title",
	"subtitle": "Some subtitle",
	"icon": {
		"src": "sap-icon://business-objects-experience",
		"visible": true
	},
	"status": {
		"text": "5 of 20"
	}
}

Numeric Header

The Numeric Header is optimized for displaying KPIs, metrics, and quantitative data with prominent visualization.

"header": {
	"type": "Numeric",
	"title": "Project Cloud Transformation",
	"subtitle": "Revenue",
	"unitOfMeasurement": "EUR",
	"mainIndicator": {
		"number": "44",
		"unit": "%",
		"trend": "Down",
		"state": "Critical"
	},
	"details": "Some details",
	"sideIndicators": [
		{
			"title": "Target",
			"number": "17",
			"unit": "%"
		},
		{
			"title": "Deviation",
			"number": "5",
			"unit": "%"
		}
	]
}

Extended Header with Info Section

Both header types can be extended with an info section for additional grouped information.

Currently, only items of type "Status" are available.

"header": {
	"title": "Project Cloud Transformation",
	"subtitle": "Revenue",
	"infoSection": {
		"rows": [
			{
				"items": [
					{
						"type": "Status",
						"value": "On Track",
						"state": "Success",
						"inverted": true,
						"showStateIcon": true
					},
					{
						"type": "Status",
						"value": "OKR Relevant",
						"state": "None",
						"inverted": true,
						"showStateIcon": true
					},
					…
				]
			}
		]
	}
}

The Card Content Area

The Card content area defines how data is rendered by selecting a declarative card type, each offering predefined structures and configuration options to visualize business information in a consistent and self-contained way.

List Card – Displays multiple items in a vertical list with flexible layouts to present titles, descriptions, and multiple attributes per item.
Table Card – Visualizes structured data in rows and columns with configurable formatting, alignment, grouping, and item count to support clear data comparison and summarization.
Object Card – Presents information about a single object in configurable groups, supporting rich attribute types, visibility control, and consistent usage across SAP products.
Analytical Card – Displays analytical business data using chart visualizations with defined dimensions to ensure accurate and meaningful insight representation.
Timeline Card – Shows time-related information as a sequence of events arranged chronologically with clear visual flow and contextual details.
Calendar Card – Displays agenda or timetable data for an entity with interactive date selection, semantic legends, and dynamic data updates.

Stay tuned for future articles with details for every Card type.

The Card Footer

The card footer, located at the bottom of the card, is used for important or routine actions that directly impact the card functionality, such as "Approve" or "Submit" actions. It serves as the designated area where users can interact with or respond to the card's content through an Actions Strip—a flexible and responsive overflow toolbar that accommodates a variety of interactive elements.

The Actions Strip supports diverse interaction patterns through three primary element types: Buttons for actionable operations, Links for navigation purposes, and Labels for displaying contextual information. Additionally, ToolbarSpacer elements provide precise control over the visual arrangement of actions, enabling left-aligned, right-aligned, or centered positioning within the footer.

Each action element can be extensively configured to match specific use cases. Buttons offer multiple visual styles (Accept, Reject, Transparent, Emphasized) and can display either text, icons, or both—with the ability to prefer icon-only display in space-constrained layouts. All elements support standard properties including tooltips, visibility conditions, accessibility attributes, and overflow behavior through overflowPriority settings (High, Low, NeverOverflow, AlwaysOverflow), which determine how actions adapt to different screen sizes.

Actions themselves can be of various types: Navigation actions for opening URLs or triggering deep links, Submit actions for posting data to backend services, Custom actions that invoke extension methods. Each action can be configured with parameters and enabled/disabled states, often bound to dynamic data for context-sensitive behavior.

Here's an example demonstrating the versatility of footer configurations:

"footer": {
  "actionsStrip": [
    {
      "type": "Link",
      "text": "View Details",
      "icon": "sap-icon://detail-view",
      "actions": [
        {
          "type": "Navigation",
          "parameters": {
            "url": "{detailsUrl}"
          }
        }
      ]
    },
    {
      "type": "ToolbarSpacer"
    },
    {
      "text": "Approve",
      "buttonType": "Accept",
      "overflowPriority": "High",
      "actions": [
        {
          "type": "Submit",
          "url": "/api/approve",
          "method": "POST"
        }
      ]
    },
    {
      "buttonType": "Transparent",
      "icon": "sap-icon://email",
      "preferIcon": true,
      "text": "Contact",
      "tooltip": "Send an email",
      "actions": [
        {
          "type": "Navigation",
          "parameters": {
            "url": "mailto:{company/email}?subject={company/emailSubject}"
          }
        }
      ]
    }
  ]
}

Beyond the Actions Strip, the footer supports additional built-in features that enhance usability. It provides built-in pagination/scrolling support through the "Show More" button, which elegantly handles content overflow by opening cards in an resizable Dialog view. When cards are displayed within dialogs, the footer automatically manages a "Close" button, streamlining the user experience without requiring explicit configuration. This is achieved by defining paginator element in the footer declaration, which automatically will show an extra "Show More" button, next to custom-defined actions. See it in action in this sample.

		"footer": {
			"paginator": {
				"totalCount": "{/itemsCount}",
				"pageSize": 5
			}
		}

The footer's visibility can be controlled dynamically through binding expressions, allowing it to appear only when specific conditions are met:

"footer": {
  "visible": "{= ${/itemsCount} > 0}",
  "actionsStrip": [ /* actions configuration */ ]
}

Final Thoughts

You can use Declarative UI Integration Cards as an entry point to an app or if you want the user to focus on a single object, topic, or group of objects.

Avoid building complex, small apps within the card that require navigation flows. Instead of being complex or multifunctional, each card is designed to serve a specific role or display business data in a clear manner.

Clarity and simplicity are prioritized in Declarative UI Integration Cards, enabling users to easily understand and integrate the cards without unnecessary complexity or ambiguity.

The architecture's three-part structure—header, content, and footer—establishes a predictable framework that accelerates development while ensuring consistency across diverse use cases. This structured approach not only simplifies the creation process but also enhances the end-user experience through familiar, intuitive patterns that work seamlessly across all SAP solutions.

By embracing the declarative paradigm, developers can rapidly compose powerful, data-driven cards without deep technical expertise, while maintaining the enterprise-grade quality and accessibility standards that users expect. The result is a flexible, scalable solution that transforms how business information is surfaced and acted upon across the digital workplace.