SAP Community - ABAP Development

Debugging SAP Smartforms : Smart tip to debug SAP smartforms

2026-07-05T07:07:11.154000+02:00

Introduction:
In SAP, Forms vary from SAPscript to Smartforms, Adobe forms, Form templates and Form fragments. Smartforms are quite useful method since 1998 and companies are keeping it frequently till date. But in some situations, any smartform printing starts raising an exception, not giving expected print, giving dump suddenly and we'll keep debugging to find exact NODE for the dump. Here, I would like to share a smart tip to get to the affected NODE within a couple of minutes.

Smart Tip:
I have been debugging ABAP codes from long back whether its standard or custom code. And finally, I had a spot which can show you exactly which NODE in SMARTFORM is having the issue. And I would like to share this knowledge which can save your time and complete the deliveries on time.

Program: SAPLSTXBC or Function Group: STXBC

Include: LSTXBCFDC

Subroutine/Perform: CALLBACK

Here, you just have to pay attention after which NODE your smartform is not giving print or raising an exception when calling from driver program. And that is the NODE which has an issue.

Best Real-time use case:
In migration projects, a few of the complex smartforms have still not been migrated to Adobe Forms while migrating from ECC to S/4 HANA. In such cases, smartforms are either not giving prints or some field mapping has been changed in new system. Or some standard texts do not exist, or some graphics do not exist, not giving expected print, raising an exception or giving dumps. Sometimes, in other scenarios we also have to debug and find the NODE which is causing the issue.

Thanks for reading, Comments are always welcome.
Happy Learning!

How to Connect Claude Code to ABAP with Zero-Config MCP

2026-07-05T13:39:48.252000+02:00

Before We Start - What This Post Deliberately Skips

- What is Claude Code, and what are the available models?

- What is MCP (Model Context Protocol) and how it works conceptually?

- What is vibe coding and why AI-assisted development matters?

- What are the benefits of using AI in SAP development?

- What development platforms are available (Web, Desktop, CLI)?

If you need more details, you can find these topics in sap community portal. Read that, then come back here.

What This Post Covers - and Why It Matters?

This post walks you through connecting Claude Code to a live SAP system using the ABAP Remote Filesystem extension's native MCP server - no external Node.js setup, no manual JSON editing, just a single toggle.

What this changes for SAP development:

No more hand-typed routine code. TYPE declarations, SELECT statements, ALV setup - written directly into the SAP object from a single prompt.
No more AI guesswork. Without a live connection, AI tools hallucinate tables and function modules that don't exist. With MCP, every suggestion is grounded in your actual system.
No more setup overhead. What used to require a custom Node.js project now takes one checkbox and one command - open to any developer with VS Code.
Clean Core by default. Claude works through the same ADT API and released objects that Eclipse uses, so generated code fits your governance model instead of fighting it.

This is the point where AI-assisted ABAP stops being a chat-window experiment and starts being a real part of your IDE.

Goal: I will cover the entire topic in 4 parts:

|Part 1| Installing Claude Code on Windows and setting up the VS Code extension |

|Part 2| Connecting VS Code to your live SAP system via the ABAP FS extension |

|Part 3| Enabling the native MCP server with a single toggle - no Node.js setup, no JSON editing |

|Part 4| A live demo: one plain-English prompt creates a real, running ABAP report on SAP |

If you're here, you already know why this matters. Let's get to the actual steps.

Pre-requisite: This guide assumes you already have an active Claude subscription (Pro, Max, Team, or Enterprise). If not, sign up at claude.ai before proceeding

Part 1 - The Setup: Getting Claude Code Running on Windows

Step 1.1 - Install Claude Code CLI

Open PowerShell (the built-in Windows command-line shell) and run:

This downloads Anthropic's official installer and executes it in one step. 'irm' fetches the script, 'iex' runs it.

> ⚠️ Common Error - Git Bash Not Found

> Claude Code needs a bash shell to run on Windows. If you see this error, install Git for Windows from [git-scm.com/downloads/win](https://git-scm.com/downloads/win). During setup, select: Git from the command line and also from 3rd-party software. Then re-run the install command above.

Step 1.2 — Verify the Installation

Close PowerShell and open a fresh window. Run:

You should see a version number like 'claude 1.x.x'. If PowerShell says claude is not recognized, the PATH wasn't set automatically. Fix it manually:

1. Start → search Environment Variables in system settings

2. Edit the environment variables for your account

3. Select Path → Edit → New → paste ( in this case path can be taken from powershell commnad prompt)

for eg:

4. Close and reopen PowerShell, then re-run claude --version.

> Run claude doctor - this command checks your PATH, authentication, Node.js version, and config in one shot. Always the first step when something isn't working.

Step 1.3 - Launch Claude Code and the VS Code Extension

Navigate to your project folder and launch Claude Code.

The first launch opens your browser to authenticate with your Anthropic account (Pro, Max, Team, or Enterprise all work).

For everyday ABAP work, the VS Code extension is where you'll spend most of your time.

Download and Install VS code from code.visualstudio.com for windows if you don't already have it. Once it is installed.Open VS Code, press 'Ctrl+Shift+X', search for Claude Code (published by Anthropic), and install it. Once installed, the Claude icon appears in the Activity Bar and connects automatically to your account.

The extension gives you a persistent chat panel inside VS Code - ask Claude about the file you have open, highlight any ABAP block and ask it to explain or refactor, and switch between ABAP and CAP projects in the same session. No terminal switching required.

> Note on Software Center installs: If your organization restricts installations, Claude Code for VS Code is typically available via your company Software Center / Company Portal.

Part 2 - Connecting VS Code to Your SAP System via ABAP FS

This is where the magic begins. The ABAP Remote Filesystem (ABAP FS)extension - built by Marcello Urbani - connects VS Code to your SAP system using the same ADT REST API that Eclipse uses. Once connected, your ABAP objects (programs, classes, CDS views, behavior definitions) appear as files in VS Code. Claude Code can then read, write, and review them like any local code file.

Pre-requisites Before You Connect

You'll need these four things from your SAP system before starting:

| Hostname or IP | The address of your SAP server (hostname preferred - IP causes SSL issues explained below) |

| ADT Service active | Go to transaction SICF → '/sap/bc/adt' must be activated |

| Client number| e.g. '100' - visible in the SAP logon screen |

|Username & Password| Your regular SAP development user |

| Port | HTTPS: '44300' (typical) | HTTP: '8000' for instance 00, '8001' for instance 01 |

Step 2.1 - Install and Configure ABAP FS

1. In VS Code Extensions ('Ctrl+Shift+X'), search ABAP remote filesystem by Marcello Urbani → Install.

2. Press 'Ctrl+Shift+P' → type ABAP FS: Connection Manager → open it.

3. Add a new connection and fill in the fields:

- Name: anything you like (e.g. DEV or SANDBOX)

- Server URL:'https://<hostname>:44300'

- ⚠️ Do NOT add '/sap/bc/adt' to the URL - the extension adds this automatically. If you include it, the path doubles and the connection fails.

- Client, Username, Language: 'EN'

4. Save.

5. Press 'Ctrl+Shift+P' → ABAP FS: Connect to an SAP system→ select your connection → enter password.

> ⚠️ SSL Certificate Error (very common on internal systems)

> If you see IP does not match certificate's altnames - this is because your SAP system's SSL certificate was issued with a hostname, not the IP. The fix: Get the hostname (e.g. 'https://sapdev.company.com:44300') and use that instead of the IP.

> ⚠️ADT Service Not Found

> If you see Resource /sap/bc/adt does not exist - the ADT service isn't activated. Run tcode SICF → navigate to default_host → 'sap/bc/adt' → right-click → Activate Service.

Step 2.2 - Navigating ABAP Objects

ABAP FS gives you two ways to find objects. Object Search lets you find anything by name instantly. If you prefer a tree view like Eclipse ADT, enable SAP GUI Integration in your connection settings - this gives you a full package tree (Dictionary, Source Code Library, Transactions) and even embeds SAP GUI for HTML directly inside VS Code, so you can run transactions without leaving the editor.

1. Click OBJECT SEARCH in the left sidebar

2. Type the object or package name (e.g. 'ZCL_MY_CLASS' or 'Z_MY_PACKAGE')

3. Double-click any result to open it as a text file in VS Code

4. To edit: right-click → edit → save (changes push back to SAP automatically)

Once an object is open in VS Code, open the integrated terminal (Ctrl+) and run claude. Some prompts that immediately pay off:

Part 3 -The Game Changer: Enabling the Native MCP Server

This is the step that changes everything - and the reason this post exists.

Why ABAP FS Alone Isn't Enough?

With only ABAP FS connected, Claude can see only the one file you currently have open. Ask it to create a new class and it might invent table names, function modules, or BAdI definitions that don't exist on your system. It's helpful, but it's guessing.

ABAP FS Only ABAP FS + MCP

Claude sees what we search Manually	Claude autonomously searches any object on the system
Hallucinates objects it hasn't seen	Grounded in live SAP system data
You copy-paste code manually	Claude reads, writes, activates autonomously
No transport awareness	Creates & assigns transports via ADT

The MCP (Model Context Protocol) server gives Claude Code a live connection to your SAP system's ADT API - the same backend Eclipse uses. Claude stops guessing and starts knowing.

Step 3.1 - Enable the MCP Server (One Toggle)

This is where the zero-config part comes in. You don't need to install anything extra, clone a Node.js repo, or edit JSON files manually.

Press 'Ctrl+Shift+P' → search ABAP FS MCP → select it → enable Autostart.

That's it. The ABAP FS extension spins up a local MCP server on your machine (default port 4847). You'll see a VS Code notification confirming it's running:

> ABAP MCP Server running on port 4847. External AI clients can connect to http://localhost:4847/mcp

Step 3.2 - Register the MCP Server with Claude Code

Now tell Claude Code where to find the ABAP tools. Run this in the VS Code integrated terminal:

This registers the local MCP server with Claude Code. The configuration is saved to your '.claude.json' file and persists across sessions - you only need to do this once.

Step 3.3 - Verify the Connection

open the terminal and run this command once the MCP server is added

You should see:

Claude Code will confirm when the server is registered:

> abap-remote-fs has been added with HTTP transport at http://localhost:4847/mcp"*

The Complete Architecture

Claude Code can now autonomously:

- Search and read any ABAP object on the live SAP system

- write → syntax check → activate → unlock objects

- Create transport requests and assign objects

- Run ATC checks and read short dumps - all from a plain-English prompt

> Golden - In Auto mode, Claude will write, syntax check, and activate without pausing - that's the power of the agentic workflow. If you want to review before anything is activated, switch to Plan mode shift+tab to cycle modes) Claude will show you the full plan and wait for your approval. For production-adjacent systems, always run in Plan or Step mode.

Part 4 - Live Demo: One Prompt, One Real ABAP Program on SAP

Disclaimer: This is my first time setting up all this and explore, so i just started with a very simple scenario. Going forward will create RAP objects and other complex artifacts and see the efficiency.

Let me show you what all of this enables. Here's the exact prompt I used:

> Create a new ABAP executable program ZCL_DEMO_REPORT_01 in my ZVS_DEMO package. Fetch data from MARA for a user-specified Material Number (select-option) and display Material Number, Type, and Created By in an ALV grid. Write in ABAP 7.5 syntax.

One prompt. No templates. No copy-paste. Here's what Claude did.

Act 1 - Claude Plans Before It Codes

Claude didn't immediately start writing code. It:

1. Confirmed the target package ('ZVS_DEMO') exists on the system

2. Detected that the program creation triggered a **transport request dialog** — and recognised it was the likely source of a cancellation

3. Called the SAP ADT API via Bash to **list existing open transports**

4. Selected the correct transport and retried the creation

There was a little bit delay on my end to confirm the transport. and it gave me this message.

> Package confirmed. The cancellation is likely a transport request dialog. Let me check for existing transports, then retry.

This is the part that impresses ABAP developers most. Claude handled a real SAP workflow quirk .

Act 2 - The Program Appears on SAP

Claude then created the program on the live system. You can watch its autonomous todo list mid-execution:

- Create ABAP program ZCL_DEMO_REPORT_01 in ZVS_DEMO package via MCP

- Get workspace URI for the new program

- Write ABAP source code into the program

- Activate the program and check diagnostics

'ZCL_DEMO_REPORT_01' appeared in the VS Code Explorer sidebar - a real, registered ABAP program on the SAP system, not a local file.

You can see initially there was no program created in my package

After few seconds, the program is created

Act 3 - Full ABAP 7.5 Source Code Written

With the object created, Claude fetched the workspace URI and wrote the complete source code directly into the SAP program. What it generated:

No placeholder code. Real, working ABAP in the correct syntax release, referencing actual MARA field types from the live system.

Act 4 - Running the Program

After activation, there are two ways to run it:

Option A - Classic SAP GUI:Log in to SAP GUI →run the program → Execute

Option B - Embedded SAP Web GUI(what I used): VS Code can open the SAP Web GUI directly in a browser tab, embedded inside the IDE. No separate login or window switching required.

Enter selection criteria:

The selection screen appeared with the Matnr field exactly as specified. I entered a range of 11to 21. The value help (F4) shows the available materials in the system

Material Number, Material Type, and Created By - exactly what was asked for. Live data from MARA. Report running.

Summary:

|Claude understands SAP context| It identified the transport dialog, queried existing transports via ADT, and handled a real SAP workflow quirk autonomously

| It created a real SAP object| 'ZCL_DEMO_REPORT_01' exists on the live system, created via ADT REST API through MCP - not a file on disk

| Production-quality ABAP 7.5 | TYPE declarations referencing actual MARA field types, correct naming conventions, modern SQL syntax

| Minutes, not hours| The developer's job shifts to reviewing - not writing skeletons, hunting transport dialogs, or looking up field types

| Fully iterative| Once created, you can ask Claude to add authority checks, error handling, ALV field catalogues, or additional filters - each iteration in seconds

| You stay in control | Claude's todo list is transparent - you see every step it plans. You review the code. You decide what activates

Where to Go from Here?

Here are five things to try once you have the setup working:

1. Understand inherited code - Explain the purpose and flow of report Z_*_REPORT. Include tables accessed, authority checks, deprecated patterns like SELECT .

2. Generate a CDS view - Create a CDS view hierarchy for Sales Order analysis: interface view joining VBAK+VBAP, projection view with Fiori Elements. UI annotations for a List Report.

3. Build a Travel Request POC - RAP Business Object with CRUD, approve/reject action, draft handling, OData V4 binding, Fiori Elements UI.

4. Write ABAP Unit tests - Generate a unit test class

5. Code review and modernization - Review this class for Clean ABAP violations, missing authority checks, SELECT * usage, and SELECT inside LOOP. Propose S/4-equivalent replacements.

The bottom line: The integration that used to require manual Node.js setup, JSON editing, and external package management now takes a single Ctrl+Shift+P toggle and one terminal command.

The ABAP Remote Filesystem team has done the hard work. Claude Code does the coding. You do the review.

Give it a try - and let me know in the comments what use case you tackle first.

A personal note : This is my first time diving deeper into vibe coding and MCP concepts. I come from a classic ABAP background, and everything covered here - from the VS Code setup to the MCP server to the live demo - I explored and built from scratch over the past few weeks. The scenario is intentionally simple. The goal was to get the fundamentals right, document them honestly, and share what works. There is a lot more ground to cover - RAP generation at scale, Clean Core extensibility patterns, ATC pre-checks via Claude Code, and deeper agentic workflows. I'll be going further in the posts ahead. If you're also just getting started with this, I hope this gives you a solid, working foundation to build on. And if you're already further ahead - I'd love to hear what you've learnt in the comments.

Note: All screenshots in this post are taken from a live S/4HANA development system. Code generated by Claude Code should always be reviewed and tested in a sandbox environment before activation in any productive system.

Building a RAP Application with External SAP HANA Cloud using CDS External Entities – Part 1

2026-07-08T10:49:55.174000+02:00

Why External Entities?

CDS external entities provide a modern way to handle secondary database connections in ABAP Cloud. They allow applications to retrieve and modify data from other databases using SQL. Sounds interesting? This blog post covers how to create a RAP application in SAP BTP ABAP Environment with a secondary HANA database connection.

Business scenario:

Many organizations already have business data stored in a separate SAP HANA Cloud database and want to build modern RAP (ABAP RESTful Application Programming Model) applications on SAP BTP ABAP Environment without replicating that data into the ABAP system.

The blog demonstrates this using a Loyalty Management application.

Scenario

Customer loyalty information (Memberships) is stored in an external SAP HANA Cloud database.
Transaction data related to each membership is also stored in the same external database.
The business wants a Fiori application where users can:
- Create loyalty memberships
- Maintain loyalty transactions
- Update and delete records
- View accumulated loyalty points
- Persist all changes directly in the external HANA database

Prerequisites:

SAP BTP Sub-Account
SAP HANA Cloud Instance
SAP BTP ABAP Environment

Steps:

Setup SAP HANA Cloud instance
Create Schema and Tables
Configure external connection to External HANA database from SAP BTP ABAP Environment using External Entities
Create External Entities

Setup SAP HANA Cloud instance

Let’s start on with the creation of SAP HANA Cloud instance.

Open SAP BTP cockpit and add the following Entitlements.
Create HANA cloud subscription.
Create HANA Cloud Instance

Specify Instance name, Set DBADMIN password and choose Allow all IP address
Spoiler
Disclaimer on Database IP Access Configuration
Allowing unrestricted access (e.g., permitting all IP addresses such as 0.0.0.0/0) to a database that contains production data introduces significant security risks. This approach should only be used in strictly controlled environments.
Once the Instance status turns into Running state and click on Actions three dots and Open in SAP HANA Database Explorer.
Provide the DBADMIN credentials from the previous step to connect to the HANA database.

Create Schema and Tables

Open SQL Console and perform the following steps to create the schema and tables.

Create Schema

CREATE SCHEMA LOYALTY;

Create Membership table: zlm_membship_ee .

Stores membership details
Primary key: client + membershipuuid

create column table loyalty."zlm_membship_ee" (
"client" nvarchar (000003) default '000' not null, 
"membershipuuid" varbinary (000016) default x'00000000000000000000000000000000' not null , 
"membershipid" nvarchar (000010) default '0000000000' not null, 
"customer" nvarchar (000010) default '' not null, 
"createdby" nvarchar (000012) default '' not null, 
"createdat" decimal (000021, 000007) default 0 not null, 
"lastchangedby" nvarchar (000012) default '' not null, 
"locallastchangedat" decimal (000021, 000007) default 0 not null, 
"lastchangedat" decimal (000021, 000007) default 0 not null,
primary key ("client", "membershipuuid" )     
) column loadable

Create Transactions table: zlm_transctns_ee

Stores transactions linked to membership.
Contains transaction value and loyalty points.

create column table loyalty."zlm_transctns_ee" (
"client" nvarchar (000003) default '000' not null, 
"transactionuuid" varbinary (000016) default x'00000000000000000000000000000000' not null ,
"membershipuuid" varbinary (000016) default x'00000000000000000000000000000000' not null , 
"transactiondate" NVARCHAR (000008) DEFAULT '00000000' NOT NULL, 
"transactionvalue" DECIMAL (000010, 000002) DEFAULT 0 NOT NULL, 
"transactioncurrency" NVARCHAR (000005) DEFAULT '' NOT NULL, 
"loyaltypoints" BIGINT DEFAULT 0 NOT NULL, 
"createdby" nvarchar (000012) default '' not null, 
"createdat" decimal (000021, 000007) default 0 not null, 
"lastchangedby" nvarchar (000012) default '' not null, 
"locallastchangedat" decimal (000021, 000007) default 0 not null, 
"lastchangedat" decimal (000021, 000007) default 0 not null,
primary key ("client", "transactionuuid" )     
) column loadable

Configure connectivity to an external SAP HANA database from Steampunk for data access using External Entities

Establish outbound SQL access using an external entity using ABAP Development Tools for Eclipse
1. Define and activate a logical external schema whose configuration specifies the connection details for the outbound communication. Create a logical external schema in ABAP Development Tools (ADT) using the creation wizard.
2. Create an Outbound Service of the type Outbound SQL Access for your logical external schema.
3. Create a Communication Scenario.
4. Include the outbound service in the communication scenario.
Configure External Connection
In the Fiori Launchpad, Logon as Administrator and perform the following steps.
1. Create a Communication Arrangement for scenario ZLM_COM_EXT_SCHEMA_EE.
2. Create a Communication System
  
  Toggle Remote SQL Access and choose Adapter Name as HANA (ODBC)
  Adapter Configuration :Driver=libodbcHDB.so;ServerNode=*.hanacloud.ondemand.com(URL of the External Database):443;
3. Create an Outbound User. Specify the HANA DB user which contains the necessary authorizations for accessing the External Schema.

Create CDS External Entities

Two types:
1. Writable External Entity → Used for INSERT/UPDATE/DELETE
2. Static External Entity → Used for SELECT (read only)

These entities map external tables to ABAP CDS.

In ABAP Development Tools for Eclipse: As an ABAP Developer, here’s what you need to do to establish outbound SQL access using a CDS external entity.

Define and activate an external entity that represents the external database object.As we are going to perform CUD operation on external database, we need to create Writable External Entity for table zlm_membship_ee which will be referred by external name zlm_membship_ee.

@EndUserText.label: 'Writable EE for HANA tab zlm_membship_ee'
define writable external entity zlm_membship_cud_ee external name "zlm_membship_ee"
{
  key client             : abap.char(3)                  external name "client";
  key membershipuuid     : sysuuid_x16                   external name "membershipuuid";
      membershipid       : zlm_membershipid_ee           external name "membershipid";
      customer           : zlm_customer_ee               external name "customer";
      @Semantics.user.createdBy: true
      createdby          : abp_creation_user             external name "createdby";
      @Semantics.systemDateTime.createdAt: true
      createdat          : abp_creation_tstmpl           external name "createdat";
      @Semantics.user.lastChangedBy: true
      lastchangedby      : abp_lastchange_user           external name "lastchangedby";
      @Semantics.systemDateTime.localInstanceLastChangedAt: true
      locallastchangedat : abp_locinst_lastchange_tstmpl external name "locallastchangedat";
      @Semantics.systemDateTime.lastChangedAt: true
      lastchangedat      : abp_lastchange_tstmpl         external name "lastchangedat";
}
with federated data provided at runtime

We need to create Writable External Entity for table zlm_transctns_ee

@EndUserText.label: 'Writable EE for HANAtab zlm_transctns_ee'
define writable external entity zlm_transctns_cud_ee external name "zlm_transctns_ee"
{
  key client              : abap.char(3)                  external name "client";
  key transactionuuid     : sysuuid_x16                   external name "transactionuuid";
      membershipuuid      : sysuuid_x16                   external name "membershipuuid";
      transactiondate     : zlm_transactiondate_ee        external name "transactiondate";
      @Semantics.amount.currencyCode : 'transactioncurrency'
      transactionvalue    : zlm_transactionvalue_ee       external name "transactionvalue";
      transactioncurrency : zlm_transactioncurrency_ee    external name "transactioncurrency";
      loyaltypoints       : zlm_loyaltypoints_ee          external name "loyaltypoints";
      @Semantics.user.createdBy: true
      createdby           : abp_creation_user             external name "createdby";
      @Semantics.systemDateTime.createdAt: true
      createdat           : abp_creation_tstmpl           external name "createdat";
      @Semantics.user.lastChangedBy: true
      lastchangedby       : abp_lastchange_user           external name "lastchangedby";
      @Semantics.systemDateTime.localInstanceLastChangedAt: true
      locallastchangedat  : abp_locinst_lastchange_tstmpl external name "locallastchangedat";
      @Semantics.systemDateTime.lastChangedAt: true
      lastchangedat       : abp_lastchange_tstmpl         external name "lastchangedat";
}
with federated data provided at runtime

To securely map a remote physical database object so it can be queried directly, we need to use STATIC EXTERNAL ENTITIES to fetch data from table zlm_membship_ee .

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Static EE for HANA tab zlm_membship_ee'
define external entity zlm_membship_ee external name "zlm_membship_ee"
{
  key client             : abap.char(3)                  external name "client";
  key membershipuuid     : sysuuid_x16                   external name "membershipuuid";
      membershipid       : zlm_membershipid_ee           external name "membershipid";
      customer           : zlm_customer_ee               external name "customer";
      @Semantics.user.createdBy: true
      createdby          : abp_creation_user             external name "createdby";
      @Semantics.systemDateTime.createdAt: true
      createdat          : abp_creation_tstmpl           external name "createdat";
      @Semantics.user.lastChangedBy: true
      lastchangedby      : abp_lastchange_user           external name "lastchangedby";
      @Semantics.systemDateTime.localInstanceLastChangedAt: true
      locallastchangedat : abp_locinst_lastchange_tstmpl external name "locallastchangedat";
      @Semantics.systemDateTime.lastChangedAt: true
      lastchangedat      : abp_lastchange_tstmpl         external name "lastchangedat";
}
with federated data provided by zlm_ext_schema_ee

We need another STATIC EXTERNAL ENTITY for table zlm_transctns_ee

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Static EE for HANA tab zlm_transctns_ee'
define external entity zlm_transctns_ee external name "zlm_transctns_ee"
{
  key client              : abap.char(3)                  external name "client";
  key transactionuuid     : sysuuid_x16                   external name "transactionuuid";
      membershipuuid      : sysuuid_x16                   external name "membershipuuid";
      transactiondate     : zlm_transactiondate_ee        external name "transactiondate";
      @Semantics.amount.currencyCode : 'transactioncurrency'
      transactionvalue    : zlm_transactionvalue_ee       external name "transactionvalue";
      transactioncurrency : zlm_transactioncurrency_ee    external name "transactioncurrency";
      loyaltypoints       : zlm_loyaltypoints_ee          external name "loyaltypoints";
      @Semantics.user.createdBy: true
      createdby           : abp_creation_user             external name "createdby";
      @Semantics.systemDateTime.createdAt: true
      createdat           : abp_creation_tstmpl           external name "createdat";
      @Semantics.user.lastChangedBy: true
      lastchangedby       : abp_lastchange_user           external name "lastchangedby";
      @Semantics.systemDateTime.localInstanceLastChangedAt: true
      locallastchangedat  : abp_locinst_lastchange_tstmpl external name "locallastchangedat";
      @Semantics.systemDateTime.lastChangedAt: true
      lastchangedat       : abp_lastchange_tstmpl         external name "lastchangedat";
}
with federated data provided by zlm_ext_schema_ee

Key Takeaways.

External entities enable real-time integration with external databases without replication.

In Part 2 of this series, we will build a RAP application using the data model created here.

Why Stock Fields Return Zero in Custom CDS Views on MARC - and How to Resolve It

2026-07-08T11:22:05.761000+02:00

Why Stock Fields Return Zero in Custom CDS Views on MARC - and How to Resolve It

I was building a custom CDS view on the MARC table (Plant Data for Material) to extract data into SAP Datasphere using Change Data Capture (CDC) for delta loads.

After activating the view, I checked the data and found something odd. The field TRAME (Stock in Transit) had a proper value in the MARC table, but in my CDS view the same field was completely empty.

To give a concrete example, for one material and plant the MARC table showed TRAME = 50.000, but my CDS view showed TRAME = 0.000 for the same key. All the master data fields were perfectly fine. Only the stock field was wrong.

That single clue — master data correct, stock field zero — is what pointed me to the real cause.

Where the data actually lives in S/4HANA

In the older SAP ECC system, stock quantities were physically saved in many tables, and the same figure was often repeated in several places. This created redundancy and slowed things down.

In S/4HANA, SAP redesigned this part of the system with the New Simplified Data Model (NSDM). The idea is straightforward: all stock movements are written into a single table called MATDOC, and the stock figures are calculated when you ask for them instead of being stored everywhere.

Because of this change, MARC became a so-called hybrid table. It still physically stores the material master and planning data, but the stock quantity fields are no longer filled in the table itself. Fields like TRAME, UMLMC, GLGMG and BWESB are now worked out on the fly from MATDOC whenever they are read.

So in S/4HANA, the TRAME column inside the physical MARC table is basically empty. The real stock-in-transit figure is calculated from MATDOC only at the moment it is needed.

Why SE16 showed the value but my CDS did not

This is the most important point of the whole story. SE16 and my CDS view were reading the same table through two completely different paths.

When you open MARC in SE16, the read goes through the normal application layer. SAP automatically redirects that read to a proxy object behind MARC, which performs the MATDOC calculation and returns the correct TRAME value. That is why SE16 happily showed 50.000.

My CDS view, on the other hand, was written as select from marc. A CDS view runs straight on the database and reads the physical MARC table directly. It never passes through the redirect, so it picked up the empty physical column and returned 0.000.

In one sentence:

SE16 reads MARC through the proxy and gets the calculated value. A CDS that selects directly from MARC reads the raw table and gets nothing. That difference in the read path was the entire reason the data "did not come."

My first fix — and why it failed

My first idea was simple. If the proxy returns the correct value, why not read from the proxy instead of the table? So I changed the source of my view to the proxy object:

Before (TRAME comes as zero):

@AbapCatalog.sqlViewName: 'ZCDS_MARC_DEX'

@AbapCatalog.compiler.compareFilter: true

@AbapCatalog.preserveKey: true

@AccessControl.authorizationCheck: #NOT_REQUIRED

@EndUserText.label: 'Plant Data for Material'

@Metadata.ignorePropagatedAnnotations: true

@analytics.dataExtraction:{enabled: true,

delta.changeDataCapture:{mapping:[

{table:'marc',role:#MAIN,

viewElement:['Matnr','Werks'],

tableElement:['matnr','werks']}]}}

define view ZCDS_MARC_DEX_CDC as select from marc

{

key matnr as Matnr,

key werks as Werks,

pstat as Pstat,

lvorm as Lvorm,

bwtty as Bwtty,

xchar as Xchar,

trame as Trame,

... remaining MARC fields ...

After (TRAME correct and CDC activates):

@AbapCatalog.sqlViewName: 'ZCDS_MARC_DEX'

@AbapCatalog.compiler.compareFilter: true

@AbapCatalog.preserveKey: true

@AccessControl.authorizationCheck: #NOT_REQUIRED

@EndUserText.label: 'Plant Data for Material'

@Metadata.ignorePropagatedAnnotations: true

@analytics:{

dataExtraction.enabled: true,

dataExtraction.delta.changeDataCapture:{

mapping:[

{

table:'marc',

role:#MAIN,

viewElement:['Matnr','Werks'],

tableElement:['matnr','werks']

}]

}

define view ZCDS_MARC_DEX_CDC as select from nsdm_e_marc

{

key matnr as Matnr,

key werks as Werks,

pstat as Pstat,

lvorm as Lvorm,

bwtty as Bwtty,

xchar as Xchar,

trame as Trame,

... remaining MARC fields ...

The only real change is the data source: from marc to nsdm_e_marc. The CDC mapping still refers to the physical table marc

This is not only a MARC problem

The same behaviour happens with all NSDM stock tables in S/4HANA. If your CDS reads stock fields straight from any of these, you can get zeros:

MARC – plant stock fields (TRAME, UMLMC, GLGMG, BWESB)
MARD – storage location stock
MCHB – batch stock
MKOL – special / consignment stock
MSKA – sales order stock
MSKU – customer special stock
MSLB – stock with vendor (subcontracting)
MSPR, MSSA, MSSQ – project and sales order stock totals
MSTB, MSTE, MSTQ – stock in transit tables

A simple rule of thumb: if a table held stock quantities in ECC, in S/4HANA those quantities are now calculated, and a direct CDS read will return zero. Use the table's proxy instead.

How to find the correct proxy in your own system

You do not have to guess the name. For any table (example: MARC):

Open the table in SE11.
Choose menu Extras → Replacement Object to see the assigned proxy (for MARC it is NSDM_E_MARC).

Example – "MARC" Replacement Object

Conclusion

What first looked like a bug in my CDS view turned out to be normal S/4HANA behaviour. Under the New Simplified Data Model, stock quantity fields are no longer stored in tables like MARC — they are calculated from MATDOC only when they are read. SE16 shows the correct value because it goes through the replacement object, while a CDS view that reads the table directly picks up the empty physical column and returns zero.

The fix itself is small but important: source the CDS view from the replacement object (for MARC, NSDM_E_MARC) instead of the base table. After that one change, TRAME returned the correct value. And because this is standard NSDM behaviour, the same approach works for every stock table in the family — whenever a stock field comes back as zero, the first thing to check is whether you are reading the base table directly instead of its replacement object.

The bigger lesson I took away is to always confirm where a field's data actually lives before building a CDS view on top of a table. A quick look at SE11 → Extras → Replacement Object tells you whether a table is a hybrid table and which object you should really be reading from. That single check can save a lot of confusing "the value is there in SE16 but missing in my view" situations.

Building a Production-Ready Custom ATC Check: Enforcing ABAP Unit Coverage

2026-07-09T05:13:31.489000+02:00

Introduction

Many development teams encourage ABAP Unit adoption, but enforcing minimum test coverage is still a challenge.

During a recent project, I needed a way to prevent the release of new developments that did not meet a minimum coverage threshold.

Since I couldn't find a standard ATC check that fulfilled this requirement, I decided to build a custom ATC validation.

The final solution became a lightweight and configurable quality gate that can be integrated directly into existing SCI and ATC processes.

Inspiration

Before starting the implementation, I analyzed several open-source ATC extensions, especially the SAP Code Pal for ABAP project.

Code Pal is an excellent reference for understanding how custom checks can be integrated into the ATC framework and how configurable validations can be implemented.

However, my goal was not to build a generic quality framework. Instead, I wanted a lightweight solution focused on a single requirement: enforcing a minimum ABAP Unit test coverage threshold.

For this reason, I implemented a simplified check that leverages the standard SCI/ATC framework and ABAP Unit coverage APIs while remaining easy to maintain and extend.

Understanding the Solution

The solution is composed of three main components:

A custom ATC category
A custom ATC check
A configurable SCI/ATC variant

The execution flow is illustrated below:

SCI / ATC
      ↓
Custom Check
      ↓
ABAP Unit Coverage Analysis
      ↓
Threshold Validation
      ↓
ATC Finding

Creating a Custom Check Category

The first step is to create a custom category that will group all checks.

Create a class that inherits from CL_CI_CATEGORY_ROOT.

METHOD constructor.
  super->constructor( ).

  description = TEXT-t01.
  category    = me->ci_category.
ENDMETHOD.

This category will later appear in the SCI administration screen and will act as a container for all custom validations.

Creating the Check Class

Next, create the actual validation check by inheriting from CL_CI_TEST_ROOT.

In the constructor, define the basic metadata of the check:

Description
Category
Display position
Version
Error messages

METHOD constructor.
  super->constructor( ).

  description = `Minimum ABAP Unit Coverage`.
  category    = `Your Custom Category`.
  position    = `010`.
  version    += 1.

  APPEND VALUE #(
           sign   = `I`
           option = `EQ`
           low    = `1PRG`
         ) TO me->typelist.

  APPEND VALUE #(
           test = me->myname
           code = `CI001`
           kind = me->c_error
           text = 'Insufficient coverage: &1% (min. &2%)'
         ) TO me->scimessages.
ENDMETHOD.

Once activated and registered in SCI, the category and the check should appear in the SCI management screen.

New checks

Category and new check

Adding Configuration Parameters

One of the main goals of this implementation was to make the validation configurable.

Instead of hardcoding values, the minimum coverage threshold and object filters are maintained through the SCI variant.

To achieve this, I redefined the method IF_CI_TEST~QUERY_ATTRIBUTES.

This allows us to build a custom parameter screen such as:

Minimum Coverage (%)
Created After
Object Type
BAdI Implementations Only
RAP Behavior Implementations Only

METHOD if_ci_test~query_attributes.
  DATA(attributes) = VALUE sci_atttab(
    ...
  ).

  DATA(break) =
    cl_ci_query_attributes=>generic(
      p_name       = me->myname
      p_title      = me->description
      p_attributes = attributes
      p_display    = p_display ).
ENDMETHOD.

The resulting configuration screen looks like this:

Screen

Persisting Variant Parameters

The values entered by users need to be stored and restored whenever the variant is executed.

This is done by redefining the methods GET_ATTRIBUTES and PUT_ATTRIBUTES.

METHOD get_attributes.
  EXPORT attributes_filled = attributes_filled
    TO DATA BUFFER p_attributes.
ENDMETHOD.

METHOD put_attributes.
  IMPORT attributes_filled = attributes_filled
    FROM DATA BUFFER p_attributes.
ENDMETHOD.

Implementing the Validation Logic

The heart of every ATC check is the RUN method.

This method is executed for every analyzed object.

METHOD run.
  CHECK me->program_name IS NOT INITIAL.
  CHECK me->get( ) = me->c_true.

  CHECK me->object_type IN me->attributes_filled-object_type.
  CHECK me->is_after_minimum_creation_date( ) >=
        me->attributes_filled-date_from.

  DATA(percentage) = me->get_coverage( ).

  IF percentage < me->attributes_filled-coverage_minimun.

    inform(
      p_sub_obj_type = me->c_type_include
      p_sub_obj_name = me->program_name
      p_kind         = me->c_error
      p_test         = me->myname
      p_code         = `CI001`
      p_param_1      = |{ percentage NUMBER = USER }|
      p_param_2      = |{ me->attributes_filled-coverage_minimun NUMBER = USER }|
    ).
  ENDIF.
ENDMETHOD.

Measuring ABAP Unit Coverage

One of the most interesting parts of this implementation was discovering that ABAP Unit coverage can be measured programmatically.

The class CL_AUCV_TASK provides the necessary APIs.

METHOD get_coverage.
  DATA(aunit) =
    cl_aucv_task=>create(
      i_measure_coverage = abap_true ).

  ...

  percentage =
    branch_coverage->get_percentage( ).
ENDMETHOD.

This allows the ATC check to compare the actual coverage with the threshold configured in the SCI variant.

Executing the Check

After creating an SCI variant and selecting the custom check, simply configure the desired threshold.

For example:

Created After = 01.01.2025
Minimum Coverage = 85%
Object Type = CLAS

First, let's measure the ABAP Unit coverage of a sample object:

ABAP Unit

When ATC is executed, findings are generated whenever the object's coverage is below the required percentage.

ATC Result

Lessons Learned

ATC is far more extensible than it initially appears.
Custom checks can be used to implement real governance requirements.
ABAP Unit coverage can be measured programmatically.
Configurable checks simplify gradual adoption.
Quality gates are an effective way to increase test adoption.

Final Thoughts

By combining the SCI framework, ATC extensibility and ABAP Unit coverage APIs, it is possible to build lightweight but powerful quality controls directly inside the SAP development process.

In addition to ATC execution, I also integrated this validation into the transport release process, ensuring that new developments cannot be released when they fail to meet the required coverage threshold.

Have you ever implemented a custom ATC validation in your landscape? Feel free to share your experience in the comments.

Extending the Fiori App Display Supplier List (F1861): A Practical Approach Using CDS Views

2026-07-09T19:17:38.648000+02:00

Introduction

Extending standard SAP Fiori applications is a common requirement in S/4HANA projects.

In a recent scenario, I needed to include additional supplier fields from table LFA1 into the standard app Display Supplier List (F1861). However, even though the fields existed in the backend, they were not available in the Fiori application.

The Challenge

At first glance, extending a standard app may seem straightforward, but when dealing with CDS-based applications, simply adding fields at database level is not enough.

The F1861 app relies on CDS views and requires specific extension steps to properly expose additional fields.

SAP Note

According to SAP Note 3200905, extending standard CDS-based applications requires following a specific approach to ensure that custom fields are correctly exposed in both UI and analytical layers.

3200905 - Display Supplier List: Standard extensibility delivered by View Entity

Approach Overview

To address this, the following approach was implemented:

Extend the CDS view used as data source (C_Supplier)
Extend the consumption CDS view (C_SupplierList)
Apply UI annotations via Metadata Extension

Implementation

The standard interface view C_Supplier was extended to include custom fields from table LFA1.

extend view C_Supplier with ZEXT_C_SUPPLIER
  association [1..1] to lfa1 as _Supplier on $projection.supplier = _Supplier.lifnr
{
  _Supplier.ort02                                         as ExtDistrictName,
  _Supplier.brsch                                         as ExtIndustry,
  cast( _Supplier.gbdat as zext_gbdat preserving type )   as ExtBirthDate, // Custom data element used – standard conversion exit PDATE is not supported in CDS
  _Supplier.txjcd                                         as ExtTaxJurisdiction,
  _Supplier.regss                                         as SupplIsSocialInsuranceRegtrd,
  _Supplier.actss                                         as SocialInsuranceActivityCode,
  _Supplier.cnae                                          as ExtTaxEconomicActivityCode
}

A custom data element was created for the birth date field, as the standard conversion exit (PDATE) is not supported in CDS views. This allowed proper handling of the field without relying on conversion exits.

Next, the consumption view C_SupplierList was extended:

extend view C_SupplierList with ZEXT_C_SUPPLIERLIST
{
  cast( '' as ort02_gp )                         as ExtDistrictName,
  cast( '' as brsch )                            as ExtIndustry,
  cast( '' as zext_gbdat )                       as ExtBirthDate,
  cast( '' as txjcd )                            as ExtTaxJurisdiction,
  cast( '' as j_1aregss preserving type )        as SupplIsSocialInsuranceRegtrd,
  cast( '' as j_1aactss )                        as SocialInsuranceActivityCode,
  cast( '' as j_1bcnae )                         as ExtTaxEconomicActivityCode
}

A metadata extension was then used to control the visibility of fields in the UI:

@Metadata.layer: #CORE
annotate view C_SupplierList with
{
  @UI: { hidden: true }
  BPTaxType;

  @UI: { hidden: true }
  VATRegistration;

  @UI: { hidden: true }
  TaxTypeName;
}

This approach ensures that the extension remains upgrade-safe and aligned with SAP extensibility guidelines.

Result

After the extensions and annotations, the custom fields were successfully displayed in the F1861 app.

Display Supplier List (new fields)

Challenges Faced

Some challenges were encountered during the implementation:

Fields not appearing due to missing annotations
Issues with CDS associations
Inconsistent behavior when extending standard views
Limitations when reusing associations locally

Key Learnings

This scenario highlights several important aspects when working with SAP extensibility:

Understanding the CDS view hierarchy is essential
Metadata Extensions are required for UI exposure
SAP Notes often contain critical implementation details

Final Thoughts

This scenario demonstrates how standard SAP applications can be extended in a structured way, without modifying the core system, following clean core principles.

I would be interested to hear how other teams are handling Fiori extensibility scenarios.

👉Feel free to share your approach or exchange ideas.

How to Find the Right Enhancement Spot in Fiori App F3516: A Practical Validation Scenario

2026-07-09T20:20:02.489000+02:00

Introduction

Validations are a common requirement in SAP Fiori applications. However, identifying the correct enhancement spot for a given app can be challenging.

The Challenge

In this scenario, a validation was required in the Fiori app Manage Profit Centers (Version 2) - F3516 to ensure that the segment value followed specific business rules.

The main challenge was not implementing the validation itself, but identifying the correct enhancement point in the backend.

How the Enhancement Spot Was Identified

A practical approach I often use is to identify the technical package behind the Fiori application.

This can be done by navigating to the Fiori Apps Library, checking the Implementation Information section, and identifying the OData service used by the application.

From there, the OData service can be searched in the ABAP environment (Eclipse), allowing identification of the corresponding package.

In this case, within the application package ODATA_PROFIT_CENTER_V2, an enhancement package with a very intuitive name was found:

ODATA_PROFIT_CENTER_V2_ENH (Enhancements for Manage Profit Center)

CLASS CL_FIN_PC_VALIDATION_IMPL_EX

Within this package, it was possible to identify available enhancement implementations. Among the options, the following example class was used as a reference:

class CL_FIN_PC_VALIDATION_IMPL_EX definition
  public
  final
  create public.

public section.

  interfaces IF_BADI_INTERFACE.
  interfaces IF_BADI_FIN_PC_VALIDATION.

protected section.
private section.
ENDCLASS.

CLASS CL_FIN_PC_VALIDATION_IMPL_EX IMPLEMENTATION.

  method IF_BADI_FIN_PC_VALIDATION~EXECUTE.

    data: ls_validationmessage like line of ct_messages.

    ls_validationmessage-msgid = 'FAC_MPC_PCTR'.
    ls_validationmessage-msgno = '022'.
    ls_validationmessage-msgty = 'E'.
    ls_validationmessage-msgv1 = 'The Field '.
    ls_validationmessage-msgv2 = 'Profit Center Category '.
    ls_validationmessage-msgv3 = 'contains invalid value '.

    insert ls_validationmessage into table ct_messages.

  endmethod.

ENDCLASS.

Implementation

The validation logic was implemented to ensure that segment values starting with "0" are not allowed:

METHOD if_badi_fin_pc_validation~execute.
    CONSTANTS: BEGIN OF segment_values,
                 geral   TYPE fb_segment VALUE `GERAL`,
                 ato     TYPE fb_segment VALUE `ATO`,
                 nao_ato TYPE fb_segment VALUE `NAO_ATO`,
               END OF segment_values.

    CHECK is_profit_center-profitcenterforedit+09(01) CA `012`.

    DATA(segment) = SWITCH fb_segment( is_profit_center-profitcenterforedit+09(01) WHEN `0` THEN segment_values-geral
                                                                                   WHEN `1` THEN segment_values-ato
                                                                                   WHEN `2` THEN segment_values-nao_ato ).

    IF is_profit_center-segment <> segment.
      INSERT VALUE #( msgid = `ZFIN`
                      msgty = `E`
                      msgno = 001
                      msgv1 = segment ) INTO TABLE ct_messages.
    ENDIF.
  ENDMETHOD.

This validation logic was implemented within the BAdI execution method, ensuring that the business rule is enforced during the save process.

Result

When the validation is triggered, the system prevents saving and displays an error message to the user.

Fiori error message

Key Insight

The most critical part of this implementation was identifying the correct enhancement point.

Once the correct spot was found, the validation itself was straightforward.

This reinforces that, in many SAP extensibility scenarios, the main challenge is not writing the logic itself, but navigating the framework to identify where that logic should be implemented.

Final Thoughts

This scenario highlights that, in many cases, the real challenge is not the implementation itself, but understanding where and how to implement it within the SAP framework.

👉I would be interested to hear how others approach similar challenges.

Making Interface Methods Optional in ABAP: DEFAULT IGNORE vs DEFAULT FAIL

2026-07-09T20:20:51.302000+02:00

Introduction

If you've worked with OO ABAP for a while, you've probably hit this situation: you define an interface with a handful of methods, and suddenly every single class that implements it is forced to write a method body even for stuff that class doesn't care about. Multiply that across a dozen implementing classes and you end up with a pile of empty, do-nothing method stubs just to keep the compiler happy.

ABAP actually has a clean way around this, and it's one of those features that doesn't get talked about enough, the DEFAULT IGNORE and DEFAULT FAIL additions on interface method declarations. Once you know about them, you'll wonder how you lived without them.

Picture an interface for handling pricing logic. Something like:

INTERFACE zif_pricing. 
 METHODS check_pricing_needed. 
 METHODS run_calculation 
   DEFAULT IGNORE. 
 METHODS fetch_base_amount 
   RETURNING VALUE(rv_amount) TYPE p 
   DEFAULT FAIL. 
ENDINTERFACE.

Not every class that plugs into zif_pricing will need all three methods. Maybe check_pricing_needed is genuinely required everywhere, but run_calculation only matters for a subset of classes, and fetch_base_amount is something you want classes to be forced to think about if they ever try to use it.

Rather than making every implementer write empty stubs, you can tell ABAP what should happen at runtime if a method is left unimplemented. That's what these two additions do, they shift the "what if this isn't implemented" decision from compile-time enforcement to a runtime behavior you control.

DEFAULT IGNORE: silently do nothing

Tag a method with DEFAULT IGNORE and here's the deal: if a class skips implementing it, calling that method just... does nothing. No error, no dump, nothing. It behaves exactly as if someone had written an empty METHOD ... ENDMETHOD. block. Any returning parameter just comes back with its initial value, and the program keeps going like nothing happened.

This is great for the genuinely optional stuff things where "not implemented" and "nothing to do here" mean the same thing. Logging hooks, audit trail updates, optional enhancement points, extra notifications anywhere a no op is a perfectly acceptable outcome.

DEFAULT FAIL: blow up loudly instead

DEFAULT FAIL is the opposite philosophy. If the implementing class doesn't provide a body for that method, calling it raises a runtime exception, specifically CX_SY_DYN_CALL_ILLEGAL_METHOD. Leave that exception unhandled and you'll get a short dump (CALL_METHOD_NOT_IMPLEMENTED).

This sounds harsh until you think about why you'd want it. There's a real difference between "this method isn't relevant for this class" and "this class genuinely needs this logic but someone forgot to write it." DEFAULT FAIL exists for the second case it converts a silent gap in your business logic into something that screams at you the moment it's hit, instead of quietly limping along and producing wrong results downstream.

Tax calculations, price determination, approval logic, validation anything where skipping the logic isn't a valid outcome, just a bug waiting to be found is a good candidate for DEFAULT FAIL.

Walking through it

Define the interface with the optional methods marked accordingly:

INTERFACE zif_pricing.
  METHODS check_pricing_needed.
  METHODS run_calculation
    DEFAULT IGNORE.
  METHODS fetch_base_amount
    RETURNING VALUE(rv_amount) TYPE p
    DEFAULT FAIL.
ENDINTERFACE.

Implement it in a class, but only bother with the mandatory method:

CLASS zcl_pricing DEFINITION.
  PUBLIC SECTION.
    INTERFACES zif_pricing.
ENDCLASS.

CLASS zcl_pricing IMPLEMENTATION.
  METHOD zif_pricing~check_pricing_needed.
    " actual business logic goes here
  ENDMETHOD.
ENDCLASS.

Notice there's no METHOD zif_pricing~run_calculation or METHOD zif_pricing~fetch_base_amount anywhere in this class and that's completely fine. The compiler only insists on an implementation for methods that don't carry a DEFAULT addition.

Call the IGNORE method and watch nothing bad happen:

DATA(lo_pricing) = NEW zcl_pricing( ).
lo_pricing->zif_pricing~run_calculation( ).

Since this one was never implemented but is marked DEFAULT IGNORE, the call just passes through quietly same as calling an empty method.

Call the FAIL method and you'll get an exception:

DATA(lv_amount) = lo_pricing->zif_pricing~fetch_base_amount( ).

Because fetch_base_amount is DEFAULT FAIL and was never implemented, this line throws CX_SY_DYN_CALL_ILLEGAL_METHOD. Leave it unhandled and the program dumps.

Handle it properly instead of letting it dump:

TRY.
    DATA(lv_amount) = lo_pricing->zif_pricing~fetch_base_amount( ).
  CATCH cx_sy_dyn_call_illegal_method INTO DATA(lx_err).
    MESSAGE lx_err->get_text( ) TYPE 'I'.
ENDTRY.

Wrapping the call in a TRY/CATCH lets you turn that hard failure into a controlled message instead of a dump in production.

Why bother with DEFAULT FAIL at all — isn't IGNORE always safer?

It feels safer on the surface, but that's actually the trap. Say you've got:

METHODS send_notification DEFAULT IGNORE.

If a class forgets to implement this, calling send_notification( ) just silently does nothing. No email goes out, no alert fires and the calling code has no idea anything went wrong. That's the kind of bug that sits undetected for months because everything looks fine from the outside.

Mark it DEFAULT FAIL instead, and a forgotten implementation gets caught the first time it's actually exercised, not three releases later when someone's wondering why customers never got their notification emails.

Rule of thumb for picking one

Go with IGNORE when "not implemented" and "nothing happens" are an acceptable, sensible default logging, auditing, optional enrichment, extension hooks.

Go with FAIL when skipping the logic would produce incorrect or incomplete business behavior pricing, tax, approvals, workflow triggers, validations. Anywhere being wrong silently is worse than crashing loudly.

A few things to keep in mind

These additions only apply inside interface declarations you can't slap DEFAULT IGNORE or DEFAULT FAIL on a regular class method.
Constructors and test methods can't be made optional this way.
Both work fine whether the method is instance bound or static.
They're also usable in BAdI interface definitions, which is honestly where I think they shine the most BAdIs love having a long list of methods where only a couple are relevant to any given implementation.

Bottom line

DEFAULT IGNORE and DEFAULT FAIL give you a way to design genuinely flexible interfaces without sacrificing safety. Instead of forcing every implementer to write boilerplate empty methods, you decide upfront, right in the interface definition, what "not implemented" should mean for each method a harmless no op, or a loud, catchable failure. Used well, it keeps your interfaces lean and your bugs visible instead of buried.

SAP Developer News, July 9th, 2026

2026-07-09T21:00:00.015000+02:00

ITEMS

Live from WeAreDevelopers

- WeAreDevelopers World Congress https://www.wearedevelopers.com/world-congress

CAP June 2026 release (cds 10)

- Release notes https://cap.cloud.sap/docs/releases/2026/jun26

ABAP Cleaner in VS Code!

- https://marketplace.visualstudio.com/items?itemName=SAPOSS.abap-cleaner

Live streams at Code Connect next week

- Code Connect https://code-connect.dev/
- UI5con https://openui5.org/ui5con/
- UI5con agenda https://openui5.org/ui5con/program.html
- UI5con 2026 Live from the Main Stage https://www.youtube.com/live/CMPudw4scSE
- reCAP https://recap-conf.dev/
- reCAP agenda https://recap-conf.dev/program.html
- reCAP Live from the Main Stage https://broadcast.sap.com/go/reCAP
- reCAP 2026 - Streaming Sidetrack https://teams.microsoft.com/meet/347149883889697?p=ZkR4erzGjpPRtZ6zJh

Additional CAP highlights and MCP Gateway

- Building MCP Servers with SAP Integration Suite: What to Design, Not Just How to Connect https://community.sap.com/t5/technology-blog-posts-by-sap/building-mcp-servers-with-sap-integration-suite-what-to-design-not-just-how/ba-p/14435261
- Design APIs and MCP servers https://help.sap.com/docs/integration-suite/isuite-integrations-and-apis/design-apis?locale=en-US
- Release calendar for SAP Integration Suite https://me.sap.com/notes/3418154

Did You Know? #25 cds add test

- The cds add command https://cap.cloud.sap/docs/tools/cds-cli#cds-add

CHAPTER TITLES

00:00 Intro
00:07 Live from WeAreDevelopers
02:16 CAP June 2026 release (cds 10)
13:14 ABAP Cleaner in VS Code!
14:37 Live streams at Code Connect next week
15:05 Additional CAP highlights and MCP Gateway
17:20 DYK #25 cds add test

TRANSCRIPT

[Intro]
This is the Developer News for July 9th 2026.

[Tom, Sheena, Shilpa, Witalij]
Hi, we're coming to you this week from WeAreDevelopers conference in Berlin, which is a little bit of a difference for us developer advocates because we're actually mostly attending a conference instead of delivering one. So it's our opportunity to connect with other developers, particularly non-SAP developers from all around the world. I'm giving a session on Friday with Michael Ameling, where I'll be doing a preview of the new developers.sap.com that's all AI-powered - we'll show you more of in the coming weeks. What are the rest of you looking forward to?

Yeah we just now attended one session on Microsoft Fabric, it was really exciting, and we also got to know the latest advanced technologies that we can look forward to. So it was really exciting to be part of that session. The line was a little too long to get into the session.

That is the challenging part, to get into the sessions, but for me the interesting part is AI and agents because, it is not a surprise, but to be outside of the SAP ecosystem is what I'm interested in too, and get to learn more of what's happening outside of SAP.

So have you tried to find any sessions without AI or agents in the name?

No, all agents. I think that was the qualifier, probably. OK, and for me it's actually not the first time I'm attending this conference. I was here in 2019 and it is really good to be back here. This time SAP has a big presence here, we are actually one of the sponsors, we have our place on the show floor, we have our sessions as Thomas mentioned, he's going to do one with Michael Ameling but as well we have some other SAP colleagues delivering sessions based on the experience from their work, working with UI for example, and with user experience in this exciting AI era. So all in all, "no coffee, no code" but unfortunately the line for coffee is the longest one here, so if you don't see me coding this week, that's just because I cannot stand in this line and get my coffee.

[DJ]
cds 10 is out! That is, the next major release of the SAP Cloud Application Programming Model, also known as cds 10, was published last week.

This particular major release marks many milestones and is packed full of goodness.

Within the limitations of these news items, I can only give a brief overview, and you should definitely head over to the release notes which are very readable and full of details.

Some of the features and highlights are marked as Alpha or Beta ... so please pay attention to these status badges when working through the content.

Now, like other releases, the notes for this release are organised into different categories. There's the main major release upgrade category of course, a set of important highlights, notes on changes and improvements for both the Node.js and Java runtimes, and some updates for multitenancy services as well.

So, let's start with the very essence of this major release - the upgrade and migration context, and what tht implies.

Each of the packages that make up the entire framework have had major release version upgrades.
As the release notes say, don't mix old and new major versions. Instead, embrace change and try out the new cds upgrade tool which can help you.

The runtime support is also changing, with both Node.js and Java.

And before leaving this upgrade context, I must highlight the facilities that the CAP team have put together for this essential part of the software lifecycle - upgrades and migration. There's a new Migration Guide to help you get to cds 10 ... and a bleeding edge new 'cds upgrade' facility, in Alpha, to help with upgrades.

So next, let's have a look at some of the highlights, of which there are many in this release. Some of them are either in Alpha or Beta status, but they're there!

Let me enumerate them briefly. There's now support for aggregate data in hierarchies, useful for product catalogs, org charts, bills of materials and similar scenarios. It's available right now with the Java runtime, and support for Node.js is coming soon.

For VS Code users there's a new Project Explorer to help you visually navigate through your project and model's structures.

Now, while this has been hinted at before this advent of cds 10, there's a new protocol which I'm going to describe as "CAP native", and that's now available, and it's called HCQL - CQL conveyed over HTTP. Well suited for CAP-to-CAP integrations, and available just by adding an @hcql annotation, in the true CAP tradition of magic-made-simple.

There are early AI related goodies too, in the form of CAP-level (Calesi-style) agents, and also a CAP skills library, because, as we know, focusing on intent and best practice in development is essential.

There's a new Data Inspector, which comes in the form of a plugin and allows the controlled inspection of data in the entities exposed by your services.

Now, event queues in CAP have also been given lots of love, in the form of a new scheduling API, improved processing, and an overhaul of the documentation.

Now, last December we saw the first public Beta of the 'cds export' command which we can use to create API client packages from CDS service definitions. With this cds 10 release, that command is now generally available.

Now there are some more highlights in this cds 10 release, but my good friend and colleague Antonio is going to cover those in another news item in this news episode, so stay tuned!

Let me now turn to the Node.js runtime context where there are also plenty of items for us to celebrate.

First up, consolidated service APIs. What does that mean? Well, the generic CRUD (Create Read Update Delete) handler now returns the same shape of data for all write operations. That means app, db and HCQL-proxied remote services all look and behave the same way, which is great for uniform and minimised handler code variations.

Now, AI agents are great, but one thing they don't know much about is Fiori draft data. So working with active data has been simplified and consolidated - making it easier for everyone, us humans and our AI overlords, to work in a draft-first context.

A massive piece of work that the team has undertaken over the last months, culminating in what we have with cds 10, is a significant move towards a greater embrace of modern tools and native libraries. Very briefly - the testing framework Vitest is now used in favour of Jest, which will be abandoned longer term. ECMAScript Modules (that's ESM to you and me) is the official standardised system for packages and reuse, and CAP is now embracing that as the default module system. Third party dependencies are being dropped in favour of native or built-in alternatives. For example this calendar year already has seen a move to a Node-native SQLite driver (which replaces better-sqlite3) and to the Node-native Fetch API (which replaces Axios, and in development scenarios, also removes the need for the SAP Cloud SDK).

This work to embrace modern techniques, native libraries and the newest stable standards is fantastic. An important "side effect" is also something we can celebrate - a significantly reduced set of dependencies (and thus a smaller install footprint and code surface area).

Now last but certainly not least in the Node.js category is some news on the Telemetry plugin, which is now at version 2 after a major update which also brings support for OpenTelemetry SDK 2.0.

Next, let's look at the Java runtime category, which has now reached major version 5. Lots of new features, including, importantly, support for Spring Boot 4.

There are some new minimum versions of major dependencies that you need to take care of.

With CAP Java 5 there are some changes that are not backwards compatible (as in any major release), but the migration is made easier for us with a specific migration guide and OpenRewrite recipes for automated code adjustments.

Now, there are changes to CDS property defaults to align them with recommended settings for production use.

The API methods that were deprecated in the previous major release and marked as 'forRemoval' ... have now been removed.

CAP Java 5 now defaults to JDK 25, which is a long-term-support version. The SapMachine 25 JDK with the SAP Java buildpack is recommended.

With this new major CAP Java release, search is harmonised with both CAP Node.js and RAP, and by default uses the SAP HANA search syntax (for which there is now full support). Fuzzy search is also now enabled by default on SAP HANA, with improved support for UUIDs and large strings, and available in hierarchy queries.

Now, there's also much faster typed data access available. Instead of using a dynamic proxy to handle the underlying data map for accessor interfaces, it's now possible to have implementation classes generated. This resulting in up to 10 times the performance.

Previously, CAP Java used Apache's Olingo library for OData support. Following Olingo's retirement last year, there's now built-in support for OData, that's no mean feat! That of course also means fewer dependencies and it also brings improved performance.

There's also support for creating active versions of draft-enabled entities, similar to what we learned about earlier in the Node.js runtime context.

There are also plenty more features that come with CAP Java 5. Check them out in the release notes.

But to round out the release notes overview for this cds 10 version, there are a couple of points of note in the context of MTX services. First, there's now a stricter annotation validation for extensions. And second, migration support to go from @SAP/cds-mtx to @SAP/cds-mtxs has been removed.

That pretty much wraps up things for this June 2026 major release, congratulations to the entire CAP team for a huge set of new features and improvements. And don't forget to check out Antonio's item in this news episode for those other highlights.

[Rich]
Hey friends, Rich Heilman here. I hope everyone is staying cool, staying out of the heat. Good news for ABAP developers this week. ABAP Cleaner is now available as a VS Code extension, bringing its powerful code formatting capabilities out of Eclipse and into the modern editor of choice for many developers. So, what does it do? ABAP Cleaner applies over 100 rules to your code with a single keyboard shortcut. Automatically cleaning up formatting, modernising syntax, and even flagging unused variables. The result is clean and consistent code across your entire team without anyone having to argue about style. You can run it as a quick one-shot format, or drop into interactive mode to choose exactly which rules apply to your codebase. If your team already has a configuration setup in Eclipse, you can import those rule variants directly. No need to start from scratch. The setup does a Java runtime and a bit of environment variable configuration, but once it's running, you get the same functionality that ABAP developers have relied on in ADT in Eclipse - now in a much lighter, faster editor. If you're doing ABAP development in VS Code, this one's worth installing. Check it out today.

[Ajay]
Hello everyone. Code Connect is next week, from 13th to 16th July 2026. For all of you who cannot join us in person, there are live streams available for UI5con and reCAP, from the main stage. Please check out the agenda and streaming links available for UI5con and reCAP and join us online during the Code Connect event. Links to the live streams and agendas will be available in the description.

[Antonio]
¡Hola, SAP Developers. As you already know, the June 2026 CAP release is huge. DJ has already shared many of the highlights and I just want to mention a couple more. There is a new AI plugin, in Alpha, which simplifies integration with SAP AI Core. It will automatically resolve service bindings, manage resource groups, and AI model deployments. And it provides a standard AI Core service to interact with AI Core programatically. The new Data Privacy plugin, in Beta, for Node.js, which provides out of the box integration with the SAP Data Privacy Integration Service. Based on the personal data and ILM annotations in the data model the plugin will automatically expose two endpoints that can be consumed by the service. Now, related to the integration space, CAP Node.js now supports the Event Mesh capability in SAP Integration Suite, as an alternative to the standalone SAP Event Mesh, meaning that you can now easily use it as an event broken in your CAP applications. There is the new MCP Protocol Adapter, which allows exposing existing CAP services to AI agents and LLM powered as just another protocol. Just install the plugin and annotate services with @McP, et voila, your CAP service exposes MCP functionality. Extremely powerful and easy to implement. I already used it in a CAP service that I'm developing while I was getting familiar with the new feature of SAP Integration Suite. Yes, what we've all been waiting for - the new MCP Gateway is now available as part of Integration Suite. It is part of the new Integration Cell Runtime which is a cloud native runtime purposely built for designing, deploying and operating APIs and MCP servers. It is GA now and being rolled out in the Enhanced and Premium editions of SAP Integration Suite. Not just that, but it is also available in the BTP Trial environment. What are yoiu waiting for? Go check it out. Hasta luego!

[Ajay]
Did you know that cds add does generate the best practices of the test implementation of your CAP service? One can rapidly create a sample CAP project with cds init bookshop --add sample. Run cds add test in the terminal to add test suite files for all the defined CAP services in your existing project. It creates the latest boilerplate files and structures required for you to get started with your test implementation in a jiffy. For each services it generates a sample test for the GET request for an entity and a test for any action defined in the service. This also adds the test dependencies to your project. It uses the Node test runner for the tests. Install your dependencies and just run npm t to execute your tests. The generated test implementation does need to be tweaked for the valid test data. CAP also provides a command npx cds test to mute the verbose server output and lets you focus only on the failing tests. Use -u to unmute the server output when you do not need them. Enjoy your CAP tests!

From SEGW to @OData.publish: Expose Your CDS View as OData in S/4HANA

2026-07-09T21:00:02.399000+02:00

Introduction:

This Blog2 is continuation of blog 1, refer below link:

Link to blog1

In Blog1, we created a CDS view using tables Sales Order Header (VBAK) and Sales Order Items (VBAP). Now, in this Blog, we will make this data available for outside world.

In S/4HANA, CDS views are not just used for reporting - they can also be exposed as OData service, which allows them to be consumed by external systems, SAP Fiori applications, API and integrations.

As an ABAP developer I have always used transaction code SEGW to manually create OData services. But now with CDS, this process is much simpler and faster.

Lets see how to expose CDS view as OData : Step by Step:

Step 1: Add OData Annotation

Open your CDS view and add anootation @odata.publish: true

Example below

@AbapCatalog.sqlViewName: 'ZSALEORDREP'
@AbapCatalog.compiler.compareFilter: true
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Creating my 1st CDS view'
@OData.publish: true

define view ZCDS_ORDVIEW
    as select from vbak as Header
  association [1..*] to vbap as Item
    on Header.vbeln = Item.vbeln
{
  key Header.vbeln as SalesOrder,
      Header.erdat as CreationDate,
      Header.netwr as NetAmount,
      Header.waerk as Currency,

      case Header.auart
        when '00' then 'Standard Order'
        else 'Other Order Type'
      end as OrderTypeDescription,

      Item
}

Step 2: Activate the CDS View

Press ctrl + F3 or icon activate to activate the CDS view. Once activated, SAP will generate the OData service with name <cdsviewname>_CDS.

In our example OData service name generated is ZCDS_ORDVIEW_CDS .

Step 3: Activate the Service in SAP Gateway

Even though the service is generated, it must be activated in gateway system. Login to your gateway system and follow below steps:

Go to transaction /n/IWFND/MAINT_SERVICE
Click Add Service
Enter system alias as: your system name
Search service: ZCDS_ORDVIEW_CDS .
Once its found, select the service and click button 'Add selected Services'.
Assign a package. In my case I used local package $TMP.

Step 4: Test the OData Service

To test the OData service, in gateway system run transaction code /n/IWFND/MAINT_SERVICE then it will list down all the services name under technical service name. Select your service ZCDS_ORDVIEW_CDS and click button SAP Client Gateway. This will open new screen SAP gateway client. Refer below screenshots:

$metadata shows full structure like Fields, types, associations

Example: Use the following URL to filter a specific sales order: /sap/opu/odata/sap/ZCDS_ORDVIEW_CDS/ZCDS_ORDVIEW?$filter=SalesOrder eq '00XXXXX178' Note: Ensure there are no spaces around the '=' in the $filter parameter.

/sap/opu/odata/sap/ZCDS_ORDVIEW_CDS/ZCDS_ORDVIEW/$count

You can also use different OData query options like Top 5 records: ...?$top=5, Sort data: ...?$orderby=CreationDate desc etc. These options help in optimizing data retrieval and are widely used in Fiori applications.

To test using URL, use below format. For testing I have used Postman :

https://<host>/sap/opu/odata/sap/ZCDS_ORDVIEW_CDS/ZCDS_ORDVIEW?$top=5

The OData service can also be tested outside of SAP using tools like: - Browser, Postman or Curl Example: https://<host>/sap/opu/odata/sap/ZCDS_ORDVIEW_CDS/ZCDS_ORDVIEW?$top=5

When you add @OData.publish: true:

SAP automatically creates an OData service
Associations become navigation properties
CDS fields are exposed as OData properties
No manual service modeling is required

This is why CDS is preferred in modern development.

Conclusion

Exposing CDS view as an OData service shows how simple and powerful modern ABAP development has become. With just a single annotation, you can turn your data model into a consumable service ready for applications, APIs, and integrations. What once required manual effort in SEGW can now be achieved in minutes using CDS. This not only improves productivity but also ensures consistency between your data model and service layer.

What’s Next?

In the next step, we’ll enhance this CDS view with UI annotations and generate a Fiori application without writing frontend code.

Let’s Discuss

Have you started exposing CDS views as OData services?

Are you still using SEGW in your projects?

Share your thoughts and experiences.

Building a Conversational AI Agent in S/4HANA — Without Leaving the ABAP Stack

2026-07-10T20:00:49.797000+02:00

An experiment with two things at once: the yaai open-source ABAP addon and SAP AI Core as the LLM provider. The goal was to see whether a non-coder could wire an LLM directly into SAP S/4HANA — no external APIs, no middleware, and no writing a single line of code.

How This Started

I had two things I wanted to experiment with:

yaai — an open-source ABAP addon by Christian Jianelli that lets you call LLMs from ABAP and register ABAP methods as tools a model can invoke. I wanted to understand what this actually meant in practice, not in theory.
SAP AI Core — SAP's managed LLM platform on BTP. I had access to a running deployment and wanted to see how it behaved as the backend for an ABAP-native agent.

For the business scenario, I needed something simple — not because the scenario mattered, but because I wanted the complexity to come from the integration, not the domain. Batch management in SAP S/4HANA was the first thing that came to mind: logistics personnel ask the same questions every day (What's the shelf life expiration date on this batch? Which batches are about to expire?), the answers are all in standard SAP S/4HANA, and the data model is well understood.

All the ABAP code was written using Claude for Coding inside Visual Studio Code. I described what I needed, reviewed what came back, tested it in the SAP system, and fed errors back in. I did not write a single line of code. All this in less than a day!! My contribution was knowing what I wanted, understanding SAP well enough to validate the results, and a great deal of cutting and pasting.

All source code is available at github.com/davidlincourt-eng/yaai-batch-agent

What yaai Actually Is

yaai is a set of ABAP classes that lets you:

Call LLM APIs (OpenAI, Anthropic, Google, Mistral, Ollama, and SAP AI Core) from ABAP
Register any ABAP instance method as a "tool" the model can invoke during a conversation
Maintain multi-turn conversation history
Use system instructions to give the model a persona and scope
Run agents with tool calling through a UI

It comes with a companion application, yaai_cockpit, which is a SAPUI5 app you deploy to your SAP S/4HANA system. It gives you a browser-based UI for configuring agents, registering tools, uploading prompt documents, and chatting with the agent — all without touching code.

Architecture in One Diagram

User (browser)
     │
     ▼
yaai_cockpit (SAPUI5, served from SAP S/4HANA)
     │  /sap/yaai/agent  (ICF REST)
     ▼
YCL_AAI_AGENT  ──► ZCL_YAAI_AICORE_CONN  ──► SAP AI Core (gpt-4.1)
     │                  (OAuth2 token)              │
     │                                    tool call │
     ▼                                              ▼
ZCL_YAAI_BATCH_TOOLS                      ZCL_YAAI_BATCH_TOOLS_PROXY
(reads MCH1, MARA, INOB, AUSP)            (STRING → typed ABAP params)

Everything runs inside the SAP S/4HANA work process. The LLM decides what to ask; ABAP fetches the answer from the database; the cockpit shows the conversation.

The Key Advantage: No Published APIs

In a conventional integration architecture, making SAP S/4HANA batch data available to an AI application means leveraging the S/4HANA primary standard API for the Batch Master Record (OData service API_BATCH_SRV). It allows external systems to synchronously read, create, and change batch data an OData or REST API.

With the yaai approach, the LLM calls ABAP methods directly, inside the same SAP S/4HANA system. In this case, there is a standard API... but it's not aways the case. That means there is no API to publish, no external endpoint to secure, and no data ever leaves the system boundary to reach the model uncontrolled. The LLM receives only what the tool method returns — a formatted string — not raw table data.

This removes an entire layer of integration and keeps the data access logic in the one place where it has always been: ABAP.

An Important Caveat: Security

This experiment does not implement authorisation checks. The ABAP tool methods (ZCL_YAAI_BATCH_TOOLS) read directly from the SAP S/4HANA database without verifying that the calling user has the appropriate roles or authorisations.

In a production scenario this is a significant gap. The tool classes should enforce the same authorisation checks that the equivalent SAP S/4HANA transactions enforce — using AUTHORITY-CHECK statements against the relevant authorisation objects (e.g. M_MSEG_WMB for batch display). Without this, any user who can access the cockpit chat can query any batch in any plant, regardless of their SAP role.

This is a proof of concept. Before deploying to a production or regulated SAP S/4HANA environment, authorisation checks must be added to every tool method.

What the Agent Can Answer

Once deployed, a user can ask questions in plain language:

User question Tool called What happens

"What is the SLED for batch 0000000045 of material TG22 in plant 1710?"	`GET_BATCH_HEADER`	Reads `MCH1` for `VFDAT`
"What classification characteristics does that batch have?"	`GET_BATCH_CLASSIFICATION`	Navigates `INOB → AUSP → CABN`
"Which batches of TG22 expire in the next 30 days?"	`FIND_EXPIRING_BATCHES`	Queries `MCH1` with date window
"List all expired batches for TG22 in plant 1710"	`FIND_EXPIRED_BATCHES`	Filters `MCH1` where `VFDAT < today`
"Can you book a meeting for me?"	—	Refused (system instructions scope it)

Building It: The Five Moving Parts

1. The Connection Layer — ZCL_YAAI_AICORE_CONN

SAP AI Core uses OAuth2 client credentials. Rather than storing a static API key, ZCL_YAAI_AICORE_CONN fetches a fresh Bearer token from XSUAA on every call and injects the required AI-Resource-Group header. The token is valid for ~12 hours; since it's fetched per-call, there is no manual key rotation.

Credentials are stored in TVARVC (transaction STVARV) — never hardcoded. See Step 0 of the Setup Guide for the exact entries required.

2. The Tool Classes — ZCL_YAAI_BATCH_TOOLS and its Proxy

The business logic reads from SAP S/4HANA tables:

" Read batch header — SLED lives in MCH1, not MCHA
SELECT SINGLE matnr, charg, vfdat, hsdat, lwedt
  FROM mch1
  INTO @DATA(ls_mch1)
  WHERE matnr = @i_matnr
    AND charg = @i_charg.

Note: VFDAT (shelf life expiration date) is stored in MCH1 (cross-plant batch table), not in MCHA (plant-level batch table). This is a common source of confusion — MCHA.VFDAT is always blank. Claude for Coding got this wrong on the first attempt and had to be corrected.

Because the LLM passes parameters as strings, a proxy class (ZCL_YAAI_BATCH_TOOLS_PROXY) handles type conversion before delegating to the real class. This is a yaai pattern that prevents runtime conversion dumps when the model sends "30" where ABAP expects TYPE i.

The full source code for both classes is in the repository: ZCL_YAAI_BATCH_TOOLS and ZCL_YAAI_BATCH_TOOLS_PROXY.

3. The Agent Persona — System Instructions and Tool Guide

Two markdown files uploaded to the cockpit define how the agent behaves:

System instructions — sets the persona ("SAP S/4HANA Batch Management Assistant"), defines scope, and enforces formatting rules (dates as DD.MM.YYYY, "not maintained" for blank characteristics)
Tool usage guide — tells the LLM exactly which tool to call for which type of question, with a decision tree and parameter examples

This is the prompt engineering layer. The better these documents are, the more reliably the agent picks the right tool for a given question.

The two documents are in the repository: system instructions and tool usage guide.

4. The Cockpit — Configuring the Agent

The yaai_cockpit provides a browser UI for wiring everything together: registering the LLM API endpoint, defining tools, uploading documents, and creating the agent — all without touching code.

The complete step-by-step cockpit configuration — LLM API setup, tool registration, document upload, and agent creation — is covered in Steps 3 through 7 of the Setup Guide.

5. The Conversation

With everything wired up, the agent is accessible via the cockpit's built-in chat panel or through any custom UI that calls the /sap/yaai/agent ICF endpoint on the SAP S/4HANA system. To see the conversation in action, the project repository includes the full setup guide of the agent responding to batch management questions.

Here is an example of a conversation in the Cockpit

What Had to Be Fixed Along the Way

Getting yaai to work with SAP AI Core required a few patches to the yaai framework classes. These were not in the original yaai documentation — they came out of debugging, and Claude for Coding was essential for working through them:

Issue Fix

AI Core returns 400 for Anthropic model deployments	Use a GPT deployment — SAP AI Core routes Anthropic and GPT through different API formats
`"We're having a little trouble..."` fallback from yaai	yaai defaults to the Responses API (`/v1/responses`); SAP AI Core only supports Chat Completions — add `use_completions( abap_true )`
Cockpit chat sends no response despite successful HTTP round-trip	`YCL_AAI_ASYNC_CHAT_OPENAI` uses a static connection with no OAuth2 token and no `AI-Resource-Group` header — replace with `ZCL_YAAI_AICORE_CONN`
STVARV uppercases credentials	Enable the Lowercase checkbox on each TVARVC entry — XSUAA credentials are case-sensitive
SLED always blank in responses	`MCHA.VFDAT` is empty; shelf life dates live in `MCH1`

Reflections on the Experiment

Two questions going in; two answers coming out.

Does yaai work? Yes. The tool calling pattern is solid, the cockpit makes agent configuration accessible without code, and the conversation history and system instructions work as advertised. The framework is genuinely usable.

Does SAP AI Core work as the backend? Yes, with caveats. It required patching two yaai framework classes and some non-obvious configuration (the use_completions flag, the AI-Resource-Group header, the OAuth2 token flow). None of these were documented anywhere — they came out of debugging. Once resolved, the integration was stable and the token refresh is fully automatic.

Does the "no coder" approach work? Also yes, with one important qualification. I wrote zero lines of ABAP. Every class, every method, every fix was generated by Claude for Coding in Visual Studio Code. My job was to:

Describe the SAP S/4HANA data model and what I wanted the agent to do
Paste the code into SE24 and SE38 and run the syntax check
Copy error messages back to Claude and iterate
Know enough about SAP to recognise when the output was wrong

That last point matters more than it sounds. The MCH1 vs MCHA issue — where shelf life dates are stored in the cross-plant batch table, not the plant-level one — was caught because I knew the data model well enough to question a blank SLED. Code generation quality was high enough that most errors were integration issues rather than logic errors. But you still need domain knowledge to validate the output.

The skill that mattered most was not coding. It was knowing SAP well enough to know what to ask for and whether the answer made sense.

What's Next

This experiment proves the pattern works. Natural extensions include:

Security hardening — AUTHORITY-CHECK in every tool method is the immediate priority before this goes anywhere near a real system.

More tools — The same pattern applies to stock quantities (MCHB), quality inspection lots (QALS), goods movements (MSEG), or any SAP S/4HANA data accessible from ABAP.

RAG integration — yaai supports Retrieval-Augmented Generation. Storage regulations, handling instructions, or compliance documents stored as markdown can be injected into the model context automatically.

Custom UI — The /sap/yaai/agent REST endpoint is available to any SAPUI5 or web application hosted on the SAP S/4HANA system. The cockpit chat is a reference implementation, not the only option.

Resources

yaai on GitHub — the open-source ABAP AI addon by Christian Jianelli
yaai_cockpit on GitHub — the management and chat UI
Full source code and setup guide — everything from this experiment, including certificates, ABAP classes, step-by-step instructions, and screenshots
SAP AI Core documentation — the BTP LLM platform used as the model provider

Thank You

A big thank you to Christian Jianelli for building yaai and yaai_cockpit and making them freely available. Christian also helped me directly with the initial setup of both libraries — without that support this experiment would have taken considerably longer to get off the ground. The yaai project is a genuine contribution to the ABAP community and I hope this post encourages others to experiment with it.

If you want to see where yaai is headed, Christian's latest blog post is a great read: yaai — ABAP AI Tools: Evolving Toward Agentic AI on the SAP Community.

Start remote Process/Actions in BTP ABAP via Task Chains from SAP Datasphere

2026-07-14T16:00:19.634000+02:00

Modern cloud architectures allow for versatile and open interoperability. So does SAP Datasphere and SAP BTP ABAP, too. This example outlines some essentials how Datasphere can kick-off actions defined on the ABAP Cloud side, beyond system boundaries.

Starting a Task/Process in BTP ABAP remotely from SAP Datasphere using Task Chains opens up new scenarios for interoperability and integration. The goal is to orchestrate remote tasks initiated by SAP Datasphere — securely, programmatically, and fully automated.

We will cover the below points:

Creating a Task Chain in Datasphere including an API Call to ABAP Cloud
Connection in Datasphere to ABAP Cloud (for direct API call)
Setting up Communication System & Arrangement in ABAP Cloud
Executing the Task Chain in Datasphere: Trigger actions in ABAP Cloud

1 Architecture Overview

Architecture

The SAP Datasphere Task Chain API Task: Datasphere acts as the caller. ABAP Cloud exposes an endpoint (inbound Web Api) to trigger an action.

Option (2) and (3) complete the picture of possible solution approaches. Main differences as well as pros & cons are outlined further down in one of the last sections.

The Solution Architecture displays 3 different options:

(1) Use Direct API Integration

Straightforward
Minimal cost and complexity
Perfect for nightly batch orchestration, event-driven data loads, or simple API-driven analytical data refresh

(2) Integration Suite

Integration involves complex message transformations, protocol mediation, multiple target systems, or when centralized API governance and monitoring across the enterprise are required.
Especially appropriate where iFlow reusability justifies the additional cost and setup effort or when integration suite is already in place and a common tool.

(3) CAP Application

Custom application logic is needed beyond what a direct API call/iFlow can provide
E.g. multi-source data aggregation, advanced parsing, enrichments
Additional persistence required
Well-suited for reusable microservice-style integrations on BTP

2 Prerequisites

You need

SAP Datasphere tenant with developer + admin access
Task Chain to design the flow of events
SAP BTP ABAP Environment (ABAP Cloud) with developer access
BTP ABAP: Authorization for OAuth clients, Communication Arrangements, ABAP development of Web APIs

3 Creating Communication Artifacts in ABAP Cloud

Navigation: ABAP Environment Web Access → Communication Management → Communication Systems/Arrangements

Communication Arrangement

Communication System

Communication System 1

Communication/Connection User:

Create a User for Inbound Communication and use the same in the subsequent step on Datasphere level for the creation of a generic HTTP connection.

4 ABAP Cloud Artifacts

For the sake of simplicity I won't go into the details of all of the development artifacts and configuration settings.

For sure, you will create:

Inbound Service
Service Binding
Communication Scenario BTP ABAP
Service Definition
Entity
Class implementation

An example of an action definition processData (ZI_DEMO_SERVICE):

managed implementation in class zbp_i_demo_service unique;

define behavior for ZI_DEMO_SERVICE alias DemoService
persistent table zdemoservice
lock master
{
  field ( readonly ) Id;
  field ( numbering : managed ) Id;

  create;
  update;
  delete;

  action processData result [1] zdemoservice;

  mapping for zdemoservice
  {
    Id = id;
    Name = name;
    Description = description;
    Status = status;
    CreatedBy = created_by;
    CreatedAt = created_at;
    LastChangedBy = last_changed_by;
    LastChangedAt = last_changed_at;
    LocalLastChanged = local_last_changed;
  }
}

An example of an ABAP Class with an action implementation:

CLASS lhc_DemoService DEFINITION INHERITING FROM cl_abap_behavior_handler.
  PUBLIC SECTION.
 
    PRIVATE SECTION.
 
    METHODS processData FOR MODIFY
      IMPORTING keys FOR ACTION DemoService~processData result result.
 
ENDCLASS.
 
CLASS lhc_DemoService IMPLEMENTATION.
  
  METHOD processData.
    " Your business logic implementation her
  ENDMETHOD.
ENDCLASS.

Service Definition:

@EndUserText.label: 'Demo Service Definition'
define service ZUI_DEMO_SERVICE {
  expose ZC_DEMO_SERVICE as DemoService;
}

Inbound Service:

Communication Scenario:

5 Create a Connection

The first step is creating a generic HTTP connection to the endpoint exposed by ABAP Cloud. In order to do so, consider the following details. Take the connection host from the BTP ABAP instance key. The credentials must be taken from the connection user as defined in the communication arrangement.

An alternative to Username/Password is an OAuth based authentication mechanism.

6 Creating a Task Chain in SAP Datasphere

The first step is defining a Task Chain that encapsulates the processing logic you want to execute .

In the given example:

The Task Chain starts with a API Task
Sends an email in case of success

Task Chain

In the API Task details, define the following:

Method POST
API Path - the path to the service endpoint of your ABAP Web API that you want to trigger
Mode Synchronous

API Task Details 1

Make sure to fetch the CSRF Token. The URL which I've used is simply the $metadata path of the service endpoint:

https://<ABAP_HOST>.abap.eu10.hana.ondemand.com/sap/opu/odata/sap/ZUI_DEMO_SERVICE_O4/$metadata

7 Execution Results

The Task Chain in Datasphere successfully executed the ABAP Web API call:

Task Chain API successfully executed

For monitoring and troubleshooting purpose, individual API calls can be traced from BTP ABAP side. The HTTP trace can be turned on for granular levels.

8 Solution Options - Comparisons

The following comparison outlines the key aspects per solution/architecture option as depicted in the initial architecture diagram. I have prototyped all of the below and all options are working flawlessly. Especially w.r.t. to the CAP based solution, there is a wide open room to play with.

Option	Pros (+)	Cons (-)
(1) Direct API	Simplest setup & fewest components & lowest cost No middleware latency Lightweight and developer-friendly	Limited transformation capability Less suitable for multi-step or conditional routing logic
(2) Integration Suite	Supports complex transformations, multiple protocols and error handling in iFlows Centralized API governance via API Management Recommended for complex mediated flows	Two-step connectivity required (Integration Suite + Datasphere) Additional licensing cost Higher setup and maintenance effort
(3) CAP CF App	Maximum flexibility for custom logic (parsing, filtering, enrichment, retry) CAP integrates natively with HANA Cloud/Datasphere HDI Supports secure credential management Reusable microservice pattern	Requires application development and BTP CF deployment skills Higher operational overhead More BTP resource consumption CAP app lifecycle must be managed independently

9 Conclusion/Outlook & Further aspects:

Overview of the major building blocks:

Capability	Result
No hardcoded secrets	via Communication Arrangements/System
Remote orchestration	Creating an end-to-end orchestrated chain of tasks, bidirectional if required
Cloud-native ABAP	Using appropriate ABAP Class APIs
Datasphere automation	Using Task Chain API

Use Cases that the implementation enables:

Nightly batch orchestration
Event-driven data loads
Cross-system workflows (this was our ultimate focus)
API-driven (transactional/analytical) data refresh

Limitations:

The Task Chain/API Task can't be parameterized dynamically with runtime parameters to e.g. initiate calls that have a variable payload in header or body
Moreover, the write-back/storing of HTTP responses is limited too

References:

SAP Datasphere Task Chain API Documentation: https://api.sap.com/api/DatasphereTasks/overview
SAP Datasphere Task Chain Help Page: https://help.sap.com/docs/SAP_DATASPHERE/c8a54ee704e94e15926551293243fd1d/274f2736465c4c48a091c67588...

This blog entry complements my other blog on Triggering SAP Datasphere/BDC Task Chains from SAP BTP ABAP Cloud using the Task Chain REST API.

In case of questions feel free to raise them and please leave a comment if you found something incorrect - thanks for any help on that. I'm hoping this blog can support somebody out there and may facilitate some problem solving.

Clean Core Levels A–D: how to classify your custom ABAP — and what to do with each grade

2026-07-15T04:47:46.379000+02:00

Disclosure: I'm the author of this post and the creator of Clean-Core.io, a free, non-commercial community tool I mention once near the end. This post is educational; the tool is optional.

Overview

With the 2025 update to the ABAP extensibility guide, SAP evolved the familiar 3-tier extensibility model into the clean core level concept — a four-grade classification of custom extensions: A, B, C, D. Instead of a blunt "clean vs. not clean", it tells you how closely each extension aligns with Clean Core, and it maps directly to ABAP Test Cockpit (ATC) behaviour:

Level Usage of SAP objects in custom development ATC behaviour

A	Released SAP APIs (local & remote) and extension points	No message
B	Classic SAP APIs and extension points (SAP-recommended)	Priority 3 · info
C	Internal SAP APIs (conditionally clean via the changelog-for-SAP-objects check)	Priority 2 · warning
D	Not-recommended objects & extension technologies (modifications, implicit enhancements)	Priority 1 · error

Level A is the cleanest — on-stack ABAP Cloud or side-by-side on SAP BTP. Levels B–D describe classic ABAP, from SAP-recommended (B) down to not-recommended (D).

Why this matters now

Every custom object you carry into S/4HANA has to be defensible. The move from a binary "clean/not clean" to A–D is a gift — it lets you transform at your own pace, prioritising the worst first instead of trying to reach "100% clean" overnight.

The real problem

Knowing the model is easy. Grading thousands of custom objects against it is not. ATC flags readiness object-by-object, and the Cloudification Repository tells you which standard objects are released — but turning that into a per-object A/B/C/D verdict plus a remediation path, across a grown Z-landscape, is still mostly manual and inconsistent between teams.

A practical classification flow

Identify the custom object and what it touches (tables, APIs, function modules, enhancements).
Look up each dependency: released API/extension point → A; classic-but-official API → B; internal SAP object → C; modification / not-recommended access → D.
Decide remediation per grade: A keep · B keep, plan to lift later · C verify via the changelog-for-SAP-objects approach and wrap behind a released interface · D replace before the upgrade.

A worked example

A classic Z_CUSTOMER_REPORT:

SELECT kunnr, name1 FROM kna1 INTO TABLE @lt_cust.   " direct read of an internal standard table

Classify: direct access to KNA1 (an internal SAP object, not a released API) → Level C (ATC: warning). A direct write would be Level D (ATC: error).

Remediate: map to the released CDS view I_Customer → the same logic becomes Level A (ATC: no message):

SELECT Customer, CustomerName FROM I_Customer INTO TABLE @lt_cust.

One dependency, one grade, one clear next step. Repeat across the landscape and you get a prioritised backlog: fix D first (upgrade blockers), lift C, schedule B, keep A.

How I approached tooling this (optional)

To avoid doing this by hand, I built Clean-Core.io — a free, non-commercial community tool. It runs a deterministic evidence engine first (parsing the code, mapping dependencies against the catalog), then AI on top, and derives an A–D grade per detected object — aligned to the clean core level concept and its ATC priorities. It is complementary to ATC/ADT, not a replacement, and every output is a draft for a qualified architect to review. Free: clean-core.io (link in the comments).

Conclusion

The move from 3-tier to A–D isn't a relabel — it's a better mental model for prioritising custom-code remediation. Give each dependency an explicit grade, start with your Level D objects, and turn "we have a lot of Z-code" into a defensible, upgrade-ready plan.

How are you classifying your custom code against the new A–D levels today — by hand, ATC, or something else? I'd genuinely like to compare approaches in the comments.

The SAP Fiscal Calendar, End to End: How It Gets Populated, How Data Loads in BW, and Where the ABAP

2026-07-15T11:53:20.719000+02:00

Every FI posting, every CO report and every BW query leans on the fiscal period — yet very few of us ever stop to trace where that period actually comes from and how it travels through the landscape. There is no "fiscal calendar load" job anywhere. So how does the fiscal calendar get populated, how does it function through every data load, and where does ABAP actually run in all of this? The short answer: it is born as configuration in ECC, derived onto every document at posting time, physically copied into BW as global settings, stamped onto every record BW extracts — and for the time characteristics themselves, served virtually by ABAP classes with no master data load at all. Let's walk through each stage.

Stage 1 — It starts as configuration, not data (OB29)

Fiscal calendars in ECC are controlled by the Fiscal Year Variant, configured via transaction OB29 and used across FI, CO and MM. Nobody uploads fiscal calendar data — the moment a variant is defined and its periods maintained in OB29, the system populates a small family of Customizing tables behind the scenes:

Table	Purpose
T009	Fiscal year variant (header) — variant ID, number of posting periods, year-dependent flag, calendar year flag
T009B	Period dates per fiscal year variant — start/end date for each posting period (and special periods)
T009C	Assignment of company code shortened fiscal year (used when a fiscal year is shortened, e.g., mid-year go-live)
T009T	Fiscal year variant texts (descriptions)
T009Y	Fiscal year variant — year-dependent version (if the calendar-year-dependent flag is set, periods can differ by year)

Two variants you will meet on almost every project: K4 (calendar year — 12 posting periods plus 4 special periods, where period 001 = January) and V3 (April to March — the standard variant for India and several other countries, where period 001 = April). K4 barely needs T009B at all because periods equal calendar months; V3 is where the real mechanics of the table come into play.

The year shift — the small entry that makes non-calendar fiscal years work

For a variant like V3, each month entry in T009B carries not only a period number but also a year shift (annual displacement) of -1, 0 or +1. This is the entry that tells the system which fiscal year a calendar month belongs to. Under V3, April through December carry shift 0 — a posting on 15.05.2026 lands in period 002 of fiscal year 2026. But January through March carry shift -1 — a posting on 15.01.2027 lands in period 010 of fiscal year 2026, because it still belongs to the fiscal year that started in April 2026. This one column is the entire secret behind non-calendar fiscal years, and it is exactly what downstream systems consume rather than recalculate.

One neighbouring concept worth separating out: the fiscal calendar is not the factory calendar (table TFACS, maintained via SCAL). The factory calendar defines working days and holidays for logistics and scheduling; the fiscal calendar defines posting periods for accounting. Both travel to BW as global settings, but they answer completely different questions.

Stage 2 — How the calendar reaches documents (assignment and derivation)

Configuration alone doesn't put a fiscal period on anything. The variant first has to be assigned, and then the period is derived at posting time.

Table / Field	Context
T001-PERIV	Company code's assigned fiscal year variant
CSKS / CEPC etc.	Controlling objects inherit the fiscal year variant from the company code
BKPF-MONAT / GJAHR	Posting period and fiscal year on FI documents, derived using T009B logic

The derivation itself is simple: given a posting date plus the fiscal year variant, the system looks up T009B (applying the year shift) to determine which period the date falls into — periods 1 to 12, plus special periods 13 to 16 for adjustments and audit. This is done via standard function modules such as FIRST_DAY_IN_PERIOD_GET, LAST_DAY_IN_PERIOD_GET and DATE_TO_PERIOD_CONVERT. The result (MONAT, GJAHR) is stamped onto the document. Special periods are never derived from a date — periods 13 to 16 are entered manually by the user during year-end closing, which is why a posting date in March can sit in period 013.

In other words, the fiscal period on a document is not stored calendar data — it is computed once at posting time from the T009B rules and then persisted on the document itself. This detail is exactly what makes the BW side behave the way it does.

Stage 3 — How the fiscal calendar physically reaches BW: Transfer Global Settings

Here is the part most people miss. BW does not query ECC's T009 tables remotely — it holds its own local copy of them. When a source system is connected, the administrator runs Transfer Global Settings (in RSA1, right-click the source system). This function copies the source system's global Customizing — fiscal year variants (T009/T009B), currencies (TCUR*), units of measure (T006*) and factory calendars — into identically structured tables inside the BW system itself.

So the fiscal calendar is populated in BW not through a DataSource or an InfoProvider, but as replicated Customizing sitting quietly in BW's own T009/T009B. BW never uses these tables as reporting data — it uses them as the rulebook for time conversion and for query runtime logic, which we'll see below. This is also why the transfer has to be repeated whenever the variant configuration changes in the source: BW's copy does not update itself.

Stage 4 — How the data load actually works in BW

With the rulebook in place, let's follow a transaction record end to end and see where fiscal time gets attached.

Step 1: Extraction — the data arrives already stamped

Business Content extractors in FI/CO (for example the General Ledger line-item extractors) read the documents where MONAT and GJAHR were already stamped at posting time. So the DataSource delivers fields like FISCVARNT and FISCPER pre-populated by ECC — the extractor is simply forwarding the result of the T009B derivation that happened when the document was posted. Nothing fiscal is computed during extraction.

Step 2: Staging and transformation — the classic load path

The record then follows the standard BW flow: DataSource → InfoPackage into the PSA → Transformation → DTP → target (DSO/ADSO or InfoCube). The transformation is where the source fields are mapped to the Time InfoObjects — FISCVARNT to 0FISCVARNT, FISCPER to 0FISCPER, the posting date to 0CALDAY, and so on.

Step 3: Automatic time conversion — where BW's local T009B earns its keep

Time characteristics enjoy a special privilege in BW transformations: automatic time conversion and derivation. If the source supplies only a date (0CALDAY) plus the fiscal year variant, BW can derive 0FISCPER, 0FISCPER3 and 0FISCYEAR automatically — and it performs that derivation using its local copy of T009B, transferred in Stage 3. The same mechanism derives 0CALMONTH, 0CALQUARTER and 0CALYEAR from 0CALDAY. This is precisely why a stale Transfer Global Settings shows up as wrong fiscal periods in BW: the derivation is only as correct as the local rulebook.

Step 4: Storage — where fiscal time finally lives in BW

Once loaded, the values settle into BW's own structures. In InfoCubes, each cube's time dimension table stores 0FISCPER, 0CALDAY and friends as dimension values, linked through SID tables; in DSOs/ADSOs they are simply fields on the record. If fiscal period hierarchies are built, they are stored like any hierarchy (e.g., /BI0/HFISCPER). From this point on, fiscal period is just another characteristic value — with one defined mapping into calendar dates, used mainly for display, sorting and hierarchy purposes.

InfoObject	Purpose
0FISCVARNT	Fiscal year variant (carried over from ECC's T009)
0FISCPER	Fiscal year/period combined (e.g., "2026001")
0FISCPER3	Fiscal period alone (3-char, e.g., "001")
0FISCYEAR	Fiscal year alone
0CALDAY	Calendar day
0CALMONTH	Calendar month (YYYYMM)
0CALWEEK	Calendar week
0CALQUARTER	Calendar quarter
0CALYEAR	Calendar year

Two modelling details worth knowing here. First, 0FISCPER is compounded to 0FISCVARNT — a period value like "001" is meaningless on its own, because period 001 is January under K4 but April under V3. The compounding forces every fiscal period value to carry its variant, which is why 0FISCVARNT must always be present (mapped or set as a constant) whenever 0FISCPER is filled in a transformation. Second, 0FISCPER is stored internally in the format YYYYPPP (e.g., 2026001) but displayed in external format (e.g., 001.2026) — a detail that regularly surprises people writing routines or filters against the raw value.

Where does ABAP actually run during a BW load?

A common mental model is "BW has classes, and data loads from those ABAP classes." The reality is more precise, and worth getting right: the load is driven by BW objects — DataSources, InfoPackages, Transformations, DTPs — and ABAP classes are the machinery that BW generates or ships to execute some of them. The classes are the engine room, not the source of the data.

On the extraction side, the code is mostly function modules, not classes: Business Content extractors run extraction function modules through the Service API (SAPI), and generic extractors built in RSO2 are based on a table/view, an InfoSet or a function module.

On the transformation side, classes genuinely appear — but they are generated by the system. When a transformation is activated, BW generates an ABAP program containing a local class, and every routine you write — start routine, end routine, field routine, expert routine — becomes a method of that generated class, working on parameters like SOURCE_PACKAGE and RESULT_PACKAGE. You write the method body; BW generates and owns the class around it. The DTP then executes this generated program at load time. Underneath all of it, the DTP framework, request handling and ADSO activation are implemented in SAP standard classes (the CL_RS* family) — framework code you never touch.

And a note for newer stacks: in BW/4HANA, a transformation without ABAP routines can be HANA-optimized — pushed down and executed entirely inside HANA as a calculation scenario, with no ABAP class running during the load at all. This is exactly why avoiding ABAP routines is a standard performance recommendation in that generation.

Why time characteristics have no master data load — virtual master data read classes

Open 0FISCYEAR in InfoObject maintenance and look at the Master data/texts tab, and you'll find the most elegant piece of this whole story. The setting Master Data Access is not "Default" — it is "Own Implementation", pointing to a master data read class: CL_RSMD_RS_0FISCYEAR.

"Default" would mean the InfoObject has physical master data tables (/BI0/P*, /BI0/T*) filled by data loads. "Own Implementation" means the opposite: the InfoObject has no stored master data at all. Whenever anyone needs its values — a query run, an F4 value help, a text display — the system calls this class at runtime and the values are generated on the fly. There is no DTP, no PSA, and no master data table filling up with a row for every year that has ever existed.

Why did SAP design it this way? Because fiscal years and periods are rule-based, not data-based. The set of valid fiscal years is trivially derivable, and fiscal periods are fully determined by the T009/T009B rules that BW already holds locally via Transfer Global Settings. Loading them as master data would mean materializing an infinite, rule-generated list. So SAP ships the time characteristics — 0FISCYEAR, 0FISCPER, 0CALDAY, 0CALMONTH and friends, each with its own CL_RSMD_RS_* class — with virtual master data access instead. The calendar was never data to begin with, and here that principle is implemented literally in code.

The distinction to keep sharp: transaction data still loads exactly as described in Stage 4 — the value "2026" arrives stamped on every record. It is only the master data of the time characteristics (the list of valid values, their texts, their ordering) that is never loaded, because the read class serves it virtually. Compare this with 0MATERIAL or 0CUSTOMER, whose master data is genuinely business-defined and must be loaded from the source via attribute and text DataSources. Time characteristics are the special case where SAP replaced the load with a class.

Stage 5 — What happens at query runtime

The local T009B copy and the read classes come together at query runtime. The OLAP engine consults them whenever fiscal logic is needed: deriving the current fiscal period from today's date for a variable, calculating period offsets (previous period, same period last year), building year-to-date ranges, serving F4 value helps for fiscal years and periods, and sorting periods correctly — including keeping special periods 013–016 in their proper place after period 012. None of this would work if BW treated 0FISCPER as a plain text value; it works because BW knows, from its replicated T009B and its time-characteristic read classes, how periods relate to dates and to each other.

The distinction that matters: source of truth vs consumer

Putting the stages together, the population story becomes very clear. ECC is the single source of truth: the fiscal calendar is populated there once, as Customizing in OB29, and applied millions of times, as period derivation on every posting. BW's fiscal calendar is populated twice over — once as replicated Customizing via Transfer Global Settings (the rulebook), and continuously as already-stamped values on every extracted record (the data). Its time characteristics need no master data load at all, because their read classes generate values from the rules. At no point does BW independently recalculate what ECC decided.

This has a practical consequence: if the variant configuration changes in ECC — a new period arrangement, a shortened fiscal year via T009C, a newly maintained year for a year-dependent variant — BW does not pick it up on its own. The global settings must be re-transferred, and only records loaded afterwards reflect the new rules. So when fiscal periods in BW look wrong, check in this order: was the period maintained in OB29 for the new year, were global settings re-transferred, and is the transformation mapping or deriving the time characteristics as expected. It is almost always one of these three — not a calculation error in BW.

Aspect	ECC	BW
Master config table	T009 (variant), T009B (period dates), maintained via OB29	Local replicated copy of T009/T009B via Transfer Global Settings — used for derivation, never for reporting
Characteristic / field	PERIV, MONAT, GJAHR	0FISCVARNT, 0FISCPER, 0FISCYEAR
Master data load	Not applicable — configuration, not data	None for time characteristics — served virtually by CL_RSMD_RS_* read classes ("Own Implementation")
Role	Source of truth — derives the period at posting time	Consumer — stores fiscal period as a reporting characteristic and derives only via the replicated rulebook
Special periods	Periods 13–16 (adjustment periods) supported in T009B, entered manually at closing	0FISCPER supports adjustment periods as additional period values, sorted after period 012

A note on newer stacks

In newer generations — BW/4HANA, or embedded analytics on S/4HANA — the same fiscal calendar is exposed through CDS views such as I_FiscalYearVariant and I_FiscalYearPeriod, rather than through the raw pool tables. The underlying logic is still the familiar T009-based configuration; only the access layer has been modernized.

Wrapping up

So the next time someone asks "where does the fiscal period actually come from, and how does it work in BW?", the answer fits in a few lines: it is born as Customizing in OB29 (T009/T009B, with the year shift doing the heavy lifting for non-calendar years), derived onto every document at posting time, copied into BW as global settings, delivered pre-stamped on every extracted record, re-derived in transformations only when needed — always against BW's local rulebook — and served virtually at query runtime by master data read classes that generate fiscal values from rules instead of loading them. There is no fiscal calendar "load" because the calendar was never data to begin with — it is configuration that every downstream layer consumes, and in BW that principle goes so deep that even the master data is a class, not a table.

If you found this useful, I'd be glad to hear how fiscal year variants are handled in your landscape — especially anyone dealing with year-dependent variants or shortened fiscal years, where the population story gets more interesting.

Ensuring Quality in BADI Implementations with ABAP Unit

2026-07-16T11:16:13.843000+02:00

Introduction

In a previous article, I described how to identify and implement the BADI FIN_PROFIT_CENTER_VALIDATION to enforce business rules during Profit Center maintenance.

However, implementing a solution is only part of the job. Once the enhancement is in production, new requirements, bug fixes, and refactoring activities can easily introduce regressions if the validation logic is not properly tested.

This is where ABAP Unit becomes essential. By creating automated tests for enhancement implementations, we can verify business rules consistently and gain confidence when evolving the solution over time.

In this article, I will share a practical example of how I tested a BADI implementation using ABAP Unit based on a real-world validation scenario.

Why Testing a BAdI Matters

BADI implementations often contain critical business logic. In many projects, this logic evolves gradually as new requirements are added. Without automated tests, every change introduces a risk of unexpected side effects.

The validation implemented in FIN_PROFIT_CENTER_VALIDATION ensures that the Segment value remains consistent with the last digit of the Profit Center. Whenever this rule is violated, an error message must be generated and the maintenance process must be blocked.

The business rule is relatively simple:

Last Digit	Expected Segment
0	GERAL
1	ATO
2	NAO_ATO

Although the rule itself is straightforward, it is a perfect candidate for automated testing because it contains clearly defined inputs and expected outcomes.

Test Class Design

Before creating individual test cases, I structured the test class to maximize readability and reduce duplication. The objective was to make each test focus only on the business rule being verified.

The class uses standard setup and teardown methods to create and release the class under test. This guarantees that each test executes in isolation and avoids side effects from previous executions.

METHOD setup.
  CREATE OBJECT me->f_cut.
ENDMETHOD.

METHOD teardown.
  FREE me->f_cut.
  REFRESH me->messages.
ENDMETHOD.

The BADI method expects a FIN_ENH_PROFIT_CENTER structure as input and returns validation messages through the CT_MESSAGES parameter. Since several test cases share the same execution flow, I introduced a helper method named ASSERT_NO_VALIDATION_ERROR.

This helper method prepares test data, executes the BADI, handles unexpected runtime exceptions, and verifies that no validation message was raised.

METHOD assert_no_validation_error.
    " Given
    DATA(profit_center_data) = VALUE fin_enh_profit_center( validityenddate	               = `19000101`
                                                            controllingareaforedit         = `SI01`
                                                            profitcenterforedit	           = profitcenter
                                                            validityenddateforedit         = `99991231`
                                                            validitystartdate	             = `20260623`
                                                            profitcentername               = `Z999999999`
                                                            profitctrresponsiblepersonname = `DFARCIC`
                                                            profitcentercreationdate       = `20260623`
                                                            profitcentercreatedbyuser	     = `DFARCIC`
                                                            profitcenterstandardhierarchy	 = `0101`
                                                            segment                        = segment ).

    " When
    TRY.
        me->f_cut->if_badi_fin_pc_validation~execute( EXPORTING is_profit_center = profit_center_data
                                                      CHANGING  ct_messages      = me->messages ).
      CATCH cx_ble_runtime_error INTO DATA(lx_error).
        cl_abap_unit_assert=>fail( msg = lx_error->get_text( ) ).
    ENDTRY.

    " Then
    cl_abap_unit_assert=>assert_initial( act = me->messages ).
  ENDMETHOD.

Using a helper method significantly reduced code duplication and allowed the individual test methods to remain concise and focused on their specific scenario.

Implementing the Test Scenario

To validate the implementation comprehensively, I created tests covering three different categories of behavior.

The first category verifies situations where the last digit of the Profit Center is not one of the supported values (0, 1, or 2). In these cases, the validation should simply be ignored.

METHOD ignore_when_last_digit_not_012.
  ...
ENDMETHOD.

The second category focuses on invalid combinations. In the following example, the Profit Center ends with 0, which means the expected Segment should be GERAL. Since the supplied value is ATO, the validation must generate an error message.

METHOD error_when_last_digit_is_0.
    " Given
    DATA(profit_center_data) = VALUE fin_enh_profit_center( validityenddate	               = `19000101`
                                                            controllingareaforedit         = `SI01`
                                                            profitcenterforedit	           = `Z999999990`
                                                            validityenddateforedit         = `99991231`
                                                            validitystartdate	             = `20260623`
                                                            profitcentername               = `Z999999999`
                                                            profitctrresponsiblepersonname = `DFARCIC`
                                                            profitcentercreationdate       = `20260623`
                                                            profitcentercreatedbyuser	     = `DFARCIC`
                                                            profitcenterstandardhierarchy	 = `0101`
                                                            segment                        = `ATO` ).

    " When
    TRY.
        me->f_cut->if_badi_fin_pc_validation~execute( EXPORTING is_profit_center = profit_center_data
                                                      CHANGING  ct_messages      = me->messages ).
      CATCH cx_ble_runtime_error INTO DATA(lx_error).
        cl_abap_unit_assert=>fail( msg = lx_error->get_text( ) ).
    ENDTRY.

    " Then
    DATA(expected_messages) = VALUE fin_enh_pc_message_t( ( msgid = `ZFIN`
                                                            msgty = `E`
                                                            msgno = 001
                                                            msgv1 = `GERAL` ) ).

    cl_abap_unit_assert=>assert_equals( act = me->messages          " Data object with current value
                                        exp = expected_messages ).  " Data object with expected type
  ENDMETHOD.

Finally, positive test cases verify that valid combinations do not generate any validation messages.

METHOD validate_when_last_digit_is_1.

  me->assert_no_validation_error(
    profitcenter = 'Z999999991'
    segment      = 'ATO' ).

ENDMETHOD.

METHOD validate_when_last_digit_is_2.

  me->assert_no_validation_error(
    profitcenter = 'Z999999992'
    segment      = 'NAO_ATO' ).

ENDMETHOD.

Lessons Learned and Clean ABAP Considerations

One interesting aspect of this exercise is how testability influenced the overall design of the solution. The need to create clear and maintainable tests encouraged the use of small methods, descriptive names, and reusable helper methods.

The resulting test class follows several Clean ABAP principles:

Small and focused test methods
Meaningful and descriptive names
Helper methods to eliminate duplication
Explicit use of me-> for clarity
Minimal shared state between tests

Another takeaway is that even relatively small BADI implementations benefit from automated testing. The effort required to create the tests was modest, while the long-term benefits in maintainability and confidence are substantial.

Final Thoughts

Implementing a BAdI is only the first step. Ensuring that the implementation remains reliable over time is equally important.

ABAP Unit provided a simple and effective way to validate the business rules implemented in FIN_PROFIT_CENTER_VALIDATION while making future changes much safer.

If you are developing custom validations through enhancement spots or BAdIs, I strongly recommend investing a little extra time in automated tests—it pays off quickly.

👉I would be interested to hear how other teams are testing their BAdI implementations and validation frameworks.

RAP Augmentation in Managed Scenario – Enriching Transactional Requests Before BO Processing

2026-07-17T11:22:43.643000+02:00

Introduction

The RESTful Application Programming Model (RAP) provides several extension points for implementing business logic, such as Determinations, Validations, Actions, and Prechecks. RAP Augmentation adds another extension point that allows developers to enrich incoming create or update requests before the framework starts processing the business object.

This early execution makes augmentation useful for scenarios where default values, audit information, or business-specific data must be available before any further RAP processing takes place. In this blog, we will understand RAP Augmentation, compare it with Determinations, and implement it using an Employee Management example.

Business Requirement

I had a requirement an Employee Management application where users create and maintain employee records. During record creation, the application should automatically populate business-specific information instead of relying on users to enter every value manually.

The application should:

Set the employee status to PENDING_APPROVAL.
Determine whether approval is required based on the selected department.
Capture the current user as the creator.
Maintain audit information during updates.

Instead of implementing all this logic inside the business object, we will use RAP Augmentation to enrich the incoming request before standard processing begins.

Problem Statement

Determinations are commonly used in RAP to derive or update field values. However, they execute after the request has already entered the transactional buffer.

In some business scenarios, values must be available even before the business object starts processing. For example, default values or audit fields may be required before validations or other business logic execute. In such cases, Augmentation provides a cleaner and more suitable solution by enriching the request at the beginning of the transaction.

What is RAP Augmentation?

RAP Augmentation is an extension mechanism that runs during the Interactive Phase of a RAP transaction. It allows developers to enrich incoming create or update requests before the framework processes the business object.

Rather than modifying persisted data, augmentation focuses on preparing the request by supplying additional values or applying business-specific logic. Once the request is enriched, RAP continues with its normal processing flow.

Augmentation Flow

The request passes through augmentation before reaching the business object implementation. During this stage, additional values can be added or modified, ensuring the business object receives a complete request for further processing.

The overall execution flow is:

User sends a create or update request.
RAP invokes the registered augmentation.
The request is enriched with additional data.
Standard RAP processing continues.
Data is persisted to the database.

Augmentation vs Determination

Defined at the Projection Behavior Definition using use create/update (augment).	Defined at the Interface Behavior Definition using determination.
Implemented in a Projection Behavior Implementation Class	Implemented in the Behavior Pool class.
Runs during the Interactive Phase, before the BO implementation processes the request.	Runs during ON MODIFY or ON SAVE, after data enters the transactional buffer.
Used to enrich or modify the incoming request before BO processing.	Used to derive or recalculate values based on data in the transactional buffer.

When Execution timing matter?

The main advantage of Augmentation is when it executes. Since it runs before business object processing, any values added during augmentation are available to the rest of the RAP processing flow.

If the application should automatically set an employee's status or determine whether approval is required, these values are already present when the framework performs subsequent processing. If the same logic were implemented in a Determination, the values would only be available later in the transaction.

When to Use Augmentation?

Augmentation is a good choice when the incoming request needs to be enriched before RAP starts processing the business object.

Typical use cases include:

Setting default values.
Populating audit fields.
Deriving values from user input.
Performing lightweight request enrichment.
Preparing data required by later processing steps.

It is not intended to replace Determinations, which remain the preferred option for business logic that should execute after the request has entered the transactional buffer.

BDEF of Interface

managed implementation in class zbp_aky_i_emp unique;
strict ( 2 );

define behavior for zaky_i_emp //alias <alias_name>
persistent table zaky_t_emp

lock master

authorization master ( instance )
//etag master <field_name>
{
  create( authorization : global ) ;
  update;
  delete;
  action Approve result [1] $self;
  mapping for zaky_t_emp
{
  Employeeid        = employeeid;
  Firstname         = firstname;
  Lastname          = lastname;
  Department        = department;
  Status            = status;
  Approvalrequired  = approvalrequired;
  Createdby         = createdby;
  Createdat         = createdat;
  Lastchangedby     = lastchangedby;
  Lastchangedat     = lastchangedat;
  }
}

BDEF of Projection

projection implementation in class zbp_aky_c_emp unique;
strict ( 2 );

define behavior for zaky_c_emp //alias <alias_name>
{
  use create( augment );
  use update( augment );
    use delete;
  field ( readonly ) Status;
  field ( readonly ) Approvalrequired;
  field ( readonly ) Createdby;
  field ( readonly ) Createdat;
  field ( readonly ) Lastchangedby;
  field ( readonly ) Lastchangedat;
  use action Approve;
}

BP of Projection

CLASS lhc_zaky_c_emp DEFINITION INHERITING FROM cl_abap_behavior_handler.
  PRIVATE SECTION.

    METHODS augment_create FOR MODIFY
      IMPORTING entities FOR CREATE zaky_c_emp.

    METHODS augment_update FOR MODIFY
      IMPORTING entities FOR UPDATE zaky_c_emp.

ENDCLASS.

CLASS lhc_zaky_c_emp IMPLEMENTATION.
  METHOD augment_create.
  LOOP AT entities INTO DATA(entity).

    IF entity-Department IS INITIAL.
      APPEND VALUE #(
        %cid = entity-%cid
        %msg = new_message_with_text(
                 severity = if_abap_behv_message=>severity-error
                 text     = 'Department is mandatory' ) )
      TO reported-zaky_c_emp.        

      APPEND VALUE #( %cid = entity-%cid )
      TO failed-zaky_c_emp.          
      CONTINUE.
    ENDIF.

    MODIFY AUGMENTING ENTITIES OF zaky_i_emp  
      ENTITY zaky_i_emp
      CREATE FIELDS ( Status Approvalrequired Createdby Createdat )
      WITH VALUE #( (
        %cid             = entity-%cid
        Status           = 'PENDING_APPROVAL'
        Approvalrequired = COND #(
                             WHEN entity-Department = 'HR'
                               OR entity-Department = 'FIN'
                             THEN abap_true
                             ELSE abap_false )
        Createdby        = sy-uname
        Createdat        = cl_abap_context_info=>get_system_date(  )
      ) ).

  ENDLOOP.
ENDMETHOD.

METHOD augment_update.
  LOOP AT entities INTO DATA(entity).

    MODIFY AUGMENTING ENTITIES OF zaky_i_emp   
      ENTITY zaky_i_emp
      UPDATE FIELDS ( Lastchangedby Lastchangedat )
      WITH VALUE #( (
        Employeeid    = entity-Employeeid
        Lastchangedby = sy-uname
        Lastchangedat = cl_abap_context_info=>get_system_date(  )
      ) ).

  ENDLOOP.
ENDMETHOD.
ENDCLASS.

BP of interface

METHOD Approve.

  " Read current status of the employee
  READ ENTITIES OF zaky_i_emp IN LOCAL MODE
    ENTITY zaky_i_emp
    FIELDS ( Status Employeeid )
    WITH CORRESPONDING #( keys )
    RESULT DATA(employees)
    FAILED DATA(read_failed).

  " Loop and update status
  LOOP AT employees INTO DATA(employee).

    " Only approve if current status is PENDING_APPROVAL
    IF employee-Status <> 'PENDING_APPROVAL'.
      APPEND VALUE #(
        %tky = employee-%tky
        %msg = new_message_with_text(
                 severity = if_abap_behv_message=>severity-error
                 text     = 'Only records with PENDING_APPROVAL status can be approved' ) )
      TO reported-zaky_i_emp.
      APPEND VALUE #( %tky = employee-%tky )
      TO failed-zaky_i_emp.
      CONTINUE.
    ENDIF.

    " Update status to APPROVED
    MODIFY ENTITIES OF zaky_i_emp IN LOCAL MODE
      ENTITY zaky_i_emp
      UPDATE FIELDS ( Status )
      WITH VALUE #( (
        %tky   = employee-%tky
        Status = 'APPROVED'
      ) )
      FAILED   DATA(update_failed)
      REPORTED DATA(update_reported).

    " Pass back result
    APPEND VALUE #(
      %tky   = employee-%tky
      %param = employee
    ) TO result.

  ENDLOOP.
ENDMETHOD.

Output

Click on the create

After adding the value click on the create and put the debugger on the create-augment method to check it is triggering or not because we are doing managed application where creation is handled by framework

Execute

Currently it is in pending state click on the Approve employee.

After clicking on action

If you not adding the department

Conclusion

RAP Augmentation provides a simple and effective way to enrich transactional requests before the RAP framework begins processing the business object. It is particularly useful for populating default values, maintaining audit information, and preparing request data that should be available throughout the transaction.

In this example, we used augmentation to automatically populate employee details while keeping the business object implementation clean and maintainable. Understanding when to use Augmentation instead of Determinations helps developers choose the right extension point and build more maintainable RAP applications

The paging catastrophe

2026-07-20T05:50:04.703000+02:00

Introduction

In the late 19th century, the scientific community started to face unexpected issues, some of them quite serious, upon proven experiments for which no accepted formula was able to produce reasonable prediction or explanation. This originated the entire collapse of the current physics, now called ‘classic physics’, into a new frame ignited by the quantum mechanics. The game-changing problem was named ‘the ultraviolet catastrophe’.

Similarly to what happened back then –hopefully less ontologically problematic–, the SAP transition from classic to Fiori-oriented development brings about some anomalies not especially easy to overcome without a systemic revolution of the technology itself. One of the problems we have experienced regards the paging mechanism when rendering a Fiori list report via back-end OData service.

Context

Let’s assume the following scenario:

On-premise OData service.
BTP Fiori list report application consuming the back-end service via custom entity.
1. Respecting the Clean Core principles, the report combines information from the back-end –only read–, and local BTP tables. To ensure integrity, the key fields are the same on both sides.
2. Consequently, the selection filters can refer to both back-end and BTP fields.
The BTP application, fields and tables underneath dominate the entire execution engine. This is to say, BTP-located filtering, if any, must lead the back-end selection.

Case 1: No BTP pre-filtering or post-filtering

Scenario

No BTP-located filter fields are set, so there is no need to implement BTP filtering before or after the service call. In real executions, this is not very likely to happen, but anyway interesting to start exposing the problem.

Behaviour

All pages are correctly delivered through scrolling. Considering n items are hit in the back-end, when reaching the last page, all of them are rendered.

Case 2: BTP post-filtering

Scenario

Here, BTP-located filter fields are set. The idea is to retrieve matching information from the back-end and, next, filter by the BTP conditions.

Behaviour

If the page is not reduced during the post filtering, i.e., no line is impacted by the BTP filtering, then it is correctly shown and the scroll for the next one continues to be enabled.

Else, if the page size is reduced, the system considers it is the last so no more scrolling is enabled; even trying to scroll down no more service calls are run. The page cropping leads then to missing information.

Case 3: BTP pre-filtering

Scenario

If the post-filtering does not work, why not first filter in BTP and then use the key fields to retrieve from the back-end only exactly what is needed?

Behaviour

Here, x items are pre-filtered in BTP. If, additionally, back-end filtering is set, the final number of retrieved items, say n, can potentially be less than x.

Anyway, the strategy seems finely focused but the problem arises when too many items are pre-filtered so the URL to call the service is too long to be accepted and leads to an exception.

Case 4: Split BTP pre-filtering

Scenario

Considering some trust was put in the previous step, maybe we could split the filtering and manually call the service in small packages to avoid problems with the URL.

Behaviour

To avoid the cropped page problem, the main purpose is to always build complete pages to keep the execution alive; otherwise, it stops. The challenge is to seamlessly advance through packages as if no additional calls were executed.

In BTP, x items are filtered and supposed to be sent to the back-end. The URL length is first checked:

If it is short enough to be accepted, then no split is needed and the call can be executed as conventionally.
In other case, the logic will split the x items into small packages of s; the package size must be greater than the page size so as to avoid the scroll disabling.

For the first call, the s items hit n back-end items, so the report counter shows n as the total number of items, but this value is not correct, as there are more items waiting to be sent.

By scrolling down, the complete list of n items related to the first package is delivered correctly, so for now no need to process other packages.

If the current page size is less than the determined size, i.e., if the page is cropped, this means we have reached the end of the package, so the next one can be processed.

The next package is then processed making sure the skip is reset to retrieve all back-end hits from the beginning. The cropped page is then completed with p - q items from the new package.

For next page the skip is automatically set to the page size and because there is no option to keep track of the actual index we are in –stateless processing–, a gap of missing information can occur.

Conclusions

The development of BTP reports via custom entities where local filtering is supposed to restrain the information coming from the back-end introduces a series of problems not easy to overcome. Business may claim classic development where all the data and logic was set on-premise did not carry this type of problems.

As it happened to physics, the transition to modern SAP development presents by comparison some obstacles for which quick adaptation is needed. The answer to this problem, something like quantum mechanics in our recurrent reference, goes through using a more powerful technology; for the time being, external entities based on HANA virtual tables are the best alternative to avoid the paging catastrophe.

SAP Note Creation Process for Customer Incident

2026-07-21T12:15:39.081000+02:00

Introduction :-
When customer raises a production-related incident in the ServiceNow tool, they provide issue details, scenario snapshots, and system information to help debug the reported issue. Based on this input after resolving the issue and testing in Internal systems. I followed a defined process to create the corresponding SAP Note and release note either tailored to the specific customer or applicable to all customers.

The process covers:

Creating the Request and associated Task

Releasing the Transport Request (TR)

Adding Corrective Instructions (Support Pack references)

Creating and structuring the SAP Note

Pilot Release and General Release process

What is I7P?

I7P is SAP’s internal support and knowledge management system that serves as the central repository for SAP Notes. It is used by SAP teams to create, maintain, and track solutions for product issues before they are published to customer-facing support channels. As the backend source of SAP Notes, I7P helps ensure accurate technical knowledge, fixes, and support documentation are delivered to customers and also I7P system help to create Transport Request , Notes and to add support Pack based on customer system version.

Transport Request and Task

Transport Request is the main container that holds all development changes. It is created whenever changes are made to repository objects such as programs, classes, and tables.

Task is a child object under a Transport Request.

Must be released first before releasing the parent request.

Tasks cannot be transported independently.

Steps to Create ABAP Corrective Measures

Step 1: Open ABAP Corr. Measures

Step 2: Provide the Required Details

Fill in the required fields — Application Component, Short Text, Priority, and Software Component — and select the SAP Note radio button.

Step 3: Select Components and Systems

Select the components and systems where the changes are needed, then click Continue with System Selection.

Step 4: Choose the Transport Request Type

Select the type of Transport Request required based on the object changes — Workbench or Customizing.

The correction request is then created, as shown below:

Note: All Transport Requests and their associated tasks can be reviewed in transactions SE09 and SE10. Once all changes have been locked in the Transport Request, open transaction SE09, enter the user name, and click Display. Select the task and run a Consistency Check. If any errors are found, the task cannot be released until they are resolved. After a successful consistency check, click the Transport icon, as shown below.

Step 5: Retrofitting

Retrofit is a synchronization process used to copy changes made in a production or maintenance system into a parallel project or development system.

Go to transaction SCWB, enter the user ID (the request should be under the name of the person performing the retrofit), and click Execute.

Double-click the request whose changes need to be distributed to other systems, then select the request and click the Distribute icon, as shown below. All object changes are transported to the respective systems, and the system releases the tasks.

The system displays a success message confirming that the changes were distributed successfully.

Step 6 : Test Transport

Test Transport is the process of importing development changes from the DEV system into QAS for testing and validation prior to production deployment.

Right-click the request for the relevant system, select Process Item, then Generate Test Transport.

Press Enter, and a success message will appear.

Step 7 : Creating Correction Instructions and Adding the Support Package

A pop-up screen will appear — click Enter.

The correction request is created as shown below. Repeat this step for all the systems.

Double-click the created correction instruction to review the changes made to the object, add the dependent SAP Note, and add the Support Package.

Double-click the object name to view the code changes (inserted and deleted blocks).

Click Validity to add the Support Package (SP) — select n+1, where n represents 12 months

Select the block and press Enter.

Check and Release the Correction Instruction.

Note: Correction instructions must be created for all the systems.

Step 8 : Creating the SAP Note

Double-click the created SAP Note and provide the symptom, solution, and objects changed for the issue. Add attachments if needed, and mention the relevant components in the SAP Note header.

Pilot Release – A customer number is added to the SAP Note so that the changes apply only to the designated customer and do not impact others.

General Release – The changes implemented through the SAP Note become applicable to all customers.

Step 9 : Final Step

After completing all development activities, SAP Note creation, correction instruction creation, and testing across various scenarios, the changes are thoroughly validated. Once all validations are successful, the SAP Note and correction request are assigned to the senior consultants for final review and release.

Conclusion

By reading this blog,one will have a knowledge on Transport Request, Task, Retrofitting, Transporting changes from Development system to Quality system, Steps to create SAP Note, Release note.
Once the release note is issued, the customer can apply the note via SNOTE transaction and the reported issue will be resolved.

Thank you for reading!!

Open-Source ABAP Utility to Search Text Symbols (Text Elements) Using READ TEXTPOOL

2026-07-21T13:15:55.012000+02:00

Introduction

During a maintenance activity, I needed to locate a company name across several custom ABAP programs. Running the standard report **RPR_ABAP_SOURCE_SCAN** successfully found occurrences in the ABAP source code, but it did not return matches maintained as **Program Text Elements (Text Symbols)**.

The reason is that program Text Elements are stored in the program's text pool and are accessed using the ABAP statement **READ TEXTPOOL**, rather than being part of the ABAP source itself.

To solve this, I developed a small open-source utility that searches text pools across multiple ABAP programs and displays the matching entries using the SALV framework.

## Why RPR_ABAP_SOURCE_SCAN Was Not Enough

The standard report **RPR_ABAP_SOURCE_SCAN** is useful for searching ABAP source code. However, it does not search **Program Text Elements (Text Symbols)** because these texts are maintained in the program's text pool rather than in the source code.

During a maintenance activity, I needed to locate a company name maintained as a Program Text Element (Text Symbol).Since the standard report did not return these occurrences, I needed another approach to search the text pool directly.

To address this limitation, I developed a utility that reads the text pool of each selected program, searches for matching text entries, and displays the results using SALV.

Implementation

To address this limitation, I developed a lightweight utility that reads the text pool of each selected ABAP program, searches for matching text entries, and displays the results using SALV.

The implementation consists of the following steps:

Retrieve the selected ABAP programs from the repository.
Read the text pool of each program using READ TEXTPOOL.
Search the retrieved text entries for the specified text.
Display the matching results using SALV.

Step 1: Retrieve the Selected Programs

The first step is to retrieve the selected ABAP programs from the repository based on the user input provided on the selection screen.

SELECT pgmid,
object,
obj_name
FROM tadir
INTO TABLE @MT_programs
WHERE pgmid = 'R3TR'
AND obj_name IN @SO_prog.

The utility reads the selected repository objects from the TADIR table. Each program is then processed individually to search its Program Text Elements.

Step 2: Read the Program Text Pool

For each selected program, the utility uses the READ TEXTPOOL statement to retrieve the program's Text Elements for the selected language.

LOOP AT mt_programs INTO DATA(ls_program).

CLEAR mt_textpool.

READ TEXTPOOL ls_program-obj_name
LANGUAGE so_lang-low
INTO mt_textpool
STATE 'A'.

ENDLOOP.

READ TEXTPOOL retrieves the text pool for the current program. The selected language (so_lang-low) determines which language version is loaded into the internal table mt_textpool. These entries are then processed in the next step.

Step 3: Search for Matching Text

After reading the text pool, the utility loops through the retrieved entries and searches for the text entered on the selection screen. A partial text search is performed using the CS (Contains String) operator.

LOOP AT mt_textpool INTO DATA(ls_textpool)
WHERE id = 'I'
AND entry CS so_text-low.

APPEND VALUE ty_result(
program = ls_program-obj_name
key = ls_textpool-key
text = ls_textpool-entry )
TO mt_result.

ENDLOOP.

The CS operator performs a substring search, allowing partial matches instead of requiring an exact text match. Whenever a matching entry is found, the program name, text key, and text are added to the result table for later display.

Step 4: Display the Search Results

After all matching text entries have been collected, the results are displayed using the SAP List Viewer (SALV), providing a simple and interactive ALV report with standard features such as sorting, filtering, and exporting.

cl_salv_table=>factory(
IMPORTING
r_salv_table = DATA(lo_alv)
CHANGING
t_table = mt_result ).

lo_alv->get_functions( )->set_all( abap_true ).
lo_alv->display( ).

The result table is passed to the SALV factory method to create the ALV output. Standard SALV functions are enabled before displaying the results.

Selection Screen

Sample Output

SOURCE CODE

The complete source code is available on GitHub:

https://github.com/aravindhanchandran/abap-text-symbol-search

The repository includes the complete implementation and can be used as a reference or extended to meet additional search requirements.

Conclusion

The standard report `RPR_ABAP_SOURCE_SCAN` is effective for searching ABAP source code, but it does not search Program Text Elements maintained in a program's text pool. This utility complements the standard report by using `READ TEXTPOOL` to search Text Symbols across multiple ABAP programs.

I hope this utility is useful for developers performing impact analysis, maintenance activities, company renaming projects, or any task that requires searching Program Text Elements. If you know of a SAP standard alternative or have suggestions for improvements, I'd be happy to hear your feedback. Contributions and ideas are always welcome.

ABAP development tools for Visual Studio Code: Version 1.1 released

2026-07-21T13:53:34.813000+02:00

What happened since the last release?

Link to the extension.

First of all, thanks for the positive feedback regarding the 1.0.1 patch which added the much requested RFC + password support! Please keep providing feedback as it helps us to plan the next releases. A lot of users are asking us how they can provide feedback. We have recently added a new customer influence channel just for the VS Code extension. We recommend using that one.

Last month, ABAPConf 2026 took place in Mannheim. We want to highlight two talks:

Tobias Hofmann provided public feedback regarding the extension and compiled a nice to-do list. I can report that a lot of these to-do items are already part of our internal to-do list. The talk can be found here.
Anne Keller and I gave a talk on the overall ABAP IDE strategy. Of course, it touches the VS Code extension but also aims to provide a broader picture on how we want to support ABAP IDEs via a single technology stack in the future and shares some insights on how the ADT MCP server will evolve in the future. The talk can be found here.

What gets shipped with this release?

Usability improvements for system connection handling

After creating a new destination there was no visual feedback that the destination was created successfully. We added a notification pop-up with a button which directly adds it as a folder to your workspace.

We added a "Log on to Destination..." command. While it was possible to log on to a destination via a right-click menu in the explorer view there was no command available for it.

Now, you can easily log on to a destination using the keyboard via the new command.

A significant improvement of object type support

A lot of requested object types get enabled by this release. Here is the list of added object types:

Classic ABAP source code

Create and Manage Function Groups and Modules
Create and Manage ABAP Programs and Includes
Create and Manage Lock Objects

Data Dictionary

Create and Manage Database Tables
Create and Manage Structures
Create and Manage Type Groups

RESTful Application Programming Model

Creating Behavior Definition Extensions
Enabling more OData Binding Types in Service Binding
Create and Manage CDS Entity Buffers

New MCP tools

Unified diff tool for transports

The unified diff tool generates a git like diff for a given transport request. The tool enables token efficient analysis of the changes contained in a transport request. This enables AI agents to fulfill requests such as:

"Explain transport XYZ"
"Generate a description for transport XYZ documenting what got changed and why"
"How much impact does transport XYZ has on the system? How dangerous is this transport?"

Tools for ABAP Test Cockpit (ATC)

The ATC MCP tools give AI agents access to running the ATC checks for a given change. This enables AI agents to fulfill requests such as:

"Implement [XYZ]. Afterwards, run the ATC checks and fix the reported findings."
"Run ATC checks for object XYZ"

Additional UX improvements

We added a command which allows you to quickly open the SAP Help documentation.

From each occurrence of a CDS annotation in a CDS data definition or CDS metadata extension, you can now navigate to its CDS annotation definition. To navigate, press F3 on the relevant CDS annotation. This helps you to investigate and to understand the use of a CDS annotation.

For more information see the new "What's New" page.

Sidenote: first version of ABAP cleaner VS Code extension available

Lots of community members asked for ABAP cleaner support in VS Code. We are happy to announce that the first version of the ABAP cleaner extension is available, now!

What's next?

From now on, we will stop listing upcoming features directly in the release blogs. Instead we have cleaned up and refreshed our ABAP Cloud Roadmap page. The planned features are listed there.

Provide feedback and influence our product backlog!

We welcome your feedback! Feel free to use the comment section or create a customer influence request to let us know which features you are missing the most. Your input will help us prioritize the feature backlog for the next releases.