SAP Community - ABAP Development

Setup your BTP Trial account and ABAP environment

2025-06-19T14:56:53.611000+02:00

Hi Community,

Here are the steps to create your first BTP trial account and setup ABAP on cloud environment in eclipse.

1. Create an account on SAP.com. If you already have S-user id or sap account, you can re-use that. SAP Software Solutions | Business Applications and Technology

2. Create BTP trial account

Go to SAP BTP cockpit Instances and Subscriptions - trial < 5c30eb07trial < Trial Home - SAP BTP Cockpit

Choose US East(VA)-AWS region

Go to your Trial Account

Go to subaccounts

3. Create new instance and setup ABAP environment in BTP account

Subaccounts >> Instance and Subscriptions >> Create

Setup ABAP environment

Enter your BTP account e-mail id here

Create service key

Enter your e-mail id with which you created BTP account

4. Download/Install and setup eclipse

SAP Development Tools

Launch eclipse from downloaded folder

Install ADT plug in

In Eclipse, choose in the menu bar Help > Install New Software...
Enter the URL https://tools.hana.ondemand.com/latest
Press Enter to display the available features.
Select ABAP Development Tools and choose Next.
On the next wizard page, you get an overview of the features to be installed. Choose Next.
Confirm the license agreements and choose Finish to start the installation.

Connect eclipse with ABAP on Cloud

File >> New >> ABAP Cloud Project

Go to your BTP account and click on view Service key

Copy url from your service key and paste in ABAP Service Instance URL in eclipse

Click Finish

Your ABAP environment on cloud will be connected.

Thanks for visiting.

Please do like, share and comment.

Sangeeta Singh

Website

Medium

ABAP Development SAP Community

SAP HANA service for SAP BTP PostgreSQL on SAP BTP, hyperscaler option SAP HANA Enterprise Cloud

SAP Managed RAP based on Header and Item table

2025-06-22T01:34:51.835000+02:00

Steps:

1. Create Data Base table for PO Header.

@EndUserText.label : 'PO Header'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table zpo_header {

  key client : abap.clnt not null;
  key pono   : ebeln not null;
  pocompany  : bukrs;
  podate     : abap.dats;
  podesc     : abap.char(20);
  postatus   : abap.char(1);

}

2. Create PO Item Database table.

@EndUserText.label : 'PO Item'
@AbapCatalog.enhancement.category : #EXTENSIBLE_ANY
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table zpo_item {

  key client : abap.clnt not null;
  @AbapCatalog.foreignKey.screenCheck : false
  key pono   : ebeln not null
    with foreign key [1..*,1] zpo_header
      where client = zpo_item.client
        and pono = zpo_item.pono;
  key poitem : ebelp not null;
  @Semantics.quantity.unitOfMeasure : 'zpo_item.unit'
  quantity   : abap.quan(10,0);
  unit       : abap.unit(3);

}

3. Create Base CDS Header view.

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Base view for po'
@Metadata.ignorePropagatedAnnotations: true
@ObjectModel.usageType:{ 
serviceQuality: #X, 
sizeCategory: #S, 
dataClass: #MIXED 
} 

define root view entity z_po_header_base as select from zpo_header
{
    key pono as Pono,
    pocompany as Pocompany,
    podate as Podate,
    podesc as Podesc,
    postatus as Postatus
    
}

4. Create Base CDS item view.

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Base view for po item'
@Metadata.ignorePropagatedAnnotations: true
define root view entity z_po_item_base as select from zpo_item

{
    key pono as Pono,
    key poitem as Poitem,
    @Semantics.quantity.unitOfMeasure : 'Unit'
    quantity as Quantity,
    unit as Unit
}

5. Create Composite Header CDS view.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Composit view for po'
@Metadata.ignorePropagatedAnnotations: true
@ObjectModel.usageType:{
    serviceQuality: #X,
    sizeCategory: #S,
    dataClass: #MIXED
}
define root  view entity z_po_header_composit as select from z_po_header_base
 composition [1..*] of z_po_item_composit as _item
   
{
    key Pono,
    Pocompany,
    Podate,
    Podesc,
    Postatus,
    _item
}

6. Create Composite Item CDS view.

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Composit view for po item'
@Metadata.ignorePropagatedAnnotations: true
define view entity z_po_item_composit as select from z_po_item_base
association to parent z_po_header_composit as _header
    on $projection.Pono = _header.Pono
{
    key Pono,
    key Poitem,
     @Semantics.quantity.unitOfMeasure : 'Unit'
   Quantity,
    Unit,
    _header 
}

7. Create Consumption CDS Header view.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Consumption view for po'
@Metadata.ignorePropagatedAnnotations: true
@Metadata.allowExtensions: true
@ObjectModel.usageType:{
    serviceQuality: #X,
    sizeCategory: #S,
    dataClass: #MIXED
}
define root view entity z_po_header_consumption  
provider contract transactional_query
as projection on z_po_header_composit
{
    key Pono,
    Pocompany,
    Podate,
    Podesc,
    Postatus,
    /* Associations */
    _item : redirected to composition child z_po_item_consumption 
}

8. Create Consumption Item CDS view.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Consumption view for po item'
@Metadata.ignorePropagatedAnnotations: true
@Metadata.allowExtensions: true
@ObjectModel.usageType:{
    serviceQuality: #X,
    sizeCategory: #S,
    dataClass: #MIXED
}
define view entity z_po_item_consumption 
as projection on z_po_item_composit

{
    key Pono,
    key Poitem,
 
   @Semantics.quantity.unitOfMeasure : 'Unit'
    Quantity,
    Unit,
    /* Associations */
    _header : redirected to parent z_po_header_consumption
}

9. Create Metadata Extension for Header.

@Metadata.layer: #CUSTOMER 
annotate entity z_po_header_consumption
    with 
{
    @ui.facet: [{ 
purpose: #STANDARD, 
position: 10, 
label: 'Header', 
type: #IDENTIFICATION_REFERENCE 
}, 
{ 
purpose: #STANDARD, 
position: 20, 
label: 'Item', 
type: #LINEITEM_REFERENCE, 
targetElement: '_item' 
}] 
@UI.selectionField: [{ position: 10 }]
@UI.lineItem: [{ position: 10, label: 'PO No' }] 
@UI.identification: [{ position: 10, label: 'Po NO' }] 
Pono; 
@UI.selectionField: [{ position: 20 }]
@UI.lineItem: [{ position: 20, label: 'Company' }] 
@UI.identification: [{ position: 20, label: 'Company' }] 
Pocompany; 
@UI.selectionField: [{ position: 30 }]
@UI.lineItem: [{ position: 30, label: 'PO Date' }] 
@UI.identification: [{ position: 30, label: 'PO Date' }] 
Podate; 
@UI.lineItem: [{ position: 40, label: 'Desc' }] 
@UI.identification: [{ position: 40, label: 'Desc' }] 
Podesc; 
@UI.lineItem: [{ position: 50, label: 'Status' }] 
@UI.identification: [{ position: 50, label: 'Status' }] 
Postatus; 
    
}

10. Create Metadata extension for Item .

@Metadata.layer: #CUSTOMER
annotate entity z_po_item_consumption
    with 
{
    @ui.facet: [{ 
purpose: #STANDARD, 
position: 10, 
label: 'Item', 
type: #IDENTIFICATION_REFERENCE 
}] 
@UI.lineItem: [{ position: 10, label: 'Po no' }] 
@UI.identification: [{ position: 10, label: 'Po no' }] 
Pono; 
@UI.lineItem: [{ position: 20, label: 'Item' }] 
@UI.identification: [{ position: 20, label: 'Item' }] 
Poitem; 
@UI.lineItem: [{ position: 30, label: 'Quantity' }] 
@UI.identification: [{ position: 30, label: 'Quantity' }] 
Quantity; 
@UI.lineItem: [{ position:40, label: 'Unit' }] 
@UI.identification: [{ position: 40, label: 'Unit' }] 
Unit; 
    
}

11. Create Behavior Definition of Composite view.

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

define behavior for z_po_header_composit //alias <alias_name>
persistent table zpo_header
lock master
authorization master ( instance )
//etag master <field_name>
{
  create;
  update;
  delete;
  association _item { create; }
}

define behavior for z_po_item_composit //alias <alias_name>
persistent table zpo_item
lock dependent by _header
authorization dependent by _header
//etag master <field_name>
{
  update;
  delete;
  field ( readonly ) Pono;
  association _header;
}

12. Create Projection Behavior Definition.

projection;
strict ( 2 );

define behavior for z_po_header_consumption //alias <alias_name>
{
  use create;
  use update;
  use delete;

  use association _item { create; }
}

define behavior for z_po_item_consumption //alias <alias_name>
{
  use update;
  use delete;

  use association _header;
}

13. Create Service Definition.

@EndUserText.label: 'Service Definition fo PO Header'
define service Z_SV_PO_HEADER {
  expose z_po_header_consumption;
  expose z_po_item_consumption;
}

14. Create Service Binding.

15. Now Application can be run from Preview. Header and Item can be created .

16. Records created in Header and Item table.

Universal OData ↔ MCP Bridge; Or: How I Accidentally Made 15,000 Enterprise Services Talk to AI

2025-06-23T18:50:46.751000+02:00

Or: How I Accidentally Made 15,000 Enterprise Services Talk to AI

In March 2025 I realised the "hard part" of enterprise AI integration was already solved by metadata we've had for years. Two hundred MCP servers suddenly became 15,000+ – with one simple translator. 🚀

What Problem Are We Solving?

Hey folks! 👋 This is the logical continuation of my ABAP-native AI journey:

ZVDB & ZLLM brought AI into ABAP (vector search, LangChain-lite, local inference)
This bridge brings ABAP — and every other OData system — to AI

Enterprises sit on thousands of OData endpoints that already expose clean business semantics, yet modern AI assistants can't reach them. All that was missing was a translator.

The "15,000+ MCP Servers" Moment

Ecosystem	OData services made AI-ready
SAP (ECC → S/4 & BTP)	≈ 10,000
Microsoft Dynamics	≈ 1,500
Salesforce	≈ 800
Oracle Cloud ERP	≈ 2,000
SharePoint, ServiceNow & friends	≈ 1,000

Total: 15,000+ enterprise-grade services now surface as first-class MCP tools.¹ Not toys—systems that move real money.

TL;DR (Four Bullets, Promise!)

Code → GitHub: oisee/odata_mcp (Python) & oisee/odata_mcp_go (Go) (link in first comment)
Problem → $2T of software speaks OData; 0% speaks MCP
Solution → Bridge auto-discovers every entity/action; zero config
Result → Your ERP landscape is AI-accessible in under two minutes

Why This Matters—The "So What?"

Role
CTO / Architect	All legacy & cloud systems become AI-ready today—no vendor roadmap, no middleware
Developer	One interface for SAP, Dynamics, Oracle, Salesforce—write once, chat everywhere
Business user	"Claude, approve all POs < $50k" – and it just happens

The "Wait, That's It?" Moment

OData = REST + machine-readable metadata
MCP = JSON-RPC + tool definitions AI assistants understand
Bridge = translate the metadata to tool definitions. That's it.

➡️Just translate between them—and you've unlocked the whole enterprise. 🤔

Two Flavours, Same Power

	Python	Go
Startup	~3s	~0.3s
Memory	~150 MB	~30 MB
Best for	Prototyping & demos	Production workloads
Shared superpowers	Full CRUD, function imports, CSRF juggling (hi SAP 👋), Basic auth, Cookies auth

Demo: From Skepticism to "Holy Wow"

Enterprise Reality Demo

The Auto-Discovery Magic ⭐

OData's metadata does 90% of the work; the bridge just speaks fluent MCP.

Want the deep dive?

Check the repo or catch me on SAP On Azure Podcast 🎙️

The Hidden Cost of Waiting

	Vendor AI (Joule / Copilot / Einstein)	Bridge Today
Availability	Cloud-only, phased rollout	Any OData v2/v3—even ECC 2007
Coverage	Single vendor	Entire landscape
Time-to-value	6-18 months	< 2 minutes
Data location	Vendor cloud	Stays on-prem / your VPC
Vendor-Lock	High	Zero (MIT licensed)

Security & Governance (Because Enterprise)

Runs inside your network — nothing leaves unless you proxy it
Honours existing roles — if users can't see it in GUI or Fiori - they can't see it via MCP
Audit trail-ready — every request loggable with full context

No new attack surface—just a protocol translator.

The Ecosystem Just Shifted

When 15,000+ production services become AI-accessible overnight, MCP stops being a dev toy and becomes the enterprise standard. This isn't iteration—it's inflection.

A Day in Your New AI-Powered Life

09:00  "Claude, what needs my attention?"
       → 3 POs > $40k awaiting approval (SAP)
       → Customer escalation (ServiceNow)
       → Budget variance on cost center 4210 (Dynamics 365)
09:05  "Approve the POs from established vendors, escalate to Sarah, schedule variance review."
       → Done. Next?

Five minutes. One assistant. Zero UI clicks.

What Could Go Wrong? (Let's Be Honest)

Query complexity: Some OData implementations choke on deeply nested $expands
Rate limits: Your backend might not love 100 requests/second from an enthusiastic AI
Schema changes: When your OData model changes, tools need regeneration
Governance: "Claude, show me all salaries" works if your auth is broken

But these are solvable with basic ops hygiene—rate limiters, caching, and proper RBAC.

Get Rolling in Two Minutes

download pre-built binary for your platform: Release Universal OData ↔ MCP Bridge v1.0.0 (Multi-Platform Binaries) · oisee/odata_mcp_go
copy/rename to the appropriate folder (like C:/bin/ )
update your claude_desktop_config.json correspondingly:

{
    "mcpServers": {
        "northwind-go": {
            "args": [
                "--service",
                "https://services.odata.org/V2/Northwind/Northwind.svc/",
                "--tool-shrink"
            ],
            "command": "C:/bin/odata-mcp.exe"
        }
    }
}

Add as many services as you want: just repeat with different --service argument

Instructions on how to build from source code - in README here: oisee/odata_mcp_go

⭐Star the repo if this unlocks value for you!

What's Next

Stay tuned for next week's deep dive: "10 Mind-Blowing Things You Can Build When Your ERP Speaks AI"

But honestly? Even this changes everything.

Try It. Break It. Make It Better.

Here's what I need from you amazing people:

Try it with your systems - SAP, Dynamics, whatever you've got
Break it creatively - I love good bug reports
Add your system's quirks - Every OData implementation is a special snowflake
Share what you build - The crazier the use case, the better

Drop a PR, open an issue, or just share what happens when you connect your enterprise to AI.

Want This as an Azure Service?

Look, this open-source bridge proves the concept works. But I know what you're thinking - "Great Alice, but what about enterprise deployment, monitoring, compliance, support?"

Fair point. What if this was available as a managed Azure service? Zero setup, enterprise SLA, built-in monitoring, automatic scaling...

Drop a comment if you want that. 😉

P.S. Yes, it handles all the authentication properly. Yes, it respects permissions. Yes, it works with your ancient SAP system from 2007. No, I don't know why this wasn't built years ago either. (Well, actually, I might know.)

P.P.S. First prompt I'll run in production: "Claude, find every place we're leaving money on the table." 💰

¹ Counts derived from SAP annual report (2024), Microsoft Dynamics docs, Salesforce API catalog, Oracle ERP Cloud guides, and the public awesome-mcp-servers list; full methodology in /analysis/service-counts.csv.

#EnterpriseAI #OData #MCP #OpenSource #AIIntegrationCP #OpenSource #AIIntegration

Implementing BOPF Actions Using CDS-Based Business Objects in S/4HANA

2025-06-24T09:40:16.716000+02:00

Introduction

In SAP S/4HANA, Core Data Services (CDS) are widely used to define meaningful and reusable data models. When these CDS views are annotated correctly, they can automatically create a Business Object Processing Framework (BOPF) model. This helps in building business objects faster and with less manual effort.

In real-world applications, we often need to perform actions that go beyond just creating, reading, updating, or deleting data. For example, we might need to "Active Status" the status of a record, "Cancel" a request. These kinds of operations are called actions in BOPF.

This object explains how to add such custom actions to a CDS-based BOPF model. It helps developers extend standard functionality by including business-specific logic that users can trigger when needed.

Steps for implementing Action for the CDS-Based Business Objects.

Enhancing CDS-Based BOPF Objects with Custom Actions in S/4HANA.

Defining and Implementing Actions in BOPF via CDS Views.

@AbapCatalog.sqlViewName: 'ZCFMEAL_SQL' 
@AbapCatalog.compiler.compareFilter: true 
@AccessControl.authorizationCheck: #NOT_REQUIRED 
@EndUserText.label: 'Flight Meal Application, Consumption View' 
@OData.publish: true 
@Metadata.allowExtensions: true 
@ObjectModel:{ 
modelCategory: #BUSINESS_OBJECT, 
compositionRoot: true, 
transactionalProcessingEnabled: true, 
createEnabled: true, 
updateEnabled: true, 
deleteEnabled: true, 
writeActivePersistence: 'ZAP_FLIGHT_MEAL' 
}
 
define view ZCFMEAL 
as select from zap_flight_meal 
association [1] to scarr as _Airline on $projection.carrid = _Airline.carrid 
association [1] to sflight as _FlightInfo on $projection.carrid = _FlightInfo.carrid 
and $projection.connid = _FlightInfo.connid 
association [1] to smeal as _Meals on $projection.carrid = _Meals.carrid 
and $projection.meal = _Meals.mealnumber 
{ 
@UI.facet: [{ 
purpose: #STANDARD, 
label: 'Meals', 
type: #IDENTIFICATION_REFERENCE, 
position: 10 
}] 
@UI.lineItem: [{ position: 10, label: 'Meal ID' }, 
{ position: 10, type: #FOR_ACTION, dataAction: 'BOPF:SET_STATUS', label: 'Active Status' } 
] 
@UI.identification: [{ position: 10, label: 'Meal ID' }] 
key meal_id, 
@UI.lineItem: [{ position: 20, label: 'Carrier' }] 
@UI.identification: [{ position: 20, label: 'Carrier' }] 
@ObjectModel.foreignKey.association: '_Airline' 
carrid, 
@UI.lineItem: [{ position: 30, label: 'Connection' }] 
@UI.identification: [{ position: 30, label: 'Connection' }] 
@ObjectModel.foreignKey.association: '_FlightInfo' 
connid, 
@UI.lineItem: [{ position: 40, label: 'Meal' }] 
@UI.identification: [{ position: 40, label: 'Meal' }] 
@ObjectModel.foreignKey.association: '_Meals' 
meal, 
@UI.lineItem: [{ position: 50, label: 'Total seats' }] 
@UI.identification: [{ position: 50, label: 'Total seats' }] 
total_seats, 
@UI.lineItem: [{ position: 10, label: 'Status' }] 
@UI.identification: [{ position: 10, label: 'Status' }] 
status, 
_Airline, 
_FlightInfo, 
_Meals  

}

Once the CDS view is activated, the corresponding BOPF object is automatically generated. You can view it using transaction code BOBX and proceed to define the action.

Next, implement the business logic for the action in the corresponding BOPF action class.

The action implementation class inherits predefined methods from the BOPF framework, such as EXECUTE_ACTION.

Implementation:

Activate and generate the BOPF object.

Now add the service and utilize it in the front-end.

Add the service by Selecting and provide the package name.

You'll get an information that the metadata has been loaded for that service.

Test the service.

Now by using the Odata service create the basic Fiori application

Steps to create basic Fiori application:

Use any tool for creating Fiori like VS Code or SAP Business Application Studio (BAS).

Open Application generator-> select the template -> provide the service ->select the entity-> finish and run the application

Once the application has been generated, you can see that an action button will appear in the Fiori front-end application.

Result:

As all the status are in ‘NO’ once we select the record and click on that action the records get updated as shown below.

Conclusion:

Implementing BOPF actions via CDS views in S/4HANA demonstrates the power of combining declarative modeling with robust transactional logic. By leveraging CDS annotations and standard frameworks, developers can deliver efficient, user-friendly, and scalable business applications—reducing custom code while staying aligned with SAP’s clean core principles.

Tree view in RAP

2025-06-24T09:43:15.825000+02:00

In this blog we will cover:

Introduction,

Architecture overview,

Scenario,

Procedure,

Conclusion.

Introduction:

The CDS hierarchy in SAP ABAP is used to define recursive, tree-like relationships in data directly within Core Data Services (CDS) views. It allows structured, hierarchical data (like manager-employee, material categories, sales orgs, BOMs, etc.) to be represented and consumed easily in UI applications and analytics tools.

In the RAP (RESTful ABAP Programming Model), a Tree View is used to visualize hierarchical (recursive) data structures in the UI—typically in Fiori Elements apps such as List Reports with tree tables.

Tree View allows end users to navigate data in a parent-child format (e.g., managers → employees, sales org → region → country).

├── Region North America

│ ├── Country USA

│ └── Country Canada

└── Region Europe

├── Country Germany

└── Country France

To enable a Tree View in a RAP app:

Model recursive data in a CDS view (e.g., employee-manager, sales org tree)
Create a CDS hierarchy (define hierarchy)
Use a C_ projection view to expose the hierarchy using: @odata.hierarchy.recursiveHierarchy: [ { entity.name: 'ZVS_I_SALES_ORG_HN' } ]
Add your entity to Service Definition and Service Binding
Run the Fiori app (it will automatically detect and display a tree)

Treeviews: Architecture Overview

The implementation of a treeview in the ABAP RESTful Application Programming Model (RAP) requires different entities depending on whether the treeview should be read-only or editable.

Architecture Overview: Read-Only Treeview

Architecture Overview: Read-Only Tree View in CDS

To enable a read-only hierarchical display of data in the UI, the following CDS artifacts are used in combination:

Database Table
A custom database table holds the hierarchical data structure.

Interface View
This CDS view entity is built on top of the database table and defines the data model. It includes a self-association to represent the parent-child hierarchy within the same dataset.

CDS Hierarchy
A persistent CDS hierarchy is created using the DEFINE HIERARCHY statement. It provides a hierarchical interpretation of the interface view, enabling the framework to understand how records are nested.

Projection View
This view projects the interface view and incorporates the CDS hierarchy to expose the structured, hierarchical data as required by the UI.

Service Definition and Service Binding
These are created to expose the CDS projection view as an OData service. This step enables the consumption of hierarchical data in SAP Fiori or other UI frameworks.

Architecture Overview: Editable Treeview with Draft

Editable Tree View with Draft Enablement – Architecture Overview

To enable an editable tree view with draft functionality, the following key artifacts work together to define and expose the hierarchical data structure to the UI:

Database table:

Active and draft tables store the hierarchical data and hierarchy directory separately, supporting draft-enabled transactional scenarios.

CDS view Entities (Interface Views):

Interface views reference the underlying database tables and act as the first projection layer.

The CDS view for the hierarchical data must include:
- A self-association to represent the parent-child relationship within the same entity (enabling hierarchy logic).
- A one-to-many association to link with the hierarchy directory entity.

CDS Hierarchy:

A persistent CDS hierarchy is defined using DEFINE HIERARCHY.
It enables hierarchical interpretation for the data exposed by the first-layer CDS view.

Base CDS views:

These views enrich the model with compositional information.
- The hierarchy directory view acts as the composition root (parent).
- The hierarchical data view acts as the composition child.

Behaviour Definition for base views:

Defines transactional behavior, including:
- Draft capability
- Editing operations required by the UI.

Projection views:

Serve the consumption layer:
- For the hierarchy directory: A projection view supports transactional queries.
- For hierarchical data: A projection view combines interface view data with hierarchical logic using the @OData.hierarchy.recursiveHierarchy annotation (referring to the CDS hierarchy).

Projection behaviour definition:

Describes the behavior of projection views, allowing:
- Custom logic like determinations, validations, authorizations, numbering, etc.

Service Definition and Service Binding:

Finally, a service definition and binding are created to expose the hierarchy and its data structure to the UI layer via OData.

===========================================================================

Scenario for Tree view in RAP:

In large global companies, the Sales & Distribution (SD) module often reflects the company's organizational structure. Typically, Sales Organizations are arranged in a multi-level hierarchy like this:

This kind of structure helps companies manage sales performance, reporting, and operations more effectively.

However, many systems don’t provide a read-only, easy-to-use view of this hierarchy — especially in a tree or drill-down format that users can easily navigate.

In this blog, we’ll walk through how to model and expose this Sales Org hierarchy using CDS Hierarchies, and finally expose it through an OData service to be consumed in a Fiori UI.

Procedure:

Step 1: Define the Base Table - ZVS_DT_SALES

This transparent table stores the core sales organization data including parent-child relationships.

@EndUserText.label : 'Hierarchy: Read Only: Sales Organization'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table zvs_dt_sales {

  key client       : abap.clnt not null;
  key sales_org_id : abap.char(6) not null;
  name             : abap.char(50);
  region           : abap.char(20);
  country          : abap.char(3);
  @Semantics.amount.currencyCode : 'zvs_dt_sales.currency'
  revenue          : abap.curr(21,2);
  currency         : /dmo/currency_code;
  parent_sales_org : abap.char(6);

}

Note: parent_sales_org is a self-referencing field to represent the hierarchy.

This table contain some records:

Step 2: Interface View - ZVS_I_SALES

This CDS view represents the Sales Org data and defines a self-association to establish the parent-child link.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Interface View: Sales Organization'
@Metadata.ignorePropagatedAnnotations: true
@ObjectModel.usageType:{
    serviceQuality: #X,
    sizeCategory: #S,
    dataClass: #MIXED
}
define view entity zvs_i_sales as select from zvs_dt_sales
association to zvs_i_sales as _Parent on 
    $projection.ParentSalesOrg = _Parent.SalesOrgId
{
    key sales_org_id as SalesOrgId,
    name as Name,
    region as Region,
    country as Country,
    @Semantics.amount.currencyCode: 'Currency'
    revenue as Revenue,
    currency as Currency,
    parent_sales_org as ParentSalesOrg,
    
    _Parent
}

Step 3: Define Hierarchy - ZVS_I_SALES_HN

Using CDS hierarchy syntax, we now define a parent-child recursive hierarchy.

@EndUserText.label:'Sales Organization Hierarchy'

define hierarchy zvs_i_sales_hn
  as parent child hierarchy (
    source zvs_i_sales
    child to parent association _Parent
    start where ParentSalesOrg is initial
    siblings order by SalesOrgId ascending
  )
{
    key SalesOrgId,
      ParentSalesOrg
    
}

This is where the magic happens. This hierarchy enables a recursive structure that can be rendered in Fiori Tree controls.

Step 4: Projection View - ZVS_C_SALES

This is the final consumption layer that will be exposed as OData. The hierarchy is referenced using the @OData.hierarchy.recursiveHierarchy annotation.

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Projection View: Sales Organization'
@Metadata.ignorePropagatedAnnotations: true
@ObjectModel.usageType:{
  serviceQuality:#X,
  sizeCategory:#S,
  dataClass:#MIXED
}
@Metadata.allowExtensions:true
@Search.searchable:true

@OData.hierarchy.recursiveHierarchy: [{ entity.name: 'zvs_i_sales_hn' }]
define view entity zvs_c_sales as select from zvs_i_sales
association of many to one zvs_c_sales as _Parent
    on $projection.ParentSalesOrg = _Parent.SalesOrgId
{
    key SalesOrgId,
    @Search.defaultSearchElement: true
    Name,
    Region,
    Country,
    @Semantics.amount.currencyCode: 'Currency'
    Revenue,
    Currency,
    ParentSalesOrg,
    /* Associations */
    _Parent
}

Screenshot:

Metadata extension:

@Metadata.layer: #CORE
annotate entity zvs_c_sales with
{
  @UI: {lineItem: [{ label: 'Sales org ID', position: 10 }],
        identification: [{ label: 'Sales org ID', position: 10 }]
  }
  SalesOrgId;

  @UI: {lineItem: [{ label: 'Sales org Name', position: 20 }],
    identification: [{ label: 'Sales org Name', position: 20 }]
  }
  Name;

  @UI: {lineItem: [{ label: 'Region', position: 30 }],
    identification: [{ label: 'Region', position: 30 }]
  }
  Region;

  @UI: {lineItem: [{ label: 'Country', position: 40 }],
    identification: [{ label: 'Country', position: 40 }]
  }
  Country;

  @UI: {lineItem: [{ label: 'Revenue', position: 50 }],
    identification: [{ label: 'Revenue', position: 50 }]
  }
  Revenue;

  @UI: {lineItem: [{ label: 'Currency', position: 60 }],
    identification: [{ label: 'Currency', position: 60 }]
  }
  Currency;

  @UI: {lineItem: [{ label: 'Parent Sales org ID', position: 70 }],
        identification: [{ label: 'Parent Sales org ID', position: 70 }]
  }
  ParentSalesOrg;

}

Step 6: Service Binding - ZVS_C_SALES_ORG_V4

If you will choose service binding type as V2, So you will get one error:

So select your Binding type as V4,

Now preview your application:

Conclusion:

Using CDS views and hierarchies in SAP S/4HANA is a simple and effective way to show the Sales Organization structure in a clear, tree-like format. It helps sales managers easily understand how different sales units are connected and how each one is performing. This setup is read-only, so the data stays safe, and it works well with Fiori apps for a smooth user experience.

Overall, this approach makes reporting and analysis easier without needing a lot of custom coding.

Reusable SAP CPI Interface for Proxies Using Groovy: Simple Proxy XML to JSON Integration

2025-06-24T10:06:56.005000+02:00

Introduction

This blog will show you how to create a single interface in SAP CPI that can be reused for processing proxy XML data from SAP S4/SAP systems or any other systems also.

Use Case

We will come across situations where we need to send different sets of data with different XML structures from SAP or SAP S4 to a target application using SAP CPI.

Normally, we design a specific proxy structure for XML that the ABAP team can use to send data to the middleware. But when there are multiple XML structures and the data needs to be sent separately from the source system, we often need to create multiple proxy structures. Also, if a field name needs to be changed or a new field needs to be added, the interface must be updated each time.

I came across this situation where SAP needed to send different XML messages, and the ABAP team asked for multiple proxy structures and changes. Each different message was going to the same target application but with a different resource path. This is going to take lot of time and different interfaces are needed as each message use different path in the HTTP.

To avoid this, I used a standardized XML format with simple <FieldName> and <FieldValue> pairs, and I added a resource path identifier in the header. This way, I was able to create just one reusable interface in SAP CPI that could handle all the different incoming messages, which I then sent to the target application.

Architecture

Development Steps

Standardize Input XML in SAP

I have created Standardize SAP proxy structures into a common, uniform format with header

<FieldName> and <FieldValue> XML pair structure

This contains Header section I will be using to identify my resource path

In SAP CPI , I have used content modifier to capture the proxy header table data and saved it in property to use in HTTP receiver adapter. This property dynamically call the endpoint.

Groovy Script in CPI for XML to Json

This Groovy script parses the incoming XML, extracts field-value pairs, and builds a JSON structure:

import com.sap.gateway.ip.core.customdev.util.Message;
import java.util.HashMap;
import groovy.xml.*
import groovy.json.*
def Message processData(Message message)
{
    def xml = message.getBody(java.lang.String)
    def records = new XmlSlurper().parseText(xml)
    def jsonList = records.Record.collect { record ->
    def map = [:]
    record.Item.each { item ->
        map[item.FieldName.text()] = item.FieldValue.text()
    }
    return map
    }
    def json = JsonOutput.prettyPrint(JsonOutput.toJson(jsonList))
    message.setBody(json)
    return message;
}

Post Transformed JSON Data to Target Endpoint
HTTP Adapter configuration: In previous Content Modifier I have used Tablename to dynamically identify target URL.

Testing

Input XML1

<Header>
		<TableName>KLAH</TableName>
		<Plant>001</Plant>
	</Header>
	<Record>
		<Item>
			<FieldName>MANDT</FieldName>
			<FieldValue>300</FieldValue>
		</Item>
		<Item>
			<FieldName>CLINT</FieldName>
			<FieldValue>1234</FieldValue>
		</Item>
		<Item>
			<FieldName>KLART</FieldName>
			<FieldValue>003</FieldValue>
		</Item>
	</Record>

Output Json1:

[
	{
		"MANDT": "300",
		"CLINT": "1234",
		"KLART": "003"
	}
]

example2:

Input XML

<message>
	<Record>
		<Item>
			<FieldName>MANDT</FieldName>
			<FieldValue>300</FieldValue>
		</Item>
		<Item>
			<FieldName>TPLNR</FieldName>
			<FieldValue>001A</FieldValue>
		</Item>
		<Item>
			<FieldName>SPRAS</FieldName>
			<FieldValue>E</FieldValue>
		</Item>
		<Item>
			<FieldName>PLTXT</FieldName>
			<FieldValue>CheckPLTXTValueRecord1</FieldValue>
		</Item>
		<Item>
			<FieldName>PLTXU</FieldName>
			<FieldValue>CheckPLTXUTValueRec1</FieldValue>
		</Item>
	</Record>
	<Record>
		<Item>
			<FieldName>MANDT</FieldName>
			<FieldValue>300</FieldValue>
		</Item>
		<Item>
			<FieldName>TPLNR</FieldName>
			<FieldValue>001B</FieldValue>
		</Item>
		<Item>
			<FieldName>SPRAS</FieldName>
			<FieldValue>E</FieldValue>
		</Item>
		<Item>
			<FieldName>PLTXT</FieldName>
			<FieldValue>CheckPLTXTValueRecord2</FieldValue>
		</Item>
		<Item>
			<FieldName>PLTXU</FieldName>
			<FieldValue>CheckPLTXUTValueRec2</FieldValue>
		</Item>
	</Record>
</message>

OutputJson:

[
    {
        "MANDT": "300",
        "TPLNR": "001A",
        "SPRAS": "E",
        "PLTXT": "CheckPLTXTValueRecord1",
        "PLTXU": "CheckPLTXUTValueRec1"
    },
    {
        "MANDT": "300",
        "TPLNR": "001B",
        "SPRAS": "E",
        "PLTXT": "CheckPLTXTValueRecord2",
        "PLTXU": "CheckPLTXUTValueRec2"
    }
]

Take Away

This design reusable, scalable integration strategy in SAP CPI using Groovy scripting and a generalized XML structure for simple transmissions.
Implementing a single interface capable of handling multiple tables data with dynamic fields, this solution simplifies integration architecture, accelerates delivery, and reduces ongoing maintenance.
Finally it eliminates the need of create multiple interfaces for similar data transmissions if we could able to handle simple design approcahes in SAP CPI.

Custom program to generate- Where used list for CDS DDLS Object.

2025-06-26T10:31:12.615000+02:00

This code is not my original creation, there was already a utility code on SCN to generate the where used list of CDS DDLS object. But that code only works for 1 CDS at a time. I supplied the same code to my team and they said it would be better if it could handle multiple entries. So, I just made those few changes rest is as it is from the original and full credit goes to that developer for his/her work. This code can surely be improved using better queries and reducing loops etc. but that will be up to the developer who uses this code in future.

report zpsb_util_cds_where_used.


types:begin of ty_ddls_w,
        ddls     type ddlname,
        o_type   type trobjtype,
        obj_name type progname,
      end of ty_ddls_w,

      begin of ty_funcm,
        funcname type rs38l_fnam,
        pname    type pname,
      end of ty_funcm,

      ty_ddls_t  type standard table of ty_ddls_w with empty key,
      ty_funcm_t type standard table of ty_funcm with empty key.

data:w_ddls_f  type string,
     t_ddls_w  type ty_ddls_t,
     t_ddls_final  type ty_ddls_t,
     s_ddlname type ty_ddls_w,
     t_func    type ty_funcm_t.

selection-screen: begin of block b1 with frame title text-001.

selection-screen skip 1.

selection-screen begin of line.
*parameters:p_rad1 radiobutton group rb1.
selection-screen comment 5(20) comment1.
"PARAMETERS: p_ddls1  TYPE ddlname.
select-options: s_ddls1 for s_ddlname-ddls NO INTERVALS.
selection-screen end of line.

selection-screen skip 1.

*selection-screen begin of line.
*parameters:p_rad2 radiobutton group rb1.
*selection-screen comment 5(20) comment2.
*parameters: p_ddls2  type ddlname.
*selection-screen end of line.
selection-screen:end of block b1.

at selection-screen output.

  comment1 = 'CDS Where Used:'.
*  comment2 = 'CDS Components:'.

class lcl_event_handler definition.

  public section.

    types:begin of lty_source_code,
            src_cd type char1000_idoc,
          end of lty_source_code.

    data:
      lo_alv type ref to cl_salv_table,
      lt_alv type ty_ddls_t.


    methods constructor
      importing
        i_alv type ref to cl_salv_table.

    methods on_double_click
      for event if_salv_events_actions_table~double_click
                  of cl_salv_events_table
      importing row column.

endclass.

class lcl_event_handler implementation.

  method constructor.
    lo_alv = i_alv.
  endmethod.

  method on_double_click.

    data: lt_source_cd type standard table of lty_source_code,
          l_obj_name   type progname,
          l_type       type trobjtype,
          l_ddls       type ddlname.

    check column = 'OBJ_NAME'.

    l_obj_name = lt_alv[ row ]-obj_name.
    l_type = lt_alv[ row ]-o_type.
    l_ddls = lt_alv[ row ]-ddls.

    case l_type.

      when 'DDLS'.

        try.
            cl_dd_ddl_handler_factory=>create( )->read(
                  exporting
                    name         = conv ddlname( to_upper( l_obj_name ) )
                  importing
                    ddddlsrcv_wa = data(ddlsrcv_wa) ).
          catch cx_dd_ddl_read into data(exc).
            cl_demo_output=>display( exc->get_text( ) ).
        endtry.
        if ddlsrcv_wa-source is initial.
          cl_demo_output=>display( |Nothing found| ).
          return.
        endif.

        cl_demo_output=>display( replace( val = ddlsrcv_wa-source
                                          sub = |\n|
                                          with = ``
                                          occ = 0 ) ).

      when others.

*---get the source code (other then DDLS)
        read report l_obj_name  into lt_source_cd.
        if sy-subrc eq 0.

          data(l_source_code) = reduce string( init lv_src type string
*---Don't consider ANY commented code
                                        for lw_source in lt_source_cd
                                    index into lv_index
                                      where ( table_line+0(1) ne '*' )
                              next lv_src=to_upper( lv_src ) &&
                              space && to_upper( lw_source-src_cd )  && | LINE#: { lv_index }#|   ).

          clear lt_source_cd.

          data(l_search_pattern) = `(?:LINE#: (\d)+)(?=#[\w\s]+` && |{  l_ddls  }| && `)`.
          data(lv_result) = match(  val = l_source_code
                                               regex = l_search_pattern
                                               case = abap_false    ).
          if lv_result is not initial.
            data(lv_line) = match(
                                     val = lv_result
                                    regex = `(?:LINE#:\s)([0-9]+)`
                                    case = abap_false
                                     ).
            split lv_line at ':' into data(l_part1) data(l_part2).
            condense l_part2 no-gaps.


          else.
            message |Object: { l_ddls }, has no direct usage| type 'S'.
          endif.

        endif.
        call function 'RS_TOOL_ACCESS'
          exporting
            operation           = 'SHOW'
            object_name         = l_obj_name
            object_type         = l_type
            position            = cond char10( when l_part2 = 0 then space else ( l_part2 + 1 ) )
          exceptions
            not_executed        = 1
            invalid_object_type = 2
            others              = 3.
        if sy-subrc <> 0.
* Implement suitable error handling here
        endif.
    endcase.
  endmethod.

endclass.

start-of-selection.

*  case abap_true.
*
*    when p_rad1.

*      IF p_ddls1 IS INITIAL.
      if s_ddls1[] is initial.
        message 'Enter a CDS View to proceed!' type 'S'.
        leave list-processing.
      endif.

      loop at s_ddls1 into data(p_ddls1).



        w_ddls_f = '\TY:' && p_ddls1-low.

*---Find parent DDLS (if any)
        select * from ddls_ris_index
        into table (t_ddls_where_used)
        where used_artifact_fullname = @w_ddls_f.
        if sy-subrc eq 0.
          loop at t_ddls_where_used reference into data(lo_ddls).
            append initial line to t_ddls_w reference into data(lo_ddls_wu).
            split lo_ddls->used_artifact_fullname at ':' into data(w_part1) data(w_part2).

            lo_ddls_wu->ddls = w_part2.
            lo_ddls_wu->o_type = 'DDLS'.
            lo_ddls_wu->obj_name = lo_ddls->ddlsrc_name.
          endloop.
        endif.

*----find all other ABAP Objects where input DDLS been used
        select name,
               include,
               case repo~subc

               when '1' then 'REPS'
               when 'K' then 'CLAS'
               when 'I' then 'INCL'
               when 'F' then 'FUGR'
               else 'UN'
               end  as o_type

            from wbcrossgt as wb
            left outer join reposrc as repo
            on wb~include = repo~progname
        INTO table (lt_wbcrossgt)
        where otype = 'TY'
        and name = @p_ddls1-low
        and indirect = .
        if sy-subrc eq 0.
          sort lt_wbcrossgt by name include o_type.

*---Check for Function Modules
          loop at lt_wbcrossgt reference into data(lo_wbcross) where o_type = 'UN'.
            append initial line to t_func reference into data(lo_func).
            lo_func->funcname = lo_wbcross->include.
          endloop.

          if t_func is not initial.
            select  funcname,
                    pname
              from tfdir INTO table (t_tfdir)
              for all entries in @t_func
              where funcname = @t_func-funcname.
            if sy-subrc eq 0.
              sort t_tfdir by funcname.
            endif.
          endif.

          loop at lt_wbcrossgt reference into lo_wbcross.
            append initial line to t_ddls_w reference into lo_ddls_wu.

            if lo_wbcross->o_type = 'UN' and line_exists( t_tfdir[ funcname = lo_wbcross->include ] ).
              lo_ddls_wu->ddls = p_ddls1.
              lo_ddls_wu->o_type = 'FUNC'.
              lo_ddls_wu->obj_name = lo_wbcross->include.
            else.

              lo_ddls_wu->ddls = p_ddls1.
              lo_ddls_wu->o_type = lo_wbcross->o_type.
              lo_ddls_wu->obj_name = lo_wbcross->include.
            endif.

          endloop.

        endif.
        append LINES OF t_ddls_w[] TO t_ddls_final[].
        clear: t_ddls_w, t_func, t_tfdir.
      endloop.

*      WHEN OTHERS.
*
**
**    when p_rad2.
**      message 'This feature, not yet Supported' type 'S'.
**      leave list-processing.
*  endcase.

*  if t_ddls_w is not initial.
  if t_ddls_final[] is not initial.

    call method cl_salv_table=>factory
      importing
        r_salv_table = data(lo_alv1)
      changing
        t_table      = t_ddls_final[].

    if lo_alv1 is bound.
      lo_alv1->get_functions( )->set_all( abap_true ).
      lo_alv1->get_columns( )->set_optimize( abap_true ).

      data(lo_evt_handler) = new lcl_event_handler( lo_alv1 ).
      data(lo_events) = lo_alv1->get_event( ).
      set handler lo_evt_handler->on_double_click for lo_events.

      lo_evt_handler->lt_alv = t_ddls_w.
      lo_alv1->display( ).
    endif.

*  else.
*
*    message 'No records found!' type 'S'.
*    leave list-processing.
*
  endif.

There is no line by line explanation or comment because the code is self-explanatory. Talk less code more 🙂

I Built LangChain-lite for ABAP, and Solved the Enterprise AI Cold Start Problem

2025-06-30T17:39:51.098000+02:00

Why enterprise AI projects fail at the "last mile"

AGI has been achieved!* Now your ABAP-Native AI can reach enterprise data where it lives.

Hello! 👋 It's Alice again, and I've spent the last 1.5 years building what I wish had existed when I started my AI journey: a complete LLM orchestration framework that lives entirely within SAP.

TL;DR:

GitHub: oisee/zllm (releasing incrementally - link in first comment)
Problem: Enterprise AI projects die in "integration hell" between proof-of-concept and production
Solution: Native ABAP AI orchestration - no Python, no APIs, no middleware
Result: Build production AI workflows in hours, not months

Remember my previous posts?

🔍ZVDB brought vector search to ABAP
📏PREDICTOKEN eliminated expensive tokenizer calls
🔗The OData-MCP bridge connected 15,000+ enterprise services to AI

Those were puzzle pieces; ZLLM is the complete picture.

The "Last Mile" Problem Nobody Talks About

Your AI proof-of-concept is brilliant. The CEO is excited. Then someone asks:

"When can we connect this to our actual SAP system?"

Traditional Answer: "We need APIs, data pipelines, authentication, environments, deployments, monitoring..."

Six months later: Still in integration hell. 💀

ZLLM Answer: "It's already connected." ✨

What Enterprise AI Actually Looks Like

This is what you can build today, in pure ABAP, with zero external dependencies:

" Complete customer intelligence pipeline
DATA(lo_flow) = zcl_llm_00_flow_lazy=>new( VALUE #(
  ( lo_extract_customer_data )    
  ( lo_analyze_behavior_patterns )
  ( lo_identify_upsell_opportunities )
  ( lo_generate_action_plan )     
  ( lo_update_crm_notes )         
) ).

DATA(lr_result) = lo_flow->exec( REF #( lv_customer_id ) ).

Time to production: Hours External systems involved: Zero** Integration code: Zero

The Template Engine That Understands Your Data

Here's where ZLLM gets magical - watch this:

" Your nested ABAP structure
DATA: BEGIN OF ls_order,
        customer TYPE BEGIN OF customer_struct,
          name TYPE string,
          vip_status TYPE abap_bool,
        END OF customer,
        items TYPE TABLE OF order_item,
      END OF ls_order.

" Template that just works
DATA(lo_pattern) = zcl_llm_00_pat=>new(
  'Customer {T-CUSTOMER-NAME} (VIP: {T-CUSTOMER-VIP_STATUS}) ' &&
  'ordered {T-ITEMS-PRODUCT_NAME} for ${T-ITEMS-PRICE}'
).

DATA(lv_prompt) = lo_pattern->apply( REF #( ls_order ) ).

The template engine automatically:

✅Navigates deep structure hierarchies
✅Iterates over internal tables
✅Converts complex data to JSON when needed
✅Handles NULL values gracefully

No JSON glue code. No data mapping. No field-by-field extraction. It just works.

Lazy Execution: The Enterprise Performance Secret

Traditional AI workflows block everything:

# Traditional synchronous hell
result1 = llm.call(prompt1)          # Wait 3 seconds
result2 = llm.call(prompt2)          # Wait 3 seconds 
result3 = llm.call(prompt3)          # Wait 3 seconds
# Total: 9 seconds of blocking execution

ZLLM uses lazy execution for real performance:

" Start all operations immediately (non-blocking)
DATA(lo_result1) = lo_step1->start( ir_input ).
DATA(lo_result2) = lo_step2->start( ir_input ).
DATA(lo_result3) = lo_step3->start( ir_input ).

" Collect results when ready
DATA(lr_final1) = lo_result1->collect( ).  " ~3 seconds total

The Security Story Enterprise Can Actually Use

ZLLM includes security foundations that scale to enterprise requirements:

At Rest:

" Default: Symmetric XOR with seed (fine for PoC/development)
SET PARAMETER ID 'ZLLM_CODEC' FIELD '12345'.

" Production: Implement your codec interface
DATA(lo_enterprise_codec) = zcl_your_enterprise_codec=>new( ).

At Runtime:

" Inherits SAP's proven security model
" If user can't access data in GUI, they can't access via AI
" No new security surface area

Bottom Line: ZLLM starts secure enough for development and PoCs, with clear paths to enterprise-grade security when you need it.

Real Demo: 30-Second Customer Intelligence

METHOD generate_customer_intelligence.
  DATA(lo_extract) = zcl_llm_00_step_lazy=>new_from_string(
    iv_usr = 'Extract key purchasing patterns from: {T}'
    iv_sys = 'Return as structured JSON with trends'
    io_llm = lo_llm
  ).

  DATA(lo_opportunities) = zcl_llm_00_step_lazy=>new_from_string(
    iv_usr = 'Based on patterns {T}, identify 3 upsell opportunities'
    io_llm = lo_llm
  ).

  DATA(lo_flow) = zcl_llm_00_flow_lazy=>new( VALUE #(
    ( lo_extract ) ( lo_opportunities )
  ) ).

  DATA(ls_customer) = get_customer_patterns( iv_customer ).
  RETURN lo_flow->exec( REF #( ls_customer ) ).
ENDMETHOD.

Result: SAP data → AI analysis → Business recommendations in 30 seconds.

Load Balancing: Right Model, Right Cost

" Smart routing based on complexity
DATA(lo_llm_smart) = zcl_llm_00_llm_lazy_composite=>new(
  io_llm       = lo_llm_mini     " Fast, cheap model
  io_llm_exp   = lo_llm_maxi     " Powerful, expensive model 
  iv_threshold = 1000            " Token threshold
).

" Simple queries → Mini model (fast + cheap)
" Complex queries → Maxi model (powerful + expensive)

PREDICTOKEN: The Secret Weapon

" Predict tokens before expensive API calls
DATA(lv_predicted_tokens) = zcl_llm_00_predictoken=>predict_tokens_gpt4( lv_text ).

IF lv_predicted_tokens < 500.
  lo_llm = lo_llm_mini.     " Cheap model
ELSEIF lv_predicted_tokens > 8000.
  lo_flow = lo_split_flow.  " Split into multiple calls
ENDIF.

Accuracy: 99.7% token prediction (R² > 0.997 on 50,000+ validation samples) without API calls.

One-Click Invoice Intelligence

Complete invoice processing workflow:

DATA(lo_flow) = zcl_llm_00_flow_lazy=>new( VALUE #(
  ( lo_extract_invoice_data )     
  ( lo_validate_against_po )      
  ( lo_flag_anomalies )          
  ( lo_generate_approval_routing )
  ( lo_update_workflow_system )  
) ).

" Process 1000 invoices in parallel
DATA(lo_parallel) = zcl_llm_00_step_lazy_parallel=>new(
  io_step = lo_flow->to_step( )
  io_llm  = lo_llm
).

Getting Started: The 10-Minute Setup

Run: ZLLM_00_ONBOARD - Configure your LLM endpoints
Demo: ZLLM_00_FLOW_DEMO - See chaining in action
Build: Your first workflow in pure ABAP

DATA(lo_llm) = zcl_llm=>new( 'DEFAULT.ENV' ).
DATA(lo_step) = zcl_llm_00_step_lazy=>new_from_string(
  iv_usr = 'Analyze this data: {T}'
  io_llm = lo_llm
).
DATA(lr_result) = lo_step->exec( REF #( your_business_data ) ).

The "But What About..." Section

"What about Python's rich AI ecosystem?" Over half of enterprise AI work is data movement, not algorithms. ZLLM excels at the majority use case.

"What about scaling?" SAP systems already handle your enterprise load. ZLLM scales with your existing infrastructure.

"What about vendor lock-in?" ZLLM actually reduces vendor lock-in. You can hot-swap your LLM including self-hosted Ollama - try this with Joule 😃

# Monday: Local Ollama (zero vendor dependency)
API_MODEL=codellama
API_URL=http://localhost:11434/
API_KEY=ollama

# Tuesday: Switch to Azure (same ABAP code)
API_AZURE_FULL_URL=https://your-domain.openai.azure.com/...
API_KEY=your-azure-key

# Wednesday: Your own inference cluster
API_MODEL=your-custom-model
API_URL=http://your-internal-cluster/v1/
API_KEY=internal

One framework, any LLM provider. Change your .env file, restart your program. That's it.

Meanwhile, Joule ties you to whatever models SAP decides to support. ZLLM works with anything that speaks OpenAI API - including models that don't exist yet.

Why This Changes Everything

Before ZLLM: AI projects required new infrastructure, teams, security reviews, integration patterns, deployment processes.

After ZLLM: AI projects are ABAP development projects. Use existing everything.

The "cold start problem" disappears because there's no cold start. Your AI capabilities live where your business logic lives.

The Enterprise AI Future

This isn't another AI framework. This is enterprise AI that makes business sense:

✅No integration projects - AI lives in your business logic
✅No new infrastructure - Use your existing SAP systems
✅No new security model - Inherit SAP's proven security
✅No new deployment process - Deploy like any ABAP development

AGI* has been achieved. Now your ABAP can generate intelligence.

Ready to eliminate your AI integration hell?

⭐Star & Fork on GitHub - Get early access to the framework

Comment below: What's your most painful SAP business process? Let's see how ZLLM can eliminate that pain.

Build in hours what took quarters—or never shipped—six months ago.

The ideal enterprise AI integration is one that doesn't exist because the capability is native: "we already have an LLM at home!"

About the Author:

Alice Vinogradova is a Senior Software Engineer with two decades of ABAP/SAP experience and a passion for practical AI integration. She specializes in eliminating complexity through innovation, bringing cutting-edge AI capabilities to conservative enterprise environments without the traditional integration overhead.

P.S. This framework exists because I got tired of explaining why enterprise AI projects fail. Better to build the solution than argue about the problem. ^_^

*ABAP Generative Intelligence 😃

**No external API, except LLM of course.

Hashtags: #SAP #ABAP #AI #EnterpriseAI #LLM #Innovation #TechLeadership #LangChain #ZLLM

N.B. It was just released and Lars Hvam already sent 5 pull-requests with bug fixes! Thanks a mil, Lars ^_^

Navigating the Labyrinth: Choosing the Right Persistent Data Storage for Your Custom Development

2025-07-01T09:57:50.815000+02:00

Hello All,

During a recent implementation project, I encountered a familiar yet significant dilemma: determining the right approach for persistent data storage in a custom RICEF development. The functional team specifically requested something as intuitive and user-friendly as SM30 for data maintenance—a scenario many of us in the SAP ecosystem can relate to.

While the need for a custom configuration table was clear, the abundance of options in S/4HANA—across both on-premise and cloud environments—made the decision more complex than expected. Add to that the challenge of balancing legacy ECC practices with modern S/4HANA architecture, and the decision-making process becomes even more nuanced.

In this blog, I’ll walk through our real-world scenario, the solutions we considered, and the reasoning behind the final choice. The goal is to offer a concise yet practical guide to help others facing similar decisions in their S/4HANA journey.

Understanding the Landscape: On-Premise vs. Cloud

Before we dive into the specifics, it's crucial to understand that the choice of approach is heavily influenced by your SAP S/4HANA deployment model: on-premise or cloud. The"clean core" strategy, which emphasizes upgrade stability and limiting direct modifications to the core system, significantly shapes the available options, especially in the public cloud. What might be a viable solution on-premise could be entirely unsupported or not recommended in the cloud.

Let's break down the options by deployment model.

S/4HANA On-Premise: A Blend of Tradition and Modernity
In an S/4HANA on-premise environment, you have the flexibility to leverage both traditional ABAP development paradigms and newer, cloud-aligned approaches. This often leads to the dilemma that we faced: which path to take?

1. The Classical ABAP Approach: The Tried and True (with a Caveat)

This is perhaps the most familiar territory for many seasoned ABAP developers. It involves creating custom tables directly in the ABAP Dictionary (transaction SE11) and then generating a maintenance dialog using the Table Maintenance Generator (TMG) viaSE11 or SE54. End-users can then maintain data using the ubiquitous transaction SM30. You can even create custom transaction codes (SE93) for direct access, enhancing user experience and security. TMG also offers "events" where you can embed custom ABAP logic for validations, defaulting values, and other business requirements.

Features:

Full Control: You get granular control over table design, field properties, and database attributes. This is ideal for highly complex data models or scenarios requiring specific performance optimizations at the database level.
Familiarity: SM30 is a standard and widely known transaction, making it familiar to many SAP users for data maintenance.
Custom Logic: TMG events provide hooks for embedding custom ABAP logic, allowing for robust validations and business rules.

When to Use:

When maximum control and flexibility over table design and implementation are paramount.
For highly complex data models or specific performance optimizations that can only be achieved at the ABAP Dictionary level.
When existing SAP GUI-based processes are acceptable or preferred by the end-users, or when the development effort for a Fiori UI is not justified for the specific use case.

2. The Custom TVARVC Table Approach: Simple Configurations, Simple Maintenance

This approach involves creating a custom table (typically starting with 'Z' or 'Y') that mimics the structure of the standard TVARVC table. This custom table is then used to store application-specific parameters or simple configuration values. Maintenance is usually performed via Custom SAP GUI report/ transactions similar to STVARV or SM30.

Features:

Simple Configuration: Ideal for storing key-value pairs or simple ranges, such as company codes, plant-specific parameters, threshold values, or lists for custom logic. It's excellent for preventing hardcoding of values in ABAP programs, userexits, and reports.
Reusable Framework: A single custom TVARVC-style table and its supporting maintenance report can be designed as a reusable framework, enabling consistent configuration handling across multiple custom developments.

When to Use:

For simple configuration parameters that control custom ABAP developments.
When a quick and straightforward solution with minimal initial development for table structure and maintenance UI is needed.
When end-users are comfortable with SAP GUI for configuration maintenance.

3. Custom Business Objects (CBOs): The Modern On-Premise Approach

Custom Business Objects (CBOs) represent a modern and increasingly recommended method for defining custom data structures and behaviors in S/4HANA on-premise. They are managed via the "Custom Business Objects" Fiori app. A significant advantage of CBOs is the automatic generation of a Fiori-based UI for data maintenance, eliminating the need for manual UI development for basic CRUD operations. Each CBO is backed by a system-provisioned database table and inherently exposes an OData service for seamless integration with Fiori applications and other systems. This is essentially a low-code approach to custom tables with integrated Fiori maintenance.

Features:

Automatic Fiori UI: The system automatically generates a Fiori-based UI for data maintenance, providing a modern user experience with minimal development effort.
OData Service Exposure: CBOs automatically expose an OData service, simplifying integration with other Fiori apps, SAP systems, and external applications.
Key User Extensibility: CBOs empower key users to define and manage their owndata structures through a Fiori interface, reducing reliance on traditional ABAP developers for simple requirements.
Associations and Logic: Supports associations with other business objects for intricate data models and allows for custom logic (validations, determinations) via cloud BAdIs.

When to Use:

When the primary requirement is a user-friendly, modern Fiori interface for custom table maintenance.
For rapid development and deployment of maintenance UIs with minimal coding.
Well-suited for moderately complex data structures.
When you want to empower key users with extensibility capabilities.

4. Fiori Elements with ABAP RESTful Application Programming Model(RAP): The Future of On-Premise Development

This is a powerful and increasingly recommended approach for building Fiori applications, including those for custom table maintenance, in S/4HANA on-premise.RAP provides a standardized way to build OData services for transactional and analytical applications. Fiori Elements then automatically generate UIs based on these OData services and CDS views, significantly accelerating development.

Features:

Model-Driven UI: Fiori Elements generate UIs automatically from CDS views andOData services, drastically reducing manual UI coding.
RAP for Backend Logic: RAP handles the transactional and analytical logic,including CRUD operations for custom tables, ensuring a robust and scalablebackend.
Integrated Development: Development is done in ADT (ABAP Development Toolsin Eclipse), providing a modern development experience.

When to Use:

When building new Fiori applications for custom table maintenance in S/4HANA on-premise.
For scenarios requiring a robust, scalable, and performant solution that aligns with SAP's strategic direction.
When you want to leverage the benefits of automated UI generation and a consistent Fiori user experience.

5. Freestyle SAPUI5 Applications: Ultimate UI Customization

For scenarios requiring highly customized user interfaces or complex interactions not easily achievable with Fiori Elements or CBOs, developers can build freestyle SAPUI5applications. These applications consume OData services (often built using classical ABAP or RAP) that expose the custom table data.

Features:

Full UI Control: Developers have complete control over the UI layout, controls, and behavior, allowing for unique branding, complex data entry forms, or highly interactive dashboards.
Flexibility: Allows for highly specific UI/UX requirements that go beyond standard Fiori Elements templates.
Data Binding: Connects to backend data via OData services, which can be built using classical ABAP (SEGW) or RAP.

When to Use:

When your UI/UX requirements are extremely unique, complex, or cannot be met by standard Fiori Elements or CBO-generated UIs.
For highly interactive applications that require a bespoke user experience.

On-Premise Summary: Choosing the Right Persistent Storage Method

Approach	UI Type	Who Builds	Coding Required	Clean Core Alignment	Best Use Case
Classical ABAP (SM30)	SAP GUI (SM30)	Developers	Medium	❌Low	Legacy compatibility, complex tables, TMG event handling
Custom TVARVC Table	SAP GUI (STVARV/SM30)	Developers	Low	❌Low	Simple config parameters, fast implementation
Custom Business Objects (CBOs)	Fiori (Auto-generated)	Key Users / Devs	Low to Medium	✅High	Rapid deployment of Fiori-based maintenance apps
RAP + Fiori Elements	Fiori (Auto-generated)	Developers	Medium to High	✅High	Modern architecture, scalable, maintainable development
Freestyle SAPUI5 App	Fiori (Custom UI)	Developers	High	✅High	Highly customized UI/UX, complex workflows or dashboards

S/4HANA Cloud: The "Clean Core" Paradigm

In SAP S/4HANA Cloud (Public Edition), custom development follows strict “clean core” principles—minimizing direct system modifications to ensure upgrade stability. Traditional ABAP methods like SM30 or TVARVC-based tables are not applicable due to the absence of SAP GUI and limited backend extensibility.

Instead, SAP provides modern, cloud-compliant extensibility options:

1. Custom Business Objects (CBOs): Key User-Friendly and Fiori-Ready

CBOs are the recommended way to handle custom data needs in the cloud. Created via the "Custom Business Objects" Fiori app, they support:

Auto-generated Fiori UI for maintenance (CRUD)
Automatic OData exposure for integration
No-code/low-code development suited for business users
Upgrade-safe by design

Use When: You need a quick, compliant way to store and maintain custom data with minimal developer effort.

2. ABAP Cloud (Embedded Steampunk) + RAP: For Pro Developers

For advanced scenarios, ABAP Cloud (via Embedded Steampunk) allows professional developers to build applications using RAP within ADT. These apps:

Use whitelisted APIs and restricted ABAP syntax
Expose OData services for consumption in Fiori Elements
Are fully aligned with clean core standards

Use When: You need full control over backend logic or have complex business scenarios beyond what key user tools offer.

3. Custom SAPUI5 on BTP: For Bespoke UI Requirements

For highly customized or interactive UIs, build SAPUI5 apps on SAP BTP, consuming OData services from RAP or CBOs.

Use When: Standard Fiori templates don’t meet your UX needs and you want to keep extensions side-by-side (not inside the core).

Summary

Approach	UI Type	Who Builds	Coding Required	Clean Core Compliance	Use Case
CBO	Auto Fiori UI	Key Users	No/Low	✅High	Simple to moderate custom data needs
RAP + Fiori Elements	Auto Fiori UI	Developers	Yes	✅High	Complex business logic, developer-led
SAPUI5 on BTP	Custom UI	Developers	Yes	✅Very High (Side-by-side)	Bespoke UX or standalone apps

Making the Right Choice: A Decision Framework

Choosing the right approach for persistent data storage in your custom RICEF development is a critical decision that impacts development effort, user experience,integration capabilities, performance, security, transportability, and long-term maintainability. To simplify this, consider the following decision framework:

1. Deployment Model First: Are you on S/4HANA On-Premise or S/4HANA Cloud(Public Edition)? This is the most crucial differentiator. Cloud environments are far more restrictive due to the "clean core" strategy.

2. User Experience Requirement: Do your users require a traditional SAP GUI experience (less common now), a modern Fiori app experience, or a highly customized, bespoke UI?

3. Data Model Complexity: Is your custom data simple (key-value pairs), moderately complex (multiple fields, simple associations), or highly complex (intricate relationships, specific performance needs)?

4. Development Effort & Skills: What are your team's existing skills (classical ABAP,RAP, SAPUI5, BTP) and what is the available development budget and timeline?

5. "Clean Core" Adherence: How strictly do you need to adhere to the "clean core"principles for future upgrades and cloud readiness?

Here's a simplified table to guide your decision:

Feature/Consideration	Classical ABAP(On-Premise)	Custom TVARVC (On-Premise)	CBOs (On-Premise &Cloud)	RAP/Fiori Elements(On-Premise &Cloud)	FreestyleUI5 (On-Premise &Cloud)
Deployment	On-Premise	On-Premise	On-Premise &Cloud	On-Premise &Cloud	On-Premise &Cloud
UI Type SAP	SAP GUI(SM30)	SAP GUI(STVARV/SM30)	Fiori(Auto-generated)	Fiori(Auto-generated)	Fiori(Custom)
Data Complexity	High	Low	Medium	High	High
Dev Effort	Medium	Low	Medium	Medium	High
"Clean Core"Alignment	Low	Low	High	High	High(especially via BTP)
Key User Extensibility	No	No	Yes	No(Developer)	No(Developer)
OData Exposure	Manual(SEGW)	No	Automatic	Automatic	Consumes OData
Best For	Legacy, complex DB needs	Simple config	Rapid Fiori apps	Robust Fiori apps,complex logic	Unique UI/UX needs

Final Thoughts

The world of SAP S/4HANA is constantly evolving, and so too are the best practices for custom development. The days of a one-size-fits-all approach are long gone. As ABAP developers and consultants, it's our responsibility to guide our functional colleagues and project teams towards the most appropriate and future-proof solutions.

My recent experience reminded me that while the technical options are abundant, the real challenge lies in understanding the business requirement, the system landscape,and the long-term implications of each choice. By carefully considering the factors outlined above, you can navigate this labyrinth with confidence, ensuring your custom RICEF developments are not only functional but also scalable, maintainable, and aligned with SAP's strategic direction.

Happy coding, and may your custom tables always be clean and performant!

RAP Transactional app: performance considerations for singleton pattern in draft enabled RAP BO

2025-07-01T11:50:32.505000+02:00

Introduction

When developing a transactional app, you can use the singleton pattern for a draft enabled RAP BO to enable editing / inline create on the actual root entity.

In this blog, you will learn how the singleton pattern impacts performance and other advantages and disadvantages of this pattern in the context of Fiori elements.

This blog is relevant for

Example BO

Our data model consists of a table T1 and a corresponding text table T1_TXT.

@EndUserText.label : 'Tab1'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table T1 {
  key client            : abap.clnt not null;
  key k1                : zpw_d1 not null;
  f1                    : abap.char(20);
  f2                    : abap.char(20);
  f3                    : abap.char(20);
  f4                    : abap.char(20);
  f5                    : abap.char(20);
  f6                    : abap.char(20);
  f7                    : abap.char(20);
  f8                    : abap.char(20);
  last_changed_at       : abp_lastchange_tstmpl;
  local_last_changed_at : abp_locinst_lastchange_tstmpl;
}

@EndUserText.label : 'Tab1 Text'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table T1_TXT {
  key client            : abap.clnt not null;
  key langu             : abap.lang not null;
  @AbapCatalog.foreignKey.keyType : #TEXT_KEY
  @AbapCatalog.foreignKey.screenCheck : false
  key k1                : zpw_d1 not null
    with foreign key T1
      where client = T1_TXT.client
        and k1 = T1_TXT.k1;
  description           : abap.char(30);
  local_last_changed_at : abp_locinst_lastchange_tstmpl;
}

Therefore, the draft-enabled RAP BO with singleton pattern consists of the singleton root entity type, T1 entity type, and T1_TXT entity type, each with a draft table.

Singleton draft

When the Edit action is performed on a root entity, a corresponding draft entity including all subentities is created. In the singleton pattern, this basically means that a draft entity is created for all entities of the RAP BO.
Typically, the Edit action is performed when the user clicks the Edit button in the Fiori elements app. You can also use the following ABAP EML statement:

MODIFY ENTITY zi_t1_s
  EXECUTE edit
  FROM VALUE #( ( %cid = |CID1|  singletonid = 1 ) ).
COMMIT ENTITIES.

For our example BO, the Edit action therefore consists of three SQL statements in the form of INSERT INTO <draft table> SELECT FROM <entity type cds view>. No data is passed to the ABAP application server, only one statement per entity type, regardless of the number of entities.

The following measurement was performed in an ABAP Platform performance test system with respect to the above SQL statements as total:

#Rows T1	#Rows T1_TXT	HANA CPU time [ms]	HANA max memory consumption [mb]
10	40	7	1
100	400	75	3
1000	4000	135	6
10000	40000	810	45
100000	400000	7600	437

This table shows the performance impact of the singleton pattern compared to a RAP BO without a singleton pattern. It is linear, so you can extrapolate for a higher number of lines.

If you use ABAP EML to modify entities, you do not need to create a draft entity, so this penalty does not necessarily apply to ABAP EML statements.

The runtime behavior when changing a draft entity or in the action prepare is not affected by the singleton pattern.

During the activation action, the draft entities are discarded using a DELETE statement:

#Rows T1	#Rows T1_TXT	HANA CPU time [ms]	HANA max memory consumption [mb]
10	40	7	1
100	400	7	2
1000	4000	27	4
10000	40000	155	10
100000	400000	430	43

So you can add this to the performance impact.

Logically, these numbers depend on the table and CDS view design as well as the system. But the basic statement remains.

If the user changes more than about 10% of the entities in the interaction phase, the singleton pattern is more performant because draft entities do not always have to be created.

Singleton in Fiori Elements

Using a singleton RAP BO pattern in Fiori elements has the following characteristics:

Multi-line edit/inline creation for the actual root entity
The app can temporarily store global information in the singleton draft entity
All entities of the RAP BO are locked for a user
You cannot use selection fields as the filter bar is only available in the list report. Alternatively, you can add search capabilities to the entity. A search field is then available

See link on how to create a Fiori Elements app for a RAP BO with singleton pattern.

Custom Business Configurations

When you create business configurations app using the ABAP RAP programming model, you use the Custom Business Configurations app and the business configuration maintenance object ADT wizard.

The RAP BO that this wizard generates always uses the singleton pattern for the following reasons:

For configuration tables, you want to have a spreadsheet like user experience
The customizing transport request can be selected once for all entities and stored in the singleton draft entity
Locking the entire configuration for only one user is beneficial. You do not want multiple users to work on the same configuration table in parallel
The performance penalty for the singleton pattern is acceptable because
- Configuration tables rarely have more than 1000 rows, let alone more than 10000 rows
- Most of the configuration takes place in the intended system/client, not in the production client
- The frequency of configuration changes is low
- There is no performance impact when using ABAP EML or the Upload Business Configurations app

The Custom Business Configurations app also supports RAP BO without singleton pattern:

Create the RAP BO / Service binding without using the business configuration maintenance object ADT wizard
Add the relevant transport related functionality to the RAP BO
Create the business configuration maintenance object (SMBC) manually. Leave the option "Skip root entity list report" unchecked

Conclusion

Do not use the singleton pattern if the RAP BO handles more than 50000 entities and the app is used frequently.

Customer & Partner Roundtable for SAP BTP ABAP Environment #25

2025-07-01T15:05:16.176000+02:00

👉 The call for contributions for one of the upcoming roundtables is open!

If you want to show a demo or share a use case scenario for SAP BTP ABAP Environment send us an email and we will get back to you.

Introduction

As SAP BTP ABAP environment (aka Steampunk) and ABAP Cloud became more popular inside and outside of SAP, there is a high demand for rolling out the latest product news and updates, asking questions, and showing demos.

💡 You can find the slides presented, recordings, and further references from the previous roundtables in this GitHub repository.

Meeting Information

When:

July 31, 10:00 - 11:00 AM CEST – Zoom Meeting (please register in advance)

Who:

All interested customers, partners, and stakeholders are invited to join this roundtable
BTP ABAP team:
- Frank Jentsch (Product Lead for SAP BTP ABAP Environment)
- Iwona Hahn (BTP ABAP Product Management)
Partner blue-zone GmbH:
- Andreas Klose (Director Software Development)
- Christof Unterste (Solution Architect)

Preliminary Agenda:

Product update for SAP BTP ABAP Environment
Partner live demo: EDI-ZONE (EDI & eInvoicing Solution) - managed SaaS solution on SAP BTP ABAP Environment: subaccount handling, customer onboarding etc.
Q&A

Looking forward to meeting you!

Check out our SAP Business Technology ABAP Environment page in SAP Community for product updates and upcoming events.

Side Effects in RAP Explained with Determination Example

2025-07-02T10:28:03.987000+02:00

In the world of SAP RAP (RESTful Application Programming), Determinations and Side Effects play a crucial role in delivering responsive and intelligent user experiences. While determinations are used to implement logic that reacts to changes in data during specific RAP phases (such as on modify or on save), side effects ensure that related fields or entities stay consistent and updated on the UI without additional user actions.

In his blog, I will demonstrate a practical scenario where determinations are used to dynamically calculate values based on user input, and side effects are configured to immediately reflect these changes on the UI. This not only improves the data integrity but also enhances usability in Fiori applications. By the end of this post, you will have a clearer understanding of how to leverage determinations and side effects together effectively within a RAP-based application.

DETERMINATION :

Actions modifies the existing BO instance where as Determination modifies the existing BO instances based on some trigger condition

We can see that Actions also triggers based on the conditions but cannot modify the BO instances , we can be able to throw the error messages.

Pre requisites :

During modification we change/modify some fields / requirements and we can compute the values of particular fields

Determination can be called during Transactional phase/Save sequence where as validations always called during the save sequence

Once a determination has been triggered , it must run independently from other determinations

During determination result must change if we execute detrmination several time under same condition

Scenario :

Here the determination calculateTotalPrice which is defined for all the three entities

(Travel, booking and booking supplements) handles the calculation of total price of one travel.

Based on the booking Fee total price must be calculated for the travel

SIDE-EFFECTS:

The SAP Fiori UI does not necessarily trigger a reload of all related BO after every User input , as it simply does not know anything about data changes on the tables

Side effects are used to reload data, permissions or messages based on data changes in UI scenarios with draft enabled BO’s

Side effects reloads the screen but it does not reload entire screen

It changes some of the field values or will enable/ disable some of the fied values Or status of the data in transactional buffer --> based on these same things should appear in the front end

We need to define side effects in Behaviour definition

Side effects will only reload the fields in front end ,nothing will happen in backend

The data which is available in the backend it will reload in the front end whihc is not currently displaying properly

Side effects have two parts :

Triggering condition : specifies when you should reload ( can be actions / validations)

Target : which fields should get reloaded ( value of a field / multiple fields / reload entire entity )

Important points:

Determinations calculates the total price and updates it into the transcational buffer

But in the front end screen older values will be there .

Requirement :

Whenever I change the booking fee and booking supplement data and flight price

The total price should be updated not only in transactional buffer but also in the front end automatically

And whenever we are updating booking fee the reload of total price should happen

Based on the trigger condition --> it should reload the values / fields

Here the source --> Booking fee

Target --> totalprice

Syntax:

Side effects { filed MyField affects Target }

{ $self affects Targets ; }

{ action MyAction affects Tragets ;}

{ determine action MyDetermineAction

Executed on sources

Affects Tagets } .

In the target we can specify :

$self : The current RAP BO is reloaded

Entity _MyAssoc : the specified associated entity _MyAssoc is reloaded when the side effect is triggered

Message : all the messages in the response parameter reported are reloaded when the side effects is triggered

We can also als provide multiple targets

Side effects { field MyField affects Field1 , Field2 , action Action1 ,

Action Action 2 [..] }

RESTRICTIONS :

Static actions defined using the addition static must not be used as a side effect trigger , nor as a side effect target

In case of the trigger entity property $sefl , the target cannot be a field of the current entity $self itself ,

However fields from the associated entity can be defined using path expressions

Side Effect In BDL:

Side effects can be specified exactly once for each RAP BO entity in the entity

Behaviour definition

Multiple side effects can be summarized with curly brackets , separated by a semicolon (; ) , if required.

The syntax ‘use side effects’ is specified in the behaviour definition header and all side effects from all RAP BO entities of the underlying RAP BO are reused

1. Create db table for travel

@EndUserText.label : 'travel table' 
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE 
@AbapCatalog.tableCategory : #TRANSPARENT 
@AbapCatalog.deliveryClass : #A 
@AbapCatalog.dataMaintenance : #RESTRICTED 
define table zpd_dt_travel {
 
key client : abap.clnt not null; 
key travel_id : /dmo/travel_id not null; 
agency_id : /dmo/agency_id; 
customer_id : /dmo/customer_id; 
begin_date : /dmo/begin_date; 
end_date : /dmo/end_date; 
@Semantics.amount.currencyCode : 'zpd_dt_travel.currency_code' 
booking_fee : /dmo/booking_fee; 
@Semantics.amount.currencyCode : 'zpd_dt_travel.currency_code' 
total_price : /dmo/total_price; 
currency_code : /dmo/currency_code; 
description : /dmo/description; 
overall_status : /dmo/overall_status; 
created_by : abp_creation_user; 
created_at : abp_creation_tstmpl; 
last_changed_by : abp_locinst_lastchange_user; 
last_changed_at : abp_locinst_lastchange_tstmpl; 

}

2.Create db table for Booking

@EndUserText.label : 'tbale for booking details' 
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE 
@AbapCatalog.tableCategory : #TRANSPARENT 
@AbapCatalog.deliveryClass : #A 
@AbapCatalog.dataMaintenance : #RESTRICTED 
define table zpd_dt_booking { 

key client : abap.clnt not null; 
@AbapCatalog.foreignKey.label : 'Travel' 
@AbapCatalog.foreignKey.screenCheck : false 
key travel_id : /dmo/travel_id not null 
with foreign key [0..*,1] zpd_dt_travel 
where travel_id = zpd_dt_booking.travel_id; 
key booking_id : /dmo/booking_id not null; 
booking_date : /dmo/booking_date; 
customer_id : /dmo/customer_id; 
carrier_id : /dmo/carrier_id; 
connection_id : /dmo/connection_id; 
flight_date : /dmo/flight_date; 
@Semantics.amount.currencyCode : 'zpd_dt_booking.currency_code' 
flight_price : /dmo/flight_price; 
currency_code : /dmo/currency_code; 
booking_status : /dmo/booking_status; 
last_changed_at : abp_locinst_lastchange_tstmpl; 

}

3.Crete a db table for Booking suppliment

@EndUserText.label : 'booking supplimnet' 
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE 
@AbapCatalog.tableCategory : #TRANSPARENT 
@AbapCatalog.deliveryClass : #A 
@AbapCatalog.dataMaintenance : #RESTRICTED 
define table zpd_dt_bsupplmnt { 

key client : abap.clnt not null; 
@AbapCatalog.foreignKey.label : 'Travel' 
@AbapCatalog.foreignKey.screenCheck : false 
key travel_id : /dmo/travel_id not null 
with foreign key [0..*,1] zpd_dt_travel 
where travel_id = zpd_dt_bsupplmnt.travel_id; 
@AbapCatalog.foreignKey.label : 'Booking' 
@AbapCatalog.foreignKey.screenCheck : false 
key booking_id : /dmo/booking_id not null 
with foreign key [0..*,1] zpd_dt_booking 
where travel_id = zpd_dt_bsupplmnt.travel_id 
and booking_id = zpd_dt_bsupplmnt.booking_id; 
key booking_supplement_id : /dmo/booking_supplement_id not null; 
supplement_id : /dmo/supplement_id; 
@Semantics.amount.currencyCode : 'zpd_dt_bsupplmnt.currency_code' 
price : /dmo/supplement_price; 
currency_code : /dmo/currency_code; 
last_changed_at : abp_locinst_lastchange_tstmpl; 

}

4.Create a root view entity for travel

AbapCatalog.viewEnhancementCategory: [#NONE] 
@AccessControl.authorizationCheck: #NOT_REQUIRED 
@EndUserText.label: 'root view for travel' 
@Metadata.ignorePropagatedAnnotations: true 
@ObjectModel.usageType:{ 
serviceQuality: #X, 
sizeCategory: #S, 
dataClass: #MIXED 

} 

define root view entity zi_travel_detail as select from zpd_dt_travel 
composition [0..*] of ZI_BOOKING_DETAIL as _booking 
association [0..1] to /DMO/I_Agency as _agency on $projection.AgencyId = _agency.AgencyID  
association [0..1] to /DMO/I_Customer as _customer on $projection.CustomerId = _customer.CustomerID 
association [1..1] to I_Currency as _currency on $projection.CurrencyCode = _currency.Currency 
association [1..1] to /DMO/I_Overall_Status_VH as _status on $projection.OverallStatus = _status.OverallStatus 

{ 

key travel_id as TravelId, 
agency_id as AgencyId, 
customer_id as CustomerId, 
begin_date as BeginDate, 
end_date as EndDate, 
@Semantics.amount.currencyCode: 'CurrencyCode' 
booking_fee as BookingFee, 
@Semantics.amount.currencyCode: 'CurrencyCode' 
total_price as TotalPrice, 
currency_code as CurrencyCode, 
description as Description, 
overall_status as OverallStatus, 
@Semantics.user.createdBy: true 
created_by as CreatedBy, 
@Semantics.systemDateTime.createdAt: true 
created_at as CreatedAt, 
@Semantics.user.localInstanceLastChangedBy: true 
last_changed_by as LastChangedBy, 
@Semantics.systemDateTime.localInstanceLastChangedAt: true 
last_changed_at as LastChangedAt, 
_agency, 
_customer, 
_currency, 
_status, 
_booking 

}

5.Create interface view for booking

@EndUserText.label: 'root view for booking' 
@Metadata.ignorePropagatedAnnotations: true 
@ObjectModel.usageType:{ 
serviceQuality: #X, 
sizeCategory: #S, 
dataClass: #MIXED 

} 

define view entity ZI_BOOKING_DETAIL as select from zpd_dt_booking association to parent zi_travel_detail as _travel 
on $projection.TravelId = _travel.TravelId 
composition [0..*] of zi_booking_supp as _bookingsuppl  
association [1..1] to /DMO/I_Carrier as _carrier on $projection.CarrierId = _carrier.AirlineID 
association [1..1] to /DMO/I_Customer as _customer on $projection.CustomerId = _customer.CustomerID  
association [1..1] to /DMO/I_Connection as _connection on $projection.CarrierId = _connection.AirlineID 
and $projection.ConnectionId = _connection.ConnectionID 
association[1..1] to /DMO/I_Booking_Status_VH as _booking_status on $projection.BookingStatus = _booking_status.BookingStatus  

{  

key travel_id as TravelId, 
key booking_id as BookingId, 
booking_date as BookingDate, 
customer_id as CustomerId, 
carrier_id as CarrierId, 
connection_id as ConnectionId, 
flight_date as FlightDate, 
@Semantics.amount.currencyCode: 'CurrencyCode' 
flight_price as FlightPrice, 
currency_code as CurrencyCode, 
booking_status as BookingStatus, 
@Semantics.systemDateTime.localInstanceLastChangedAt: true 
last_changed_at as LastChangedAt, 
_carrier, 
_customer,
_connection,
_booking_status, 
_travel, 
_bookingsuppl 
}

6.Create Interface view for Booking suppliment

@AbapCatalog.viewEnhancementCategory: [#NONE] 
@AccessControl.authorizationCheck: #NOT_REQUIRED 
@EndUserText.label: 'root view for booking suppliment' 
@Metadata.ignorePropagatedAnnotations: true 
@ObjectModel.usageType:{ 
serviceQuality: #X, 
sizeCategory: #S, 
dataClass: #MIXED 
} 

define view entity zi_booking_supp as select from zpd_dt_bsupplmnt 
association to parent ZI_BOOKING_DETAIL as _booking on $projection.TravelId = _booking.TravelId 
and $projection.BookingId = _booking.BookingId 
association[1..1] to zi_travel_detail as _travel on $projection.TravelId = _travel.TravelId 
association [1..1] to /DMO/I_Supplement as _suppliment on $projection.SupplementId = _suppliment.SupplementID 
association[1..*] to /DMO/I_SupplementText as _supplimentText on $projection.SupplementId = _supplimentText.SupplementID  

{ 

key travel_id as TravelId,  
key booking_id as BookingId, 
key booking_supplement_id as BookingSupplementId, 
supplement_id as SupplementId, 
@Semantics.amount.currencyCode: 'CurrencyCode' 
price as Price, 
currency_code as CurrencyCode, 
@Semantics.systemDateTime.localInstanceLastChangedAt: true 
last_changed_at as LastChangedAt, 
_travel, 
_supplimentText, 
_suppliment, 
_booking 

}

7.Define projection for travel root entity

@AccessControl.authorizationCheck: #NOT_REQUIRED 
@EndUserText.label: 'consumption view for travel' 
@Metadata.ignorePropagatedAnnotations: true 
@Metadata.allowExtensions: true 
define root view entity zc_travel_det provider contract transactional_query 
as projection on zi_travel_detail 

{ 

key TravelId, 
@ObjectModel.text.element: [ 'AgencyName' ] 
AgencyId, 
_Agency.Name as AgencyName, 
@ObjectModel.text.element: [ 'CustomerName' ] 
CustomerId, 
_Customer.LastName as CustomerName, 
BeginDate, 
EndDate, 
@Semantics.amount.currencyCode: 'CurrencyCode' 
BookingFee, 
@Semantics.amount.currencyCode: 'CurrencyCode' 
TotalPrice, 
CurrencyCode, 
Description, 
@ObjectModel.text.element: [ 'OverallStatusText' ] 
OverallStatus, 
_Status._Text.Text as OverallStatusText : localized, 
CreatedBy, 
CreatedAt, 
LastChangedBy, 
LastChangedAt, 
/* Associations */ 
_Agency, 
_booking : redirected to composition child zc_booking_det, 
_Currency, 
_Customer, 
_Status 

}

8.Define projection for booking entity

@AccessControl.authorizationCheck: #NOT_REQUIRED 
@EndUserText.label: 'consumption view for booking' 
@Metadata.ignorePropagatedAnnotations: true 
@Metadata.allowExtensions: true 
define view entity zc_booking_det  
as projection on ZI_BOOKING_DETAIL 
{ 

key TravelId, 
key BookingId, 
BookingDate, 
@ObjectModel.text.element: [ 'CustomerName' ] 
@Consumption.valueHelpDefinition: [{ entity: { 
name: '/DMO/I_Customer', 
element: 'CustomerID' 

} }] 

CustomerId, 
_customer.LastName as CustomerName, 
@ObjectModel.text.element: [ 'CarrierName' ] 
@Consumption.valueHelpDefinition: [{ entity: { 
name: '/DMO/I_Carrier', 
element: 'AirlineId' 

} }] 

CarrierId, 
_carrier.Name as CarrierName, 
@Consumption.valueHelpDefinition: [{ entity: { 
name: '/DMO/I_Flight', 
element: 'Connection Id' 

}  

}] 
ConnectionId,  
FlightDate, 
@Semantics.amount.currencyCode: 'CurrencyCode' 
FlightPrice, 
CurrencyCode, 
@ObjectModel.text.element: [ 'BookingStatusText' ] 
_booking_status._Text.Text as BookingStatusText : localized, 
@Consumption.valueHelpDefinition: [{ entity: { 
name: '/DMO/I_Booking_Status_VH', 
element: 'Booking_Status' 

} }] 
BookingStatus, 
LastChangedAt, 
/* Associations */ 
_bookingsuppl : redirected to composition child zc_booking_supp, 
_booking_status, 
_carrier, 
_connection, 
_customer, 
_travel : redirected to parent zc_travel_det 

}

9.Define projection for booking suppliment entity

@AccessControl.authorizationCheck: #NOT_REQUIRED 
@EndUserText.label: 'consumption view for booking suppliment' 
@Metadata.ignorePropagatedAnnotations: true 
@Metadata.allowExtensions: true 
define view entity zc_booking_supp  
as projection on zi_booking_supp 

{ 

key TravelId, 
key BookingId, 
key BookingSupplementId, 
@ObjectModel.text.element: [ 'SupplemenDesc' ] 
SupplementId, 
_SupplementText.Description as SupplemenDesc : localized, 
@Semantics.amount.currencyCode: 'CurrencyCode' 
Price, 
CurrencyCode, 
LastChangedAt, 
/* Associations */ 
_Travel : redirected to zc_travel_det,
_Booking : redirected to parent zc_booking_det, 
_Supplement, 
_SupplementText 

}

10.provide metada extension for projected views

@Metadata.layer: #CORE 

@Search.searchable: true 
@UI.headerInfo: { 
typeName: 'Travel', 
typeNamePlural: 'Travels', 

title: { 
type: #STANDARD, 
label: 'Travel', 
value: 'TravelId' 

} 

} 
annotate view zc_travel_det 
with  

{ 

@UI.facet: [{ 
id: 'Travel', 
purpose: #STANDARD, 
position: 10 , 
label: 'Travel', 
type: #IDENTIFICATION_REFERENCE 

}, 

{ 

id: 'Booking', 
purpose: #STANDARD, 
position: 20 , 
label: 'Booking', 
type: #LINEITEM_REFERENCE, 
targetElement: '_booking' 

} 

] 

@UI.lineItem: [{ position: 10 }, { type:#FOR_ACTION, dataAction: 'CopyTravel', label: 'Copy Travel' } 
,{ type:#FOR_ACTION, dataAction: 'AcceptTravel', label: 'AcceptTravel' } 
,{ position: 30 },{ type:#FOR_ACTION, dataAction: 'RejectTravel', label: 'RejectTravel' }] 
@UI.identification: [{ position: 10 }] 
@Search.defaultSearchElement: true 
TravelId; 
@UI: { lineItem: [{ position: 40 }], 
selectionField: [{ position: 40 }], 
identification: [{ position: 40 }] 

} 

@Search.defaultSearchElement: true 
@Consumption.valueHelpDefinition: [{ entity: { 
name: '/DMO/I_Agency', 
element: 'AgencyID' 

} }] 

AgencyId; 
// AgencyName; 
@UI: { lineItem: [{ position: 50 }], 
selectionField: [{ position: 50 }], 
identification: [{ position: 50 }] 
} 
@Search.defaultSearchElement: true 
@Consumption.valueHelpDefinition: [{ entity: { 
name: '/DMO/I_Customer', 
element: 'CustomerID' 

} }] 
CustomerId; 
// CustomerName; 
@UI.lineItem: [{ position: 60 }] 
@UI.identification: [{ position: 60 }] 
BeginDate; 
@UI.lineItem: [{ position: 70 }] 
@UI.identification: [{ position: 70 }] 
EndDate; 
@UI.identification: [{ position: 75 }] 
BookingFee; 
@UI.lineItem: [{ position: 80 }] 
@UI.identification: [{ position: 80 }] 
TotalPrice; 
@Consumption.valueHelpDefinition: [{ entity: { 
name: 'I_Currency', 
element: 'Currency' 
} }] 

CurrencyCode; 
@UI.identification: [{ position: 85 }] 
Description; 
@UI: { lineItem: [{ position: 90 }],
selectionField: [{ position: 60 }], 
identification: [{ position: 90 }],
textArrangement: #TEXT_ONLY 
} 
@Search.defaultSearchElement: true 
@Consumption.valueHelpDefinition: [{ entity: { 
name: '/DMO/I_Overall_Status_VH', 
element: 'OverallStatus' 
} }] 

OverallStatus; 
// OverallStatusText;
// .hidden: true 
// LastChangedAt; 

}

11. metadata extension for booking entity

@Metadata.layer: #CORE 

@Search.searchable: true 
@UI.headerInfo: { 
typeName: 'Booking',
typeNamePlural: 'Bookings', 

title: { 
type: #STANDARD, 
label: 'Booking', 
value: 'BookingId' 

} 

} 

annotate view zc_booking_det 

with  

{ 

@UI.facet: [{ 
id: 'Booking', 
purpose: #STANDARD,
position: 10 , 
label: 'Booking', 
type: #IDENTIFICATION_REFERENCE 

}, 

{ 

id: 'BookingSuppl', 
purpose: #STANDARD, 
position: 20 ,  
label: 'Booking Suppliments', 
type: #LINEITEM_REFERENCE, 
targetElement: '_bookingsuppl' 

} 

] 

// .defaultSearchElement: true 
// TravelId; 

@UI.lineItem: [{ position: 10 }] 
@UI.identification: [{ position: 10 }] 
@Search.defaultSearchElement: true 
BookingId; 
@UI.lineItem: [{ position: 20 }] 
@UI.identification: [{ position: 20 }] 

BookingDate; 
@UI.lineItem: [{ position: 30 }] 
@UI.identification: [{ position: 30 }] 
@Search.defaultSearchElement: true 
@Consumption.valueHelpDefinition: [{ entity: { 
name: '/DMO/I_Customer',
element: 'CustomerID' 

} }] 

CustomerId; 
@UI.lineItem: [{ position: 40 }] 
@UI.identification: [{ position: 40 }] 
@Consumption.valueHelpDefinition: [{ entity: { 
name: '/DMO/I_Carrier', 
element: 'AirlineID' 

} }] 

CarrierId; 
@UI.lineItem: [{ position: 50 }] 
@UI.identification: [{ position: 50 }] 
@Consumption.valueHelpDefinition: [{ entity: { 
name: '/DMO/I_Flight', 
element: 'ConnectionId' 

}, 

additionalBinding: [{ element: 'ConnectionId' ,  
localElement: 'ConnectionID'}, 
{ element: 'AirlineID' ,  
localElement: 'CarrierId'},  
{ element: 'CurrencyCode' ,  
localElement: 'CurrencyCode'}, 
{ element: 'Price' ,  
localElement: 'FlightPrice'} ] 

}]  

ConnectionId; 
@UI.lineItem: [{ position: 60 }] 
@UI.identification: [{ position: 60 }] 
@Consumption.valueHelpDefinition: [{ entity: { 
name: '/DMO/I_Flight', 
element: 'FlightDate' 

}, 

additionalBinding: [{ element: 'FlightDate' ,  
localElement: 'FlightDate'}, 
{ element: 'AirlineID' ,  
localElement: 'CarrierId'},  
{ element: 'CurrencyCode' ,  

localElement: 'CurrencyCode'}, 
{ element: 'Price' ,  
localElement: 'FlightPrice'} ] 

}]  

FlightDate; 
@UI.lineItem: [{ position: 70 }] 
@UI.identification: [{ position: 70 }] 
FlightPrice; 
// @Consumption.valueHelpDefinition: [{ entity: { 
// name: 'I_Currency', 
// element: 'Currency' 

// } }] 

// CurrencyCode; 
@UI.lineItem: [{ position: 80 }]
@UI.identification: [{ position: 80 }] 
@UI.textArrangement: #TEXT_ONLY 
@Consumption.valueHelpDefinition: [{ entity: { 
name: '/DMO/I_Booking_Status_VH', 
element: 'BookingStatus' 

} }] 

BookingStatus; 
// LastChangedAt; 

}

12. Metadata extension for booking entity

@Metadata.layer: #CORE 

@Search.searchable: true 
@UI.headerInfo: { 
typeName: 'Booking', 
typeNamePlural: 'Bookings', 
title: { 
type: #STANDARD, 
label: 'Booking', 
value: 'BookingId' 

} 

} 
annotate view zc_booking_det 
with  

{ 

@UI.facet: [{ 
id: 'Booking', 
purpose: #STANDARD, 
position: 10 , 
label: 'Booking', 
type: #IDENTIFICATION_REFERENCE 

}, 

{ 

id: 'BookingSuppl', 
purpose: #STANDARD, 
position: 20 ,  
label: 'Booking Suppliments', 
type: #LINEITEM_REFERENCE, 
targetElement: '_bookingsuppl' 

} 

] 
// .defaultSearchElement: true 
// TravelId; 

@UI.lineItem: [{ position: 10 }] 
@UI.identification: [{ position: 10 }] 
@Search.defaultSearchElement: true 
BookingId; 
@UI.lineItem: [{ position: 20 }] 
@UI.identification: [{ position: 20 }] 
BookingDate; 
@UI.lineItem: [{ position: 30 }] 
@UI.identification: [{ position: 30 }] 
@Search.defaultSearchElement: true 
@Consumption.valueHelpDefinition: [{ entity: {
name: '/DMO/I_Customer', 
element: 'CustomerID' 

} }] 

CustomerId; 
@UI.lineItem: [{ position: 40 }] 
@UI.identification: [{ position: 40 }] 
@Consumption.valueHelpDefinition: [{ entity: { 
name: '/DMO/I_Carrier', 
element: 'AirlineID' 

} }] 

CarrierId; 
@UI.lineItem: [{ position: 50 }] 
@UI.identification: [{ position: 50 }] 
@Consumption.valueHelpDefinition: [{ entity: { 
name: '/DMO/I_Flight', 
element: 'ConnectionId' 

}, 
additionalBinding: [{ element: 'ConnectionId' ,  
localElement: 'ConnectionID'}, 

{ element: 'AirlineID' ,  
localElement: 'CarrierId'},  
{ element: 'CurrencyCode' ,  
localElement: 'CurrencyCode'}, 
{ element: 'Price' , 
localElement: 'FlightPrice'} ] 

}]  
ConnectionId; 
@UI.lineItem: [{ position: 60 }] 
@UI.identification: [{ position: 60 }] 
@Consumption.valueHelpDefinition: [{ entity: { 
name: '/DMO/I_Flight', 
element: 'FlightDate' 

}, 

additionalBinding: [{ element: 'FlightDate' ,  
localElement: 'FlightDate'}, 
{ element: 'AirlineID' ,  
localElement: 'CarrierId'},  
{ element: 'CurrencyCode' ,  
localElement: 'CurrencyCode'}, 
{ element: 'Price' ,  
localElement: 'FlightPrice'} ] 

}]  
FlightDate; 
@UI.lineItem: [{ position: 70 }] 
@UI.identification: [{ position: 70 }] 

FlightPrice; 
// @Consumption.valueHelpDefinition: [{ entity: { 
// name: 'I_Currency', 
// element: 'Currency' 
// } }] 

// CurrencyCode; 
@UI.lineItem: [{ position: 80 }] 
@UI.identification: [{ position: 80 }] 
@UI.textArrangement: #TEXT_ONLY 
@Consumption.valueHelpDefinition: [{ entity: { 
name: '/DMO/I_Booking_Status_VH', 
element: 'BookingStatus' 

} }] 
BookingStatus; 
// LastChangedAt; 


}

13. Metadata extension for booking suppliment entity

@Metadata.layer: #CORE 

@Search.searchable: true 
@UI.headerInfo: { 
typeName: 'BookingSuppl', 
typeNamePlural: 'BookingSuppls', 
title: { 
type: #STANDARD, 
label: 'Booking Suppliments', 
value: 'BookingSupplementId' 

} 
} 

annotate view zc_booking_supp 
with  
{ 
@UI.facet: [{ 
id: 'BookingSuppl', 
purpose: #STANDARD, 
position: 10 ,
label: 'Booking Suppliments', 
type: #IDENTIFICATION_REFERENCE 
} 
] 
// @Search.defaultSearchElement: true 
// TravelId; 
@Search.defaultSearchElement: true 
BookingId; 
@UI.lineItem: [{ position: 10 }] 
@UI.identification: [{ position: 10 }] 
BookingSupplementId; 
@UI.lineItem: [{ position: 20 }] 
@UI.identification: [{ position: 20 }] 
@Consumption.valueHelpDefinition: [{ entity: { 
name: '/DMO/I_SUPPLEMENT', 
element: 'SupplementID' 
}, 

additionalBinding: [{ element: 'SupplementID' , 
localElement: 'SupplementId'}, 
{ element: 'Price' , 
localElement: 'Price'}, 
{ element: 'CurrencyCode' , 
localElement: 'CurrencyCode'} 

] 

}] 
SupplementId; 
@UI.lineItem: [{ position: 30 }] 
@UI.identification: [{ position: 30 }] 

Price; 
// @Consumption.valueHelpDefinition: [{ entity: { 
// name: 'I_Currency', 
// element: 'Currency' 
// } }] 
// CurrencyCode; 
// @UI.hidden: true 
// LastChangedAt; 

}

14. Create behaviour definition travel root entity

managed; 

strict ( 2 ); 
define behavior for zi_travel_detail //alias <alias_name> 
implementation in class zcl_bp_travel_maa unique 
persistent table zpd_dt_travel 
lock master 
authorization master ( global ) 
etag master LastChangedAt 
early numbering 

{ 

field ( readonly ) TravelId; 
action AcceptTravel result [1] $self; 
action RejectTravel result [1] $self; 

factory action CopyTravel [1]; 
internal action RecalcTotalPrice; 
determination CalcTotalPrice on modify { create; field BookingFee, CurrencyCode; } 

// authorization ( global ), 
create; 
update; 
delete; 
// field ( readonly ) TravelId; 
association _booking { create; } 
mapping for zpd_dt_travel 
{ 

TravelId = travel_id; 
AgencyId = agency_id; 
CustomerId = customer_id; 
BeginDate = begin_date; 
EndDate = end_date; 
BookingFee = booking_fee; 
TotalPrice = total_price; 
CurrencyCode = currency_code; 
Description = description; 
OverallStatus = overall_status; 
CreatedBy = created_by; 
CreatedAt = created_at; 
LastChangedBy = last_changed_by; 
LastChangedAt = last_changed_at; 

} 
} 
define behavior for ZI_BOOKING_DETAIL //alias <alias_name> 
implementation in class zcl_bp_booking_ma unique 
persistent table zpd_dt_booking 
lock dependent by _Travel 
//authorization dependent by _travel 
authorization master ( global ) 
etag master LastChangedAt 
early numbering 
{ 
update; 
delete; 
field ( readonly ) TravelId, BookingId;

determination CalcTotalPrice on modify { create; field FlightPrice, CurrencyCode; } 
association _travel; 
association _bookingsuppl { create; } 
mapping for zpd_dt_booking 

{ 
TravelId = travel_id; 
BookingId = booking_id; 
BookingDate = booking_date; 
CustomerId = customer_id; 
CarrierId = carrier_id; 
ConnectionId = connection_id; 
FlightDate = flight_date; 
FlightPrice = flight_price; 

CurrencyCode = currency_code; 
BookingStatus = booking_status; 
LastChangedAt = last_changed_at; 

} 

} 
define behavior for zi_booking_supp //alias <alias_name> 
implementation in class zcl_bp_booking_ma unique 
persistent table zpd_dt_bsupplmnt 
lock dependent by _Travel 
//authorization dependent by _Travel 
authorization master ( global ) 
etag master LastChangedAt 
early numbering 

{ 
update; 
delete; 
field ( readonly ) TravelId, BookingId, BookingSupplementId; 
determination CalcTotalPrice on modify { create; field Price, CurrencyCode; } 
association _Travel; 
association _Booking; 
mapping for zpd_dt_bsupplmnt 
{ 

SupplementId = supplement_id; 
TravelId = travel_id; 
BookingId = booking_id; 
BookingSupplementId = booking_supplement_id; 
Price = price; 
CurrencyCode = currency_code; 
LastChangedAt = last_changed_at; 

} 

}

15. Define behavior definition for projection root entity

projection; 

strict ( 2 );
define behavior for zc_travel_det //alias <alias_name> 

{ 
use create; 
use update; 
use delete; 

use action AcceptTravel; 
use action RejectTravel; 
use action CopyTravel; 
use association _booking { create; } 

} 
define behavior for zc_booking_det //alias <alias_name> 

{ 

use update; 
use delete; 
use association _travel; 
use association _bookingsuppl { create; } 

} 

define behavior for zc_booking_supp //alias <alias_name> 
{ 

use update; 
use delete; 

use association _Travel; 
use association _Booking; 

}

16. Create Service Definition

@EndUserText.label: 'service def for travel' 
define service Zsr_travel_det { 

expose zc_travel_det; 
expose zc_booking_det; 
expose zc_booking_supp;
expose /DMO/I_Supplement_StdVH as Supplement; 
expose /DMO/I_SupplementCategory_VH as SupplementCategory; 
expose /DMO/I_Customer_StdVH as Passenger; 
expose /DMO/I_Agency_StdVH as TravelAgency; 
expose /DMO/I_Carrier_StdVH as Airline; 
expose /DMO/I_Connection_StdVH as FlightConnection; 
expose /DMO/I_Flight_StdVH as Flight; 
expose /DMO/I_Airport_StdVH as Airport; 
expose /DMO/I_Overall_Status_VH as OverallStatus; 
expose /DMO/I_Booking_Status_VH as BookingStatus; 
expose I_CurrencyStdVH as Currency; 
expose I_CountryVH as Country; 

}

17. Create service binding

18. Implement the class

CLASS lhc_zi_travel_detail DEFINITION INHERITING FROM cl_abap_behavior_handler. 

PRIVATE SECTION. 

METHODS get_global_authorizations FOR GLOBAL AUTHORIZATION 
IMPORTING REQUEST requested_authorizations FOR zi_travel_detail RESULT result. 
METHODS accepttravel FOR MODIFY 
IMPORTING keys FOR ACTION zi_travel_detail~accepttravel RESULT result. 
METHODS copytravel FOR MODIFY 
IMPORTING keys FOR ACTION zi_travel_detail~copytravel. 
METHODS recalctotalprice FOR MODIFY 
IMPORTING keys FOR ACTION zi_travel_detail~recalctotalprice. 
METHODS rejecttravel FOR MODIFY 
IMPORTING keys FOR ACTION zi_travel_detail~rejecttravel RESULT result. 
METHODS calctotalprice FOR DETERMINE ON MODIFY 
IMPORTING keys FOR zi_travel_detail~calctotalprice. 
METHODS earlynumbering_cba_booking FOR NUMBERING 
IMPORTING entities FOR CREATE zi_travel_detail\_booking. 
METHODS earlynumbering_create FOR NUMBERING 
IMPORTING entities FOR CREATE zi_travel_detail. 

ENDCLASS. 

CLASS lhc_zi_travel_detail IMPLEMENTATION. 
METHOD get_global_authorizations. 
ENDMETHOD. 

METHOD earlynumbering_create. 
DATA(lt_entities) = entities. 
DELETE lt_entities WHERE TravelId IS NOT INITIAL . 
TRY. 
cl_numberrange_runtime=>number_get( 

EXPORTING 
nr_range_nr = '01' 
object = '/DMO/TRV_M' 
quantity = CONV #( lines( lt_entities ) ) 
IMPORTING 
number = DATA(lv_latest_num) 
returncode = DATA(lv_code) 
returned_quantity = DATA(lv_qty) 

). 
CATCH cx_nr_object_not_found. 
CATCH cx_number_ranges INTO DATA(lo_error). 

LOOP AT lt_entities INTO DATA(ls_entities). 
APPEND VALUE #( %cid = ls_entities-%cid 
%key = ls_entities-%key ) 
TO failed-zi_travel_detail. 
APPEND VALUE #( %cid = ls_entities-%cid 
%key = ls_entities-%key 
%msg = lo_error ) 
TO reported-zi_travel_detail. 
ENDLOOP. 
EXIT. 
ENDTRY.. 

ASSERT lv_qty = lines( lt_entities ). 
DATA(lv_curr_num) = lv_latest_num - lv_qty. 
LOOP AT lt_entities INTO ls_entities. 
lv_curr_num = lv_curr_num + 1. 
APPEND VALUE #( %cid = ls_entities-%cid 
TravelId = lv_curr_num ) 
TO mapped-zi_travel_detail. 
ENDLOOP. 
ENDMETHOD. 

METHOD earlynumbering_cba_Booking. 

DATA : lv_max_booking TYPE /dmo/booking_id. 
READ ENTITIES OF zi_travel_detail IN LOCAL MODE 
ENTITY zi_travel_detail BY \_booking 
FROM CORRESPONDING #( entities ) 
LINK DATA(lt_link_data). 
LOOP AT entities ASSIGNING FIELD-SYMBOL(<ls_group_entity>) 
GROUP BY <ls_group_entity>-TravelId. 

lv_max_booking = REDUCE #( INIT lv_max = CONV /dmo/booking_id( '0' ) 
FOR ls_link IN lt_link_data USING KEY entity 
WHERE ( source-TravelId = <ls_group_entity>-TravelId ) 
NEXT lv_max = COND /dmo/booking_id( WHEN lv_max < ls_link-target-BookingId 
THEN ls_link-target-BookingId 
ELSE lv_max ) ). 

lv_max_booking = REDUCE #( INIT lv_max = lv_max_booking 
FOR ls_entity IN entities USING KEY entity 
WHERE ( TravelId = <ls_group_entity>-TravelId ) 
FOR ls_booking IN ls_entity-%target 
NEXT lv_max = COND /dmo/booking_id( WHEN lv_max < ls_booking-BookingId 
THEN ls_booking-BookingId 
ELSE lv_max ) ). 
LOOP AT entities ASSIGNING FIELD-SYMBOL(<ls_entities>) 
USING KEY entity 
WHERE TravelId = <ls_group_entity>-TravelId. 

LOOP AT <ls_entities>-%target ASSIGNING FIELD-SYMBOL(<ls_booking>). 
IF <ls_booking>-BookingId IS INITIAL. 
lv_max_booking += 10. 
APPEND CORRESPONDING #( <ls_booking> ) TO mapped-zi_booking_detail ASSIGNING FIELD-SYMBOL(<ls_new_map_book>). 
<ls_new_map_book>-BookingId = lv_max_booking. 

ENDIF. 
ENDLOOP. 
ENDLOOP. 

ENDLOOP. 
ENDMETHOD. 

METHOD AcceptTravel. 
MODIFY ENTITIES OF zi_travel_detail IN LOCAL MODE 
ENTITY zi_travel_detail 

UPDATE FIELDS ( OverallStatus ) 
WITH VALUE #( FOR ls_keys IN keys ( %tky = ls_keys-%tky 
OverallStatus = 'A') ). 
READ ENTITIES OF zi_travel_detail IN LOCAL MODE 
ENTITY zi_travel_detail 
ALL FIELDS WITH CORRESPONDING #( keys ) 
RESULT DATA(lt_result). 
result = VALUE #( FOR ls_result IN lt_result ( %tky = ls_result-%tky 
%param = ls_result ) ). 

ENDMETHOD. 
METHOD CopyTravel. 
ENDMETHOD. 

 

METHOD RecalcTotalPrice.

TYPES : BEGIN OF ty_total, 
price TYPE /dmo/total_price, 
curr TYPE /dmo/currency_code, 
END OF ty_total. 

DATA : lt_total TYPE TABLE OF ty_total, 
lv_conv_price TYPE ty_total-price. 

READ ENTITIES OF zi_travel_detail IN LOCAL MODE 
ENTITY zi_travel_detail 
FIELDS ( BookingFee CurrencyCode ) 
WITH CORRESPONDING #( keys ) 
RESULT DATA(lt_travel). 
DELETE lt_travel WHERE CurrencyCode IS INITIAL. 

READ ENTITIES OF zi_travel_detail IN LOCAL MODE 
ENTITY zi_travel_detail BY \_booking 
FIELDS ( FlightPrice CurrencyCode ) 
WITH CORRESPONDING #( lt_travel ) 
RESULT DATA(lt_ba_booking) . 

READ ENTITIES OF zi_travel_detail IN LOCAL MODE 
ENTITY zi_booking_detail BY \_bookingsuppl 
FIELDS ( Price CurrencyCode ) 
WITH CORRESPONDING #( lt_ba_booking ) 
RESULT DATA(lt_ba_bookingsupp) . 
LOOP AT lt_travel ASSIGNING FIELD-SYMBOL(<ls_travel>). 
lt_total = VALUE #( ( price = <ls_travel>-BookingFee curr = <ls_travel>-CurrencyCode ) ). 

LOOP AT lt_ba_booking ASSIGNING FIELD-SYMBOL(<ls_booking>) 
USING KEY entity 
WHERE TravelId = <ls_travel>-TravelId 
AND CurrencyCode IS NOT INITIAL.

APPEND VALUE #( price = <ls_booking>-FlightPrice curr = <ls_booking>-CurrencyCode ) 
TO lt_total. 

LOOP AT lt_ba_bookingsupp ASSIGNING FIELD-SYMBOL(<ls_bookingsupp>) 
USING KEY entity 
WHERE TravelId = <ls_booking>-TravelId 

AND BookingId = <ls_booking>-BookingId 
AND CurrencyCode IS NOT INITIAL. 
APPEND VALUE #( price = <ls_bookingsupp>-Price curr = <ls_bookingsupp>-CurrencyCode ) 

TO lt_total. 
ENDLOOP. 
ENDLOOP. 

LOOP AT lt_total ASSIGNING FIELD-SYMBOL(<ls_total>). 
IF <ls_total>-curr = <ls_travel>-CurrencyCode . 
lv_conv_price = <ls_total>-price . 
ELSE. 

/dmo/cl_flight_amdp=>convert_currency( 

EXPORTING 
iv_amount = <ls_total>-price 
iv_currency_code_source = <ls_total>-curr 
iv_currency_code_target = <ls_travel>-CurrencyCode 
iv_exchange_rate_date = cl_abap_context_info=>get_system_date( ) 
IMPORTING 
ev_amount = lv_conv_price 

). 

ENDIF. 
<ls_travel>-TotalPrice = <ls_travel>-TotalPrice + lv_conv_price. 
ENDLOOP.

MODIFY ENTITIES OF zi_travel_detail IN LOCAL MODE 
ENTITY zi_travel_detail 
UPDATE FIELDS ( TotalPrice ) 
WITH CORRESPONDING #( lt_travel ). 
ENDLOOP. 

ENDMETHOD. 
METHOD RejectTravel. 

MODIFY ENTITIES OF zi_travel_detail IN LOCAL MODE 

ENTITY zi_travel_detail 
UPDATE FIELDS ( OverallStatus ) 
WITH VALUE #( FOR ls_keys IN keys ( %tky = ls_keys-%tky 
OverallStatus = 'X') ) 
REPORTED DATA(lt_travel). 

READ ENTITIES OF zi_travel_detail IN LOCAL MODE 
ENTITY zi_travel_detail 
ALL FIELDS WITH CORRESPONDING #( keys ) 
RESULT DATA(lt_result). 
result = VALUE #( FOR ls_result IN lt_result ( %tky = ls_result-%tky 
%param = ls_result ) ). 
ENDMETHOD. 

METHOD CalcTotalPrice. 

MODIFY ENTITIES OF zi_travel_detail IN LOCAL MODE 
ENTITY zi_travel_detail 
EXECUTE RecalcTotalPrice 
FROM CORRESPONDING #( keys ). 
ENDMETHOD. 

ENDCLASS.

18. Here we are calculating the total price , whenever somebody changes the total Price and currency manually this determination should call on transactional phase(on modify)

METHOD CalcTotalPrice. 

MODIFY ENTITIES OF zi_travel_detail IN LOCAL MODE 
ENTITY zi_travel_detail 
EXECUTE RecalcTotalPrice 
FROM CORRESPONDING #( keys ). 

ENDMETHOD.

19. will call RecacTotalPrice for each determination

All the travel id which we modify will trigger when we are calculating total price

RecacTotalPrice--> will be called . We need to write the logic to modify Our BO instance based on travel ID And it will read and updae the price

Here the action will take care of the process – when we change the price ( based on determination ) action will be called

And as soon as price filed changes, determination happens And we need to read the travel entity with fields booking fee and currency code And we need to provide travel IDs which is present in keys Result is taken in LT_TRAVEL

Same thing we need to do it for boking and booking suppliment

METHOD RecalcTotalPrice. 

TYPES : BEGIN OF ty_total, 
price TYPE /dmo/total_price, 
curr TYPE /dmo/currency_code, 
END OF ty_total. 

DATA : lt_total TYPE TABLE OF ty_total, 
lv_conv_price TYPE ty_total-price. 

READ ENTITIES OF zi_travel_detail IN LOCAL MODE 
ENTITY zi_travel_detail 
FIELDS ( BookingFee CurrencyCode ) 
WITH CORRESPONDING #( keys ) 
RESULT DATA(lt_travel). 

DELETE lt_travel WHERE CurrencyCode IS INITIAL. 
READ ENTITIES OF zi_travel_detail IN LOCAL MODE 

ENTITY zi_travel_detail BY \_booking 
FIELDS ( FlightPrice CurrencyCode ) 
WITH CORRESPONDING #( lt_travel ) 
RESULT DATA(lt_ba_booking) . 
READ ENTITIES OF zi_travel_detail IN LOCAL MODE 
ENTITY zi_booking_detail BY \_bookingsuppl 
FIELDS ( Price CurrencyCode ) 
WITH CORRESPONDING #( lt_ba_booking ) 

RESULT DATA(lt_ba_bookingsupp) . 

LOOP AT lt_travel ASSIGNING FIELD-SYMBOL(<ls_travel>). 
lt_total = VALUE #( ( price = <ls_travel>-BookingFee curr = <ls_travel>-CurrencyCode ) ). 

LOOP AT lt_ba_booking ASSIGNING FIELD-SYMBOL(<ls_booking>) 
USING KEY entity 
WHERE TravelId = <ls_travel>-TravelId 
AND CurrencyCode IS NOT INITIAL. 
APPEND VALUE #( price = <ls_booking>-FlightPrice curr = <ls_booking>-CurrencyCode ) 
TO lt_total. 
LOOP AT lt_ba_bookingsupp ASSIGNING FIELD-SYMBOL(<ls_bookingsupp>) 
USING KEY entity 

WHERE TravelId = <ls_booking>-TravelId 
AND BookingId = <ls_booking>-BookingId 
AND CurrencyCode IS NOT INITIAL. 

APPEND VALUE #( price = <ls_bookingsupp>-Price curr = <ls_bookingsupp>-CurrencyCode ) 
TO lt_total. 

ENDLOOP. 
ENDLOOP. 


LOOP AT lt_total ASSIGNING FIELD-SYMBOL(<ls_total>). 

IF <ls_total>-curr = <ls_travel>-CurrencyCode . 
lv_conv_price = <ls_total>-price . 
ELSE. 

/dmo/cl_flight_amdp=>convert_currency( 
EXPORTING 
iv_amount = <ls_total>-price 
iv_currency_code_source = <ls_total>-curr 
iv_currency_code_target = <ls_travel>-CurrencyCode 
iv_exchange_rate_date = cl_abap_context_info=>get_system_date( ) 
IMPORTING 
ev_amount = lv_conv_price 

). 
 
ENDIF. 

<ls_travel>-TotalPrice = <ls_travel>-TotalPrice + lv_conv_price. 

ENDLOOP. 

MODIFY ENTITIES OF zi_travel_detail in LOCAL MODE 
ENTITY zi_travel_detail 
UPDATE FIELDS ( TotalPrice ) 
WITH CORRESPONDING #( lt_travel ). 
ENDLOOP. 

ENDMETHOD.

20. Class for booking suppliment

CLASS lhc_zi_booking_supp DEFINITION INHERITING FROM cl_abap_behavior_handler. 

PRIVATE SECTION. 

METHODS CalcTotalPrice FOR DETERMINE ON MODIFY 
IMPORTING keys FOR zi_booking_supp~CalcTotalPrice. 
METHODS get_global_authorizations FOR GLOBAL AUTHORIZATION 
IMPORTING REQUEST requested_authorizations FOR zi_booking_supp RESULT result. 
ENDCLASS. 

CLASS lhc_zi_booking_supp IMPLEMENTATION. 
METHOD CalcTotalPrice. 

ENDMETHOD. 
METHOD get_global_authorizations. 
ENDMETHOD. 

ENDCLASS. 
 
CLASS lhc_zi_booking_detail DEFINITION INHERITING FROM cl_abap_behavior_handler. 

PRIVATE SECTION. 
METHODS earlynumbering_cba_Bookingsupp FOR NUMBERING 

IMPORTING entities FOR CREATE zi_booking_detail\_Bookingsuppl. 
METHODS CalcTotalPrice FOR DETERMINE ON MODIFY 
IMPORTING keys FOR zi_booking_detail~CalcTotalPrice. 

METHODS get_global_authorizations FOR GLOBAL AUTHORIZATION 
IMPORTING REQUEST requested_authorizations FOR zi_booking_detail RESULT result. 

ENDCLASS. 


CLASS lhc_zi_booking_detail IMPLEMENTATION. 

METHOD earlynumbering_cba_Bookingsupp. 
DATA: max_booking_suppl_id TYPE /dmo/booking_supplement_id . 
READ ENTITIES OF zi_travel_detail IN LOCAL MODE 
ENTITY zi_booking_detail BY \_Bookingsuppl 
FROM CORRESPONDING #( entities ) 
LINK DATA(booking_supplements). 

" Loop over all unique tky (TravelID + BookingID) 
LOOP AT entities ASSIGNING FIELD-SYMBOL(<booking_group>) GROUP BY <booking_group>-%tky. 

" Get highest bookingsupplement_id from bookings belonging to booking 
max_booking_suppl_id = REDUCE #( INIT max = CONV /dmo/booking_supplement_id( '0' ) 

FOR booksuppl IN booking_supplements USING KEY entity 
WHERE ( source-TravelId = <booking_group>-TravelId 
AND source-BookingId = <booking_group>-BookingId ) 
NEXT max = COND /dmo/booking_supplement_id( WHEN booksuppl-target-BookingSupplementId > max 
THEN booksuppl-target-BookingSupplementId 
ELSE max ) 

). 
" Get highest assigned bookingsupplement_id from incoming entities 

max_booking_suppl_id = REDUCE #( INIT max = max_booking_suppl_id 
FOR entity IN entities USING KEY entity 
WHERE ( TravelId = <booking_group>-TravelId 
AND BookingId = <booking_group>-BookingId ) 
FOR target IN entity-%target 
NEXT max = COND /dmo/booking_supplement_id( WHEN target-BookingSupplementId > max 
THEN target-BookingSupplementId 
ELSE max ) 

). 
" Loop over all entries in entities with the same TravelID and BookingID
LOOP AT entities ASSIGNING FIELD-SYMBOL(<booking>) USING KEY entity WHERE TravelId = <booking_group>-TravelId 
AND BookingId = <booking_group>-BookingId. 

" Assign new booking_supplement-ids 
LOOP AT <booking>-%target ASSIGNING FIELD-SYMBOL(<booksuppl_wo_numbers>). 
APPEND CORRESPONDING #( <booksuppl_wo_numbers> ) TO mapped-zi_booking_supp ASSIGNING FIELD-SYMBOL(<mapped_booksuppl>). 
IF <booksuppl_wo_numbers>-BookingSupplementId IS INITIAL. 
max_booking_suppl_id += 1 . 
<mapped_booksuppl>-BookingSupplementId = max_booking_suppl_id . 
ENDIF. 
ENDLOOP. 
ENDLOOP. 
ENDLOOP.
ENDMETHOD.

21. Based on the booking fee we need to calculate the total price , So we need to write the logic in calcTotal price method

METHOD CalcTotalPrice. 

DATA : it_travel TYPE STANDARD TABLE OF zpd_dt_travel WITH UNIQUE HASHED KEY key COMPONENTS travel_id. 
it_travel = CORRESPONDING #( keys DISCARDING DUPLICATES MAPPING travel_id = TravelId ). 

MODIFY ENTITIES OF zi_travel_detail IN LOCAL MODE 
ENTITY zi_travel_detail 
EXECUTE RecalcTotalPrice 
FROM CORRESPONDING #( it_travel ). 

ENDMETHOD.

22. OUTPUT

23. Edit--> changing booking fee from 140 USD to 240 USD

24. Click on save << after saving , the total price is still the same ---> not updated at the screen level

25. When we refresh the page—the total price gets updated

26. Now we need to use the side effects to make the data refreshed on save at screen level , So now it should not only be updated in the transactional buffer – it should also be updated in the front end

27. Change the booking fee 258 USD and click on save

28. As soon as you click on save

Thanks and regards

-PRADEEP ISHWAR DEVADIGA

You Won't Believe Where ZLLM's Documentation Lives (And How It Got There)

2025-07-02T12:45:53.530000+02:00

How I Made AI Write Its Own Documentation... In SAP's Standard Format

Spoiler: The AI is already documenting itself in production*.

Hello again! 👋 It's Alice, and I have a confession: I absolutely love writing documentation.

But I hate writing it BY HAND. Especially in SAP's bizarre ITF format - that cryptic markup language designed back when the closest thing to modern markup was SGML, and HTML didn't even exist yet!

(Fun fact: ITF format was actually designed for SAPscript in the early 1980s as part of SAP R/2 - when "markup language" meant something completely different! ^_^)

But here's the thing - ZLLM has incredible documentation. Comprehensive, detailed, and perfectly formatted. And it lives exactly where every SAP developer NOT expects it: behind the standard "Show Documentation" button 😃

Plot Twist:

I didn't write a single line of that documentation manually.

ZLLM documented itself.

The Documentation That Writes Itself

Click on any ZLLM class in SE80 or ADT. Hit CTRL+SHIFT+F2 (Show Documentation).

What you'll see isn't your typical sparse ABAP documentation. It's rich, detailed, with examples, architecture diagrams, and usage patterns. All perfectly formatted in SAP's native documentation system.

Here's what makes this magical:

The documentation exists in standard SAP format (ITF), appears in standard SAP locations, but was generated by modern AI and written in human-readable Markdown first.

How I Built The Documentation Factory

Step 1: The Analysis Phase

" ZLLM analyzes the codebase
DATA(lo_analyzer) = zcl_llm_00_step_lazy=>new_from_string(
  iv_usr = 'Analyze this ABAP class and extract:'
           '- Purpose and responsibility'
           '- Public methods and parameters' 
           '- Usage patterns and examples'
           '- Integration points: {T}'
  io_llm = lo_llm
).

Step 2: The Generation Phase

" Generate comprehensive Markdown documentation
DATA(lo_generator) = zcl_llm_00_step_lazy=>new_from_string(
  iv_usr = 'Create technical documentation in Markdown format:'
           '- Overview section with clear purpose'
           '- Method documentation with examples'
           '- Code samples showing real usage'
           '- Integration notes and best practices'
           'Based on analysis: {T}'
  io_llm = lo_llm
).

Step 3: The Integration Magic

" Chain it all together
DATA(lo_doc_flow) = zcl_llm_00_flow_lazy=>new( VALUE #(
  ( lo_analyzer )
  ( lo_generator )
) ).

" Generate docs for entire framework
DATA(lr_result) = lo_doc_flow->exec( REF #( class_metadata ) ).

For the Markdown → ITF conversion and integration with SAP's documentation system, I used another one of my frameworks: XRAY. But that's a story for another article... ^_^

The Real Magic: Production-Ready Documentation

This isn't a toy example. This is live, production documentation that:

✅Appears in standard SAP tools (SE80, ADT, SE11)

✅Follows SAP documentation conventions

✅Updates automaticallywhen code changes

✅Includes real examplesand usage patterns

✅Maintains technical accuracy through AI analysis

### Before vs After:

Traditional SAP Documentation:

* It is a class.

ZLLM-Generated Documentation:

Why This Changes a Lot

For SAP Developers:

No more "TODO: Add documentation" comments
Comprehensive docs appear automatically in familiar places
Examples and usage patterns generated from actual code

For Enterprise Teams:

Documentation stays current with code changes
Consistent format across entire codebase
Onboarding new developers becomes trivial

For AI Adoption:

Demonstrates practical AI value in daily development
Shows integration with existing enterprise tools
Proves AI can enhance rather than replace existing workflows

The Recursive Beauty

Here's the beautiful irony: ZLLM used itself to document itself.

The framework that makes enterprise AI integration effortless also made documenting itself effortless. It's AI all the way down.

How You Can Build This

Want to auto-document your own ABAP code? Here's the starter pattern:

METHOD auto_document_class.
  " 1. Extract class metadata
  DATA(lo_metadata) = extract_class_info( iv_class_name ).
  
  " 2. Generate documentation
  DATA(lo_doc_step) = zcl_llm_00_step_lazy=>new_from_string(
    iv_usr = 'Create comprehensive documentation for this ABAP class: {T}'
    io_llm = lo_llm
  ).
  
  " 3. Chain and execute
  DATA(lo_flow) = zcl_llm_00_flow_lazy=>new( VALUE #(
    ( lo_doc_step )
  ) ).
  
  DATA(lv_markdown_doc) = lo_flow->start( REF #( lo_metadata ) )->to_string( ).
  
ENDMETHOD.

The Bigger Picture

This isn't just about documentation. It's about AI that enhances existing enterprise workflows instead of disrupting them.

Traditional AI Integration: "We need new tools, new processes, new training..."

ZLLM Approach: "Your existing tools just got smarter."

The documentation appears exactly where SAP developers (not?) expect it. No new interfaces to learn. No new processes to adopt. Just better, more comprehensive information in familiar places.

What's Next?

This is just one example of ZLLM eating its own dog food. Other production uses:

Code Analysis- Analyzing patterns across the entire ABAP stack

Performance Monitoring- Generating insights from system metrics

Test Generation- Creating unit tests from business requirements

Migration Planning - Analyzing code dependencies for S/4HANA migration

Ready to Document Your Code Automatically?

⭐Explore ZLLM: -> github/oisee/zllm

Comment below:What part of your ABAP development would you want AI to handle?

🔄Share if you think your SAP team needs this

Try it yourself:

1. Install ZLLM in your development system

2. Run the documentation generator on your classes

3. Watch as comprehensive docs appear in standard SAP locations

4. Never write manual documentation again

About Alice Vinogradova:

Senior Software Engineer with 20+ years in ABAP/SAP. I specialize in making enterprise AI practical, starting with solving our own problems first. If the AI can't document itself, how can it document your business processes?

P.S. Yes, this article was edited by ZLLM too. And the Markdown → ITF conversion? That's handled by my XRAY framework - another story of making SAP development less painful. It's recursive intelligence all the way down.

*production for development - is development.

Tags: #SAP #ABAP #AI #Documentation #TechLeadership #Automation

"The ideal documentation is one that doesn't need to be written because it writes itself."

ABAP Cloud - Number ranges ( Using SNRO )

2025-07-02T13:44:45.577000+02:00

ABAP Cloud - Number ranges

How can you use number ranges in ABAP Cloud and does this actually still make sense? In this article we will look at some of the background information.

Number range objects and number ranges have long been a standard feature across various SAP specialist modules. But what’s the current approach in ABAP Cloud? Do we still need these objects? In this article, we’ll explore the new concepts introduced in ABAP Cloud and how you can effectively work with them.

Introduction

In traditional on-premise systems, the SNRO transaction was your go-to tool for creating and managing number ranges. However, with ABAP Cloud, the landscape has changed transactions like SNRO are no longer available, and maintaining intervals directly is no longer an option. Instead, SAP now offers a set of ABAP APIs along with a dedicated Fiori app to handle number range management. In this post, we’ll take a closer look at these new tools and how you can use them effectively in the cloud environment.

Why do we actually need number ranges and consecutive numbers in the system? Data is stored in databases and records in relational databases usually require a unique key. To assign numbers automatically, we could always look at the database and calculate the current ID plus 1 to get a new unique key. However, since we are not alone on the system and several booking processes can run at the same time, this would not guarantee that we would always receive a unique number. Number range objects therefore manage the individual number range statuses and always give us a unique number via a function and take care of the increase.

ABAP Cloud

When developing with ABAP Cloud, we rely on the ABAP RESTful Programming Model, or RAP for short, which very often uses GUIDs to manage the keys. The GUIDs are generated randomly and we don't have to worry about managing the key. Furthermore, we can change any field in the data record in the workflow if we want to. If we need a readable or unique key in our data record, we can also use a semantic key, which we can also declare as unique, but we have to carry out the check ourselves.

However, with this method we cannot prove any sequence or gaps in the data. Therefore, in certain technical scenarios it still makes sense to use number ranges to create a semantic key.

Creation

You can easily create the number range object using the ABAP Development Tools. In the following steps we create a domain and then the appropriate object.

Domain

In order to create a number range, we first need a domain that determines the data type. To do this, we create a domain using the context menu; a new domain on our system.

We then give the domain a type that determines the number and options of the generated numbers.

Number Range Object (ADT)

We can now create a number range object. Here we have to make sure that the name is not too long, as the field currently only has 10 characters.

Created the ABAP class in RAP application using ADT to check SNRO number range object.

CLASS zcl_rap_snro_number_range DEFINITION 

PUBLIC 

FINAL 

CREATE PUBLIC . 

 

PUBLIC SECTION. 

INTERFACES if_oo_adt_classrun. 

 

PROTECTED SECTION. 

PRIVATE SECTION. 

ENDCLASS. 

 

 

 

CLASS zcl_rap_snro_number_range IMPLEMENTATION. 

METHOD if_oo_adt_classrun~main. 

TRY. 

zcl_sm_helper_class=>get_snro_id( EXPORTING iv_range_nr = '01' 

iv_object = 'ZSM_USERID' 

IMPORTING ev_num = DATA(lv_num) ). 

CATCH cx_number_ranges INTO DATA(lx_obj). 

out->write( lx_obj->get_text( ) ). 

ENDTRY. 

out->write( |EI{ lv_num+12(8) }| ). 

ENDMETHOD. 

 

ENDCLASS.

Next we have an helper class -->> ZCL_SM_HELPER_CLASS.

CLASS zcl_sm_helper_class DEFINITION 

PUBLIC 

FINAL 

CREATE PUBLIC. 

 

PUBLIC SECTION. 

CLASS-METHODS get_snro_id IMPORTING iv_range_nr TYPE zsm_NRNR 

iv_object TYPE zsm_NROBJ 

EXPORTING ev_num TYPE zsm_num 

RAISING cx_number_ranges. 

 

PROTECTED SECTION. 

PRIVATE SECTION. 

ENDCLASS. 

 

CLASS zcl_sm_helper_class IMPLEMENTATION. 

METHOD get_snro_id. 

TRY. 

cl_numberrange_intervals=>read( EXPORTING nr_range_nr1 = iv_range_nr 

* nr_range_nr2 = 

object = iv_object 

* subobject = 

IMPORTING interval = DATA(ls_interval) ). 

CATCH cx_nr_object_not_found INTO DATA(lx_obj1). " TODO: variable is assigned but never used (ABAP cleaner) 

 

CATCH cx_nr_subobject INTO DATA(lx_obj2). " TODO: variable is assigned but never used (ABAP cleaner) 

 

CATCH cx_number_ranges INTO DATA(lx_obj3). " TODO: variable is assigned but never used (ABAP cleaner) 

 

ENDTRY. 

 

IF ls_interval IS INITIAL. 

 

TRY. 

 

cl_numberrange_intervals=>create( 

interval = VALUE #( ( nrrangenr = '01' fromnumber = '00000001' tonumber = '99999999' ) ) 

object = iv_object ). 

* subobject = 

* option = 

* IMPORTING 

* error = 

* error_inf = 

* error_iv = 

* warning = 

CATCH cx_nr_object_not_found INTO DATA(lx_obj4). " TODO: variable is assigned but never used (ABAP cleaner) 

 

CATCH cx_number_ranges INTO DATA(lx_obj5). " TODO: variable is assigned but never used (ABAP cleaner) 

 

ENDTRY. 

ENDIF. 

TRY. 

 

cl_numberrange_runtime=>number_get( EXPORTING 

* ignore_buffer = 

nr_range_nr = iv_range_nr 

object = iv_object 

* quantity = 

* subobject = 

* toyear = 

IMPORTING number = ev_num 

* returncode = 

* returned_quantity = 

). 

 

CATCH cx_number_ranges INTO DATA(lx_obj). 

RAISE EXCEPTION lx_obj. 

ENDTRY. 

ENDMETHOD. 

 

ENDCLASS.

OUTPUT: We are getting serial numbers from SNRO in the expected format.

BDC Batch Data Communication using Session Method And Call Transaction Method

2025-07-02T14:14:43.654000+02:00

This Blog provides an overview of BDC (Batch Data Communication) using the Session Method. BDC is a classic data migration technique in SAP. The Session Method is suitable for large volumes of data and allows better error handling

For Recording the Transaction T code: SHDB
Batch Input Sessions: SM35
1.Session Method

REPORT ZBDC_SESSIONMETHOD_MA.

"Type declaration for customer structure
TYPES: BEGIN OF ty_customer,
         kunnr TYPE kunnr,         " Customer Number
         name1 TYPE name1_gp,      " Name
         ort01 TYPE ort01,         " City
       END OF ty_customer.

"Internal tables and variables
DATA: it_customer TYPE TABLE OF ty_customer,  " Internal table to hold customer data
      wa_customer TYPE ty_customer,           " Work area
      it_bdcdata  TYPE TABLE OF bdcdata,      " BDC table
      wa_bdcdata  TYPE bdcdata,               " BDC work area
      v_file      TYPE string.                " File path variable

DATA: p_pp TYPE string.                       " Temporary file path variable

"BDC session name (used in SM35)
DATA: lv_group TYPE apqi-groupid VALUE 'ZCUS_UPLOAD'.

"Selection screen to get file path input
PARAMETERS: p_file TYPE rlgrap-filename OBLIGATORY.

"AT SELECTION SCREEN: F4 help to choose file
AT SELECTION-SCREEN ON VALUE-REQUEST FOR p_file.
  CALL FUNCTION 'F4_FILENAME'
    IMPORTING file_name = p_file.

"START OF SELECTION
START-OF-SELECTION.

"Move user-selected file to internal variable
p_pp = p_file.

"Upload flat file with customer data
CALL FUNCTION 'GUI_UPLOAD'
  EXPORTING
    filename            = p_pp
    filetype            = 'ASC'
    has_field_separator = '|'        " Pipe delimiter
  TABLES
    data_tab = it_customer.

"Check if file has data
IF it_customer IS INITIAL.
  WRITE: / 'No data found in file.'.
  EXIT.
ENDIF.

"Open BDC session
CALL FUNCTION 'BDC_OPEN_GROUP'
  EXPORTING
    client   = sy-mandt
    group    = lv_group
    user     = sy-uname
    keep     = 'X'            " Keep session after execution
    holddate = sy-datum.      " Process date

"Loop through uploaded customer data
LOOP AT it_customer INTO wa_customer.

  CLEAR it_bdcdata.

  "First screen entries
  PERFORM bdc_dynpro      USING 'ZBDC_SCREEN' '1000'.
  PERFORM bdc_field       USING 'BDC_CURSOR' 'P_ORT01'.
  PERFORM bdc_field       USING 'BDC_OKCODE' '=ONLI'.
  PERFORM bdc_field       USING 'P_KUNNR'    wa_customer-kunnr.
  PERFORM bdc_field       USING 'P_NAME'     wa_customer-name1.
  PERFORM bdc_field       USING 'P_ORT01'    wa_customer-ort01.

  "Exit screen to return
  PERFORM bdc_dynpro      USING 'ZBDC_SCREEN' '1000'.
  PERFORM bdc_field       USING 'BDC_OKCODE' '/EE'.
  PERFORM bdc_field       USING 'BDC_CURSOR' 'P_KUNNR'.

  "Insert transaction step into the BDC session
  CALL FUNCTION 'BDC_INSERT'
    EXPORTING tcode = 'ZBDC_CUS'
    TABLES   dynprotab = it_bdcdata.

ENDLOOP.

"Close the BDC session
CALL FUNCTION 'BDC_CLOSE_GROUP'.

"Success message
WRITE: / 'BDC Session created successfully. Use SM35 to process it.'.

"-----------------------------------------
" Subroutine to add dynpro screen
"-----------------------------------------
FORM bdc_dynpro USING program screen.
  CLEAR wa_bdcdata.
  wa_bdcdata-program  = program.
  wa_bdcdata-dynpro   = screen.
  wa_bdcdata-dynbegin = 'X'.
  APPEND wa_bdcdata TO it_bdcdata.
ENDFORM.

"-----------------------------------------
" Subroutine to add field values
"-----------------------------------------
FORM bdc_field USING fnam fval.
  CLEAR wa_bdcdata.
  wa_bdcdata-fnam = fnam.
  wa_bdcdata-fval = fval.
  APPEND wa_bdcdata TO it_bdcdata.
ENDFORM.

After execute go to Sm35

2.Call Transaction Method

REPORT ZBDC_CALLTRAN_CUSTOMER.

"--- Structure Definition ---
TYPES: BEGIN OF ty_customer,
         kunnr TYPE kunnr,         " Customer Number
         name1 TYPE name1_gp,      " Name
         ort01 TYPE ort01,         " City
       END OF ty_customer.

"--- Data Declarations ---
DATA: p_file_s    TYPE string,              " To hold the selected file path
      it_customer TYPE TABLE OF ty_customer, " Internal table for uploaded data
      wa_customer TYPE ty_customer,          " Work area for one record
      it_bdcdata  TYPE TABLE OF bdcdata,     " BDC data table
      wa_bdcdata  TYPE bdcdata.              " BDC line

"--- File Input Parameter ---
PARAMETERS: p_file TYPE IBIPPARMS-PATH OBLIGATORY.

"--- F4 Help for File Selection ---
AT SELECTION-SCREEN ON VALUE-REQUEST FOR p_file.
  CALL FUNCTION 'F4_FILENAME'
    IMPORTING
      file_name = p_file.

"--- Main Program Execution ---
START-OF-SELECTION.

  " Assign selected file to variable
  p_file_s = p_file.

  " Upload the customer data from text file
  CALL FUNCTION 'GUI_UPLOAD'
    EXPORTING
      filename            = p_file_s
      filetype            = 'ASC'
      has_field_separator = '|'              " Data separated by '|'
    TABLES
      data_tab            = it_customer
    EXCEPTIONS
      OTHERS              = 1.

  " Loop over each uploaded customer record
  LOOP AT it_customer INTO wa_customer.

    " Clear previous BDC data
    CLEAR it_bdcdata[].

    " Build BDC data for screen input
    PERFORM bdc_dynpro USING 'ZBDC_SCREEN' '1000'.
    PERFORM bdc_field  USING 'BDC_CURSOR' 'P_ORT01'.
    PERFORM bdc_field  USING 'BDC_OKCODE' '=ONLI'.        " Press Enter
    PERFORM bdc_field  USING 'P_KUNNR'    wa_customer-KUNNR.
    PERFORM bdc_field  USING 'P_NAME'     wa_customer-NAME1.
    PERFORM bdc_field  USING 'P_ORT01'    wa_customer-ORT01.

    " Optionally simulate pressing Exit or Back
    PERFORM bdc_dynpro USING 'ZBDC_SCREEN' '1000'.
    PERFORM bdc_field  USING 'BDC_OKCODE' '/EE'.           " Exit
    PERFORM bdc_field  USING 'BDC_CURSOR' 'P_KUNNR'.

    " Call transaction with built BDC data in background mode
    CALL TRANSACTION 'ZBDC_CUS' USING it_bdcdata
      MODE 'N'          " 'N' - Background, 'A' - Foreground, 'E' - Errors only
      UPDATE 'S'.       " Synchronous update

  ENDLOOP.

"--- Subroutine to declare dynpro screen ---
FORM bdc_dynpro USING program screen.
  CLEAR wa_bdcdata.
  wa_bdcdata-program  = program.
  wa_bdcdata-dynpro   = screen.
  wa_bdcdata-dynbegin = 'X'.
  APPEND wa_bdcdata TO it_bdcdata.
ENDFORM.

"--- Subroutine to assign value to a field ---
FORM bdc_field USING fnam fval.
  CLEAR wa_bdcdata.
  wa_bdcdata-fnam = fnam.
  wa_bdcdata-fval = fval.
  APPEND wa_bdcdata TO it_bdcdata.
ENDFORM.

3. Difference Between CALL TRANSACTION and SESSION METHOD

Aspect	CALL TRANSACTION	SESSION METHOD
Execution	Immediate	Deferred via SM35
Error Handling	Manual/Error log	SM35 Session log
Performance	Faster, suitable for small data	Better for large volumes
Mode	Foreground/Background/No Display	Processes in background
Data Volume	Limited	Handles large volumes efficiently

Recap: SQL selection patterns in SAP HANA database, presented at SAP Inside Track Wroclaw 2025

2025-07-03T10:23:24.088000+02:00

A couple of words about me:   

My name is Bogdan Brzozowski and I’m Managing Software Architect working for Capgemini Poland within more than 14 years. My current position encompasses the following responsibilities:

Establishing architecture (ERD, UML) for ABAP based custom solutions to be implemented for our customers by our developers.
Reverse engineering of the legacy ABAP solutions belonging to our customers to take the full responsibility for their further development and maintenance.
Conducting internal trainings for our technical consultants to improve their technical skills.
Presentations for external audience to make our company visible as top provider of SAP technology-based solutions.
Custom code conversion guidelines – I am responsible for creation and keeping this document up to date.
Spreading knowledge about internal Capgemini data migration tools like Syniti or Concert Tool.

A couple of sentences about the event: 

SAP Inside Track was held again in Wroclaw this year. That time we met on rainy Saturday day (7-JUNE-2025) in the premises of WBS Merito University - well known private university that was event co-organizer (together with Capgemini). We welcomed attendees from 9 countries, who were participating in the sessions conducted in English by 18 presenters. Most of the presentations were running in parallel split between 2 rooms. Predominant topics shared with the audience were related to the use of genAI in the context of SAP technologies. But there were also few sessions focusing on modern aspects of ABAP programming, like the subject presented in this blog :-).

My Session:   

This year I had the opportunity to do a session called “ SQL selection patterns in CDS views examples”. Good practices are worth following and this is why design patterns like singleton, factory, prototype and many others became popular within object-oriented programming languages. The same may partially apply to data retrieval from any relational database. I noticed that there are typical techniques of data selection, that are useful in different projects for the customers from various branches: pharma, retail, automotive, utility supply to name few of them. In this blog I will share those selection patterns using syntax from ABAP Advanced Open SQL, ABAP CDS view entities and SQL script. HANA database is compliant with standard SQL ANSI 2016, so the examples presented in this blog may be useful to retrieve the data from other relational databases, which are compliant with SQL standard.. Below I would like to share main highlights, insights and key takeaways from my presentation. 

Entity Relationship Diagram of the data model used for the code presented later on this blog.

Sales Order header is kept in VBAK table, while its items in VBAP. Additionally all the changes within Sales Order data are recorded in so called Change Documents with 2 main tables: CDHDR as the change header and CDPOS that stores old and new value of a given field. ERD diagram above uses well known crow's foot notation - see more details here.

Main highlights and key takeaways :  

 I have presented 2 selection patterns for the performance improvement:

exclusion
case vs union all

...plus 2 functional patterns:

predecessor and successor
data source determination during runtime.

Performance pattern: Exclusion

Let's take a look at ERD diagram again. Imagine the requirement to select all Sales Orders items (VBAP table), that do not refer to any material from MARA or they refer to materials of HAWA type only. (MARA-MTART = 'HAWA'). Additionally we are interested in Sales Orders of TA type only (VBAK-AUART = 'TA').

The very first idea is the use of subquery embedded inside NOT EXISTS operator:

SELECT
  vbak~vbeln,
  vbap~posnr,
  vbap~matnr,
  vbap~netwr,
  vbap~waerk
  FROM vbak
  INNER JOIN vbap
  ON vbap~vbeln = vbak~vbeln
  WHERE vbak~auart = @cv_sd_order_type_ta
  AND NOT EXISTS (
    SELECT @abap_true FROM mara AS subq
      WHERE subq~matnr = vbap~matnr
        AND subq~lvorm = @abap_false
        AND subq~mtart = @cv_material_type_hawa
  )
  ORDER BY vbak~vbeln, vbap~posnr
  INTO CORRESPONDING FIELDS OF TABLE @me->mt_so_head_item[].

But subquery has 2 major disadvantages: it consumes a lot of database server resources (which is valid for any database provider: SAP, Oracle, MS, IBM, etc.) and it cannot be used in ABAP CDS view (valid for SAP HANA database only).

The alternative offering much faster data retrieval is LEFT OUTER JOIN:

SELECT
  vbak~vbeln,
  vbap~posnr,
  vbap~matnr,
  vbap~netwr,
  vbap~waerk,
  mara~mtart,
  mara~xchpf
  FROM vbak
  INNER JOIN vbap
  ON vbap~vbeln = vbak~vbeln
  LEFT OUTER JOIN mara
  ON  mara~matnr = vbap~matnr
  AND mara~lvorm = @ABAP_false "NOT in WHERE if OUTER join is expected
  WHERE vbak~auart = @CV_sd_order_type_ta
  AND (    mara~matnr IS NULL
        OR mara~mtart <> @CV_material_type_hawa
      )
   ORDER BY vbak~vbeln, vbap~posnr
  INTO CORRESPONDING FIELDS OF TABLE @ME->mt_so_head_item[].

ATTENTION: any additional conditions against the data source from the left side of the outer join must be specified within ON operator, not as a part of WHERE clause. Otherwise you will transform your OUTER join (unintentionally) into the INNER join! You may get caught into this trap using Advanced Open SQL (with @ prefix when you refer to the variables declared in ABAP and residing on application server). Old Open SQL flavor for ABAP programming on ECC system (predecessor of S/4HANA) did not allow such implicit (and most likely unwanted) conversion of OUTER join into the INNER one.

Association is not part of SQL standard, but it may be perceived like lazy outer join. This 'laziness' means that as long as ABAP app does not require the columns from the data source on the left side of the outer join, the database system does not perform outer join operation at all, saving some processing time and its resources. This is why we can use the similar technique to obtain data with our exclusion condition from the CDS view that uses association:

SELECT
  SalesOrder AS vbeln,
  so~\_Item-SalesOrderItem AS posnr,
  so~\_Item-Product AS matnr,
  so~\_Item-NetAmount AS netwr,
  so~\_Item-TransactionCurrency AS waerk,
  so~\_Item\_Product-ProductType AS mtart,
  so~\_Item\_Product-IsBatchManagementRequired AS xchpf
  FROM R_SalesOrderTP AS so
  WHERE so~SalesOrderType = @cv_sd_order_type_ta
  AND so~\_Item-SalesOrderItem IS NOT NULL
  AND ( so~\_Item\_Product-ProductType IS NULL
        OR (     so~\_Item\_Product-ProductType <> @cv_material_type_hawa
             AND so~\_Item\_Product-IsMarkedForDeletion = @abap_false
           )
      )
  ORDER BY vbeln, posnr
  INTO TABLE @me->mt_so_head_item[].

Performance pattern: Case vs Union all

Imagine the following projection list using CASE operator:

SELECT
  SalesDocument AS vbeln,
  so~\_ItemBasic-SalesDocumentItem AS posnr,
  so~\_ItemBasic-Material AS matnr,
  so~\_ItemBasic-NetAmount AS netwr,
  so~\_ItemBasic-TransactionCurrency AS waerk,
  so~\_ItemBasic\_Material-MaterialType AS mtart,
  so~\_ItemBasic\_Material-IsBatchManagementRequired AS xchpf,
  CASE
    WHEN so~\_ItemBasic\_Material-IsBatchManagementRequired IS NULL
      THEN 'Batch Managment is IRRELEVANT'
    WHEN so~\_ItemBasic\_Material-IsBatchManagementRequired = @abap_true
      THEN 'Batch Managment IS required'
    ELSE 'Batch Managment is NOT required'
  END AS IsBatchMgmtReq
  FROM I_SalesDocumentBasic AS so
  WHERE so~SalesDocumentType = @cv_sd_order_type_ta
  AND so~\_ItemBasic-SalesDocumentItem IS NOT NULL
  AND (   so~\_ItemBasic\_Material-MaterialType <> @cv_material_type_hawa
       OR so~\_ItemBasic\_Material-MaterialType IS NULL
      )
  ORDER BY vbeln, posnr
  INTO TABLE @me->mt_so_descriptive[].

It may be time consuming to execute, as it runs as a single thread on HANA database server. The alternative is to split such single SELECT statement into as many SELECT statements as many CASE conditions are used. All these SELECT statements will be combined with UNION ALL operator, like in the code below:

SELECT
  SalesDocument AS vbeln,
  so~\_ItemBasic-SalesDocumentItem AS posnr,
  so~\_ItemBasic-Material AS matnr,
  so~\_ItemBasic-NetAmount AS netwr,
  so~\_ItemBasic-TransactionCurrency AS waerk,
  so~\_ItemBasic\_Material-MaterialType AS mtart,
  so~\_ItemBasic\_Material-IsBatchManagementRequired AS xchpf,
  'Batch Managment is IRRELEVANT' AS IsBatchMgmtReq
  FROM I_SalesDocumentBasic AS so
  WHERE so~SalesDocumentType = @cv_sd_order_type_ta
  AND so~\_ItemBasic-SalesDocumentItem IS NOT NULL
  AND (    so~\_ItemBasic\_Material-MaterialType <> @cv_material_type_hawa
        OR so~\_ItemBasic\_Material-MaterialType IS NULL
      )
  AND so~\_ItemBasic\_Material-IsBatchManagementRequired IS NULL
UNION ALL
SELECT
  SalesDocument AS vbeln,
  so~\_ItemBasic-SalesDocumentItem AS posnr,
  so~\_ItemBasic-Material AS matnr,
  so~\_ItemBasic-NetAmount AS netwr,
  so~\_ItemBasic-TransactionCurrency AS waerk,
  so~\_ItemBasic\_Material-MaterialType AS mtart,
  so~\_ItemBasic\_Material-IsBatchManagementRequired AS xchpf,
  'Batch Managment IS required' AS IsBatchMgmtReq
  FROM I_SalesDocumentBasic AS so
  WHERE so~SalesDocumentType = @cv_sd_order_type_ta
  AND so~\_ItemBasic-SalesDocumentItem IS NOT NULL
  AND (    so~\_ItemBasic\_Material-MaterialType <> @cv_material_type_hawa
        OR so~\_ItemBasic\_Material-MaterialType IS NULL
      )
  AND so~\_ItemBasic\_Material-IsBatchManagementRequired = @abap_true
UNION ALL
SELECT
  SalesDocument AS vbeln,
  so~\_ItemBasic-SalesDocumentItem AS posnr,
  so~\_ItemBasic-Material AS matnr,
  so~\_ItemBasic-NetAmount AS netwr,
  so~\_ItemBasic-TransactionCurrency AS waerk,
  so~\_ItemBasic\_Material-MaterialType AS mtart,
  so~\_ItemBasic\_Material-IsBatchManagementRequired AS xchpf,
  'Batch Managment is NOT required' AS IsBatchMgmtReq
  FROM I_SalesDocumentBasic AS so
  WHERE so~SalesDocumentType = @cv_sd_order_type_ta
  AND so~\_ItemBasic-SalesDocumentItem IS NOT NULL
  AND (    so~\_ItemBasic\_Material-MaterialType <> @cv_material_type_hawa
        OR so~\_ItemBasic\_Material-MaterialType IS NULL
      )
  AND so~\_ItemBasic\_Material-IsBatchManagementRequired = @abap_false
  ORDER BY vbeln, posnr
INTO TABLE @me->mt_so_descriptive[].

Each of 3 SELECT commands above contains respective conditions from the CASE operator used on the projection list of the single SELECT instruction. Such approach allows database system execute 3 separate threads in parallel and then combine their results via UNION ALL.

ATTENTION: do not use UNION without ALL keyword, because the advantage of parallel processing may be overshadowed with additional effort to eliminate duplicates from the result set (mt_so_descriptive[] internal table in our example).

Functional pattern: predecessor and successor

Imagine the situation in which we need to provide old and new values of the given table field in chronological order. 2 main tables of Change Documents (CDHDR - header and CDPOS - position) store such information. Our goal is to retrieve the pairs of the values for a given field - the old value before the change (predecessor) and the new value saved as the result of the change (successor). Subquery seems to be inevitable option to achieve this functionality, so SQL script implemented in ABAP Managed Database Procedure (AMDP) global class is the way to go. But first let's prepare CDS view that joins CDHDR and CDPOS before programming in SQL script:

define view entity Z_I_CD
with parameters
  iv_objclass : cdobjectcl,
  iv_tabname : tabname,
  iv_fldname : fieldname
as select from cdhdr as hdr
inner join cdpos as pos
on  pos.objectid = hdr.objectid
and pos.changenr = hdr.changenr
{
  key hdr.objectid,
  key hdr.changenr,
  key pos.tabkey,
  key pos.chngind,
  hdr.username,
  concat(hdr.udate, hdr.utime) as changed_on,
  pos.unit_old,
  pos.unit_new,
  pos.cuky_old,
  pos.cuky_new,
  pos.value_old,
  pos.value_new
}
where hdr.objectclas = $parameters.iv_objclass
and pos.tabname = $parameters.iv_tabname
and pos.fname = $parameters.iv_fldname

Another good practice used in the implementation above is the use of CDS view parameters: iv_objclass, iv_tabname and iv_fldname as we need to track the changes for the specific table field only. Concatenation of the date and time indicating when exactly the change occurred is crucial to build appropriate subquery in SQL script - see the field CHANGED_ON:

CLASS zcl_amdp_sel_pattern DEFINITION
  PUBLIC FINAL CREATE PUBLIC .

PUBLIC SECTION.
  INTERFACES : if_amdp_marker_hdb.

  CLASS-METHODS:
    read_cd_pair FOR TABLE FUNCTION z_f_cd_pair,
    read_toax FOR TABLE FUNCTION z_f_toax.

  PROTECTED SECTION.
  PRIVATE SECTION.
ENDCLASS.

CLASS zcl_amdp_sel_pattern IMPLEMENTATION.
  METHOD read_cd_pair
    BY DATABASE FUNCTION
    FOR HDB LANGUAGE SQLSCRIPT
    OPTIONS READ-ONLY
    USING z_i_cd.
    lt_result =
    select
      cd.mandt,
      cd.objectid,
      cd.tabkey,
      cd.changenr,
      cd.chngind,
      cd.username,
      cd.changed_on,
      cd.unit_old,
      cd.unit_new,
      cd.cuky_old,
      cd.cuky_new,
      cd.value_old,
      cd.value_new,
      pred.username as pred_username,
      pred.changed_on as pred_changed_on,
      pred.unit_old as pred_unit_old,
      pred.unit_new as pred_unit_new,
      pred.cuky_old as pred_cuky_old,
      pred.cuky_new as pred_cuky_new,
      pred.value_old as pred_value_old,
      pred.value_new pred_value_new
      from z_i_cd(
        iv_objclass => :iv_objclass,
        iv_tabname => :iv_tabname,
        iv_fldname => :iv_fldname ) as cd
      left outer join z_i_cd(
        iv_objclass => :iv_objclass,
        iv_tabname => :iv_tabname,
        iv_fldname => :iv_fldname ) as pred
      on pred.mandt = cd.mandt
      and pred.objectid = cd.objectid
      and pred.tabkey = cd.tabkey
      and pred.changed_on = (
        select MAX( cdlast.changed_on )
          from z_i_cd(
            iv_objclass => :iv_objclass,
            iv_tabname => :iv_tabname,
            iv_fldname => :iv_fldname ) as cdlast
          where cdlast.objectid = cd.objectid
          and cdlast.tabkey = cd.tabkey
          and cdlast.changed_on < cd.changed_on );
    RETURN :lt_result;
  ENDMETHOD.
ENDCLASS.

Optional predecessor (see alias PRED for Z_I_CD in outer join above) must have the greatest available value of the field CHANGED_ON but still lower than CHANGED_ON in successor entry (alias CD). Code available in github.com contains testing console class ZCL_SEL_PATTERN_TEST_CONSOLE that retrieves the pair of predecessor and successor with regard to the changes in VBAP-MATNR field (material of the Sales Order position).

Functional pattern: dynamic data source determination in CDS view

Dynamic data source determination in ABAP is a trivial task to implement:

DATA lt_toa01 TYPE STANDARD TABLE OF toa01.
DATA(lv_table_name) = 'TOA01'.

SELECT * FROM (lv_table_name) INTO TABLE @lt_toa01[].

Archive link tables like TOA01, TOA02, TOA03, etc. share identical structure, but based on the configuration each of these tables stores the links for the documents of different SAP objects. Implementing a similar solution in CDS view is not such straightforward topic. It is possible only via table function:

@EndUserText.label: 'Any TOA0x table'
define table function Z_F_TOAX
with parameters 
  iv_table_name : tabname16
returns {
  mandt : abap.clnt;
  sap_object : saeanwdid;
  object_id : saeobjid;
  archiv_id : saearchivi;
  arc_doc_id : saeardoid;
  ar_object : saeobjart;
  ar_date : saeabadate;
  del_date : saedeldate;
  reserve : saereserve;
}
implemented by method zcl_amdp_sel_pattern=>read_toax;

...and AMDP class:

METHOD read_toax
  BY DATABASE FUNCTION
  FOR HDB LANGUAGE SQLSCRIPT
  OPTIONS READ-ONLY
  USING toa01.

  DECLARE lv_query STRING;
  DECLARE lt_result TABLE LIKE toa01;

  lv_query = 'SELECT * FROM ' || :iv_table_name;

  EXECUTE IMMEDIATE lv_query INTO lt_result;

  RETURN :lt_result;
ENDMETHOD.

As we can see the whole trick is the use of EXECUTE IMMEDIATE command that SQL script offers. The source of data selection is delivered into AMDP method as input parameter iv_table_name.

Recommended resources for your readers to continue with your learning journey: 

Working code presented in this blog can be downloaded from here:

https://github.com/brbogdan/SQL-selection-patterns-in-S4

Related community managed tags you should subscribe to remain informed about this topic:   

ABAP Development

SQL

Related community blog posts:   

CDS Views Vs Traditional ABAP Logic Performance

SQL Scripts in SAP HANA

 How was the event for you?:   

 My session has gathered around 40 participants, who were acting interactively despite being a bit exhausted after big portion of the preceding sessions and rainy weather :-). I hope that some of them will have a chance to implement the patterns I shared on their commercial projects for their real customers.

I have also benefited from this event taking part in some very impressive sessions:

Level up your CAP skills by learning how to use the cds REPL presented by DJ Adams @qmacro
AI agents collaboration for SAP business processes using Google A2A protocol by Igor Narodowy
Why is it becoming increasingly difficult to keep up with SAP? by Paweł Pawlak @PawelPawlak
AI agents and SAP. What's the buzz? by Vitaliy Rudnytskiy @Vitaliy-R
3D modeling in UI5 by Nico Schoenteich @nicoschoenteich
SAPdalf Crafts AI agents by Łukasz Skorwider
SAP migrations and GenAI: pioneering the path forward by Tomasz Wilk

Many thanks to these speakers from me!    

Now let’s hear from you:   

Before ending the blog post I want to share that one of the things I enjoyed the most in SAP Inside Track Wroclaw 2025. It was meeting new people and old colleagues I haven't seen for a while . Who said this kind of fun needs to end in SAP Inside Track?:) Please introduce yourself in the comment’s section and share what you do in the world of SAP?

Splitstorm - A Generic Splitter Configuration Tool

2025-07-03T17:51:47.033000+02:00

Extracting and Restoring Splitter Container Configurations in SAP GUI with ABAP

When working with complex SAP GUI applications, it's common to use CL_GUI_SPLITTER_CONTAINER to structure screens. These splitter configurations often evolve over time and differ between users, environments, or sSAPGUI-settings.

This article presents a simple but effective way to extract and later restore the current configuration of SAP splitter containers using a small local ABAP utility that I call SplitStorm.

The core idea is not product-related. It's about treating layout configurations as data that can be stored and restored. While SAP provides APIs to define and modify split containers, it lacks built-in support for introspection and persistence of these layout states.

Problem Statement

There are a few typical situations where this becomes relevant:

Users have different SAPGUI settings (theme, fonts or fontsize) which results in different output and hidden information.
Different users have different interest on different areas. One user needs to have a bigger view on the global ALV-Grid, another colleague wants to see more of the detail view.
Different screen resolutions result in unused screen areas, e.g. when the ratio is set to 30% for the left object tree, what fits great on FullHD but is to much for higher resolutions or wide screens

Approach

Using recursive traversal and some clever techniques, it’s possible to extract the layout structure and size ratios of a splitter hierarchy. The data is stored in a simple, format that can later be used to reconstruct the exact same configuration.

The main features include:

Reading the layout hierarchy of nested CL_GUI_SPLITTER_CONTAINER instances
Capturing the orientation, pane sizes, and nesting relationships
Rebuilding the structure with the same layout at a later time

How does it work?

The method ANALYZE_AND_SAVE analyzes the container hierarchy of the given main container. To retrieve the number of rows and columns of a splitter, I simply try to get all containers in a 20x20-Grid. If I do not get a valid container for row 3 and column 4 then I know that there are max 2 rows or max 3 columns.

The height and width for each pane will be read and stored in a simple matrix information

Data will be saved in the Index-Table INDX where data in any format can be stored easily. A better way would be to transform the data to JSON or serialize in a data object and store it in an own table. But for my purposes I think that INDX is okay.

Restoring the data reads the path to the current container and sets height and width.

It's easy to build the standard layout and the restore the configuration from saved data.

The Code

The actual complete source code is available at github: Splitstorm

Demo report

The Demo report builds a sample configuration using splitter containers without any controls in it.

You can save the current configuration, load or delete an existing layout.

REPORT zt9r_splitstorm_demo01.

SELECTION-SCREEN PUSHBUTTON /1(20) TEXT-sav USER-COMMAND zsave.
SELECTION-SCREEN PUSHBUTTON /1(20) TEXT-lod USER-COMMAND zload.
SELECTION-SCREEN PUSHBUTTON /1(20) TEXT-del USER-COMMAND zdelete.

INITIALIZATION.

  DATA(docker) = NEW cl_gui_docking_container( ratio = 90 side = cl_gui_docking_container=>dock_at_bottom ).

  DATA(sca)   = NEW cl_gui_splitter_container( parent = docker rows = 2 columns = 2 ).
  DATA(sca1)  = NEW cl_gui_splitter_container( parent = sca->get_container( row = 1 column = 1 ) rows = 1 columns = 2 ).
  DATA(sca2)  = NEW cl_gui_splitter_container( parent = sca->get_container( row = 2 column = 1 ) rows = 2 columns = 1 ).
  DATA(scb1)  = NEW cl_gui_splitter_container( parent = sca2->get_container( row = 1 column = 1 ) rows = 1 columns = 2 ).
  DATA(scb2)  = NEW cl_gui_splitter_container( parent = sca2->get_container( row = 2 column = 1 ) rows = 2 columns = 1 ).


AT SELECTION-SCREEN.

  DATA(info) = NEW zt9r_splitstorm( sy-cprog ).

  CASE sy-ucomm.
    WHEN 'ZSAVE'.
      info->analyze_and_save( docker ).
    WHEN 'ZLOAD'.
      info->load_and_restore( docker ).
    WHEN 'ZDELETE'.
      info->delete( ).
  ENDCASE.

Main class

CLASS zt9r_splitstorm DEFINITION PUBLIC.
  PUBLIC SECTION.
    TYPES: BEGIN OF ty_splitter_info,
             path          TYPE string,
             rows          TYPE i,
             columns       TYPE i,
             row_heights   TYPE STANDARD TABLE OF i WITH DEFAULT KEY,
             column_widths TYPE STANDARD TABLE OF i WITH DEFAULT KEY,
           END OF ty_splitter_info.

    TYPES ty_splitter_info_tab TYPE STANDARD TABLE OF ty_splitter_info WITH DEFAULT KEY.

    METHODS delete.

    METHODS load_and_restore
      IMPORTING
        i_container TYPE REF TO cl_gui_container.

    METHODS analyze_and_save
      IMPORTING
        i_container TYPE REF TO cl_gui_container.

    METHODS constructor
      IMPORTING
        repid TYPE clike.

  PRIVATE SECTION.
    METHODS save.
    METHODS load.

    CONSTANTS mc_root TYPE string VALUE `ROOT`.

    METHODS analyze_recursive
      IMPORTING
        i_container   TYPE REF TO cl_gui_control
        i_path        TYPE string
      RETURNING
        VALUE(result) TYPE abap_bool.

    METHODS get_row_count
      IMPORTING
        i_splitter    TYPE REF TO cl_gui_splitter_container
      RETURNING
        VALUE(result) TYPE i.

    METHODS get_column_count
      IMPORTING
        i_splitter    TYPE REF TO cl_gui_splitter_container
      RETURNING
        VALUE(result) TYPE i.

    METHODS restore_recursive
      IMPORTING
        i_container TYPE REF TO cl_gui_control
        i_path      TYPE string.

    METHODS get_splitter_row_height
      IMPORTING
        io_splitter   TYPE REF TO cl_gui_splitter_container
      RETURNING
        VALUE(r_size) TYPE i.

    METHODS get_splitter_col_width
      IMPORTING
        io_splitter   TYPE REF TO cl_gui_splitter_container
      RETURNING
        VALUE(r_size) TYPE i.

    METHODS analyze
      IMPORTING
        i_container   TYPE REF TO cl_gui_container
      RETURNING
        VALUE(result) TYPE ty_splitter_info_tab.

    METHODS restore_sizes
      IMPORTING
        i_container TYPE REF TO cl_gui_container.

    METHODS get_id
      RETURNING
        VALUE(r_id) TYPE char20.

    DATA size_info TYPE ty_splitter_info_tab.
    DATA repid     TYPE c LENGTH 40.
ENDCLASS.



CLASS ZT9R_SPLITSTORM IMPLEMENTATION.


* <SIGNATURE>---------------------------------------------------------------------------------------+
* | Instance Private Method ZT9R_SPLITSTORM->ANALYZE
* +-------------------------------------------------------------------------------------------------+
* | [--->] I_CONTAINER                    TYPE REF TO CL_GUI_CONTAINER
* | [<-()] RESULT                         TYPE        TY_SPLITTER_INFO_TAB
* +--------------------------------------------------------------------------------------</SIGNATURE>
  METHOD analyze.
    LOOP AT i_container->children INTO DATA(child).
      analyze_recursive( i_container = child
                         i_path      = mc_root ).
    ENDLOOP.

    result = size_info.
  ENDMETHOD.


* <SIGNATURE>---------------------------------------------------------------------------------------+
* | Instance Public Method ZT9R_SPLITSTORM->ANALYZE_AND_SAVE
* +-------------------------------------------------------------------------------------------------+
* | [--->] I_CONTAINER                    TYPE REF TO CL_GUI_CONTAINER
* +--------------------------------------------------------------------------------------</SIGNATURE>
  METHOD analyze_and_save.
    analyze( i_container = i_container ).
    save( ).
  ENDMETHOD.


* <SIGNATURE>---------------------------------------------------------------------------------------+
* | Instance Private Method ZT9R_SPLITSTORM->ANALYZE_RECURSIVE
* +-------------------------------------------------------------------------------------------------+
* | [--->] I_CONTAINER                    TYPE REF TO CL_GUI_CONTROL
* | [--->] I_PATH                         TYPE        STRING
* | [<-()] RESULT                         TYPE        ABAP_BOOL
* +--------------------------------------------------------------------------------------</SIGNATURE>
  METHOD analyze_recursive.
    TRY.
        DATA(lo_splitter) = CAST cl_gui_splitter_container( i_container ).
        result = abap_true.
      CATCH cx_sy_move_cast_error.
        result = abap_false.
        RETURN.
    ENDTRY.

    DATA(lv_rows)    = get_row_count( lo_splitter ).
    DATA(lv_columns) = get_column_count( lo_splitter ).

    DATA lt_row_heights TYPE STANDARD TABLE OF i WITH DEFAULT KEY.
    DATA lt_col_widths  TYPE STANDARD TABLE OF i WITH DEFAULT KEY.

    DO lv_rows TIMES.
      APPEND get_splitter_row_height( lo_splitter ) TO lt_row_heights.
    ENDDO.

    DO lv_columns TIMES.
      APPEND get_splitter_col_width( lo_splitter ) TO lt_col_widths.
    ENDDO.

    APPEND VALUE ty_splitter_info( path          = i_path
                                   rows          = lv_rows
                                   columns       = lv_columns
                                   row_heights   = lt_row_heights
                                   column_widths = lt_col_widths )
           TO size_info.

    DATA(index_row) = 0.
    DATA(index_col) = 0.
    DO lv_rows TIMES.
      index_col = 0.
      index_row = index_row + 1.
      DO lv_columns TIMES.
        index_col = index_col + 1.
        DATA(lo_container) = lo_splitter->get_container( row    = index_row
                                                         column = index_col ).
        LOOP AT lo_container->children INTO DATA(lo_child).
          IF NOT analyze_recursive(
                     i_container = lo_child
                     i_path      = |{ i_path }[{ index_row },{ index_col }]| ).
            EXIT. " from do
          ENDIF.
        ENDLOOP.
      ENDDO.
    ENDDO.
  ENDMETHOD.


* <SIGNATURE>---------------------------------------------------------------------------------------+
* | Instance Public Method ZT9R_SPLITSTORM->CONSTRUCTOR
* +-------------------------------------------------------------------------------------------------+
* | [--->] REPID                          TYPE        CLIKE
* +--------------------------------------------------------------------------------------</SIGNATURE>
  METHOD constructor.
    me->repid = repid.
  ENDMETHOD.


* <SIGNATURE>---------------------------------------------------------------------------------------+
* | Instance Public Method ZT9R_SPLITSTORM->DELETE
* +-------------------------------------------------------------------------------------------------+
* +--------------------------------------------------------------------------------------</SIGNATURE>
  METHOD delete.
    DATA(id) = get_id( ).
    DELETE FROM DATABASE indx(z1) ID id.
    IF sy-subrc = 0 AND size_info IS NOT INITIAL.
      MESSAGE 'Splitter configuration deleted' TYPE 'S'.
    ENDIF.
  ENDMETHOD.


* <SIGNATURE>---------------------------------------------------------------------------------------+
* | Instance Private Method ZT9R_SPLITSTORM->GET_COLUMN_COUNT
* +-------------------------------------------------------------------------------------------------+
* | [--->] I_SPLITTER                     TYPE REF TO CL_GUI_SPLITTER_CONTAINER
* | [<-()] RESULT                         TYPE        I
* +--------------------------------------------------------------------------------------</SIGNATURE>
  METHOD get_column_count.
    result = 0.
    DO 20 TIMES.
      DATA(container) = i_splitter->get_container( row    = 1
                                                   column = sy-index ).
      IF container IS INITIAL.
        RETURN.
      ELSE.
        result = result + 1.
      ENDIF.
    ENDDO.
  ENDMETHOD.


* <SIGNATURE>---------------------------------------------------------------------------------------+
* | Instance Private Method ZT9R_SPLITSTORM->GET_ID
* +-------------------------------------------------------------------------------------------------+
* | [<-()] R_ID                           TYPE        CHAR20
* +--------------------------------------------------------------------------------------</SIGNATURE>
  METHOD get_id.
    r_id = |SPLITTER-{ repid }-{ sy-uname }|.
  ENDMETHOD.


* <SIGNATURE>---------------------------------------------------------------------------------------+
* | Instance Private Method ZT9R_SPLITSTORM->GET_ROW_COUNT
* +-------------------------------------------------------------------------------------------------+
* | [--->] I_SPLITTER                     TYPE REF TO CL_GUI_SPLITTER_CONTAINER
* | [<-()] RESULT                         TYPE        I
* +--------------------------------------------------------------------------------------</SIGNATURE>
  METHOD get_row_count.
    result = 0.
    DO 20 TIMES.
      DATA(container) = i_splitter->get_container( row    = sy-index
                                                   column = 1 ).
      IF container IS INITIAL.
        RETURN.
      ELSE.
        result = result + 1.
      ENDIF.

    ENDDO.
  ENDMETHOD.


* <SIGNATURE>---------------------------------------------------------------------------------------+
* | Instance Private Method ZT9R_SPLITSTORM->GET_SPLITTER_COL_WIDTH
* +-------------------------------------------------------------------------------------------------+
* | [--->] IO_SPLITTER                    TYPE REF TO CL_GUI_SPLITTER_CONTAINER
* | [<-()] R_SIZE                         TYPE        I
* +--------------------------------------------------------------------------------------</SIGNATURE>
  METHOD get_splitter_col_width.
    io_splitter->get_column_width( EXPORTING
                                     id     = sy-index
                                   IMPORTING
                                     result = r_size  ).
    cl_gui_cfw=>flush( ).
  ENDMETHOD.


* <SIGNATURE>---------------------------------------------------------------------------------------+
* | Instance Private Method ZT9R_SPLITSTORM->GET_SPLITTER_ROW_HEIGHT
* +-------------------------------------------------------------------------------------------------+
* | [--->] IO_SPLITTER                    TYPE REF TO CL_GUI_SPLITTER_CONTAINER
* | [<-()] R_SIZE                         TYPE        I
* +--------------------------------------------------------------------------------------</SIGNATURE>
  METHOD get_splitter_row_height.
    io_splitter->get_row_height( EXPORTING
                                   id     = sy-index
                                 IMPORTING
                                   result = r_size  ).
    cl_gui_cfw=>flush( ).
  ENDMETHOD.


* <SIGNATURE>---------------------------------------------------------------------------------------+
* | Instance Private Method ZT9R_SPLITSTORM->LOAD
* +-------------------------------------------------------------------------------------------------+
* +--------------------------------------------------------------------------------------</SIGNATURE>
  METHOD load.
    DATA(id) = get_id( ).
    IMPORT splitter_info TO size_info FROM DATABASE indx(z1) ID id.
    IF sy-subrc = 0 AND size_info IS NOT INITIAL.
      MESSAGE 'Splitter configuration loaded' TYPE 'S'.
    ENDIF.
  ENDMETHOD.


* <SIGNATURE>---------------------------------------------------------------------------------------+
* | Instance Public Method ZT9R_SPLITSTORM->LOAD_AND_RESTORE
* +-------------------------------------------------------------------------------------------------+
* | [--->] I_CONTAINER                    TYPE REF TO CL_GUI_CONTAINER
* +--------------------------------------------------------------------------------------</SIGNATURE>
  METHOD load_and_restore.
    load( ).
    restore_sizes( i_container = i_container ).
  ENDMETHOD.


* <SIGNATURE>---------------------------------------------------------------------------------------+
* | Instance Private Method ZT9R_SPLITSTORM->RESTORE_RECURSIVE
* +-------------------------------------------------------------------------------------------------+
* | [--->] I_CONTAINER                    TYPE REF TO CL_GUI_CONTROL
* | [--->] I_PATH                         TYPE        STRING
* +--------------------------------------------------------------------------------------</SIGNATURE>
  METHOD restore_recursive.
    TRY.
        DATA(splitter) = CAST cl_gui_splitter_container( i_container ) ##NO_TEXT.
      CATCH cx_sy_move_cast_error.
        RETURN.
    ENDTRY.

    READ TABLE size_info INTO DATA(info) WITH KEY path = i_path.
    IF sy-subrc <> 0 OR splitter IS INITIAL.
      RETURN.
    ENDIF.

    DATA(idx) = 1.

    LOOP AT info-row_heights INTO DATA(lv_r).
      splitter->set_row_height( id = idx height = lv_r ).
      idx = idx + 1.
    ENDLOOP.

    idx = 1.
    LOOP AT info-column_widths INTO DATA(lv_c).
      splitter->set_column_width( id = idx width = lv_c ).
      idx = idx + 1.
    ENDLOOP.

    " Rekursiv weiter
    DATA(index_row) = 0.
    DATA(index_col) = 0.
    DO info-rows TIMES.
      index_col = 0.
      index_row = index_row + 1.
      DO info-columns TIMES.
        index_col = index_col + 1.
        DATA(lo_container) = splitter->get_container( row    = index_row
                                                      column = index_col ).
        DATA(lv_subpath) = |{ i_path }[{ index_row },{ index_col }]|.
        LOOP AT lo_container->children INTO DATA(lo_child).
          restore_recursive( i_container = lo_child
                             i_path      = lv_subpath ).
        ENDLOOP.
      ENDDO.
    ENDDO.
  ENDMETHOD.


* <SIGNATURE>---------------------------------------------------------------------------------------+
* | Instance Private Method ZT9R_SPLITSTORM->RESTORE_SIZES
* +-------------------------------------------------------------------------------------------------+
* | [--->] I_CONTAINER                    TYPE REF TO CL_GUI_CONTAINER
* +--------------------------------------------------------------------------------------</SIGNATURE>
  METHOD restore_sizes.
    IF size_info IS INITIAL.
      RETURN.
    ENDIF.

    LOOP AT i_container->children INTO DATA(child).
      restore_recursive( i_container = child
                         i_path      = mc_root ).
    ENDLOOP.
  ENDMETHOD.


* <SIGNATURE>---------------------------------------------------------------------------------------+
* | Instance Private Method ZT9R_SPLITSTORM->SAVE
* +-------------------------------------------------------------------------------------------------+
* +--------------------------------------------------------------------------------------</SIGNATURE>
  METHOD save.
    IF size_info IS INITIAL.
      RETURN.
    ENDIF.

    DATA(id) = get_id( ).
    EXPORT splitter_info FROM size_info TO DATABASE indx(z1) ID id.
    MESSAGE 'Splitter configuration saved' TYPE 'S'.
  ENDMETHOD.
ENDCLASS.

Replace All Occurrences in Multiple Fields of an Internal Table

2025-07-04T18:13:43.456000+02:00

This blog provides a smart way to clean special characters like @, #, !, and , from internal table data.
It helps when exporting data to CSV files, especially for AL11 directory usage.
Instead of writing code for each field, we clean all fields in one loop using field symbols.
RTTI (Runtime Type Info) is used to make it dynamic for any table.
This makes your exported data neat, clean, and ready for use.

Before Replacing

Code :

REPORT ZREPLACE_INTERNAL_TABLE.

"Define structure TY_DATA for sample person data
TYPES: BEGIN OF TY_DATA,
         NAME     TYPE STRING,
         CITY     TYPE STRING,
         EMAIL    TYPE STRING,
         ADDRESS  TYPE STRING,
         COMMENTS TYPE STRING,
       END OF TY_DATA.

"Internal table and work area to hold the data
DATA: LT_DATA TYPE TABLE OF TY_DATA,
      LS_DATA TYPE TY_DATA.

"Reference for SALV display
DATA: LT_FACTORTY  TYPE REF TO CL_SALV_TABLE.

"Sample data containing unwanted characters: @, #, !, ,
LT_DATA = VALUE #(
  ( name = 'Mani@ Yadav!' city = 'Hydera#bad' email = 'mani@yadav@example.com' address = 'Road No, 1, Banjara Hills' comments = 'Good@ Person!' )
  ( name = 'Anil Kumar' city = 'Mum#bai' email = 'anil.kumar@exa!mple.com' address = 'Apt@ 123, Green Society' comments = 'Very# Good, Employee' )
  ( name = 'Ravi Teja!' city = 'Hyder@abad' email = 'ravi.teja#@example.com' address = 'Street 45, Jubilee@ Hills' comments = 'Nice, and Reliable!' )
  ( name = 'Sushil Kumar' city = 'Chen@nai' email = 'sushil@kumar@example.com' address = 'Block 7, Ap@artment 3' comments = 'Great, Wo!rker' )
  ( name = 'Kavita@ Lal' city = 'Pune, City' email = 'kavita.lal#@example.com' address = 'MG Road@, Sector 2!' comments = 'Smart and@ Intellig!ent' )
  ( name = 'Arjun Mehta' city = 'Kolkata' email = 'arjun!mehta@example.com' address = 'Sector 9@, Block B' comments = 'Honest@ and Helpful!' )
  ( name = 'Deepa Agarwal#' city = 'Jai!pur' email = 'deepa@agarwal@example.com' address = 'Colony 5@, Lane 3' comments = 'Re#liable Friend!' )
  ( name = 'Vikrant Singh' city = 'Goa! Beach@' email = 'vikrant@singh#@example.com' address = 'Villa 22, P@alolem' comments = 'Social@ Worker#' )
  ( name = 'Neha Sharma' city = 'Ind@ore# MP!' email = 'neha@sharma@example.com' address = 'Home@ 98, New Town!' comments = 'Quick@ L!ear#ner' )
  ( name = 'Priya! Verma' city = 'De@lhi' email = 'priya.verma@example.com' address = 'Flat 12B, Lotus En@clave!' comments = 'Team, Play#er!' )
).

"Characters we want to remove from all fields
DATA: LT_UNWANTED TYPE STANDARD TABLE OF STRING WITH EMPTY KEY,
      LV_CHAR     TYPE STRING.

APPEND '@' TO LT_UNWANTED.
APPEND '#' TO LT_UNWANTED.
APPEND '!' TO LT_UNWANTED.
APPEND ',' TO LT_UNWANTED.

FIELD-SYMBOLS: <FS_DATA>  TYPE ANY,
               <FS_FIELD> TYPE ANY.

"Loop through each row in the internal table
LOOP AT LT_DATA ASSIGNING <FS_DATA>.

  "Get runtime structure description using RTTI
  DATA(LO_TABLE_DESCR) = CAST CL_ABAP_TABLEDESCR( CL_ABAP_TYPEDESCR=>DESCRIBE_BY_DATA( LT_DATA ) ).
  DATA(LO_LINE_DESCR)  = CAST CL_ABAP_STRUCTDESCR( LO_TABLE_DESCR->GET_TABLE_LINE_TYPE( ) ).
  DATA(LT_COMPONENTS)  = LO_LINE_DESCR->COMPONENTS.

  "Loop through each field in the structure
  LOOP AT LT_COMPONENTS INTO DATA(LS_COMPONENT).
    ASSIGN COMPONENT LS_COMPONENT-NAME OF STRUCTURE <FS_DATA> TO <FS_FIELD>.

    "Replace all unwanted characters with space
    IF SY-SUBRC = 0 AND <FS_FIELD> IS ASSIGNED.
      LOOP AT LT_UNWANTED INTO LV_CHAR.
        REPLACE ALL OCCURRENCES OF LV_CHAR IN <FS_FIELD> WITH ' '.
      ENDLOOP.
    ENDIF.
  ENDLOOP.
ENDLOOP.

"Display the cleaned internal table using SALV Grid
CALL METHOD CL_SALV_TABLE=>FACTORY
  IMPORTING
    R_SALV_TABLE = LT_FACTORTY
  CHANGING
    T_TABLE      = LT_DATA.

LT_FACTORTY->DISPLAY( ).

"Debugger breakpoint for inspection (optional)
BREAK-POINT.

Final Output after Replacing

ABAP Development

FACTORY ALV with Header , Logo and Footer in ABAP

2025-07-05T11:39:33.748000+02:00

I’m excited to share my very first blog post on SAP ABAP programming! In this post, you'll learn how to create an ALV report using the Factory Method, complete with a custom header, logo, and footer to enhance your report’s appearance and professionalism.

1. Create Logo

step1 : Go to OAER T code .

step2 : Enter the following fields for your logo.

Step 3: Click on Execute.

Step 4: Below screen will displayed, double click on Standard Doc Types.

Step 5: Double Click on a screen and select the picture from your files you want make logo.

REPORT ZVA_HEADER_LOGO_FACTORY.
* Declare table reference
TABLES: ZVA_VENDOR_TA.
* Declare data references
DATA: LT_TABLE TYPE REF TO CL_SALV_TABLE, " Reference to ALV table object
      LV_TEXT  TYPE STRING.               " Text string for header

* Selection screen for Vendor Numbers
SELECT-OPTIONS: S_VENO FOR ZVA_VENDOR_TA-VENDERNO.

START-OF-SELECTION.

  * Select data from custom vendor table based on selection
  SELECT VENDERNO, NAME, CITY, POSTALCODE, EMAIL, ACCOUNTGROUP, PROCESSORGROUP, POSTINGBLOCK
    INTO TABLE @DATA(LT_VENDOR)
    FROM ZVA_VENDOR_TA
    WHERE VENDERNO IN @S_VENO.

  * Proceed only if records are found
  IF LT_VENDOR IS NOT INITIAL.

    * Create the SALV (ALV) object using factory method
    CL_SALV_TABLE=>FACTORY(
      IMPORTING
        R_SALV_TABLE = LT_TABLE
      CHANGING
        T_TABLE      = LT_VENDOR
    ).

    * Create layout grids and logo objects for header and footer customization
    DATA(LT_LAYOUT)  = NEW CL_SALV_FORM_LAYOUT_GRID( ).
    DATA(LT_LAYOUT1) = NEW CL_SALV_FORM_LAYOUT_GRID( ).
    DATA(LT_LOGO)    = NEW CL_SALV_FORM_LAYOUT_LOGO( ).

    * Set the header title
    LV_TEXT = 'VINOD KUMAR REDDY'.
    LT_LAYOUT->CREATE_HEADER_INFORMATION(
      EXPORTING
        ROW     = 3
        COLUMN  = 1
        TEXT    = LV_TEXT
    ).

    * Add user name label and text
    LT_LAYOUT->CREATE_LABEL(
      EXPORTING
        ROW     = 5
        COLUMN  = 1
        TEXT    = 'User Name' ).

    LT_LAYOUT->CREATE_TEXT(
      EXPORTING
        ROW     = 5
        COLUMN  = 2
        TEXT    = 'VINOD APPANNAGARI' ).

    * Add date label and current date value
    LT_LAYOUT->CREATE_LABEL(
      EXPORTING
        ROW     = 3
        COLUMN  = 1
        TEXT    = 'Date' ).

    LT_LAYOUT->CREATE_TEXT(
      EXPORTING
        ROW     = 3
        COLUMN  = 2
        TEXT    = SY-DATUM ).

    * Add time label and current system time
    LT_LAYOUT->CREATE_LABEL(
      EXPORTING
        ROW     = 4
        COLUMN  = 1
        TEXT    = 'Time' ).

    LT_LAYOUT->CREATE_TEXT(
      EXPORTING
        ROW     = 4
        COLUMN  = 2
        TEXT    = SY-UZEIT ).

    * Add footer layout - number of records found
    LT_LAYOUT1->CREATE_LABEL(
      EXPORTING
        ROW     = 2
        COLUMN  = 1
        TEXT    = 'Number of records found' ).

    DATA: LV_COUNT TYPE INT4.
    DESCRIBE TABLE LT_VENDOR LINES LV_COUNT.

    LT_LAYOUT1->CREATE_TEXT(
      EXPORTING
        ROW     = 2
        COLUMN  = 2
        TEXT    = LV_COUNT
        TOOLTIP = LV_COUNT ).

    * Set SAP logo on the right of the header
    LT_LOGO->SET_RIGHT_LOGO( 'SAPLOGO1' ).
    * Set header and footer content
    LT_LOGO->SET_LEFT_CONTENT( LT_LAYOUT ).
    LT_TABLE->SET_TOP_OF_LIST( VALUE = LT_LOGO ).
    LT_TABLE->SET_END_OF_LIST( VALUE = LT_LAYOUT1 ).
    * Display the ALV table
    LT_TABLE->DISPLAY( ).
  ENDIF.

Output:

ABAP Development

🚀 SAP RAP Events: Custom Logic Without BAdIs or User Exits

2025-07-08T08:49:47.512000+02:00

As SAP S/4HANA continues to evolve with clean core principles, the ABAP RESTful Application Programming Model (RAP) is taking center stage. One of the most underused but powerful features of RAP is its event-based architecture, which allows you to plug in custom logic in a clean and upgrade-safe way.

Today, I want to share how you can listen to standard RAP events and trigger your own custom events — no BAdIs or user exits needed!

🧠 The Concept: RAP Event Listeners

In classic SAP ABAP, you’d typically write enhancements using:

🔧 BAdIs
🔄 User exits
💡 Implicit enhancements

But in RAP, you can react to standard business behavior via events. That means you can write your own custom logic that responds when something happens in a standard RAP BO (Business Object) — like a purchase order being approved — by listening to its published events.

This is cleaner, future-proof, and doesn't modify the standard codebase.

🎯 Real Use Case

Let’s say SAP’s standard BO for PurchaseOrder publishes an event when a PO is approved. You want to send a custom email, update another Z table, or trigger integration — only when that event happens.

✅ In RAP, you can do this like so:

Step 1: The standard RAP object publishes the approval event (R_PurchaseOrderTP)
Step 2: Your custom RAP behavior definition listens for that event.
Step 3: You trigger a custom implementation, e.g., a mail sender class or integration call.

No BAdI. No user exit. No modifications.

🖼️ Illustration: RAP Event Flow

Figure 1: Listening to Standard RAP Events in a Custom BO

🛠️ How to Implement

Here’s a simplified code sketch of how this works:

1. Listen to Standard Event in Custom BO

CLASS zcl_po_ext DEFINITION

PUBLIC ABSTRACT FINAL

FOR EVENTS OF R_PurchaseOrderTP.

PUBLIC SECTION.

PROTECTED SECTION.

PRIVATE SECTION.

ENDCLASS.

2. Handle the Event in Your Class

CLASS lhe_po_ext DEFINITION INHERITING FROM cl_abap_behavior_event_handler.

PRIVATE SECTION.

METHODS on_approved FOR ENTITY EVENT

approved FOR purchaseorder~approved.

ENDCLASS.

You’re done — and you didn’t need to touch a single line of standard code!

💡 Why This Matters

🔒 Clean Core Compliant – Stay upgrade-safe.
⚡ No Enhancements or BAdIs Needed – Simpler architecture.
🧱 Composable – Build logic modularly using RAP principles.
🔁 Reusability – Listen to multiple events, reuse handlers across objects.

📣 Final Thoughts

The RAP event mechanism offers a paradigm shift in how we build custom logic in SAP. It allows us to be event-driven, clean, and compliant with SAP's future direction.

If you’re developing on S/4HANA or looking to modernize your ABAP stack — RAP events are your secret weapon.

👀 Have you tried this approach in your projects? I’d love to hear your experience. Let’s connect and share ideas!

🔗 #SAPRAP #CleanCore #S4HANA #ABAP #SAPDevelopers #NoMoreBADIs #EventDrivenArchitecture