SAP Community - ABAP RESTful Application Programming Model

Implementing RAP Action Parameter Value Help Using CDS Abstract Entity in SAP RAP

2026-06-09T09:39:02.577000+02:00

Introduction

The ABAP RESTful Application Programming Model (RAP) provides a powerful way to build modern SAP Fiori applications using behavior definitions, CDS views, and OData services.

One common requirement in business applications is allowing users to execute actions on one or multiple records while providing additional input through a dialog popup. In many scenarios, this input should be selected from a predefined list of values rather than entered manually.

A typical example is updating the category of one or more products. Users should be able to trigger an action, choose a valid category from a value help dialog, and apply the selected category to all chosen records.

This blog demonstrates how to implement an RAP Action Parameter with Value Help using a CDS Abstract Entity, CDS Value Help View, and Behavior Action. The result is a Fiori Elements application where users can execute an action and select values through standard SAP F4 help.

What are RAP Action Parameters?

Actions in RAP allow developers to execute custom business logic that goes beyond standard Create, Update, and Delete operations.

An action can:

Execute custom business logic
Update one or multiple records
Trigger validations
Open parameter dialogs for user input

When an action requires user input, RAP automatically generates a dialog popup using an Abstract Entity.

This makes actions ideal for scenarios such as:

Approving business documents
Assigning categories
Updating statuses
Triggering business processes

Real-Time Business Scenario: Mass Category Assignment

Consider a product management application.

Business users maintain products and their categories.

Examples:

Product ID Product Name Category

P1001	Laptop	ELEC
P1002	Office Chair	FURN
P1003	T-Shirt	CLTH

A user selects multiple products and wants to update their category simultaneously.

Instead of editing each product individually:

Select one or more products
Click Set Category
Choose a category from F4 Help
Confirm the action

All selected products are updated automatically.

The Problem

If the category field is entered manually:

Users may enter invalid values
Validation becomes difficult
User experience is poor
Data consistency cannot be guaranteed

Example:

ELEC  ✔ Valid
FURN  ✔ Valid
ABCD  ✖ Invalid
XYZ1  ✖ Invalid

Without a value help mechanism, users can easily enter incorrect data.

The Solution

To solve this problem, we implement:

A Category Master table
A CDS Value Help View
A CDS Abstract Entity for action parameters
A RAP Action with parameter support
A Fiori Elements Value Help dialog

The action parameter field is linked to the value help CDS entity using:

@Consumption.valueHelpDefinition

This automatically generates:

F4 Help
Search dialog
Value validation
User-friendly selection experience

Implementation Using RAP Action Parameter Value Help

Step 1: Create Category Master Table

Create a database table to store available product categories.

@EndUserText.label : 'Product Category Table'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table zprod_category {

  key client      : abap.clnt not null;
  key category_id : abap.char(4) not null;
  category_name   : abap.char(40);

}

This table acts as the master source for the value help.

Step 2: Create Product Table

Create a product table containing:

Product ID
Product Name
Category
Audit fields

@EndUserText.label : 'Product Table'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #ALLOWED
define table zproduct_s {

  key client            : abap.clnt not null;
  key product_id        : abap.char(10) not null;
  product_name          : abap.char(40);
  category              : abap.char(4);
  created_by            : abp_creation_user;
  created_at            : abp_creation_tstmpl;
  last_changed_by       : abp_locinst_lastchange_user;
  last_changed_at       : abp_locinst_lastchange_tstmpl;
  local_last_changed_at : abp_locinst_lastchange_tstmpl;

}

This table stores the transactional product data.

Step 3: Create Value Help CDS View

Create a CDS View Entity that exposes category information.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Category Value Help'
@Metadata.ignorePropagatedAnnotations: true
@ObjectModel.usageType:{
    serviceQuality: #X,
    sizeCategory: #S,
    dataClass: #MIXED
}

define view entity ZI_CategoryVH
  as select from zprod_category
{
  key category_id   as CategoryId,
      category_name as CategoryName
}

Explanation:

Provides the source for value help
Supplies category IDs and descriptions
Used by both RAP and Fiori Elements

Step 4: Create Root Interface View

Create the RAP Root Interface View.

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Product Interface View'
@Metadata.ignorePropagatedAnnotations: true
define root view entity ZI_PRODUCT_S as select from zproduct_s
{
    
  key product_id              as ProductId,
      product_name            as ProductName,
      category                as Category,

      @Semantics.user.createdBy: true
      created_by              as CreatedBy,

      @Semantics.systemDateTime.createdAt: true
      created_at              as CreatedAt,

      @Semantics.user.lastChangedBy: true
      last_changed_by         as LastChangedBy,

      @Semantics.systemDateTime.lastChangedAt: true
      last_changed_at         as LastChangedAt,

      @Semantics.systemDateTime.localInstanceLastChangedAt: true
      local_last_changed_at   as LocalLastChangedAt
}

This view represents the Product business object.

Step 5: Create Projection View

Create the Projection View exposed to Fiori.

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Product Projection View'
@Metadata.ignorePropagatedAnnotations: true
@Metadata.allowExtensions: true
define root view entity ZC_PRODUCT
  provider contract transactional_query
  as projection on ZI_PRODUCT_S
{
  key ProductId,
      ProductName,
      @Consumption.valueHelpDefinition: [{
         entity: {
           name: 'ZI_CATEGORYVH',
           element: 'CategoryId'
         }
       }]
      Category,
      CreatedBy,
      CreatedAt,
      LastChangedBy,
      LastChangedAt,
      LocalLastChangedAt
}

This enables F4 Help on the Category field.

Step 6: Create Abstract Entity for Action Parameters

The action dialog parameters are defined using a CDS Abstract Entity.

@EndUserText.label: 'Parameter for Set Category Action'
define abstract entity ZA_SETCATEGORY_PARAM
{
  @EndUserText.label: 'New Category'
  @Consumption.valueHelpDefinition: [{
    entity    : {
      name    : 'ZI_CATEGORYVH',
      element : 'CategoryId'
    },
    useForValidation: true
  }]
  NewCategory : abap.char(4);

}

Explanation:

Generates the popup field
Provides F4 help
Enables automatic validation

Important:

useForValidation: true

prevents invalid values from being entered.

Step 7: Create Interface Behavior Definition

Define the RAP Action.

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

define behavior for ZI_PRODUCT_S alias Product
persistent table zproduct_s
lock master
authorization master ( instance )
etag master LastChangedAt
{
  create;
  update;
  delete;

  field ( readonly ) ProductId, CreatedBy, CreatedAt,
  LastChangedBy, LastChangedAt,
  LocalLastChangedAt;

  field ( mandatory ) ProductName;

  action setCategory parameter ZA_SETCATEGORY_PARAM
    result [1] $self;

  mapping for zproduct_s corresponding
    {
      ProductId          = product_id;
      ProductName        = product_name;
      Category           = category;
      CreatedBy          = created_by;
      CreatedAt          = created_at;
      LastChangedBy      = last_changed_by;
      LastChangedAt      = last_changed_at;
      LocalLastChangedAt = local_last_changed_at;
    }
}

Step 8: Implement Action Logic

In the behavior implementation class:

METHOD setcategory.

The implementation:

Reads selected products
Retrieves action parameter value
Updates category field
Returns updated records

The selected category is obtained from:

keys[ ... ]-%param-NewCategory

CLASS lhc_Product DEFINITION INHERITING FROM cl_abap_behavior_handler.
  PRIVATE SECTION.

    METHODS get_instance_authorizations FOR INSTANCE AUTHORIZATION
      IMPORTING keys REQUEST requested_authorizations FOR Product RESULT result.

    METHODS setCategory FOR MODIFY
      IMPORTING keys FOR ACTION Product~setCategory RESULT result.

ENDCLASS.

CLASS lhc_Product IMPLEMENTATION.

  METHOD get_instance_authorizations.
  ENDMETHOD.

  METHOD setCategory.

    " Read current product records
    READ ENTITIES OF zi_product_s IN LOCAL MODE
      ENTITY Product
        FIELDS ( ProductId Category )
        WITH CORRESPONDING #( keys )
      RESULT DATA(lt_products).

    " Update category field for each selected product
    MODIFY ENTITIES OF zi_product_s IN LOCAL MODE
      ENTITY Product
        UPDATE FIELDS ( Category )
        WITH VALUE #(
          FOR ls_prod IN lt_products
          (
            %tky     = ls_prod-%tky
            Category = keys[ KEY entity
                              %key = ls_prod-%key
                            ]-%param-NewCategory
          )
        )
      REPORTED DATA(lt_reported).

    " Return updated records as action result
    READ ENTITIES OF zi_product_s IN LOCAL MODE
      ENTITY Product
        ALL FIELDS
        WITH CORRESPONDING #( keys )
      RESULT DATA(lt_result).

    result = VALUE #(
      FOR ls_res IN lt_result
      ( %tky   = ls_res-%tky
        %param = ls_res )
    ).
  ENDMETHOD.

ENDCLASS.

Step 9: Create Projection Behavior Definition

Expose the action:

projection;
strict ( 2 );

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

  use action setCategory;
}

Step 10: Create Metadata Extension

Add UI annotations.

@Metadata.layer: #CORE

annotate entity ZC_PRODUCT with
{
  @ui.facet: [
  {
    id:       'ProductInfo',
    type:     #IDENTIFICATION_REFERENCE,
    label:    'Product Information',
    position: 10
  }
  ]

  @ui.lineItem: [
    { position: 10, label: 'Product ID' },
    { type: #FOR_ACTION, dataAction: 'setCategory',
      label: 'Set Category', position: 40 }
  ]
  @ui.identification: [{ position: 10 }]
  @ui.selectionField: [{ position: 10 }]
  ProductId;

  @ui.lineItem: [{ position: 20, label: 'Product Name' }]
  @ui.identification: [{ position: 20 }]
  ProductName;

  @ui.lineItem: [{ position: 30, label: 'Category' }]
  @ui.identification: [{ position: 30 }]
  Category;

}

Step 11: Create Service Definition

Expose both entities.

@EndUserText.label: 'Product Service'
define service ZSD_PRODUCT {
  expose ZC_PRODUCT    as Product;
  expose ZI_CategoryVH as CategoryVH;
}

Important:

Many developers forget to expose the value help entity.

Without exposing:

ZI_CATEGORY_VH

the F4 dialog will not display any data.

Step 12: Create Service Binding

Create:

OData V4 - UI

service binding.

Activate and Publish the service.

Result

Once the application is launched, users can:

1. Select Products

☑ P1001 Laptop
☑ P1002 Office Chair

2. Click Set Category

[ Set Category ]

3. Action Dialog Opens

Set Category

New Category [      ] 🔍

4. Open Value Help

ELEC  Electronics
FURN  Furniture
CLTH  Clothing
FOOD  Food & Beverages

5. Choose a Category

Example:

ELEC

6. Confirm

OK

7. RAP Action Executes

Selected records are updated automatically.

8. List Refreshes

P1001  Laptop        ELEC
P1002  Office Chair  ELEC

Success message:

Category updated successfully

Conclusion

In this blog, we explored how to implement RAP Action Parameters with Value Help using a CDS Abstract Entity.

We discussed a real-world business scenario where users need to update product categories for multiple records while ensuring only valid values can be selected.

By combining a CDS Value Help View, Abstract Entity, RAP Action, and Fiori Elements annotations, we were able to create a user-friendly action dialog with built-in F4 help and validation.

This approach provides a reusable pattern for implementing parameterized actions in RAP and can easily be extended for approval processes, status updates, assignment actions, and many other business scenarios while maintaining a clean and scalable design.

Using Domain Fixed Values as Value Help in SAP RAP Fiori Elements

2026-06-09T12:32:30.310000+02:00

Introduction

In SAP RAP Fiori applications, value help improves the user experience by providing predefined selectable values for filter and input fields.

One simple and efficient approach is to use ABAP Domain Fixed Values as value help instead of creating separate CDS value help entities.

In this blog, we will see how to implement value help in Fiori Elements using Domain Fixed Values in SAP RAP.

Business Requirement

In a SAP RAP Fiori Elements application, users should be able to select predefined status values through Value Help instead of entering values manually.

The Status field should display fixed values maintained in an ABAP Domain, such as:

100 – Not Prepared
101 – In Preparation
102 – Completed
When the user opens the value help in the Fiori application, the system should automatically display these fixed domain values along with their descriptions.
Step 1: Create a Domain with Fixed Values
Before building the Value Help CDS View, we first need to create an ABAP Domain that contains the fixed status values.
The domain will act as the source for the Value Help values displayed in the Fiori application.

Step 2: Build the Value Help CDS View
SAP provides two standard tables that expose domain fixed values:
1. DD07L - Contains the fixed values of the domains.
2. DD07T - Language-dependent description texts.
We join these two views and pass our domain name as a parameter. The join on `$session.system_language` is important — without it, you'd get one row per language in the system, causing duplicates in the dropdown.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Status'
@Metadata.ignorePropagatedAnnotations: true
define view entity ZI_BP_STATUS_VH 
as select from dd07l as values
    inner join   dd07t as texts on  values.domname    = texts.domname
                                and values.domvalue_l = texts.domvalue_l
                                and texts.ddlanguage  = $session.system_language
{
      @ObjectModel.text.element: [ 'StatusText' ]
  key values.domvalue_l as StatusCode,
      texts.ddtext      as StatusText
}
where values.domname = 'ZDO_VD_STATUS'
and texts.domname = 'ZDO_VD_STATUS'.

Step 3: Attach the Value Help to the Main CDS View

Now go to the Projection View (Consumption CDS View) where the Status field is defined.

Use the annotation @Consumption.valueHelpDefinition to connect the field with the Value Help CDS View.

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Header'
@Metadata.ignorePropagatedAnnotations: true
@Metadata.allowExtensions: true
@Search.searchable: true
@ObjectModel.semanticKey: [ 'ExternalId' ]
define root view entity ZC_BP_REQHDR
  provider contract transactional_query
  as projection on ZI_BP_REQHDR
{

  key     RequestUuid,

          @search.defaultSearchElement: true
          ExternalId,
          @search.defaultSearchElement: true
          @ObjectModel.text.element: [ 'RequesterName' ]
          @Consumption.valueHelpDefinition: [{ entity: { name: 'I_BusinessPartnerVH',
                                                         element: 'BusinessPartner' } }]
          RequesterId,
          _Requester.BusinessPartnerName as RequesterName,
          @search.defaultSearchElement: true
          @ObjectModel.text.element: [ 'StatusText' ]
          @Consumption.valueHelpDefinition: [{ entity: { name: 'ZI_BP_STATUS_EDIT_VH',
                                                          element: 'StatusCode' } }]
          Status,
          @ObjectModel.text.element: [ 'StatusText' ]
          @Consumption.valueHelpDefinition: [{ entity: { name: 'ZI_BP_STATUS_VH',
                                                         element: 'StatusCode' } }]
          //          Status                         as StatusFilter,
          _status.StatusText             as StatusText,
          StatusCriticality,
          @search.defaultSearchElement: true
          @ObjectModel.text.element: [ 'PriorityText' ]
          @Consumption.valueHelpDefinition: [{ entity: { name: 'ZI_BP_PRIORITY_VH',
                                                         element: 'PriorityCode' } }]
          @Consumption.filter.selectionType: #SINGLE
          Priority,
          _priority.PriorityText         as PriorityText,
          DeadlineDate,
          CancelReason,

          @ObjectModel.virtualElement: true
          @ObjectModel.virtualElementCalculatedBy: 'ABAP:ZCL_BP_CANCEL_REQUEST'
  virtual CancelReasonHidden : abap_boolean,

          LastChangedAt,

          _items : redirected to composition child ZC_BP_REQITEM,
          _Requester
}

Value Help Configuration in RAP

The below annotations are used to enable Value Help for the Status field in SAP RAP Fiori Elements.

`@Consumption.valueHelpDefinition`

This annotation connects the field with a CDS Value Help entity.

`ZI_BP_STATUS_VH`

This CDS View acts as the Value Help provider and supplies the fixed domain values.

`element: 'StatusCode'`

Specifies which field from the Value Help entity should be returned to the main field.

`@ObjectModel.text.element`

This annotation helps display the description text together with the code value in the Fiori UI.

With this configuration, users can select predefined status values directly from the Fiori Value Help dialog instead of entering values manually.

Step 4: Expose the CDS View in Service Definition

After creating the Value Help CDS View and Projection View, the next step is to expose the CDS entity through a Service Definition.

@EndUserText.label: 'Request Services'
define service ZUI_BP_REQUEST {
  expose ZC_BP_REQHDR;
  expose ZC_BP_REQITEM;
}

Output

After activating the CDS Views, Service Definition, and Service Binding, the Status field in the Fiori Elements application will display a Value Help popup containing the fixed values maintained in the ABAP Domain.

Conclusion

In this blog, we saw how to implement Value Help using ABAP Domain Fixed Values in a SAP RAP Fiori Elements application without creating custom database tables or complex Value Help logic.

By using the standard tables DD07L and DD07T, we were able to:

Expose domain fixed values directly in the Fiori UI
Display meaningful descriptions alongside technical keys
Improve the user experience with predefined selections
Avoid unnecessary custom Value Help entities
Build a lightweight and reusable solution

This approach is simple, efficient, and easy to maintain. Any changes made to the domain fixed values are automatically reflected in the Fiori application without additional development effort.

I hope this blog helps you implement Value Help efficiently in your SAP RAP applications.

Simple RAP managed app with Abstract entity popup.

2026-06-11T10:09:06.732000+02:00

This post is to help those who are interested in learning SAP RAP application development. I have tried to cover the concepts of Validation, Determination, Actions, Draft handling, Authorization control, Late numbering and Side effects in this application.

This is a application to manage student data covering the below concepts.

Validation: It verifies the data before saving the same to the database. In our example, we will be checking if the marks entered is positive.

Determination: It automatically calculates or derives field values. It gets executed before Validation in RAP lifecycle. In our example, we will be filling the "created by" and "percentage" fields using determination logic.

Actions: It is used to achieve custom business operations that are beyond standard CRUD(Create, Read, Update, Delete) operations. In our example, we will be showing a popup for data update using action.

Draft handling: It is used to save work-in-progress without committing changes to the persistent database table. In our example, draft handling would be enabled.

Authorization control: It is used to control who is allowed to access the BO application. In our example, we will see how Global authorization is handled.

Numbering: It is used to generate key of business object. In our example, we will see "Later numbering" concept implemented.

Etag: It is used for Optimistic locking to provide concurrency control.

Popup: Creating POPUP using Abstract entity.

Lets get started with the application.

Step 1: Create database table in eclipse.

@EndUserText.label : 'Student table'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table zjd_student_tbl {
  key client : abap.clnt not null;
  key id     : sysuuid_x16 not null;
  name       : abap.char(30);
  address    : abap.char(50);
  marks      : abap.int1;
  percentage : abap.int1;
  createdby  : abap.char(15);
  createdon  : abp_locinst_lastchange_tstmpl;
}

Step 2. Create Feeder class to populate data in the database table.

CLASS zcl_student_feeder DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC.
  PUBLIC SECTION.
    INTERFACES if_oo_adt_classrun .
  PROTECTED SECTION.
  PRIVATE SECTION.
ENDCLASS.

CLASS zcl_student_feeder IMPLEMENTATION.
  METHOD if_oo_adt_classrun~main.
    DATA: lv_count     TYPE i VALUE 1,
          lv_name      TYPE string,
          lv_timestamp TYPE timestampl.
    DELETE FROM zjd_student_tbl.
    WHILE lv_count <= 5.
      GET TIME STAMP FIELD lv_timestamp.
      lv_name = |Test_| &&  lv_count .
      DATA(lt_Data) = VALUE zjd_student_tbl(  id = lv_count
                                              name = lv_name
                                              marks = '100'
                                              percentage = '100'
                                              address = 'Sion'
                                              createdby = sy-uname
                                              createdon = lv_timestamp
                                           ).
      INSERT  zjd_student_tbl FROM @LT_Data.
      CLEAR: lt_data, lv_name.
      lv_count += 1.
    ENDWHILE.
  ENDMETHOD.
ENDCLASS.

Step 3: Create Interface root CDS view entity.

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Interface view for Student table'
@Metadata.ignorePropagatedAnnotations: true
define root view entity ZI_STUDENT_TBL
  as select from zjd_student_tbl
{
  key id         as Id,
      name       as Name,
      address    as Address,
      marks      as Marks,
      percentage as Percentage,
      createdby  as Createdby,
      @Semantics.systemDateTime.localInstanceLastChangedAt: true
      createdon  as Createdon
}

Step 4: Create projection root CDS view entity on top of Interface root view.

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Projection view on ZI_STUDENT_TBL'
@Metadata.ignorePropagatedAnnotations: true
@Metadata.allowExtensions: true
define root view entity ZC_STUDENT_TBL
  provider contract transactional_query as projection on ZI_STUDENT_TBL
{
    key Id,
    Name,
    Address,
    Marks,
    Percentage,
    Createdby,
    @Semantics.systemDateTime.lastChangedAt: true
    Createdon
}

Step 5: Create Abstract entity. The same will be used for displaying popup to the user for editing the records.

@EndUserText.label: 'Student POPUP abstract entity'
@Metadata.allowExtensions: true
define abstract entity ZA_STUD_EDIT
{
  name       : abap.char(30);
  address    : abap.char(50);
  marks      : abap.int1;
}

Step 6: Create database table "zjd_student_log" to demonstrate additional save with managed application.

@EndUserText.label : 'Student log table'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table zjd_student_log {
  key client         : abap.clnt not null;
  key id             : sysuuid_x16 not null;
  name               : abap.char(30);
  address            : abap.char(50);
  marks              : abap.int1;
  percentage         : abap.int1;
  createdby          : abap.char(15);
  createdon          : abp_locinst_lastchange_tstmpl;
  changing_operation : abap.char(20);
  created_at         : timestampl;
}

Step 7: Create behavior definition for Interface view.

managed implementation in class zbp_i_student_tbl unique;
strict ( 2 );
with draft; //For Draft

define behavior for ZI_STUDENT_TBL 
persistent table zjd_student_tbl
draft table zjd_student_d //For Draft
with additional save// For additional save
lock master
total etag Createdon //For Draft
authorization master ( global, instance )
etag master Createdon
late numbering
{
  create ( authorization : global );
  update;
  delete;

  draft action Edit; //For Draft
  draft action Activate optimized; //For Draft
  draft action Discard; //For Draft
  draft action Resume; //For Draft
  draft determine action Prepare; //For Draft

  action updatestud parameter ZA_STUD_EDIT result [1] $self;

  determination setcreatedby on save { field id; create; }

  determination setPercentage on modify { field marks; update; }

  validation validatepercentage on save { field id; update; create; }

  side effects { field Marks affects field Percentage; }

  field ( readonly ) Id;
  field ( readonly ) Createdby;
  field ( readonly ) Createdon;
  field ( readonly ) Percentage;

  mapping for zjd_student_tbl
    {
      Id         = id;
      Name       = name;
      Address    = address;
      Marks      = marks;
      Percentage = percentage;
      Createdby  = createdby;
      Createdon  = createdon;
    }
}

Step 8: Create Behavior implementation class(Quick fix CTRL + 1) will create the class. Go to 'Local Types' tab to see the Handler and Saver class.

i. Late numbering code will be done in Saver class method "adjust numbers".

CLASS lsc_zi_student_tbl DEFINITION INHERITING FROM cl_abap_behavior_saver.
  PROTECTED SECTION.
    METHODS adjust_numbers REDEFINITION.
    METHODS save_modified REDEFINITION.
ENDCLASS.

CLASS lsc_zi_student_tbl IMPLEMENTATION.
  METHOD adjust_numbers.
    SELECT MAX( id ) FROM zjd_student_tbl INTO @DATA(lv_id).
    IF sy-subrc EQ 0.
      lv_id += 1.
    ELSE.
      lv_id = 1.
    ENDIF.
    LOOP AT mapped-zi_student_tbl REFERENCE INTO DATA(ls_num).
      ls_num->Id = lv_id.
    ENDLOOP.
  ENDMETHOD.
  METHOD save_modified.
    DATA: lt_student_tbl TYPE STANDARD TABLE OF zjd_student_tbl,
          lt_student_log TYPE STANDARD TABLE OF zjd_student_log.
    IF create-zi_student_tbl IS NOT INITIAL.
      lt_student_log = CORRESPONDING #( create-zi_student_tbl ).
      LOOP AT lt_student_log ASSIGNING FIELD-SYMBOL(<ls_student_log>).
        <ls_student_log>-changing_operation = 'CREATE'.
        GET TIME STAMP FIELD <ls_student_log>-created_at.
      ENDLOOP.
      INSERT zjd_student_log FROM TABLE @LT_student_log.
    ENDIF.
  ENDMETHOD.
ENDCLASS.

ii. The following methods in Handler class will help us in Action, Determination, Validation, Authorization handling.

CLASS lhc_ZI_STUDENT_TBL DEFINITION INHERITING FROM cl_abap_behavior_handler.
  PRIVATE SECTION.
    METHODS get_instance_authorizations FOR INSTANCE AUTHORIZATION
      IMPORTING keys REQUEST requested_authorizations FOR zi_student_tbl RESULT result.
    METHODS get_global_authorizations FOR GLOBAL AUTHORIZATION
      IMPORTING REQUEST requested_authorizations FOR zi_student_tbl RESULT result.
    METHODS updatestud FOR MODIFY
      IMPORTING keys FOR ACTION zi_student_tbl~updatestud RESULT result.
    METHODS setcreatedby FOR DETERMINE ON SAVE
      IMPORTING keys FOR zi_student_tbl~setcreatedby.
    METHODS validatepercentage FOR VALIDATE ON SAVE
      IMPORTING keys FOR zi_student_tbl~validatepercentage.
    METHODS setpercentage FOR DETERMINE ON MODIFY
      IMPORTING keys FOR zi_student_tbl~setpercentage.
ENDCLASS.

Authorization: For demo, I have just restricted based on username.

METHOD get_global_authorizations.
    IF requested_authorizations-%create EQ if_abap_behv=>mk-on AND sy-uname EQ <Your_user_name>.
      result-%create = if_abap_behv=>auth-unauthorized.
    ENDIF.
ENDMETHOD.

Update student data based on popup.

METHOD updatestud.
    DATA(lv_new_name) = keys[ 1 ]-%param-name.
    DATA(lv_new_address) = keys[ 1 ]-%param-address.
    DATA(lv_new_percentage) = keys[ 1 ]-%param-marks.

    MODIFY ENTITIES OF zi_student_tbl IN LOCAL MODE
    ENTITY zi_student_tbl
    UPDATE FIELDS ( Name Address Percentage )
    WITH VALUE #( ( %tky = keys[ 1 ]-%tky
                    Name = lv_new_name
                    Address = lv_new_address
                    Marks = lv_new_percentage
                    Percentage = lv_new_percentage  ) ).

    READ ENTITIES OF zi_student_tbl IN LOCAL MODE
    ENTITY zi_student_tbl
    ALL FIELDS WITH CORRESPONDING #( keys )
    RESULT DATA(lt_res).
    result = VALUE #( FOR <lfs_data> IN lt_res (
                      %tky = <lfs_data>-%tky
                      %param = <lfs_data> ) ).
ENDMETHOD.

Determination to set 'Created by' and 'Percentage':

METHOD setcreatedby.
    READ ENTITIES OF zi_student_tbl IN LOCAL MODE
    ENTITY zi_student_tbl
    ALL FIELDS WITH CORRESPONDING #( keys )
    RESULT DATA(lt_result).

    MODIFY ENTITIES OF zi_student_tbl IN LOCAL MODE
    ENTITY zi_student_tbl
    UPDATE FIELDS ( Createdby )
    WITH VALUE #( (  %tky = keys[ 1 ]-%tky
                     Createdby = sy-uname
                     ) ).
  ENDMETHOD.

METHOD setPercentage.
    READ ENTITIES OF zi_student_tbl IN LOCAL MODE
      ENTITY zi_student_tbl
      ALL FIELDS WITH CORRESPONDING #( keys )
      RESULT DATA(lt_result).

    LOOP AT lt_result ASSIGNING FIELD-SYMBOL(<ls_result>).
      IF <ls_result>-Percentage NE <ls_result>-marks .
        MODIFY ENTITIES OF zi_student_tbl IN LOCAL MODE
         ENTITY zi_student_tbl
         UPDATE FIELDS ( Marks Percentage  )
         WITH VALUE #( (  %tky = keys[ 1 ]-%tky
                          marks = lt_result[ 1 ]-Marks
                          Percentage = lt_result[ 1 ]-Marks ) ).
      ENDIF.
    ENDLOOP.
  ENDMETHOD.

Validatation:

METHOD validatepercentage.
    READ ENTITIES OF zi_student_tbl IN LOCAL MODE
    ENTITY zi_student_tbl
    ALL FIELDS WITH CORRESPONDING #( keys )
    RESULT DATA(lt_result).
    IF lt_result[ 1 ]-Marks < 20.
      APPEND VALUE #(  %tky = lt_result[ 1 ]-%tky ) TO failed-zi_student_tbl.

      APPEND VALUE #( %tky = lt_result[ 1 ]-%tky
                      %msg = new_message_with_text(
                        severity = if_abap_behv_message=>severity-error
                        text = 'validation failed'
                      )
                    ) TO reported-zi_student_tbl.
    ENDIF.
  ENDMETHOD.

Step 9: Create Metadata extension file for the projection view(By right clicking the projection view "ZC_STUDENT_TBL)".

@Metadata.layer: #CORE
annotate entity ZC_STUDENT_TBL with
{
  @ui.facet: [{ id: 'StudentPage',
                purpose: #STANDARD,
                label: 'Student Overview',
                type: #IDENTIFICATION_REFERENCE }]
  @ui.lineItem: [{
      type: #FOR_ACTION,
      dataAction: 'updatestud',
      label: 'Update Student',
      position: 10

   }] //this piece of code is for displaying popup
  @ui.identification: [{ position: 10, label: 'ID' }]
  Id;
  @ui.lineItem: [{ position:10, label: 'Name' }]
  @ui.identification: [{ position: 20, label: 'Name' }]
  Name;
  @ui.lineItem: [{ position:20, label: 'Address' }]
  @ui.identification: [{ position: 30, label: 'Address' }]
  Address;
  @ui.lineItem: [{ position:30, label: 'Marks' }]
  @ui.identification: [{ position: 40, label: 'Marks' }]
  Marks;
  @ui.lineItem: [{ position:35, label: 'Percentage' }]
  @ui.identification: [{ position: 45, label: 'Percentage' }]
  Percentage;
  @ui.lineItem: [{ position:40, label: 'Created By' }]
  @ui.identification: [{ position: 50, label: 'Created By' }]
  Createdby;
  @ui.lineItem: [{ position:50, label: 'Created On' }]
  @ui.identification: [{ position: 60, label: 'Created On' }]
  Createdon;
}

Step 10: Create Metadata extension file for Abstract view.

@Metadata.layer: #CORE
annotate entity ZA_STUD_EDIT
    with 
{
    @ui.lineItem: [{ position: 10  }]
    name;
    @ui.lineItem: [{ position: 20 }]
    address;
    @ui.lineItem: [{ position: 30 }]
    marks;    
}

Step 11: Behavior definition for consumption view.

projection;
strict ( 2 );
use draft; //For Draft
use side effects;
define behavior for ZC_STUDENT_TBL //alias <alias_name>
{
  use create;
  use update;
  use delete;

  use action updatestud;

  use action Activate; //For Draft
  use action Discard;  //For Draft
  use action Edit;     //For Draft
  use action Prepare;  //For Draft
  use action Resume;   //For Draft
}

Step 12: Create Service Definition.

@EndUserText.label: 'Student service definition'
define service ZSD_STUDENT_DEMO {
  expose ZC_STUDENT_TBL;
}

Step 13: Create Service Binding.

After all the above steps are performed. The below components should be ready.

Step 14: Publish and preview the application.

Output: Line item display.

Popup to update data

In this blog, we explored the development of a SAP RAP application by implementing several important RAP concepts within a Student Data Management scenario. We covered how validations ensure data integrity, determinations automate field derivation, actions enable custom business operations, and draft handling manages work-in-progress data. We also demonstrated global authorization control, late numbering for key generation, ETag-based optimistic locking for concurrency control, and popup implementation using abstract entities.

By combining these features, SAP RAP enables developers to build modern, cloud-ready, and enterprise-grade applications with less custom code while following SAP's clean-core principles. Understanding these concepts is essential for designing robust and scalable RAP applications in SAP S/4HANA and SAP BTP environments.

I hope this blog provides a practical starting point for your RAP learning journey.

Keep exploring! Keep learning 🙂

Etag(Entity Tag) in RAP

2026-06-11T10:17:11.558000+02:00

Etag is used to achieve Optimistic concurrency control.

Now comes the question : What is Optimistic Concurrency?

Optimistic concurrency control ensures data consistency by preventing lost updates when multiple users read the same data simultaneously and attempt to modify it.

Scenario without ETag:

User A and user B reading the same record from database

User A update the data and save the record in database.

User B without knowing data has been already updated, updates the same record and saves the data , at this time data saved by user A will be overwritten by data of user B. This will result in data inconsistency. To handle such scenario we will go for ETag (Entity tag) .

Scenario with ETag:

For implementing ETag, we will include a ETag field which will uniquely identify each updating of the record whenever its updated.

User A and user B reading the same record from database. Both get ETag value E1.

User A update the data and save the record in database. Sets the ETag value to E2.

User B without knowing data has been already updated, tries to update the same record but this time the Etag value in database is E2 which is not matching with ETag value in E1. So, update fails for User B with error code 412. This will ensure data consistency.

Steps to implement ETag in RAP:

Step1: Take one field of the database table with datatype ‘abp_locinst_lastchange_tstmpl’. This would be our etag field.

@EndUserText.label : 'Student table'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table zjd_student_tbl {
  key client : abap.clnt not null;
  key id     : sysuuid_x16 not null;
  name       : abap.char(30);
  address    : abap.char(50);
  marks      : abap.int1;
  percentage : abap.int1;
  createdby  : abap.char(15);
  createdon  : abp_locinst_lastchange_tstmpl;
}

Step2: Add “etag master Createdon” in behaviour definition

Step3: Make the field read only.

Once the above three steps are done, RAP ensures optimistic concurrency control.

By leveraging ETags, SAP RAP provides an efficient and scalable approach to concurrency management. Understanding and implementing ETags is essential for building robust, reliable, and enterprise-ready RAP applications that can safely handle concurrent user updates.

Keep learning! Keep exploring 🙂

ABAP development tools for Visual Studio Code: Patch 1.0.1 released

2026-06-12T07:41:59.469000+02:00

What happened since the first release?

First of all, thanks to all the ABAP developers who have already tried out the new extension! You provided a lot of positive feedback & constructive criticism over the last two weeks and can be assured that we read every single one. When looking at the overall feedback three things stand out:

1. Trouble with setting up system connections. Because the extension ships with a new way for configuring system destinations, some of you had trouble configuring ABAP system access. We have already published improved documentation and we are also looking into how we can further improve the usability of these user flows in the upcoming releases.

2. Missing support for Windows ARM hardware. We added this to our backlog and already made some progress. However, further testing needs to be done until we can release it to the public.

3. Missing support for RFC + password. We communicated openly and proactively across multiple channels that RFC + password support would arrive in the next major release, and we were aware of its importance. Even so, we were still surprised by how many users are relying on classic passwords. That’s why we reacted quickly. Since the mandatory security review of such a critical change was already done, we are pleased to add support for passwords via a patch.

We also received general feedback that the community would appreciate more how-to guides. Here are some links for getting started and learning more about the extension. We are planning to provide more guides in the future.

RAP130 tutorial. A tutorial that walks you through using the ADT MCP server together with an AI agent.
Setup guide how to get started with GitHub Copilot. Björn Schulz published a nice guide for configuring the initial setup.
Podcast on the ADT for VS Code extension. Rich Heilman did a podcast with some members of the ADT team. It covers a lot of technical aspects of the extension but also provides some insights into the plan for the next releases.

What gets shipped with this release?

RFC System logon via password

You can create RFC destinations with password access.

AGENTS.md template

The documentation already provides a template for an AGENTS.md file. With the update the same file gets shipped with the VS Code extension. This makes it easier to get started. We still recommend duplicating the template and adding your own company/team/project-specific instructions. The more time you spend on onboarding the agent into your project the better results it will produce.

What's next?

The next release is currently planned for next month. The planned features remain unchanged from the previous blog post:

Support of more core development object types: RAP behavior extensions, DDIC tables, DDIC structures, DDIC enqueue objects, DDIC type groups, CDS entity buffers, programs/includes, function groups and modules, ...
MCP tools: Unified diff tool for transports, ABAP test cockpit tools, …

Follow the ABAP Cloud Roadmap if you are interested in knowing what comes next.

Provide feedback and influence our product backlog!

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

Unmanaged RAP application for Excel File Upload and CDS Custom Entity with Unmanaged Query Implement

2026-06-14T15:02:55.897000+02:00

Intro

Nowadays, finding information is easier than ever. Although, the experience still remains the key differentiator. And that’s what I would like to share through this blog – my experience in implementing the Excel File Upload in a RAP application in BTP ABAP environment. RAP application was implemented with an unmanaged behavior, supporting also the editing of multiple items at the same time. Additionally, the data model is based on custom entities with unmanaged queries.

Use-case

RAP application for maintaining Bonus Plans; allow the editing of multiple records at the same time; allow mass upload from an Excel file.

Data Model

The data model for my scenario is based on 2 DB tables (ZIP_BONUS_PLAN and ZIP_BP_UPLOAD) and 3 CDS Custom Entities (ZCE_BP_SINGLETON, ZCE_BONUS_PLAN and ZCE_BP_UPLOAD). Refer to Custom Entities | SAP Help Portal.

The root entity is a singleton entity aiming to implement multi-inline-edit. Refer to Developing Transactional Apps with Multi-Inline-Edit Capabilities | SAP Help Portal.

All 3 Custom Entities implement the retrieval logic in the same ABAP class ZCL_BP_UNMNG_QUERY.

In the attachment you can find the files containing the most interesting parts of coding:

2 Database Tables
3 CDS views
Unmanage Query implementation
Processing logic
RAP Behavior Definition
RAP Behavior Implementation

Implementation of Excel Upload

The implementation of File Upload is based on large objects (LOBs), providing end users the option to incorporate external files when editing entity instances. To make it work with Excel files you have to implement XCO_CP_XLSX. Refer to Working with Large Objects | SAP Help Portal and XLSX | SAP Help Portal.

Service Binding

For Service Binding I’ve chosen “OData V2 – UI” because if I go for “OData V4 – UI” some parts are missing and I get the following notification in the Service Binding itself “oData V4 services with no draft capability will be primarily READ-ONLY”.

Fiori UI Preview

The preview starts with the root entity ZCE_BP_SINGLETON for which the if_rap_query_provider builds a dummy record during runtime:

Here I have implemented a custom action “Drop all Data” to be able to clear my demo tables.

When I select the singleton record, the application navigates to the page with Bonus Plan Grid:

Here we start with the “Mass Upload” functionality, by executing the “Create New Upload Template”. As a result, a new record is created in the table ZIP_BP_UPLOAD, containing a template file attachment.

When you enter into the details of this record, you can download the template:

Maintain the Excel file data and upload it back:

Now, the file is uploaded and the record is updated:

Once the file is uploaded, it can be processed:

Successfully processed file will create records in the table ZIP_BONUS_PLAN. The UI allows editing multiple records:

Final words

In an era where AI helps us find answers faster than ever, the craft still lies in how we turn those answers into working solutions. This Excel upload journey—unmanaged behavior for bulk editing, custom entities with unmanaged queries—was my way of shaping RAP to the problem, not the other way around. If my experience saves you a few hours, a few pitfalls, or inspires a cleaner design, then sharing it was worth it. The rest is practice—and I’m looking forward to hearing about your experience in the comments below.

Building an Inventory System with RAP on BTP Trial — CDS Views Explained

2026-06-17T11:55:35.487000+02:00

Introduction

When people talk about RAP (RESTful ABAP Programming Model), the conversation usually jumps straight to behavior definitions, actions, and determinations. The CDS layer gets a brief mention and everyone moves on.

That's a mistake.

The CDS view architecture is the contract your entire application is built on. Get it right and everything above it — behaviors, OData services, Fiori UIs — falls into place naturally. Get it wrong and you'll spend hours debugging problems that were actually design issues.

In this post I'll walk through the complete CDS layer of a Mini Inventory & Stock Movement System I built on SAP BTP Trial, covering four entities across three business objects. I'll explain the design decisions, not just the code.

The System at a Glance

The application manages warehouse stock movements. Three business objects cover the full domain:

Business Object Interface View Database Table

Material Master	ZI_MiniMM_Material	ZRMZ_MM_MATERIAL
Storage Location	ZI_MiniMM_Storage	ZRMZ_MM_STORAGE
Stock Document (Header)	ZI_MiniMM_StockDocument	ZRMZ_MM_DOC_HDR
Stock Document (Item)	ZI_MiniMM_StockDocumentItem	ZRMZ_MM_DOC_ITEM
Current Stock (read-only)	ZI_MiniMM_CurrentStock	ZRMZ_MM_STOCK

Each entity has a matching projection view (ZC_ prefix) used to expose the OData service.

The Two-Layer Architecture

RAP enforces a clean separation between two CDS view types. Understanding why this separation exists is more important than understanding the syntax.

Interface views (ZI_) are the authoritative source of truth. They sit directly on the database tables and carry everything the framework needs to understand your data: semantic annotations, associations, compositions, and quantity/currency references. These views should be stable — changing them has downstream impact.

Projection views (ZC_) consume the interface views and add presentation concerns: the provider contract, @Metadata.allowExtensions for metadata extensions, and the redirection of compositions so that OData navigation points to the correct projection layer. Projection views can evolve more freely.

A useful mental model: ZI_ is the API contract, ZC_ is the UI adapter.

Composition: Stock Document Header and Item

The most important structural relationship in this model is the header-item composition between ZI_MiniMM_StockDocument and ZI_MiniMM_StockDocumentItem.

In the header (root entity):

abap

composition [0..*] of ZI_MiniMM_StockDocumentItem    as _Items

In the item (child entity):

abap

association to parent ZI_MiniMM_StockDocument  as _Header  on $projection.DocumentID = _Header.DocumentID

The [0..*] cardinality means a document can have zero or more items — appropriate here since a newly created document starts empty. The parent association on the item side creates the back-navigation link.

Why does this matter? Composition in RAP is not just a modelling convenience. It has runtime implications: the managed runtime treats the composition tree as a single transactional unit. When you delete a header, items are automatically deleted. When you lock a header for editing, the entire tree is locked. This is the correct behaviour for a stock document.

Associations: Two Aliases, One Target View

The item view introduces an interesting challenge: a stock movement can have both a source storage location and a target storage location, and both must be validated against the same ZI_MiniMM_Storage entity.

The solution is two separate associations pointing to the same underlying view:

abap

association [1..1] to ZI_MiniMM_Material as _Material  on $projection.MaterialID = _Material.MaterialID
association [0..1] to ZI_MiniMM_Storage as _SourceStorage  on $projection.SourceStorage = _SourceStorage.StorageID
association [0..1] to ZI_MiniMM_Storage as _TargetStorage  on $projection.TargetStorage = _TargetStorage.StorageID

A few design points worth noting here.

The _Material association is [1..1] — every item line must reference a valid material. _SourceStorage and _TargetStorage are both [0..1] because not every movement type uses both. A goods receipt (GR) has no source; a goods issue (GI) has no target. Making both optional at the CDS level correctly reflects the business reality.

The alias names (_SourceStorage, _TargetStorage) are different even though both navigate to ZI_MiniMM_Storage. This is required by the framework — CDS does not allow two associations with identical names on the same view, even if the target differs.

Semantic Annotations: Free Administrative Data

RAP's managed runtime will auto-populate administrative fields if you annotate them correctly. No custom code required.

abap

@Semantics.user.createdBy: truecreated_by      as CreatedBy,

@Semantics.systemDateTime.createdAt: truecreated_at      as CreatedAt,

@Semantics.user.lastChangedBy: truelast_changed_by as ChangedBy,

@Semantics.systemDateTime.lastChangedAt: truelast_changed_at as ChangedAt

These annotations go on the interface view, not the projection. The framework reads them at runtime and fills the mapped database columns on every create and update operation.

The only requirement is that the underlying database table columns have compatible data types (SYUNAME, TIMESTAMPL respectively) and that you declare with_draft or standard managed behaviour in the behavior definition. If those conditions are met, this is genuinely zero-effort audit trail data.

Projection Views: What Most Tutorials Skip

Every interface view has a corresponding projection view. The projection view adds three things that the interface view cannot provide: the provider contract transactional_query declaration (required for OData V4 exposure), @Metadata.allowExtensions: true (required for metadata extensions to attach), and — crucially — the composition redirect.

The composition redirect is the step that most beginner tutorials either skip or explain poorly.

In the projection header:

abap

_Items : redirected to composition child ZC_MiniMM_StockDocumentItem

In the projection item:

abap

_Header : redirected to parent ZC_MiniMM_StockDocument

Without this redirect, OData navigation from the header to its items would traverse back to the interface entities (ZI_), not the projection entities (ZC_). The service binding would still activate, but navigation in Fiori would either fail silently or return data without the metadata annotations your UI depends on.

Value Help Annotations

The final piece of the CDS layer is the value help definitions, which live in the metadata extension of the item projection view.

abap

@Consumption.valueHelpDefinition: [{
  entity.name: 'ZC_MiniMM_Material',
  entity.element: 'MaterialID' }]MaterialID;
@Consumption.valueHelpDefinition: [{
  entity.name: 'ZC_MiniMM_Storage',
  entity.element: 'StorageID' }]SourceStorage;
@Consumption.valueHelpDefinition: [{
  entity.name: 'ZC_MiniMM_Storage',
  entity.element: 'StorageID' }]TargetStorage;

The annotation always points to the projection view (ZC_), not the interface view. This is because the value help dropdown in Fiori is itself an OData call, and OData services are generated from projection views. Pointing at ZI_ would fail at activation or produce no results.

Both SourceStorage and TargetStorage reference the same ZC_MiniMM_Storage projection — same entity, same element, different field. The framework handles this correctly.

Running This on BTP Trial

Everything described in this post runs on a free SAP BTP Trial account with the ABAP environment service instance. No S/4HANA system required. No license. The ABAP Development Tools (ADT) in Eclipse is the only tool you need locally.

If you've been waiting for the right time to start learning ABAP Cloud and RAP, a BTP trial account is genuinely the right place to start. The constraints of the cloud environment (no classic ABAP, no access to SAP standard tables directly) force you to learn the correct patterns from the beginning.

ArchitectureMaterial View InterfaceMaterial Create InterfaceStock Movement Interface

On‑the‑Fly Excel Download in a RAP Fiori App — No Database Table, No Persistence, Pure CDS + ABAP

2026-06-18T21:45:02.090000+02:00

Author's note: Views are my own. Object names in this post are illustrative placeholders (ZC_*, ZCL_*) — adapt them to your own naming convention. The pattern is what matters, not the names.

Tags: ABAP RAP · CDS Custom Entity · Fiori Elements · Open XML / XLSX · cl_abap_zip · cl_salv_table · IF_RAP_QUERY_PROVIDER · ABAP Cloud

TL;DR

You can serve an Excel file from a Fiori Elements list without ever creating a database table for it. Combine a CDS Custom Entity (whose data is delivered by an ABAP class), a query provider that implements IF_RAP_QUERY_PROVIDER, and the standard @Semantics.largeObject annotation — and the binary you build at runtime is streamed straight to the user's browser as a .xlsx.

This blog shows the end‑to‑end pattern with two flavours of XLSX generation:

Multi‑sheet workbook assembled by hand from Open XML parts using cl_abap_zip.
Single‑sheet workbook generated in one line via cl_salv_table=>to_xml( c_type_xlsx ).

Both are 100% ABAP Cloud–compatible, both use only released APIs, and neither persists a single byte.

1. The problem

Every RAP project eventually hits this requirement:

"Put a Download button on the Fiori list page — when the user clicks, hand them an Excel file."

The default reflex is to:

Create a Z‑table with a RAWSTRING column.
Build the binary in a background job.
Expose it via a transactional CDS view.
Add a clean‑up job for stale rows.
Transport the table, the data, and the cleanup job through every system.

That works — but it's wasteful when the file is derivable from master data. You're persisting something that goes stale the moment master data changes, you're transporting binaries, and you're paying storage for content you could regenerate in milliseconds.

There is a stateless alternative.

2. The pattern in one picture

Fiori Elements List Report
        │  GET …/ZC_TmplDownload?$filter=TemplateType eq 'TYPE_A'
        ▼
CDS Custom Entity   ZC_TmplDownload
   @ObjectModel.query.implementedBy: 'ABAP:ZCL_TMPL_DWNLD_PROVIDER'
        │
        ▼
ABAP Class   ZCL_TMPL_DWNLD_PROVIDER
   IF_RAP_QUERY_PROVIDER~SELECT
        │  builds XLSX as XSTRING in memory at request time
        ▼
   @Semantics.largeObject  ⇒  Browser "Save as…" dialog

No database table sits on this path. The binary lives in memory only as long as the HTTP request takes to complete.

3. The CDS Custom Entity

A custom entity is a CDS view whose data is not fetched by the SADL runtime — it is delivered by an ABAP class you write. That makes it the perfect anchor for runtime‑computed binaries.

@EndUserText.label: 'Template Download'
@ObjectModel.query.implementedBy: 'ABAP:ZCL_TMPL_DWNLD_PROVIDER'
define custom entity ZC_TmplDownload
{
      @UI.hidden: true
  key TemplateType : abap.char(20);

      @UI.lineItem: [{ position: 20, label: 'Filename' }]
      Filename     : abap.char(255);

      @UI.lineItem: [{ position: 30, label: 'Download' }]
      @Semantics.largeObject: {
            mimeType                    : 'MimeType',
            fileName                    : 'Filename',
            acceptableMimeTypes         : [
                  'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet'
            ],
            contentDispositionPreference: #ATTACHMENT
      }
      Attachment   : abap.rawstring(0);

      @Semantics.mimeType: true
      @UI.hidden:   true
      MimeType     : abap.char(100);
}

What each piece does

Annotation / Field Why it matters

`@ObjectModel.query.implementedBy: 'ABAP:ZCL_TMPL_DWNLD_PROVIDER'`	Tells the RAP runtime: don't query the DB — call this class.
`key TemplateType`	Lets the same entity ship N different files. We'll return one row per template type.
`Attachment : abap.rawstring(0)`	The binary payload column. `rawstring(0)` = unbounded length.
`@Semantics.largeObject`	The magic annotation. Fiori Elements renders this column as a Download link, fetches it lazily as a separate `$value` request, and pushes the bytes to the browser with the right MIME type and filename.
`mimeType` / `fileName` reference fields	Per‑row file name and content type — each row downloads as its own correctly‑named `.xlsx`.
`contentDispositionPreference: #ATTACHMENT`	Forces the browser to save, not to render the file in‑tab.

💡 Tip: Even on download‑only entities, populate acceptableMimeTypes. Some Fiori Elements versions use it to harden the download link.

4. The query provider class — skeleton

CLASS zcl_tmpl_dwnld_provider DEFINITION
  PUBLIC FINAL CREATE PUBLIC.

  PUBLIC SECTION.
    INTERFACES if_rap_query_provider.

  PRIVATE SECTION.
    METHODS build_template_a
      RETURNING VALUE(rv_xlsx) TYPE xstring.
    METHODS build_template_b
      RETURNING VALUE(rv_xlsx) TYPE xstring.
ENDCLASS.

IF_RAP_QUERY_PROVIDER has a single method that matters here: SELECT. RAP calls it for every GET against the entity.

`IF_RAP_QUERY_PROVIDER~SELECT` — the dispatcher

METHOD if_rap_query_provider~select.
  DATA lt_result TYPE STANDARD TABLE OF ZC_TmplDownload.

  DATA(lt_filter)    = io_request->get_filter( )->get_as_ranges( ).
  DATA(lt_requested) = io_request->get_requested_elements( ).

  " Optional pushdown: only build the file the user actually asked for.
  DATA(lv_wants_a) = abap_true.
  DATA(lv_wants_b) = abap_true.
  LOOP AT lt_filter INTO DATA(ls_filter) WHERE name = 'TEMPLATETYPE'.
    lv_wants_a = COND #( WHEN 'TYPE_A' IN ls_filter-range THEN abap_true ELSE abap_false ).
    lv_wants_b = COND #( WHEN 'TYPE_B' IN ls_filter-range THEN abap_true ELSE abap_false ).
  ENDLOOP.

  IF lv_wants_a = abap_true.
    APPEND VALUE #(
      templatetype = 'TYPE_A'
      filename     = 'TemplateA.xlsx'
      attachment   = build_template_a( )
      mimetype     = 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet'
    ) TO lt_result.
  ENDIF.

  IF lv_wants_b = abap_true.
    APPEND VALUE #(
      templatetype = 'TYPE_B'
      filename     = 'TemplateB.xlsx'
      attachment   = build_template_b( )
      mimetype     = 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet'
    ) TO lt_result.
  ENDIF.

  io_response->set_total_number_of_records( lines( lt_result ) ).
  io_response->set_data( lt_result ).
ENDMETHOD.

Two ideas worth flagging:

The XLSX is generated at every GET. That is the whole point — the file is always fresh.
Filter pushdown is honoured manually. io_request->get_filter( )->get_as_ranges( ) returns the OData $filter as ABAP ranges. Use it to decide which template to build, so a click on row A never computes row B.

5. Technique A — Hand‑build a multi‑sheet XLSX with `cl_abap_zip`

An .xlsx file is a ZIP archive of XML files that follow the Open XML SpreadsheetML specification. If you control the XML, you control the file — no SAP Office, no DOI, no OLE, and no third‑party library.

5.1 The minimum parts you need

TemplateA.xlsx (zip)
├── [Content_Types].xml          ← MIME map for every part inside
├── _rels/.rels                  ← root relationship → workbook.xml
└── xl/
    ├── workbook.xml             ← declares the sheets
    ├── styles.xml               ← fonts / borders / cellXfs (we use a "bold header" xf)
    ├── _rels/
    │   └── workbook.xml.rels    ← workbook → sheet1..N + styles
    └── worksheets/
        ├── sheet1.xml
        ├── sheet2.xml
        ├── sheet3.xml
        └── sheet4.xml

5.2 Build the package skeleton

DATA: lo_zip      TYPE REF TO cl_abap_zip,
      lv_xml      TYPE string,
      lv_xstr     TYPE xstring,
      lv_zip_xstr TYPE xstring.

lo_zip = NEW cl_abap_zip( ).

Each XML part is built as a string, converted to UTF‑8 xstring, then dropped into the zip.

5.3 `[Content_Types].xml` — the MIME map

lv_xml =
  `<?xml version="1.0" encoding="UTF-8" standalone="yes"?>` &&
  `<Types xmlns="http://schemas.openxmlformats.org/package/2006/content-types">` &&
    `<Default Extension="rels" ContentType="application/vnd.openxmlformats-package.relationships+xml"/>` &&
    `<Default Extension="xml" ContentType="application/xml"/>` &&
    `<Override PartName="/xl/workbook.xml"`
        && ` ContentType="application/vnd.openxmlformats-officedocument.spreadsheetml.sheet.main+xml"/>` &&
    `<Override PartName="/xl/worksheets/sheet1.xml"`
        && ` ContentType="application/vnd.openxmlformats-officedocument.spreadsheetml.worksheet+xml"/>` &&
    `<Override PartName="/xl/worksheets/sheet2.xml"`
        && ` ContentType="application/vnd.openxmlformats-officedocument.spreadsheetml.worksheet+xml"/>` &&
    `<Override PartName="/xl/worksheets/sheet3.xml"`
        && ` ContentType="application/vnd.openxmlformats-officedocument.spreadsheetml.worksheet+xml"/>` &&
    `<Override PartName="/xl/worksheets/sheet4.xml"`
        && ` ContentType="application/vnd.openxmlformats-officedocument.spreadsheetml.worksheet+xml"/>` &&
    `<Override PartName="/xl/styles.xml"`
        && ` ContentType="application/vnd.openxmlformats-officedocument.spreadsheetml.styles+xml"/>` &&
  `</Types>`.

lv_xstr = cl_abap_codepage=>convert_to( source = lv_xml codepage = 'UTF-8' ).
lo_zip->add( name = '[Content_Types].xml' content = lv_xstr ).

5.4 The root relationship

lv_xml =
  `<?xml version="1.0" encoding="UTF-8" standalone="yes"?>` &&
  `<Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships">` &&
    `<Relationship Id="rId1"`
       && ` Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/officeDocument"`
       && ` Target="xl/workbook.xml"/>` &&
  `</Relationships>`.

lv_xstr = cl_abap_codepage=>convert_to( source = lv_xml codepage = 'UTF-8' ).
lo_zip->add( name = '_rels/.rels' content = lv_xstr ).

5.5 `workbook.xml` — wire up four sheets

lv_xml =
  `<?xml version="1.0" encoding="UTF-8" standalone="yes"?>` &&
  `<workbook xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main"`
     && ` xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships">` &&
    `<sheets>` &&
      `<sheet name="Header"      sheetId="1" r:id="rId1"/>` &&
      `<sheet name="Header_Text" sheetId="2" r:id="rId2"/>` &&
      `<sheet name="Item"        sheetId="3" r:id="rId3"/>` &&
      `<sheet name="Item_Text"   sheetId="4" r:id="rId4"/>` &&
    `</sheets>` &&
  `</workbook>`.

Each r:id resolves through xl/_rels/workbook.xml.rels to a real worksheets/sheetN.xml file. Get this wrong and Excel refuses the file with the dreaded "We found a problem with some content" dialog.

5.6 The workbook's relationships and styles

" xl/_rels/workbook.xml.rels — workbook → sheets + styles
lv_xml =
  `<?xml version="1.0" encoding="UTF-8" standalone="yes"?>` &&
  `<Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships">` &&
    `<Relationship Id="rId1" Type=".../worksheet" Target="worksheets/sheet1.xml"/>` &&
    `<Relationship Id="rId2" Type=".../worksheet" Target="worksheets/sheet2.xml"/>` &&
    `<Relationship Id="rId3" Type=".../worksheet" Target="worksheets/sheet3.xml"/>` &&
    `<Relationship Id="rId4" Type=".../worksheet" Target="worksheets/sheet4.xml"/>` &&
    `<Relationship Id="rId5" Type=".../styles"    Target="styles.xml"/>` &&
  `</Relationships>`.
" (Type URLs abbreviated for readability — use the full openxmlformats.org URLs in real code.)

" xl/styles.xml — xf 0 = normal, xf 1 = bold (used by header rows via s="1")
lv_xml =
  `<?xml version="1.0" encoding="UTF-8" standalone="yes"?>` &&
  `<styleSheet xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main">` &&
    `<fonts count="2">` &&
      `<font><sz val="11"/><name val="Calibri"/></font>` &&
      `<font><b/><sz val="11"/><name val="Calibri"/></font>` &&
    `</fonts>` &&
    `<fills count="2">` &&
      `<fill><patternFill patternType="none"/></fill>` &&
      `<fill><patternFill patternType="gray125"/></fill>` &&
    `</fills>` &&
    `<borders count="1">` &&
      `<border><left/><right/><top/><bottom/><diagonal/></border>` &&
    `</borders>` &&
    `<cellStyleXfs count="1">` &&
      `<xf numFmtId="0" fontId="0" fillId="0" borderId="0"/>` &&
    `</cellStyleXfs>` &&
    `<cellXfs count="2">` &&
      `<xf numFmtId="0" fontId="0" fillId="0" borderId="0" xfId="0"/>` &&
      `<xf numFmtId="0" fontId="1" fillId="0" borderId="0" xfId="0"/>` &&
    `</cellXfs>` &&
  `</styleSheet>`.

5.7 A worksheet — bold header + data row

" Sheet 1 — Header  (KEY_FIELD | GROUP_FIELD | STATUS)
" s="1"          → cellXfs index 1 (bold) defined in styles.xml
" t="inlineStr"  → string lives inside the cell (no shared-strings table needed)
lv_xml =
  `<?xml version="1.0" encoding="UTF-8" standalone="yes"?>` &&
  `<worksheet xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main">` &&
    `<sheetData>` &&
      `<row r="1">` &&
        `<c r="A1" t="inlineStr" s="1"><is><t>Key Field</t></is></c>` &&
        `<c r="B1" t="inlineStr" s="1"><is><t>Group Field</t></is></c>` &&
        `<c r="C1" t="inlineStr" s="1"><is><t>Status</t></is></c>` &&
      `</row>` &&
      `<row r="2">` &&
        `<c r="A2" t="inlineStr"><is><t>KEY01</t></is></c>` &&
        `<c r="B2" t="inlineStr"><is><t>GRP01</t></is></c>` &&
        `<c r="C2" t="inlineStr"><is><t>X</t></is></c>` &&
      `</row>` &&
    `</sheetData>` &&
  `</worksheet>`.

Two pragmatic tricks worth knowing:

t="inlineStr" — store strings inside the cell. The alternative is a shared‑strings part, more efficient for large repeated text but it doubles the moving parts. For a download template, inline is the right trade‑off.
s="1" — refer to cellXfs index 1, which we defined as bold. Headers come out bold without further effort.

5.8 Finalize

lo_zip->save( RECEIVING zip = lv_zip_xstr ).
rv_xlsx = lv_zip_xstr.   "  ← this xstring IS the .xlsx file

That xstring flows up through set_data( ) into the Attachment column of the custom entity, and the @Semantics.largeObject runtime serves it to the browser as a real .xlsx.

6. Technique B — Single‑sheet XLSX via `cl_salv_table` (the easy route)

When you only need one worksheet, skip the manual XML and let SALV do it:

METHOD build_template_b.
  TYPES: BEGIN OF ty_row,
           field_a TYPE char20,
           field_b TYPE char10,
           field_c TYPE char10,
         END OF ty_row.

  DATA lt_data    TYPE TABLE OF ty_row.
  DATA lo_table   TYPE REF TO cl_salv_table.
  DATA lo_columns TYPE REF TO cl_salv_columns_table.
  DATA lo_column  TYPE REF TO cl_salv_column.

  lt_data = VALUE #(
    ( field_a = 'SAMPLE_KEY_001' field_b = 'CODE01' field_c = 'GRP01' ) ).

  TRY.
      cl_salv_table=>factory(
        IMPORTING r_salv_table = lo_table
        CHANGING  t_table      = lt_data ).

      lo_columns = lo_table->get_columns( ).

      TRY.
          lo_column = lo_columns->get_column( 'FIELD_A' ).
          lo_column->set_long_text( 'Field A' ).
          lo_column->set_output_length( 20 ).
        CATCH cx_salv_not_found.
      ENDTRY.

      " ★ The single line that turns a SALV table into a complete .xlsx xstring
      rv_xlsx = lo_table->to_xml( xml_type = if_salv_bs_xml=>c_type_xlsx ).

    CATCH cx_salv_msg.
      RETURN.
  ENDTRY.
ENDMETHOD.

cl_salv_table=>to_xml( c_type_xlsx ) returns a fully‑formed XLSX xstring. The catch: it produces exactly one sheet. That is why the multi‑sheet template needs Technique A.

7. Wire it up in Fiori Elements

In your service definition:

@EndUserText.label: 'Template Downloads'
define service ZUI_TEMPLATE_DOWNLOADS {
  expose ZC_TmplDownload;
}

Bind it to a service binding (OData V4 → UI), generate a Fiori Elements List Report, and you'll see one row per template type, each with a download icon in the Download column. Click → the browser receives TemplateA.xlsx or TemplateB.xlsx directly from memory.

That's it. Zero DB tables. Zero persistence.

8. Why this pattern is worth adopting

Concern Stateless Custom Entity (this blog) Persisted "blob in a Z‑table"

Freshness	Always live — built per request	Goes stale; needs a refresh job
Storage	None	RAWSTRING in DB, every release
Transport / cutover	Just code	Code and data
Authorization	Enforced in the class	Same, plus DB‑level checks
Testability	Plain ABAP unit test on the helper methods	Needs DB fixtures
Performance	One ZIP build per click	One DB read — but you paid for the build earlier, in a job

For templates and other derivable artifacts the trade is one‑sided in favour of statelessness. Reach for the persisted variant only when (a) the file is genuinely expensive to build (think tens of MB / millions of rows) and (b) it doesn't need to reflect the latest master data.

9. Pitfalls (so you don't have to learn them the hard way)

UTF‑8 everywhere. cl_abap_codepage=>convert_to( … codepage = 'UTF-8' ) for every XML part. Excel will reject mixed encodings.
Relationship IDs (rId…) must match across workbook.xml and xl/_rels/workbook.xml.rels. Easiest way to corrupt the file.
Don't forget styles.xml in BOTH [Content_Types].xml AND workbook.xml.rels. If you reference s="1" without a registered styles part, Excel opens with a "repair" prompt.
@Semantics.largeObject requires mimeType and fileName to point at columns — not literal strings. The annotation references field names.
Don't mix shared strings with inline strings unless you really need to. t="inlineStr" keeps each sheet self‑contained.
Filter pushdown costs nothing. Build only the row Fiori asked for — your download click should never compute the other template.
Avoid stacks/classes that aren't released for ABAP Cloud (some XLSX helper classes aren't). cl_abap_zip, cl_abap_codepage, and cl_salv_table are the safe choices.
Authorization checks belong in the class. A custom entity has no built‑in DB‑level access controls — your SELECT is the gatekeeper. Call your authorization object before set_data( ).
Watch the response size. @Semantics.largeObject streams, but the gateway still buffers — keep templates under a few MB. For very large files, switch to a dedicated streaming endpoint.

10. Closing

The combination of CDS Custom Entity + IF_RAP_QUERY_PROVIDER + @Semantics.largeObject is one of the most under‑used corners of RAP. Once you internalise that the Attachment column is just an xstring you build at runtime, every "give me a download" requirement becomes a one‑class problem — no schema change, no transport drama, no stale binaries.

The same wiring works for:

PDF previews — build the bytes with the form runtime and serve them.
CSV exports — return UTF‑8 text (with BOM if Excel users will open them).
ZIP archives of multiple files — keep add( )‑ing into cl_abap_zip.
Image thumbnails — computed from master data.

Same plumbing. Different xstring.

If this pattern saved you a Z‑table, drop a 👍 and tell me what you used it for in the comments.

Happy RAP‑ing. 🛠️

Personal disclaimer

The views and techniques expressed here are my own and do not represent those of my employer or SAP. Code samples are illustrative — validate them in your own development system before adopting them in productive code.

Understanding field(suppress) in SAP RAP and How It Differs from @UI.hidden and @Consumption.hidden

2026-06-25T20:52:31.333000+02:00

INTRODUCTION

When working with SAP RAP (RESTful Application Programming Model), the Behavior Definition (BDEF) offers several keywords to control how data is exposed and handled. One of the less-discussed but powerful ones is field(suppress).

This blog is not just about syntax — it’s about what actually happens at runtime, the edge cases I hit, and why I chose suppression over readonly.

Requirement: In had one requirement, customer service reps needed to update Priority, Deadline Date, Cancel Reason, but they should never touch Created Time or Created User. These audit fields must remain intact, even during draft saves or mass updates.

What I Tried First
@UI.hidden: Hid the fields in Fiori, but they were still exposed in OData payloads.

field(readonly): Made the fields immutable, but they still appeared in EML structures — meaning a payload could attempt to overwrite them.

Both approaches failed to fully protect the audit fields.

What is field(suppress)?
field(suppress) is a static feature control in the BDEF that removes a field from RAP's transactional behavior layer. When a field is marked as suppressed, RAP excludes it from:

EML (Entity Manipulation Language) structures — such as TYPE TABLE FOR CREATE, TYPE STRUCTURE FOR UPDATE
RAP-generated behavior APIs
Behavior-related metadata

Runtime Behavior of Suppressed Fields
When I switched to field(suppress), here’s what I observed:

In EML statements, suppressed fields simply don’t exist. If you try to reference them, RAP silently ignores them, no runtime dump, no short dump.

If you mistakenly add them in the mapping section, RAP throws a framework error at activation time.

In draft handling, suppressed fields are still maintained internally, but you can’t overwrite them. This was critical for audit consistency.

In determinations, you cannot reference suppressed fields — the compiler blocks it. I observed this when trying to auto-populate Created By and Created At.

Syntax:

define behavior for ZI_REQHDR {
    field ( suppress ) CreatedAt, CreatedBy; 
}

Attempting to map them in the behavior pool raises:
Field "CreatedBy" cannot be suppressed.

Key insight: field(suppress) is a behavior-layer protection tool — it removes a field from RAP-generated transactional types and APIs. It is not a UI visibility control or an OData filter

Why Suppress Instead of Readonly
Readonly: Field is visible but immutable — still exposed in payloads.

Suppress: Field is completely removed from RAP’s transactional model — safest option for audit fields.

Note: Key fields (primary key fields) cannot be suppressed.

Suppressed fields must also be excluded from the field mapping. Attempting to include them raises a framework error:

mapping for zdt_vd_reqhdr corresponding
{
    RequestUuid   = request_uuid;
    Status        = status;
    Priority      = priority;
    ExternalId    = external_id;
    DeadlineDate  = deadline_date;
    RequesterId   = requester_id;
    CancelReason  = cancel_reason;

* // If i try to add the below fields error will get raised
*   CreatedBy     = created_by; // Field "CreatedBy" cannot suppressed
*   CreatedAt     = created_at; // Field "CreatedAt" cannot suppressed

    LastChangedBy = last_changed_by;
    LastChangedAt = last_changed_at;
}

Behavior Pool: Effect on EML Strutcure

Once suppressed, the fields are no longer available in EML operations. For example, in a MODIFY ENTITIES call, suppressed fields do not appear in the FIELDS ( ) selector:

 MODIFY ENTITIES OF zi_vd_reqhdr IN LOCAL MODE
    ENTITY RequestHeader
    UPDATE FIELDS (  ) 
* i try add the fields which i have done suppressed those not visible here 
    WITH VALUE #( FOR ls_key IN keys
                  ( %key = ls_key-%key
                  Status = 100 ) )
    REPORTED DATA(lt_report).

This confirms that suppressed fields are cleanly removed from the generated TYPE STRUCTURE FOR UPDATE and equivalent EML types.

How Does It Differ from `@ui.hidden` and `@Consumption.hidden`?

All three mechanisms can "hide" a field, but they operate at different layers:

Mechanism Layer Effect

`field(suppress)`	RAP behavior / EML	Removes field from RAP transactional APIs and EML structures
`@ui.hidden: true`	UI rendering	Hides the field from generated Fiori screens; field may still appear in OData metadata and API payloads
`@Consumption.hidden: true`	OData consumption	Hides the field from OData consumers and Fiori Elements scenarios

Use field(suppress) to protect a field from the RAP behavior layer entirely.
Use @ui.hidden to keep a field out of the UI while it remains accessible in APIs.
Use @Consumption.hidden to hide a field from external OData consumers.

Conclusion

field(suppress), @ui.hidden, and @Consumption.hidden serve distinct purposes in the RAP stack and should not be treated as interchangeable. When you have internal technical fields — timestamps, UUIDs, control fields — that RAP should never expose through its transactional model, field(suppress) is the right tool. Pair it with @Consumption.hidden to lock down the field at both the behavior and OData layers.

Updating Sales Order Header and Sales Order Item using Business Object Framework(Cleancore Approach)

2026-06-26T07:11:15.507000+02:00

In RAP, business processes are encapsulated within Business Objects (BOs), which define the data model and business logic. Developers interact with these Business Objects using the Entity Manipulation Language (EML), a modern ABAP syntax that supports operations such as CREATE, UPDATE, DELETE, and EXECUTE. By leveraging RAP and EML, applications become more maintainable, extensible, and upgrade-safe while adhering to SAP's Clean Core strategy and cloud-ready development standards.

Example : -

MODIFY ENTITIES OF i_salesordertp

ENTITY salesorder

UPDATE FIELDS ( zz1_testdata_sdh )

WITH VALUE #( (

%key-salesorder = keys[ 1 ]-salesorder

zz1_testdata_sdh = 'TestingData'

) )

ENTITY salesorderitem

UPDATE FIELDS ( zz1_status1_sdi )

WITH VALUE #(

(

%key-salesorder = keys[ 1 ]-salesorder

%key-salesorderitem = keys[ 1 ]-itemno

zz1_status1_sdi = keys[ 1 ]-%param-status

)

Note: The approach described here is not limited to custom fields. It applies to any field exposed by the SalesOrder or SalesOrderItem Business Object, regardless of whether the field is standard or custom.

If you introduce a custom field by directly appending standard database tables (for example, VBAK or VBAP), you must manually extend the entire data exposure layer. This typically involves extending CDS views, updating OData services, enhancing APIs, and ensuring the field is propagated across all relevant artifacts, which increases development effort and maintenance complexity.

A more Clean Core–compliant approach is to create custom fields using the Custom Fields and Logic (CFL) framework. When configured and enabled correctly, CFL automatically extends the relevant CDS views, OData services, and Business Objects, significantly reducing manual development. To ensure end-to-end availability of the custom field, enable the required UIs, SAP GUI, CDS Views, and APIs during field creation. For implementing custom business logic, use Cloud BAdIs instead of classical enhancement techniques.

For a detailed walkthrough on enabling CFL artifacts and implementing Cloud BAdIs, please refer to my previous blog.

- https://community.sap.com/t5/technology-blog-posts-by-sap/custom-field-and-logic-from-scratch/ba-p/14426888

Custom Root Entity Use case along with custom messages in RAP

2026-06-30T06:27:11.282000+02:00

A Custom Entity

A Custom Entity has no real table linked to it. RAP cannot read it automatically. Instead, it creates an empty structure and hands over the control to you. You then write your own ABAP code inside a Query Provider Class (QPC).

Custom Root Entity Example

@EndUserText.label: 'Custom Root Entity'

@ObjectModel: {
  query: {
    implementedBy: 'ABAP:ZCL_SALES_STATUS'
  }
}

@UI: {
  headerInfo: {
    typeName: 'SalesData',
    typeNamePlural: 'SalesData',
    title: { value: 'Salesorder' },
    description: { value: 'Itemno' }
  }
}

define root custom entity ZCR_CUSTSO_VIEW
{

  @UI.lineItem: [{ position: 10 , label: 'Sales Order' }]
  @Consumption.filter.mandatory: true
  @Search.defaultSearchElement: true
  @UI.identification:[{ position: 10 , label: 'Sales Order'}]
  key Salesorder : vbeln_va;

  @Consumption.filter.mandatory: true
  @Search.defaultSearchElement: true
  @UI.lineItem: [{ position: 20 , label: 'Sales Order Item' }]
  @UI.identification: [{ position: 20 , label: 'Sales Order Item' }]
  key Itemno : posnr_va;

  @Consumption.valueHelpDefinition: [{
    entity: {
      name: 'ZStatus_VH', // Your Value Help View
      element: 'Value'    // Source field for Status
    },
    additionalBinding: [{
      localElement: 'Statusdesc',   // Target field in your app
      element: 'Description',       // Source field from Value Help View
      usage: #RESULT                // Passes data on selection
    }]
  }]

  @UI.lineItem: [{ position: 30 , label: 'Sales Order Status' }]
  @UI.identification: [{ position: 30 , label: 'Sales Order Status' }]
  Status : abap.char( 1 );

  @UI.lineItem: [{ position: 40 , label: 'Time Stamp' }]
  @UI.identification: [{ position: 40 , label: 'Time Stamp' }]
  Timestamp : timestampl;

  @UI.identification: [{ position: 50 , label: 'Status Description' }]
  @UI.lineItem: [{ position: 50 , label: 'Status Description' }]
  Statusdesc : abap.char(20);

}

As you have created a Custom Root Entity, you are not forced to fetch data from a database source.

You can validate the input before fetching the data, or you can write your validation logic along with the data retrieval because you are implementing the query yourself.

You can loop over the data, modify it, apply your own business logic, or perform any operation you require before returning the response.

CLASS zcl_sales_status DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC .

PUBLIC SECTION.

  INTERFACES if_rap_query_provider .

PROTECTED SECTION.
PRIVATE SECTION.

ENDCLASS.

CLASS zcl_sales_status IMPLEMENTATION.

METHOD if_rap_query_provider~select.

  DATA(lv_top) = io_request->get_paging( )->get_page_size( ).

  IF lv_top < 0.
    lv_top = 1.
  ENDIF.

  DATA(lv_skip) = io_request->get_paging( )->get_offset( ).

  DATA(lt_sort) = io_request->get_sort_elements( ).

  DATA : lv_orderby TYPE string.

  LOOP AT lt_sort INTO DATA(ls_sort).

    IF ls_sort-descending = abap_true.
      lv_orderby = |'{ lv_orderby } { ls_sort-element_name } DESCENDING |.
    ELSE.
      lv_orderby = |'{ lv_orderby } { ls_sort-element_name } ASCENDING |.
    ENDIF.

  ENDLOOP.

  IF lv_orderby IS INITIAL.
    lv_orderby = 'Salesorder'.
  ENDIF.

  DATA(lv_conditions) = io_request->get_filter( )->get_as_sql_string( ).

  SELECT FROM zebst_status_log
    FIELDS salesorder,
           itemno,
           status,
           statusdesc,
           timestamp
    WHERE (lv_conditions)
    ORDER BY (lv_orderby)
    INTO TABLE @DATA(lt_status)
    UP TO @lv_top ROWS
    OFFSET @lv_skip.

  IF lt_status IS INITIAL.

    IF lv_conditions IS NOT INITIAL.

      RAISE EXCEPTION TYPE zcx_rap_exception_provider
        EXPORTING
          textid = VALUE scx_t100key(

*           HOW TO ADD CUSTOM MESSAGE CREATED IN SE91 (ZMSG_STATUS)

            msgid = 'ZMSG_STATUS'
            msgno = '000'
          )
          previous = NEW cx_sadl_contract_violation( ).

    ELSEIF lv_conditions IS INITIAL.

      RAISE EXCEPTION TYPE zcx_rap_exception_provider
        EXPORTING
          textid = VALUE scx_t100key(

*           HOW TO ADD CUSTOM MESSAGE CREATED IN SE91 (ZMSG_STATUS)

            msgid = 'ZMSG_STATUS'
            msgno = '001'
          )
          previous = NEW cx_sadl_contract_violation( ).

    ENDIF.

  ELSE.

    IF io_request->is_total_numb_of_rec_requested( ).
      io_response->set_total_number_of_records( lines( lt_status ) ).
      io_response->set_data( lt_status ).
    ENDIF.

  ENDIF.

ENDMETHOD.

ENDCLASS.

Using this approach, you can display a custom message when the user clicks the Go button.

In Managed and Unmanaged RAP scenarios, it is not straightforward to display this type of validation message during the read operation because the framework handles the data retrieval automatically. However, with a Custom Root Entity and Query Provider Class, you have complete control over the query execution and can perform validations before returning the data.

Custom Exception Class

To display custom messages, you need to create a custom exception class by inheriting from the standard RAP Query Provider exception class.

CLASS zcx_rap_exception_provider DEFINITION
  PUBLIC
  INHERITING FROM cx_rap_query_provider
  FINAL
  CREATE PUBLIC .

PUBLIC SECTION.

  METHODS constructor
    IMPORTING
      !textid   LIKE if_t100_message=>t100key OPTIONAL
      !previous LIKE previous OPTIONAL.

PROTECTED SECTION.
PRIVATE SECTION.

ENDCLASS.

CLASS zcx_rap_exception_provider IMPLEMENTATION.

METHOD constructor ##ADT_SUPPRESS_GENERATION.

  CALL METHOD super->constructor
    EXPORTING
      previous = previous.

  CLEAR me->textid.

  IF textid IS INITIAL.
    if_t100_message~t100key = if_t100_message=>default_textid.
  ELSE.
    if_t100_message~t100key = textid.
  ENDIF.

ENDMETHOD.

ENDCLASS.

After creating this custom exception class, you can use your custom SE91 message class (for example, ZMSG_STATUS) to display meaningful validation messages directly in the Fiori application when the user clicks the Go button.

This approach gives you complete control over the read operation. You can validate user input, fetch data from any source, modify the retrieved data, implement custom business logic, and raise custom exceptions whenever required.

Bypassing the List Report in SAP Fiori Apps: BCMO, Static Keys, and Dynamic Keys

2026-07-03T09:09:19.145000+02:00

If you've ever generated a Business Configuration Maintenance Object (BCMO) app or built a standard List Report Fiori app for a table with just one relevant record, you've probably run into the same annoyance: the app insists on showing you a list page first, even when there's really only one record, or one record per user, that anyone should ever land on.

In this post, I'll walk through the complete flow: generating a BCMO app for a custom table, getting rid of the pointless singleton list report, and then bypassing the list page in a regular List Report app using both a static key and a dynamic key, such as the logged-in username.

What is a BCMO App, and How Does It Relate to Table Maintenance Generator (TMG)?

Before we jump into the how, a quick primer for anyone new to this.

A Table Maintenance Generator (TMG) is the classic SAP GUI way of generating a maintenance screen for a customizing table, using transaction SE11/SE54. You get a generated SM30 style screen where users can create, edit, and delete entries in a table.

BCMO, Business Configuration Maintenance Object, is essentially the RAP and Fiori based evolution of the same idea. Instead of generating an SM30 style dynpro, ADT generates a full RAP based application stack, behavior definition, behavior implementation, service definition, and service binding, for your custom table, and exposes it as a modern Fiori app. You get the same core purpose as TMG, maintaining configuration or master data in a table, but with a UI5 based List Report and Object Page instead of a classic table control screen.

So think of BCMO as: you want the SM30/TMG experience, but as a proper Fiori Elements app, generated automatically from your table.

You can access a BCMO app in two ways:

Through the Custom Business Configurations (CBC) app, where all the configuration and settings are automatically applied.
As a standalone app, published separately to your Fiori Launchpad or SAP Build Work Zone. In this case, the actual table maintenance appears on the object page, but you also get a singleton list report page in front of it, which is usually unnecessary.

That useless singleton list report is exactly what we're going to eliminate below.

Part 1: Creating a BCMO App

Prerequisites on the Database Table

Before ADT will let you generate a BCMO app, your custom table needs to satisfy a few conditions. If you skip these, generation will fail, and you'll typically see errors pointing you toward three things:

The table's delivery class needs to be set to C, since BCMO is meant for customizing tables, not regular application data.
Data maintenance needs to be explicitly allowed on the table, via the AbapCatalog.dataMaintenance annotation.
Character-like key fields need to be based on a domain, rather than a plain built-in type, so the generator can derive proper value help and type information.

Once these three conditions are met, ADT will happily generate the BCMO stack for you. Here's an example table definition that satisfies all of them:

@EndUserText.label : 'Product Industry Mapping'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zsac_t_prod_ind {

  key client          : abap.clnt not null;
  key industry_sector : mbrsh not null;
  unit_of_measure     : meins;
  currency_code       : abap.cuky;

}

Generating the BCMO Objects

Right-click on the table in ADT, click Generate ABAP Repository Objects, select Business Configuration Maintenance Object, and click Next.

Enter the package.

In the Configure Generator step, you decide the naming of the generated objects and which features to enable. For this example, we'll set Transport Selection to No Transport and uncheck "Enable Transport Selection Strip" to keep things simple. Depending on your landscape, you may want this enabled instead.

Here's the full list of objects that get generated for us:

After selecting your transport request, or choosing No Transport, click Finish, and sip a cup of tea while ADT does its thing.

Once generation completes, this is what you get in ADT:

Accessing the BCMO App

You can access your BCMO app in two ways:

Through the Custom Business Configurations (CBC) app, where all the standard settings are already applied for you.
As a standalone app, published separately to your SAP Fiori Launchpad or SAP Build Work Zone.

If you go the standalone route, the actual table maintenance will appear correctly on the object page, but you'll also get an unnecessary singleton list report page in front of it, which is exactly the problem we're solving in the next section.

Now open the service binding, publish it, and test it.

A Note on Authorizations

You may notice that an access control object gets automatically generated as part of BCMO. If the authorization object S_TABU_NAM is not assigned to your user role, you may see no data in the output, or the Edit button may be disabled.

In that case, you have two options:

Delete the access control on your root entity, or
Assign the required authorizations to your user ID.

While testing this, I also had to comment out the global authorization check in the generated behavior implementation just to see data, due to missing authorizations in my BTP trial account. Obviously, don't do this in a real system, it's purely a local testing workaround.

Part 2: Getting Rid of the Singleton List Report for a BCMO App

Now that our BCMO app is ready, let's get rid of the singleton list report. It doesn't add any value, there's only ever one relevant "list," so why make the user click through it every time?

Step 1: Create a New Project in BAS

Go to SAP Business Application Studio and create a new project from the available templates.

Select SAP Fiori Generator.

Select List Report Page and click Next.

Select the Data Source and Service.

Note: If your system isn't logged in yet, log in first. If you're on an SAP BTP trial account, you'll need to connect BAS to Cloud Foundry before you can see the available Service Bindings.

To do that, open the top search bar and type:

>CF: Login to Cloud Foundry

Once logged in, you should now be able to see the service. Look for your Service Binding for the BCMO app and select it.

Select the entity.

If you're planning to deploy the app immediately, make sure to check "Add Deployment Configuration" and "Add SAP Fiori Launchpad Configuration." For this demo, I'm keeping both unchecked since we're only focused on getting rid of the list report page, not deployment.

Click Finish, and go have another cup of tea while the project scaffolds.

Step 2: Remove the List Report Route from the Manifest

With the project created in BAS, let's get to the main task.

Open manifest.json under the webapp folder and remove the list report route and its corresponding target.

We do this because the default routing configuration always points the app to the list report as the landing page first. By removing this route and target pair, we prevent the router from ever resolving to the list report on initial load, which sets us up to redirect straight to the object page instead.

Step 3: Auto-Navigate to the Object Page in Component.js

Now go to Component.js under the webapp folder and add the following code so the app routes directly to the object page of our singleton record whenever it loads:

init: function () {
    Component.prototype.init.apply(this, arguments);
    this.getRouter().navTo("ProductIndSingletonObjectPage", { key: "(1)" }, true);
}

Step 4: Test It

Run the following command in the terminal to preview the app:

npm run start

And voilà, the first page that opens is no longer the singleton list report, but the actual object page we wanted users to land on directly.

From here, you can continue with deployment as per your requirement, including Fiori Launchpad configuration and transport.

Part 3: Bypassing the List Report for a Standard List Report App

The technique above works great for a true singleton, a table with essentially one record. But what if you're working with a regular List Report app on a table with multiple records, and you want to skip the list page in favor of a specific object page, based on a static key or a dynamic key like the logged-in user? Let's look at both.

Deploying the Base List Report App

As before, start by creating a new project in SAP BAS or VS Code, selecting SAP Fiori Application, then List Report as the template.

In the template wizard, select your Data Source, System, and Service, then click Next. Select the correct main entity and navigation entity, and choose Yes to automatically add table columns and a section to the object page.

Enter your project attribute details, choose Yes for deployment configuration, click Finish, and wait for the dependencies to install. Don't refresh the page while you see "Installing Dependencies" at the bottom right of VS Code.

Once deployed, remove the singleton list report the same way described above: strip the route and target from the manifest, and add the navTo call in Component.js.

The difference this time is what key you pass into that navTo call.

Option A: Bypassing with a Static Key

If you always want the app to open a specific, known record, hardcode the key directly:

init: function () {
    Component.prototype.init.apply(this, arguments);
    this.getRouter().navTo("TableGroupAllObjectPage", { key: "(1)" }, true);
}

This is the simplest approach and works well when there's genuinely one record everyone should see, similar to the BCMO singleton pattern above, but applied manually to a regular List Report app.

Option B: Bypassing with a Dynamic Key (Logged-in Username)

Often, though, you don't want everyone landing on the same record. You want each user routed to their own record, based on who's logged in. For this, we fetch the current username first, then use it to construct the key dynamically before navigating.

init: function () {
    Component.prototype.init.apply(this, arguments);

    var sUser = sap.ushell.Container
        ? sap.ushell.Container.getUser().getId()
        : "DEFAULT_USER";

    this.getRouter().navTo("TableGroupAllObjectPage", { key: "('" + sUser + "')" }, true);
}

A few things to keep in mind with the dynamic key approach:

Make sure the key field in your entity actually corresponds to something like a username, or a field you can reliably derive from the logged-in user, for example, mapped via a custom table or CDS view.
If no record exists for that user yet, decide upfront how your app should behave: show an empty object page in create mode, show a "no data" message, or fall back to a default record.
Test this thoroughly with multiple user IDs before deploying, since the whole point is that different users see different landing records.

For Multi-Level Apps

If your app has more than two navigation levels, for example, a list report page, then an object page showing a related sub-entity's list, then a further object page for that sub-entity's own details, you'll need to add another navigation node to the page map.

To do this, right-click on the app's folder in BAS and select Show Page Map. You'll see the existing levels, with a plus icon enabled on the deepest Object Page. Click it, select the correct navigation property, and add the new page.

Once your routing is set up correctly, deploy using:

npm run deploy

Wrapping Up

Whether you're working with a BCMO app generated straight from ADT, or a hand-built List Report Fiori app, the pattern for bypassing the list page is fundamentally the same:

Remove the list report's route and target from the manifest.
Add a navTo call in Component.js's init function that routes straight to the object page.
Decide whether that route needs a static key, same record for everyone, or a dynamic key, per-user record, typically derived from the logged-in username.
If you have deeper navigation levels, extend the page map accordingly before deploying.

This small change removes a genuinely pointless click for your end users, and it's one of those RAP and Fiori details that separates a generated-and-shipped app from a genuinely polished one.

If deployment configuration for RAP apps to SAP BTP is something you'd like a refresher on before trying this end to end, it's worth reading up on that step separately once you're ready to move beyond local testing.

How to Scan Custom ABAP for Security Issues in Eclipse (Step-by-Step)

2026-07-03T10:20:40.741000+02:00

Disclosure: I work on this tool at RedRays. This post is a straightforward setup guide, not a product pitch.

This post walks through connecting Eclipse to a static analysis backend that scans custom ABAP for common security issues (SQL injection, missing authorization checks, hard-coded credentials, weak crypto, and similar) and returns findings directly in the IDE.

Prerequisites

- Eclipse 2024-09 or newer
- SAP ABAP Development Tools (ADT) installed
- Java 17
- Network access to the backend you plan to scan against (in this walkthrough, a demo instance)

Step 1: Get an API key

The plugin needs an API key to authenticate against a scan backend. For testing, there's a self-service demo instance:

1. Open get.abap-security.com.
2. Enter a name and email address.
3. Click Create my Eclipse API key.
4. Copy the key immediately - it is displayed once.

Notes on the demo instance:
- Limited to one key per IP address per time window.
- It is a shared instance - do not submit confidential or production code to it. For real use, point the plugin at your own tenant or an on-premise instance instead (see "Beyond the demo" below).

Step 2: Install the plugin

In Eclipse:

1. Help → Install New Software…
2. Click Add… and enter the update site: plugin.abap-security.com
3. Select RedRays ABAP Scanner from the list.
4. Finish the wizard and restart Eclipse when prompted.

Step 3: Configure the connection

1. Window → Preferences → RedRays Scanner
2. Set Working mode to RedRays.
3. Set RedRays URL to https://demo.abap-security.com:8443/ (or your own instance's URL).
4. Paste the API key from Step 1 into RedRays API key.
5. Click Test connection and confirm it succeeds before continuing.

Step 4: Run a scan

1. Right-click any ABAP object in the Project Explorer.
2. Select Scan with RedRays.
3. Choose the Quick scan profile for a first run.
4. Findings appear in a dedicated Eclipse view as the scan completes.

Reading the results

- Findings are grouped by severity: Critical, High, Medium, Low.
- Double-clicking a finding opens the source at the exact line.
- Each finding includes a CVSS score and an automated exploitability check, intended to reduce false positives that would otherwise need manual triage.

Categories currently covered include: SQL/ADBC injection, OS command execution, dynamic WHERE/ORDER BY clauses, path traversal on OPEN DATASET, RFC trust issues, missing AUTHORITY-CHECK, hard-coded credentials, and weak cryptographic algorithms (MD5/SHA-1), among others.

Beyond the demo

The same plugin can point at a privately provisioned tenant or an on-premise instance instead of the shared demo, with isolated access per subaccount and no source retention (code is scanned in memory and discarded; only findings are stored). There is also a REST API for scanning from CI/CD, including an endpoint that returns an allow/block decision for a transport based on a severity threshold - useful as a pre-import gate.

Resources

- Plugin overview: redrays.io/abap-scanner-eclipse-plugin
- Demo / API key: get.abap-security.com

Chat-based RAP Business Object Generation in VS Code

2026-07-03T14:28:10.192000+02:00

With ABAP Development Tools (ADT) for VS Code, you can now generate complete RAP Business Objects directly from chat prompts. Describe your business scenario in natural language, and GitHub Copilot generates the corresponding RAP artifacts in your ABAP system.

The generated artifacts include:

Database tables
CDS views
Behavior definitions
Service definitions
Service bindings

This feature is enabled by the extension’s built-in MCP (Model Context Protocol) server, which exposes ABAP backend APIs as tools that AI agents can invoke directly. This lets them create and connect the necessary RAP artifacts on your behalf.

Getting Started

For more information about setting up ADT for VS Code, configuring GitHub Copilot Agent Mode, using the ADT MCP server, and troubleshooting common issues, refer to the guide.

Prerequisites:

Before you begin, ensure that you have the following:

ABAP Development Tools for VS Code installed from the VS Code Marketplace
An ABAP system connection configured in the extension (steps shown below)

Figure 1. Adding an ABAP system to the workspaceFigure 2. Selecting a destinationFigure 3. Log on with your credentials

GitHub Copilot with Agent Mode enabled

Figure 4. GitHub Copilot in agent mode

Enable the ADT MCP Server

First, verify that the ADT MCP server is enabled. To do so:

Open the Settings and Search for ADT MCP Server in the search bar
Check the box Enable ADT MCP Server

Figure 5. Enabling ADT MCP Server in settings

Configuring ADT MCP Server

The ADT MCP server is not automatically configured for GitHub Copilot. To configure the ADT MCP Server, open the Command Palette and run MCP: List Servers, then start the ADT MCP server.

Figure 6. Listing the available MCP servers

Figure 7. Starting the ADT MCP Server (part 1)Figure 8. Starting the ADT MCP Server (part 2)

When the ADT MCP server is running and successfully connected, the following notification appears in the lower-right corner:

Figure 9. Success message

Once connected, the available ABAP MCP tools appear in GitHub Copilot. You can verify this by opening Configure Tools in the GitHub Copilot chat, where you can view and select the tools that are active for your session.

Figure 10. Verifying the connection to the ABAP MCP Server (part 1)Figure 11. Verifying the connection to the ADT MCP Server (part 2)

If MCP tools don't appear after setup please refer to troubleshooting

Generating a RAP Business Object

Note: Before running the generation, ensure that your target package already exists. Currently, new packages must be created in ADT for Eclipse. Creating packages directly from ADT for VS Code will be supported in a future release.

With the ADT MCP server running, open GitHub Copilot Chat in Agent Mode and describe the RAP Business Object you want to generate. For best results you can take a look at agent prompt best practices.

An example prompt would be:

“ Generate a RAP Business Object for conference and tech event management, including a database table, CDS views,

behavior definition, and an OData V4 UI service.

Use the Package TEST_BB_CONFERENCE_MGT
Use the following specification:
- Entity 1: Event (root entity)
- Entity 2: Session, child of Event
- Entity 3: Speaker, child of Event
- Entity 4: Registration, child of Session“

Figure 12. Entering a prompt in the chatFigure 13. GitHub Copilot response to the prompt

After your prompt, Copilot will:

List available destinations (abap_list_destinations)
Retrieve the schema (abap_generators-get_schema)
Validate (abap_creation-run_validation)
Create a transport request (abap_transport-create)
Generate all objects (abap_generators-generate_objects)
Activate objects (abap_activate_objects)

After the generation completes, refresh your ABAP project by opening the Command Palette (Ctrl+Shift+P) and running ABAP: Refresh. The generated RAP artifacts will then appear in your workspace under the target package.

Figure 14. RAP artifacts displayed under the defined package

Once the service binding appears in your workspace, use the Publish CodeLens action to publish the service directly from VS Code. After publishing, the OData service is available for consumption.

Figure 15. Publishing the service bindingFigure 16. Success message

Then, use the Preview CodeLens to launch a live preview of your Fiori elements application directly in your browser:

Figure 17. Launching the application previewFigure 18. Selecting the entity for preview

Your generated application is then displayed in the browser:

Figure 19. Application preview

All generated artifacts are created directly in your ABAP system as standard repository objects. They are identical to the RAP artifacts you would create manually, fully editable in ADT for VS Code, and can be extended using the standard RAP development workflow.

Summary

Chat-based RAP Business Object generation enables you to create complete RAP Business Objects directly from natural language prompts in ADT for VS Code. Combined with GitHub Copilot Agent Mode and the ADT MCP server, it automates the creation of the required RAP artifacts while keeping them fully editable as standard ABAP repository objects.

For more information, including setup instructions and configuration details, see the ABAP Development Tools for Visual Studio Code | SAP Help Portal

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

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

Why External Entities?

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

Business scenario:

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

The blog demonstrates this using a Loyalty Management application.

Scenario

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

Prerequisites:

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

Steps:

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

Setup SAP HANA Cloud instance

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

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

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

Create Schema and Tables

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

Create Schema

CREATE SCHEMA LOYALTY;

Create Membership table: zlm_membship_ee .

Stores membership details
Primary key: client + membershipuuid

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

Create Transactions table: zlm_transctns_ee

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

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

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

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

Create CDS External Entities

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

These entities map external tables to ABAP CDS.

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

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

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

We need to create Writable External Entity for table zlm_transctns_ee

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

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

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

We need another STATIC EXTERNAL ENTITY for table zlm_transctns_ee

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

Key Takeaways.

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

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

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

2026-07-08T10:50:41.923000+02:00

Business scenario:

The blog demonstrates this using a Loyalty Management application.

Scenario

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

Prerequisites

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

Build CDS Data Model

For creating Loyalty Management Application, we need to have customer master data. For our reference scenario and to show only required fields, we will create a custom CDS entity over I_BusinessPartner .

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Value help for Business Partner'
@Metadata.ignorePropagatedAnnotations: true

define view entity zlm_i_businesspartner_vh
  as select from I_BusinessPartner as BusinessPartner
{
      @ObjectModel.text.element: [ 'BusinessPartnerName' ]
      @Consumption.filter.hidden: true
  key BusinessPartner.BusinessPartner,
      @ui.hidden: true
      BusinessPartnerCategory,
      @EndUserText.label: 'Business Partner Name'
      @search.defaultSearchElement: true
      @search.fuzzinessThreshold: 0.8
      @search.ranking: #HIGH
      BusinessPartner.BusinessPartnerName

}

Ceate root entity (Membership) and child entity (Transactions).
Add composition: One membership can have multiple transactions.
Use associations for linking data like Business Partner.

Create root entitity zlm_r_membship_ee

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'CDS on Static EE for Loyalty Membership'
define root view entity zlm_r_membship_ee
  as select from zlm_membship_ee
  composition [1..*] of zlm_r_transctns_ee           as _MembershipTransactions
  association [1..1] to zlm_i_businesspartner_vh     as _BusinessPartner on $projection.Customer = _BusinessPartner.BusinessPartner
{
  key membershipuuid     as Membershipuuid,
      membershipid       as Membershipid,
      customer           as Customer,
      createdby          as Createdby,
      createdat          as Createdat,
      lastchangedby      as Lastchangedby,
      locallastchangedat as Locallastchangedat,
      lastchangedat      as Lastchangedat,
      _BusinessPartner,
      _MembershipTransactions
}
where
  zlm_membship_ee.client = $session.client

Save the cds zlm_r_membship_ee and don’t activate.
Create Child Entity zlm_r_transctns_ee.

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'CDS on Static EE  for transactions'
define view entity zlm_r_transctns_ee
  as select from zlm_transctns_ee
  association to parent zlm_r_membship_ee as _LoyaltyMembership on $projection.Membershipuuid = _LoyaltyMembership.Membershipuuid
{
  key transactionuuid     as Transactionuuid,
      membershipuuid      as Membershipuuid,
      transactiondate     as Transactiondate,
      @Semantics.amount.currencyCode : 'transactioncurrency'
      transactionvalue    as Transactionvalue,
      transactioncurrency as Transactioncurrency,
      loyaltypoints       as Loyaltypoints,
      createdby           as Createdby,
      createdat           as Createdat,
      lastchangedby       as Lastchangedby,
      locallastchangedat  as Locallastchangedat,
      lastchangedat       as Lastchangedat,
      _LoyaltyMembership
}
where
  zlm_transctns_ee.client = $session.client

Save and activate both the entities using "Activate inactive development objects".
To calculate the loyalty points at runtime along with draft mode, we create the following CDS view entities.

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Total Loyalty Points-Without draft'
@Metadata.ignorePropagatedAnnotations: true
define view entity zlm_c_loyaltypoints_total_ee
  as select from zlm_r_transctns_ee
{
  key Membershipuuid,
      sum ( Loyaltypoints ) as Total
}
group by
  zlm_r_transctns_ee.Membershipuuid

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Loyalty Pts in draft-existing Membership'
@Metadata.ignorePropagatedAnnotations: true
define view entity zlm_c_loyaltypoints_dfttot_ee
  as select from zlm_trans_ee_d
{
  key membershipuuid,
      sum ( loyaltypoints ) as Total
}
group by
  zlm_trans_ee_d.membershipuuid

Merge the CDS views and compute the total loyalty points per membership.

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Effective Loyalty Pts per Membership'
@Metadata.ignorePropagatedAnnotations: true

define view entity zlm_c_membship_loyaltypts_ee
  as select from zlm_c_loyaltypoints_total_ee as actual
    left outer join zlm_c_loyaltypoints_dfttot_ee as draft
      on actual.Membershipuuid = draft.membershipuuid
{
  key actual.Membershipuuid               as Membershipuuid,
      coalesce (
        draft.Total,
        actual.Total
      )                                   as Total
}

union all

select from zlm_c_loyaltypoints_dfttot_ee as draft
  left outer join zlm_c_loyaltypoints_total_ee as actual
    on draft.membershipuuid = actual.Membershipuuid
{
  key draft.membershipuuid                as Membershipuuid,
      draft.Total                         as Total
}
where actual.Membershipuuid is null;

Define Behaviour

Enable CRUD operations:
- Create
- Update
- Delete
Add determination logic:
- Automatically calculate loyalty points when transaction value changes.

To perform CRUD operations, we need to define corresponding behaviour definitions and implementations for root and child entities.In ABAP Development Tools for eclipse, right click on zlm_r_membship_ee and create behaviour definition.

unmanaged implementation in class zbp_lm_membship_ee unique;
strict ( 2 );
with draft;
define behavior for zlm_r_membship_ee alias LoyaltyMembership
draft table zlm_memb_ee_d
lock master total etag Lastchangedat
authorization master ( instance )
etag master Locallastchangedat

{
  create ( precheck ,  authorization : global );
  update;
  delete;
  field ( numbering : managed ) Membershipuuid;
   field ( readonly ) Membershipuuid;
  draft action Activate optimized;
  draft action Discard;
  draft action Edit;
  draft action Resume;
  draft determine action Prepare;
  association _MembershipTransactions { create{default function GetDefaultsForCBA;} with draft; }
}

define behavior for zlm_r_transctns_ee alias MembershipTransactions
draft table zlm_trans_ee_d
lock dependent by _LoyaltyMembership
authorization dependent by _LoyaltyMembership
etag master Locallastchangedat
{
  update;
  delete;
  field ( numbering : managed ) Transactionuuid;
  field ( readonly ) Transactionuuid, Membershipuuid;
    //calculate loyalty points when a transaction is created or relevant fields are modified
  determination CalculateLoyaltyPoints on modify
  { create; field Transactionvalue; }
  side effects
  {
    field Transactionvalue affects field Loyaltypoints, entity _LoyaltyMembership;
  }
  association _LoyaltyMembership { with draft; }
}

Implement Business Logic

Create number range object ZLM_MID_EE via ADT and by using Fiori application “Manage Number range Intervals” , maintain the number range.

Create message class ZLM_MESSAGES_EE and add the following messages.

Create Interface zlm_if_constants_ee for maintaining constants.

INTERFACE zlm_if_constants_ee
  PUBLIC .
  CONSTANTS:
    nr_obj_value             TYPE cl_numberrange_runtime=>nr_object VALUE 'ZLM_MID_EE',
    nr_range_nr              TYPE cl_numberrange_runtime=>nr_interval VALUE '01',
    draft                    TYPE abp_behv_flag VALUE '00',
    cid                      TYPE abp_behv_cid VALUE '01'.
ENDINTERFACE.

Create class zcx_lm_messages_ee to handle exceptions in the application.

CLASS zcx_lm_messages_ee DEFINITION
  PUBLIC
  INHERITING FROM cx_static_check
  FINAL
  CREATE PUBLIC .
  PUBLIC SECTION.
    INTERFACES:
      if_t100_message,
      if_abap_behv_message.
    CONSTANTS:
      message_class TYPE symsgid VALUE 'ZLM_MESSAGES_EE',
      BEGIN OF extdb_cud_failure,
        msgid TYPE symsgid VALUE message_class,
        msgno TYPE symsgno VALUE '001',
        attr1 TYPE scx_attrname VALUE '',
        attr2 TYPE scx_attrname VALUE '',
        attr3 TYPE scx_attrname VALUE '',
        attr4 TYPE scx_attrname VALUE '',
      END OF extdb_cud_failure,
      BEGIN OF extdb_mcrt_success,
        msgid TYPE symsgid VALUE message_class,
        msgno TYPE symsgno VALUE '002',
        attr1 TYPE scx_attrname VALUE 'MV_MEMBERSHIPID',
        attr2 TYPE scx_attrname VALUE '',
        attr3 TYPE scx_attrname VALUE '',
        attr4 TYPE scx_attrname VALUE '',
      END OF extdb_mcrt_success,
      BEGIN OF extdb_mupd_success,
        msgid TYPE symsgid VALUE message_class,
        msgno TYPE symsgno VALUE '003',
        attr1 TYPE scx_attrname VALUE 'MV_MEMBERSHIPID',
        attr2 TYPE scx_attrname VALUE '',
        attr3 TYPE scx_attrname VALUE '',
        attr4 TYPE scx_attrname VALUE '',
      END OF extdb_mupd_success,
      BEGIN OF extdb_mdel_success,
        msgid TYPE symsgid VALUE message_class,
        msgno TYPE symsgno VALUE '004',
        attr1 TYPE scx_attrname VALUE 'MV_MEMBERSHIPID',
        attr2 TYPE scx_attrname VALUE '',
        attr3 TYPE scx_attrname VALUE '',
        attr4 TYPE scx_attrname VALUE '',
      END OF extdb_mdel_success,
      BEGIN OF extdb_tcrt_success,
        msgid TYPE symsgid VALUE message_class,
        msgno TYPE symsgno VALUE '005',
        attr1 TYPE scx_attrname VALUE 'MV_LOYALTYPOINTS',
        attr2 TYPE scx_attrname VALUE '',
        attr3 TYPE scx_attrname VALUE '',
        attr4 TYPE scx_attrname VALUE '',
      END OF extdb_tcrt_success,
      BEGIN OF extdb_tupd_success,
        msgid TYPE symsgid VALUE message_class,
        msgno TYPE symsgno VALUE '006',
        attr1 TYPE scx_attrname VALUE 'MV_LOYALTYPOINTS',
        attr2 TYPE scx_attrname VALUE '',
        attr3 TYPE scx_attrname VALUE '',
        attr4 TYPE scx_attrname VALUE '',
      END OF extdb_tupd_success,
      BEGIN OF extdb_tdel_success,
        msgid TYPE symsgid VALUE message_class,
        msgno TYPE symsgno VALUE '007',
        attr1 TYPE scx_attrname VALUE '',
        attr2 TYPE scx_attrname VALUE '',
        attr3 TYPE scx_attrname VALUE '',
        attr4 TYPE scx_attrname VALUE '',
      END OF extdb_tdel_success,
      BEGIN OF extdb_mdel_failure,
        msgid TYPE symsgid VALUE message_class,
        msgno TYPE symsgno VALUE '008',
        attr1 TYPE scx_attrname VALUE '',
        attr2 TYPE scx_attrname VALUE '',
        attr3 TYPE scx_attrname VALUE '',
        attr4 TYPE scx_attrname VALUE '',
      END OF extdb_mdel_failure.
    DATA:
      mv_membershipid  TYPE zlm_membershipid_ee,
      mv_loyaltypoints TYPE zlm_loyaltypoints_ee.
    METHODS:
      constructor
        IMPORTING
          textid        LIKE if_t100_message=>t100key         OPTIONAL
          previous      LIKE previous                         OPTIONAL
          severity      TYPE if_abap_behv_message=>t_severity DEFAULT  if_abap_behv_message=>severity-error
          membershipid  TYPE zlm_membershipid_ee   OPTIONAL
          loyaltypoints TYPE zlm_loyaltypoints_ee OPTIONAL
            PREFERRED PARAMETER textid .
  PROTECTED SECTION.
  PRIVATE SECTION.
ENDCLASS.
CLASS zcx_lm_messages_ee IMPLEMENTATION.
  METHOD constructor ##ADT_SUPPRESS_GENERATION.
    super->constructor( previous = previous ).
    me->if_abap_behv_message~m_severity = severity.
    me->mv_membershipid   = membershipid.
    me->mv_loyaltypoints  = loyaltypoints.
    CLEAR me->textid.
    IF textid IS INITIAL.
      if_t100_message~t100key = if_t100_message=>default_textid.
    ELSE.
      if_t100_message~t100key = textid.
    ENDIF.
  ENDMETHOD.
ENDCLASS.

Behaviour Implementation.

CLASS zbp_lm_membship_ee DEFINITION PUBLIC ABSTRACT FINAL FOR BEHAVIOR OF zlm_r_membship_ee.
ENDCLASS.
CLASS ZBP_LM_MEMBSHIP_EE IMPLEMENTATION.
ENDCLASS.

In the local types tab of class zbp_lm_membship_ee, add the following .

CLASS lcl_buffer DEFINITION CREATE PRIVATE.
  PUBLIC SECTION.
    TYPES: membship_crt TYPE TABLE FOR CREATE zlm_c_membship_ee.
    TYPES: transactns_crt TYPE TABLE FOR CREATE zlm_c_membship_ee\_membershiptransactions.
    TYPES: membship_upd TYPE TABLE FOR UPDATE zlm_c_membship_ee.
    TYPES: transactns_upd TYPE TABLE FOR UPDATE zlm_c_transctns_ee.
    TYPES: membship_del TYPE TABLE FOR DELETE zlm_c_membship_ee.
    TYPES: transactns_del TYPE TABLE FOR DELETE zlm_c_transctns_ee.
    CLASS-METHODS get_instance
      RETURNING VALUE(ro_instance) TYPE REF TO lcl_buffer.
    DATA create_memberships TYPE membship_crt READ-ONLY.
    DATA create_transactions TYPE transactns_crt READ-ONLY.
    DATA update_memberships TYPE membship_upd READ-ONLY.
    DATA update_transactions TYPE transactns_upd  READ-ONLY.
    DATA delete_memberships TYPE membship_del READ-ONLY.
    DATA delete_transactions TYPE transactns_del READ-ONLY.
    METHODS set_create_memberships   IMPORTING memberships TYPE membship_crt.
    METHODS set_create_transactions IMPORTING transactions TYPE transactns_crt.
    METHODS set_update_memberships   IMPORTING memberships TYPE membship_upd.
    METHODS set_update_transactions IMPORTING transactions TYPE transactns_upd.
    METHODS set_delete_memberships   IMPORTING memberships TYPE membship_del.
    METHODS set_delete_transactions IMPORTING transactions TYPE transactns_del.
  PRIVATE SECTION.
    CLASS-DATA: go_instance TYPE REF TO lcl_buffer.
ENDCLASS.
CLASS lcl_buffer IMPLEMENTATION.
  METHOD get_instance.
    IF go_instance IS NOT BOUND.
      go_instance = NEW #( ).
    ENDIF.
    ro_instance = go_instance.
  ENDMETHOD.
  METHOD set_create_memberships.
    me->create_memberships = CORRESPONDING #( memberships ).
  ENDMETHOD.
  METHOD set_create_transactions.
    me->create_transactions = CORRESPONDING #( transactions ) .
  ENDMETHOD.
  METHOD set_delete_memberships.
    me->delete_memberships = CORRESPONDING #( memberships ).
  ENDMETHOD.
  METHOD set_delete_transactions.
    me->delete_transactions = CORRESPONDING #( transactions ).
  ENDMETHOD.
  METHOD set_update_memberships.
    me->update_memberships = CORRESPONDING #( memberships ).
  ENDMETHOD.
  METHOD set_update_transactions.
    me->update_transactions = CORRESPONDING #( transactions ).
    LOOP AT me->update_transactions ASSIGNING FIELD-SYMBOL(<upd_tran>).
      <upd_tran>-Lastchangedby = sy-uname.
      <upd_tran>-Lastchangedat = <upd_tran>-Locallastchangedat.
    ENDLOOP.
  ENDMETHOD.
ENDCLASS.
CLASS lhc_loyaltymembership DEFINITION INHERITING FROM cl_abap_behavior_handler.
  PRIVATE SECTION.
    METHODS get_instance_authorizations FOR INSTANCE AUTHORIZATION
      IMPORTING keys REQUEST requested_authorizations FOR loyaltymembership RESULT result.
    METHODS get_global_authorizations FOR GLOBAL AUTHORIZATION
      IMPORTING REQUEST requested_authorizations FOR loyaltymembership RESULT result.
    METHODS create FOR MODIFY
      IMPORTING entities FOR CREATE loyaltymembership.
    METHODS update FOR MODIFY
      IMPORTING entities FOR UPDATE loyaltymembership.
    METHODS delete FOR MODIFY
      IMPORTING keys FOR DELETE loyaltymembership.
    METHODS read FOR READ
      IMPORTING keys FOR READ loyaltymembership RESULT result.
    METHODS lock FOR LOCK
      IMPORTING keys FOR LOCK loyaltymembership.
    METHODS rba_membershiptransactions FOR READ
      IMPORTING keys_rba FOR READ loyaltymembership\_membershiptransactions FULL result_requested RESULT result LINK association_links.
    METHODS cba_membershiptransactions FOR MODIFY
      IMPORTING entities_cba FOR CREATE loyaltymembership\_membershiptransactions.
    METHODS getdefaultsforcba FOR READ
      IMPORTING keys FOR FUNCTION loyaltymembership~getdefaultsforcba RESULT result.
    METHODS precheck_create FOR PRECHECK
      IMPORTING entities FOR CREATE loyaltymembership.
ENDCLASS.
CLASS lhc_loyaltymembership IMPLEMENTATION.
  METHOD get_instance_authorizations.
  ENDMETHOD.
  METHOD get_global_authorizations.
  ENDMETHOD.
  METHOD create.
    lcl_buffer=>get_instance( )->set_create_memberships( memberships = CORRESPONDING #( entities ) ).
    mapped-loyaltymembership = CORRESPONDING #( lcl_buffer=>get_instance( )->create_memberships ).
  ENDMETHOD.
  METHOD update.
    lcl_buffer=>get_instance( )->set_update_memberships( memberships = CORRESPONDING #( entities ) ).
    mapped-loyaltymembership = CORRESPONDING #( lcl_buffer=>get_instance( )->update_memberships ).
  ENDMETHOD.

  METHOD delete.
    lcl_buffer=>get_instance( )->set_delete_memberships( memberships = CORRESPONDING #( keys ) ).
  ENDMETHOD.

  METHOD read.
    DATA lylmem_uuids TYPE RANGE OF xsduuid_raw.
    lylmem_uuids = VALUE #( FOR key IN keys
                            LET s      = 'I'
                                o      = 'EQ'
                            IN  sign   = s
                                option = o
                            ( low = key-Membershipuuid ) ).
    SELECT
     FROM zlm_r_membship_ee
     FIELDS *
     WHERE "Clnt = @SY-mandt AND
           Membershipuuid IN @lylmem_uuids
     INTO TABLE @DATA(memberships) .
    result = CORRESPONDING #( memberships MAPPING  Membershipuuid = Membershipuuid
                                                   Membershipid = Membershipid
                                                   createdat = Createdat
                                                   createdby = Createdby
                                                   lastchangedat = Lastchangedat
                                                   lastchangedby = Lastchangedby
                                                   Locallastchangedat = Locallastchangedat ).
  ENDMETHOD.

  METHOD lock.
  ENDMETHOD.

  METHOD rba_membershiptransactions.
    DATA lylmem_uuids TYPE RANGE OF xsduuid_raw.

    lylmem_uuids = VALUE #( FOR key IN keys_rba
                          LET s      = 'I'
                              o      = 'EQ'
                          IN  sign   = s
                              option = o
                          ( low = key-Membershipuuid ) ).
    SELECT
       FROM zlm_r_transctns_ee
       FIELDS *
       WHERE Membershipuuid IN @lylmem_uuids
       INTO TABLE @DATA(transactions) .
    result = CORRESPONDING #( transactions MAPPING Transactionuuid = Transactionuuid
                                                   Membershipuuid = Membershipuuid
                                                   Transactiondate = Transactiondate
                                                   Transactionvalue = Transactionvalue
                                                   Transactioncurrency = Transactioncurrency
                                                   Loyaltypoints = Loyaltypoints
                                                   createdat = Createdat
                                                   createdby = Createdby
                                                   lastchangedat = Lastchangedat
                                                   lastchangedby = Lastchangedby
                                                   Locallastchangedat = Locallastchangedat ).
  ENDMETHOD.
  METHOD cba_membershiptransactions.
    lcl_buffer=>get_instance( )->set_create_transactions( transactions = CORRESPONDING #( entities_cba MAPPING %target = %target  ) ).
    mapped-membershiptransactions = CORRESPONDING #( lcl_buffer=>get_instance( )->create_transactions ).
  ENDMETHOD.
  METHOD GetDefaultsForCBA.
    result = VALUE #( FOR key IN keys (
                        %tky = key-%tky
                        %param-Transactiondate = cl_abap_context_info=>get_system_date( )
                        %param-Transactioncurrency = 'INR'
                      ) ).
  ENDMETHOD.
  METHOD precheck_create.
    LOOP AT entities INTO DATA(ls_entity).
      "--------------------------------------------
      " Duplicate Check
      "--------------------------------------------
      SELECT SINGLE
      FROM zlm_R_membship_ee
      FIELDS Membershipid , Customer
      WHERE Customer = @LS_entity-Customer
      INTO @DATA(membership) .
      IF membership IS NOT INITIAL.
        APPEND VALUE #(
          %key = ls_entity-%key
          %msg = new_message(
                    id       = 'ZLM_MESSAGES_EE'
                    number   = '009'
                    v1       = membership-Membershipid
                    v2       = membership-Customer
                    severity = if_abap_behv_message=>severity-error )
        ) TO reported-loyaltymembership.

        APPEND VALUE #( %key = ls_entity-%key ) TO failed-loyaltymembership.

        CONTINUE.
      ENDIF.
      CLEAR membership.
    ENDLOOP.
  ENDMETHOD.
ENDCLASS.
CLASS lhc_membershiptransactions DEFINITION INHERITING FROM cl_abap_behavior_handler.
  PRIVATE SECTION.
    METHODS update FOR MODIFY
      IMPORTING entities FOR UPDATE membershiptransactions.
    METHODS delete FOR MODIFY
      IMPORTING keys FOR DELETE membershiptransactions.
    METHODS read FOR READ
      IMPORTING keys FOR READ membershiptransactions RESULT result.
    METHODS rba_loyaltymembership FOR READ
      IMPORTING keys_rba FOR READ membershiptransactions\_loyaltymembership FULL result_requested RESULT result LINK association_links.
    METHODS calculateloyaltypoints FOR DETERMINE ON MODIFY
      IMPORTING keys FOR membershiptransactions~calculateloyaltypoints.
ENDCLASS.

CLASS lhc_membershiptransactions IMPLEMENTATION.
  METHOD update.
    lcl_buffer=>get_instance( )->set_update_transactions( transactions = CORRESPONDING #( entities ) ).
    mapped-membershiptransactions = CORRESPONDING #( lcl_buffer=>get_instance( )->update_transactions ).
  ENDMETHOD.
  METHOD delete.
    lcl_buffer=>get_instance( )->set_delete_transactions( transactions = CORRESPONDING #( keys ) ).
  ENDMETHOD.
  METHOD read.
  ENDMETHOD.
  METHOD rba_loyaltymembership.
  ENDMETHOD.

  METHOD CalculateLoyaltyPoints.
    " Calculates loyalty points for a transaction based on its value, then updates the Loyaltypoints field in MembershipTransactions.
    DATA updateTransactions TYPE TABLE FOR UPDATE zlm_r_transctns_ee.
    " Read all relevant transaction instances.
    READ ENTITIES OF zlm_r_membship_ee IN LOCAL MODE
         ENTITY MembershipTransactions
         FIELDS ( Transactionuuid Membershipuuid Transactionvalue Loyaltypoints  )
         WITH CORRESPONDING #( keys )
      RESULT DATA(lylpointstransactions)
      FAILED DATA(failed).
    IF lylpointstransactions IS NOT INITIAL.
      lylpointstransactions[ 1 ]-Loyaltypoints =   lylpointstransactions[ 1 ]-Transactionvalue * '0.10' .
      updateTransactions  =  CORRESPONDING #( lylpointstransactions ).
      MODIFY ENTITIES OF zlm_r_membship_ee IN LOCAL MODE
                ENTITY MembershipTransactions
                UPDATE FIELDS ( Loyaltypoints )
                WITH updateTransactions
              MAPPED   DATA(updated_transactions)
              FAILED   DATA(update_failed)
              REPORTED  DATA(update_reported).
      IF reported IS NOT INITIAL OR update_failed IS NOT INITIAL.
*Fill reported
        reported = CORRESPONDING #( DEEP update_reported ).
*Set failed keys
        APPEND VALUE #(  %tky = lylpointstransactions[ 1 ]-%tky )
                      TO update_failed-membershiptransactions.
      ENDIF.
    ENDIF.
  ENDMETHOD.
ENDCLASS.
CLASS lsc_zlm_r_membship_ee DEFINITION INHERITING FROM cl_abap_behavior_saver.
  PROTECTED SECTION.
    METHODS finalize REDEFINITION.
    METHODS check_before_save REDEFINITION.
    METHODS save REDEFINITION.
    METHODS cleanup REDEFINITION.
    METHODS cleanup_finalize REDEFINITION.
ENDCLASS.
CLASS lsc_zlm_r_membship_ee IMPLEMENTATION.
  METHOD finalize.
  ENDMETHOD.
  METHOD check_before_save.
  ENDMETHOD.
  METHOD save.
    DATA(create_memberships) = lcl_buffer=>get_instance( )->create_memberships.
    DATA(create_transactions) = lcl_buffer=>get_instance( )->create_transactions.
    DATA(update_memberships) = lcl_buffer=>get_instance( )->update_memberships.
    DATA(update_transactions) = lcl_buffer=>get_instance( )->update_transactions.
    DATA(delete_memberships) = lcl_buffer=>get_instance( )->delete_memberships.
    DATA(delete_transactions) = lcl_buffer=>get_instance( )->delete_transactions.

    IF create_memberships IS INITIAL
    AND create_transactions IS INITIAL
    AND update_memberships IS INITIAL
    AND update_transactions IS INITIAL
    AND delete_memberships IS INITIAL
    AND delete_transactions IS INITIAL.
      RETURN.
    ENDIF.
    TRY.

        FINAL(ext_con) = cl_abap_sql_connection_builder=>write_enabled_4_logical_schema(
          i_connection_name     = 'R/3*SERVICE'
          i_logical_schema_name = 'ZLM_EXT_SCHEMA_EE' )->create( ).

        IF create_memberships  IS NOT INITIAL.
          " Request sequential numbers from Number Range Object
          TRY.
              cl_numberrange_runtime=>number_get( EXPORTING nr_range_nr       = zlm_if_constants_ee=>nr_range_nr
                                                            object            = zlm_if_constants_ee=>nr_obj_value
                                                            quantity          = CONV #( lines( create_memberships ) )
                                                  IMPORTING number            = DATA(number_range_key) ).
            CATCH cx_number_ranges INTO DATA(nr_allocation_failed).
              INSERT VALUE #( %msg = new_message_with_text( severity = if_abap_behv_message=>severity-error
                                                              text     = nr_allocation_failed->get_text( ) ) )
                     INTO TABLE reported-loyaltymembership.
              EXIT.
          ENDTRY.
          INSERT zlm_membship_cud_ee PROVIDED BY zlm_ext_schema_ee CONNECTION @ext_con
             FROM TABLE  @( VALUE #( FOR memb IN create_memberships
                                     (
                                     client                = sy-mandt
                                     membershipuuid        = memb-membershipuuid
                                     membershipid          = number_range_key "memb-membershipid
                                     customer              = memb-customer
                                     createdby            = memb-createdby
                                     createdat            = memb-createdat
                                     lastchangedby       = memb-lastchangedby
                                     lastchangedat       = memb-lastchangedat
                                     locallastchangedat = memb-locallastchangedat
                                   ) ) ).
          IF sy-subrc = 0.
            reported-loyaltymembership = CORRESPONDING #( create_memberships ).
            LOOP AT reported-loyaltymembership ASSIGNING FIELD-SYMBOL(<mem>).
              DATA(membershipuuid) = <mem>-membershipuuid .
              <mem>-%msg = NEW zcx_lm_messages_ee(
                textid     = zcx_lm_messages_ee=>extdb_mcrt_success
                severity   = if_abap_behv_message=>severity-success
                membershipid = CONV #( number_range_key ) )."create_memberships[ KEY entity COMPONENTS Membershipuuid = <mem>-membershipuuid ]-Membershipid ).
            ENDLOOP.
          ELSE.
            reported-%other = VALUE #( ( NEW zcx_lm_messages_ee(
                                       textid   = zcx_lm_messages_ee=>extdb_cud_failure
                                       severity = if_abap_behv_message=>severity-error ) ) ).
            RAISE EXCEPTION TYPE zcx_lm_messages_ee.
          ENDIF.

        ENDIF.
        IF update_memberships  IS NOT INITIAL.
          UPDATE zlm_membship_cud_ee PROVIDED BY zlm_ext_schema_ee CONNECTION @ext_con
             FROM TABLE  @( VALUE #( FOR memb_upd IN update_memberships
                                     (
                                     lastchangedby       = memb_upd-lastchangedby
                                     lastchangedat       = memb_upd-lastchangedat
                                     locallastchangedat = memb_upd-locallastchangedat
                                   ) ) ).


          IF sy-subrc = 0.
            reported-loyaltymembership = CORRESPONDING #( update_memberships ).
            LOOP AT reported-loyaltymembership ASSIGNING FIELD-SYMBOL(<mem_upd>).
              membershipuuid = <mem_upd>-membershipuuid.
              <mem_upd>-%msg = NEW zcx_lm_messages_ee(
                textid     = zcx_lm_messages_ee=>extdb_mupd_success
                severity   = if_abap_behv_message=>severity-success
                membershipid = update_memberships[  KEY entity membershipuuid = <mem_upd>-membershipuuid ]-membershipid ).
            ENDLOOP.
          ELSE.
            reported-%other = VALUE #( ( NEW zcx_lm_messages_ee(
                                       textid   = zcx_lm_messages_ee=>extdb_cud_failure
                                       severity = if_abap_behv_message=>severity-error ) ) ).
            RAISE EXCEPTION TYPE zcx_lm_messages_ee.            .
          ENDIF.
        ENDIF.


        IF delete_memberships  IS NOT INITIAL.

          DELETE zlm_membship_cud_ee PROVIDED BY zlm_ext_schema_ee CONNECTION @ext_con
             FROM TABLE  @( VALUE #( FOR memb_del IN delete_memberships
                                     (
                                     client = sy-mandt
                                     membershipuuid        = memb_del-membershipuuid
                                   )  ) ).
          IF sy-subrc = 0.
            reported-loyaltymembership = CORRESPONDING #( delete_memberships ).
            LOOP AT reported-loyaltymembership ASSIGNING FIELD-SYMBOL(<mem_del>).
              <mem_del>-%msg = NEW zcx_lm_messages_ee(
                textid   = zcx_lm_messages_ee=>extdb_mdel_success
                severity = if_abap_behv_message=>severity-success ).
            ENDLOOP.
          ELSE.
            reported-%other = VALUE #( ( NEW zcx_lm_messages_ee(
                                       textid   = zcx_lm_messages_ee=>extdb_cud_failure
                                       severity = if_abap_behv_message=>severity-error ) ) ).
            RAISE EXCEPTION TYPE zcx_lm_messages_ee.
          ENDIF.

        ENDIF.
        IF create_transactions  IS NOT INITIAL.
          INSERT zlm_transctns_cud_ee PROVIDED BY zlm_ext_schema_ee CONNECTION @ext_con
             FROM TABLE  @( VALUE #( FOR txns IN create_transactions
                                     FOR txn IN txns-%target
                                     (
                                      client          = sy-mandt
                                      transactionuuid = txn-transactionuuid
                                      membershipuuid =  txn-membershipuuid
                                      transactiondate = txn-transactiondate
                                      transactionvalue = txn-transactionvalue
                                      transactioncurrency = txn-transactioncurrency
                                      loyaltypoints = txn-loyaltypoints
                                      createdby = txn-createdby
                                      createdat = txn-createdat
                                      lastchangedby = txn-lastchangedby
                                      locallastchangedat = txn-locallastchangedat
                                      lastchangedat = txn-lastchangedat
                                ) ) ).

          IF sy-subrc = 0.
            LOOP AT create_transactions ASSIGNING FIELD-SYMBOL(<txns>).
              LOOP AT <txns>-%target ASSIGNING FIELD-SYMBOL(<txn>).
                membershipuuid = <txn>-membershipuuid.
                reported-membershiptransactions = VALUE #( BASE reported-membershiptransactions
                                                        (

                                                     Transactionuuid = <txn>-Transactionuuid
                                                      %msg       = NEW zcx_lm_messages_ee(
                                                      textid     = zcx_lm_messages_ee=>extdb_tcrt_success
                                                      severity   = if_abap_behv_message=>severity-success
                                                      loyaltypoints = <txn>-Loyaltypoints

                                                      ) ) ).
              ENDLOOP.
            ENDLOOP.

          ELSE.
            reported-%other = VALUE #( ( NEW zcx_lm_messages_ee(
                                       textid   = zcx_lm_messages_ee=>extdb_cud_failure
                                       severity = if_abap_behv_message=>severity-error ) ) ).
            RAISE EXCEPTION TYPE zcx_lm_messages_ee.
          ENDIF.
        ENDIF.

        IF update_transactions  IS NOT INITIAL.
          UPDATE zlm_transctns_cud_ee PROVIDED BY zlm_ext_schema_ee CONNECTION @ext_con
             FROM TABLE  @( VALUE #( FOR txns_upd IN update_transactions
                                   (
                                      client          = sy-mandt
                                      transactionuuid = txns_upd-transactionuuid
                                      membershipuuid =  txns_upd-membershipuuid
                                      transactiondate = txns_upd-transactiondate
                                      transactionvalue = txns_upd-transactionvalue
                                      transactioncurrency = txns_upd-transactioncurrency
                                      loyaltypoints = txns_upd-loyaltypoints
                                      createdby = txns_upd-createdby
                                      createdat = txns_upd-createdat
                                      lastchangedby = txns_upd-lastchangedby
                                      locallastchangedat = txns_upd-locallastchangedat
                                      lastchangedat = txns_upd-lastchangedat
                                   ) ) ).

          IF sy-subrc = 0.

            LOOP AT update_transactions ASSIGNING FIELD-SYMBOL(<txn_upd>).
              reported-membershiptransactions = VALUE #( BASE reported-membershiptransactions
                                                      (
                                                      Transactionuuid = <txn_upd>-Transactionuuid
                                                      %msg       = NEW zcx_lm_messages_ee(
                                                      textid     = zcx_lm_messages_ee=>extdb_tupd_success
                                                      severity   = if_abap_behv_message=>severity-success
                                                      loyaltypoints = <txn_upd>-Loyaltypoints
                                                       ) ) ).
            ENDLOOP.
          ELSE.
            reported-%other = VALUE #( ( NEW zcx_lm_messages_ee(
                                       textid   = zcx_lm_messages_ee=>extdb_cud_failure
                                       severity = if_abap_behv_message=>severity-error ) ) ).
            RAISE EXCEPTION TYPE zcx_lm_messages_ee.
          ENDIF.
        ENDIF.
        IF delete_transactions  IS NOT INITIAL.
          DELETE zlm_transctns_cud_ee PROVIDED BY zlm_ext_schema_ee CONNECTION @ext_con
             FROM TABLE   @( VALUE #( FOR trans_del IN delete_transactions
                                     (
                                     client = sy-mandt
                                     transactionuuid = trans_del-transactionuuid
                                   )  ) ).
          IF sy-subrc = 0.
            LOOP AT delete_transactions ASSIGNING FIELD-SYMBOL(<txn_del>).
              reported-membershiptransactions = VALUE #( BASE reported-membershiptransactions
                                                      ( Transactionuuid = <txn_del>-Transactionuuid
                                                        %msg       = NEW zcx_lm_messages_ee(
                                                        textid   = zcx_lm_messages_ee=>extdb_tdel_success
                                                        severity = if_abap_behv_message=>severity-success
                                                    ) ) ).
            ENDLOOP.
          ELSE.
            reported-%other = VALUE #( ( NEW zcx_lm_messages_ee(
                                       textid   = zcx_lm_messages_ee=>extdb_cud_failure
                                       severity = if_abap_behv_message=>severity-error ) ) ).
            RAISE EXCEPTION TYPE zcx_lm_messages_ee.
          ENDIF.
        ENDIF.
        COMMIT CONNECTION @ext_con.
        ext_con->close( ).
      CATCH cx_root INTO FINAL(exc).
        APPEND VALUE #(
                %msg = new_message_with_text(
                         severity = if_abap_behv_message=>severity-error
                         text     = exc->get_text( ) ) )
                TO reported-loyaltymembership.
    ENDTRY.
    READ ENTITIES OF zlm_r_membship_ee IN LOCAL MODE ENTITY LoyaltyMembership
    ALL FIELDS
    WITH VALUE #( ( membershipuuid = membershipuuid ) )
    RESULT DATA(loyaltymembership).
  ENDMETHOD.
  METHOD cleanup.
  ENDMETHOD.
  METHOD cleanup_finalize.
  ENDMETHOD.
ENDCLASS.

Projection Layer

Create projection views for UI consumption

Purpose:

- Simplify backend data model

- Expose only required fields

We now create the corresponding consumption view zlm_c_membship_ee .

@Metadata.allowExtensions: true
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Projection View'
define root view entity zlm_c_membship_ee
  provider contract transactional_query
  as projection on zlm_r_membship_ee

{
  key Membershipuuid,
      Membershipid,
      Customer,
      _BusinessPartner.BusinessPartnerName as CustomerName,
      _Loyaltypoints.total                 as Loyaltypoints,
      Createdby,
      Createdat,
      Lastchangedby,
      Locallastchangedat,
      Lastchangedat,
      /* Associations */
      _MembershipTransactions : redirected to composition child zlm_c_transctns_ee
}

Save the cds entity zlm_c_membship_ee and don’t activate.

Create consumption view zlm_c_transctns_ee.

@Metadata.allowExtensions: true
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Projection View'
define view entity zlm_c_transctns_ee
  as projection on zlm_r_transctns_ee
{
  key Transactionuuid,
      Membershipuuid,
      Transactiondate,
      @Semantics.amount.currencyCode : 'Transactioncurrency'
      Transactionvalue,
      @Consumption.valueHelpDefinition: [{
      entity: {
         name: 'I_Currency',
         element: 'Currency'
      },
      useForValidation: true
      }]
      Transactioncurrency,
      Loyaltypoints,
      Createdby,
      Createdat,
      Lastchangedby,
      Locallastchangedat,
      Lastchangedat,
      /* Associations */
      _LoyaltyMembership : redirected to parent zlm_c_membship_ee // Make association public
}

Save and activate both the entities using “Activate inactive ABAP development objects”.

We now create behaviour projection zlm_c_membship_ee .

projection;
strict ( 2 );
use draft;
use side effects;

define behavior for zlm_c_membship_ee alias LoyaltyMembership
{
  use create;
  use update;
  use delete;

  field ( readonly ) Membershipuuid,Membershipid;
  field (readonly:update) Customer;
  use action Activate;
  use action Discard;
  use action Edit ;
  use action Resume;
  use action Prepare;

  //use association _MembershipTransactions { create; with draft;}
  use association _MembershipTransactions { create ; with draft; }
  use function GetDefaultsForCBA;

}

define behavior for zlm_c_transctns_ee alias MembershipTransactions
{
  use update;
  use delete;
  field ( readonly ) Loyaltypoints;
  use association _LoyaltyMembership { with draft;}
}

UI Annotations

Add annotations:
- @ui.lineItem → table columns
- @ui.identification → object page fields
- @Consumption.valueHelp → dropdown values

These control Fiori UI behavior.
Create Metadata extension for zlm_c_membship_ee .

@Metadata.layer: #CORE
@Search.searchable: true
@UI: {
  headerInfo: {
                typeName: 'Loyalty Management',
                typeNamePlural: 'Loyalty Management ',
                title: { type: #STANDARD, label: 'Loyalty Management', value: 'Membershipid' }},
  presentationVariant: [{ sortOrder: [{ by: 'Membershipid', direction:  #ASC }] }] }
annotate view zlm_c_membship_ee with
{

  @ui.facet: [
      {
        id: 'LoyaltyMembership',
        purpose: #STANDARD,
        label: 'Membership Details',
        type: #IDENTIFICATION_REFERENCE,
        position: 10
      },
     {
        id: 'Transactions',
        label: 'Transactions',
        type: #LINEITEM_REFERENCE,
        position: 20,
        targetElement: '_MembershipTransactions'
     }]

  @ui.hidden: true
  Membershipuuid;
  @ui: {  identification  : [ { position: 10, label: 'Membership ID' } ],
          lineItem        : [ { position: 10, label: 'Membership ID' }]
       }
  Membershipid;


  @ui: {  identification  : [ { position: 20, label: 'Customer ID' } ],
        lineItem        : [ { position: 20, label: 'Customer ID' } ] }
  @Consumption.valueHelpDefinition: [{  entity: {   name: 'zlm_i_businesspartner_vh' ,
                                                         element: 'BusinessPartner'  }     }]
  Customer;
  @ui: {  identification  : [ { position: 30, label: 'Customer Name' } ],
        lineItem        : [ { position: 30, label: 'Customer Name' } ],
        selectionField : [ { position: 30 } ]
     }
  @search.defaultSearchElement: true

  CustomerName;

  @ui: {  identification  : [ { position: 40, label: 'Loyalty Points' } ],
       lineItem        : [ { position: 40, label: 'Loyalty Points' } ],
       selectionField : [ { position: 40 } ]
    }
  Loyaltypoints;

  @ui.hidden: true
  Createdby;

  @ui.hidden: true
  Createdat;

  @ui.hidden: true
  Lastchangedby;

  @ui.hidden: true
  Locallastchangedat;

  @ui.hidden: true
  Lastchangedat;

}

Metadata extension for zlm_c_transctns_ee.

@Metadata.layer: #CORE
@UI: {
  headerInfo: { typeName: 'Loyalty Membership Transaction',
                typeNamePlural: 'Loyalty Membership Transactions',
                title: { type: #STANDARD, label: 'Loyalty Membership Transactions', value: 'Transactiondate' } } }
annotate entity zlm_c_transctns_ee with
{
  @ui.facet: [
     {
      id: 'Transactions',
      purpose: #STANDARD,
      label: 'Transactions',
      type: #IDENTIFICATION_REFERENCE
     }
   ]

  @ui.hidden: true
  Transactionuuid;
  @ui.hidden: true
  Membershipuuid;
  @ui.identification: [ {
    position: 10 ,
    label: 'Transaction date'
  } ]
  @ui.lineItem: [ {
    position: 10 ,
    label: 'Transaction date'
  } ]
  @ui.selectionField: [ {
    position: 10
  } ]
  Transactiondate;
  @ui.identification: [ {
      position: 20 ,
      label: 'Transaction value'
    } ]
  @ui.lineItem: [ {
    position: 20 ,
    label: 'Transaction value'
  } ]
  @ui.selectionField: [ {
    position: 20
  } ]
  Transactionvalue;
  @ui.identification: [ {
    position: 30 ,
    label: 'Loyalty points'
  } ]
  @ui.lineItem: [ {
    position: 30 ,
    label: 'Loyalty points'
  } ]
  @ui.selectionField: [ {
    position: 30
  } ]
  Loyaltypoints;
  @ui.hidden: true
  Createdby;
  @ui.hidden: true
  Createdat;
  @ui.hidden: true
  Lastchangedby;
  @ui.hidden: true
  Locallastchangedat;
  @ui.hidden: true
  Lastchangedat;
}

Service Definition & Binding

Create OData V4 service:
- Expose projection views
- Create service binding
- Publish service

This enables UI consumption.

Create service definition and service binding.

@EndUserText.label: 'OData V4 UI loyalty membership'
define service ZLY_UI_MEMBERSHIP_EE_O4 {
  expose zlm_c_membship_ee  as LoyaltyMembership;
  expose zlm_c_transctns_ee as MembershipTransactions;
}

Testing

Open binding
Launch Fiori app
Create membership
Add transaction
Verify loyalty points calculation
Check that data is saved in external HANA database.

End-to-End Flow

User enters data in UI
RAP behavior triggers
Data stored temporarily in buffer
Save method writes to external DB
Commit completes transaction
UI displays updated data

Key Takeaways.

RAP model separates data, behavior, and UI
Logical schema handles secure connectivity
Business logic is implemented in ABAP classes
No data replication required

Further info

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

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

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

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

We will cover the below points:

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

1 Architecture Overview

Architecture

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

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

The Solution Architecture displays 3 different options:

(1) Use Direct API Integration

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

(2) Integration Suite

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

(3) CAP Application

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

2 Prerequisites

You need

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

3 Creating Communication Artifacts in ABAP Cloud

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

Communication Arrangement

Communication System

Communication System 1

Communication/Connection User:

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

4 ABAP Cloud Artifacts

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

For sure, you will create:

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

An example of an action definition processData (ZI_DEMO_SERVICE):

managed implementation in class zbp_i_demo_service unique;

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

  create;
  update;
  delete;

  action processData result [1] zdemoservice;

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

An example of an ABAP Class with an action implementation:

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

Service Definition:

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

Inbound Service:

Communication Scenario:

5 Create a Connection

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

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

6 Creating a Task Chain in SAP Datasphere

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

In the given example:

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

Task Chain

In the API Task details, define the following:

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

API Task Details 1

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

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

7 Execution Results

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

Task Chain API successfully executed

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

8 Solution Options - Comparisons

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

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

9 Conclusion/Outlook & Further aspects:

Overview of the major building blocks:

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

Use Cases that the implementation enables:

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

Limitations:

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

References:

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

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

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

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

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

Introduction

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

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

Business Requirement

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

The application should:

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

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

Problem Statement

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

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

What is RAP Augmentation?

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

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

Augmentation Flow

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

The overall execution flow is:

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

Augmentation vs Determination

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

When Execution timing matter?

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

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

When to Use Augmentation?

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

Typical use cases include:

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

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

BDEF of Interface

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

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

lock master

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

BDEF of Projection

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

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

BP of Projection

CLASS lhc_zaky_c_emp DEFINITION INHERITING FROM cl_abap_behavior_handler.
  PRIVATE SECTION.

    METHODS augment_create FOR MODIFY
      IMPORTING entities FOR CREATE zaky_c_emp.

    METHODS augment_update FOR MODIFY
      IMPORTING entities FOR UPDATE zaky_c_emp.

ENDCLASS.

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

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

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

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

  ENDLOOP.
ENDMETHOD.

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

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

  ENDLOOP.
ENDMETHOD.
ENDCLASS.

BP of interface

METHOD Approve.

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

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

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

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

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

  ENDLOOP.
ENDMETHOD.

Output

Click on the create

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

Execute

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

After clicking on action

If you not adding the department

Conclusion

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

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

ABAP development tools for Visual Studio Code: Version 1.1 released

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

What happened since the last release?

Link to the extension.

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

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

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

What gets shipped with this release?

Usability improvements for system connection handling

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

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

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

A significant improvement of object type support

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

Classic ABAP source code

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

Data Dictionary

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

RESTful Application Programming Model

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

New MCP tools

Unified diff tool for transports

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

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

Tools for ABAP Test Cockpit (ATC)

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

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

Additional UX improvements

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

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

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

Sidenote: first version of ABAP cleaner VS Code extension available

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

What's next?

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

Provide feedback and influence our product backlog!

How to run different versions of the ABAP development tools for Visual Studio Code in parallel?

2026-07-24T20:16:18.829000+02:00

Introduction

Having now released a second version of the ABAP development tools for Visual Studio Code the question may arise how to run different versions of this plugin in parallel in order to test the latest version or to check differences in the behavior of the new and an older version.

At least SAP internally this is a question that is of interest for me since I want to run the public available version and the next upcoming version before this is going to be released officially 😉.

For the ABAP Development Tools for Eclipse you have to install a second Eclipse so that you can test a second version there.

How to section

Co-Pilot will provide various options to this question from which I chose the IMHO most easiest one, namely to create different profiles and install a different extension version in each profile.

You can either click on the gear icon and select Profiles.

Or you can open Command Palette (Ctrl+Shift+P) and then enter Profiles and select Profiles: New Profile.

This will open the following dialogue where you can select the default profile from the drop down box.

This let you swith to the newly created profile.

Using the drop down arrow of the "uninstall" button you are offered to install a specific version of the selected extension in the copied profile.

Here you are able to select an older version

As a result you can activate this older version by restarting the extension.

Please note that the Auto Update option has been deactivated conveniently.

SAP Community - ABAP RESTful Application Programming Model

Implementing RAP Action Parameter Value Help Using CDS Abstract Entity in SAP RAP

Introduction

What are RAP Action Parameters?

Real-Time Business Scenario: Mass Category Assignment

The Problem

The Solution

Implementation Using RAP Action Parameter Value Help

Step 1: Create Category Master Table

Step 2: Create Product Table

Step 3: Create Value Help CDS View

Step 4: Create Root Interface View

Step 5: Create Projection View

Step 6: Create Abstract Entity for Action Parameters

Step 7: Create Interface Behavior Definition

Step 8: Implement Action Logic

Step 9: Create Projection Behavior Definition

Step 10: Create Metadata Extension

Step 11: Create Service Definition

Step 12: Create Service Binding

Result

1. Select Products

2. Click Set Category

3. Action Dialog Opens

4. Open Value Help

5. Choose a Category

6. Confirm

7. RAP Action Executes

8. List Refreshes

Conclusion

Using Domain Fixed Values as Value Help in SAP RAP Fiori Elements

Introduction

Step 3: Attach the Value Help to the Main CDS View

Value Help Configuration in RAP

@Consumption.valueHelpDefinition

ZI_BP_STATUS_VH

element: 'StatusCode'

@ObjectModel.text.element

Step 4: Expose the CDS View in Service Definition

Output

Conclusion

Simple RAP managed app with Abstract entity popup.

Etag(Entity Tag) in RAP

ABAP development tools for Visual Studio Code: Patch 1.0.1 released

What happened since the first release?

What gets shipped with this release?

RFC System logon via password

AGENTS.md template

What's next?

Provide feedback and influence our product backlog!

Unmanaged RAP application for Excel File Upload and CDS Custom Entity with Unmanaged Query Implement

Intro

Use-case

Data Model

Implementation of Excel Upload

Service Binding

Fiori UI Preview

Final words

Building an Inventory System with RAP on BTP Trial — CDS Views Explained

Introduction

The System at a Glance

The Two-Layer Architecture

Composition: Stock Document Header and Item

Associations: Two Aliases, One Target View

Semantic Annotations: Free Administrative Data

Projection Views: What Most Tutorials Skip

Value Help Annotations

Running This on BTP Trial

On‑the‑Fly Excel Download in a RAP Fiori App — No Database Table, No Persistence, Pure CDS + ABAP

TL;DR

1. The problem

2. The pattern in one picture

3. The CDS Custom Entity

What each piece does

4. The query provider class — skeleton

IF_RAP_QUERY_PROVIDER~SELECT — the dispatcher

5. Technique A — Hand‑build a multi‑sheet XLSX with cl_abap_zip

5.1 The minimum parts you need

5.2 Build the package skeleton

5.3 [Content_Types].xml — the MIME map

`@Consumption.valueHelpDefinition`

`ZI_BP_STATUS_VH`

`element: 'StatusCode'`

`@ObjectModel.text.element`

`IF_RAP_QUERY_PROVIDER~SELECT` — the dispatcher

5. Technique A — Hand‑build a multi‑sheet XLSX with `cl_abap_zip`

5.3 `[Content_Types].xml` — the MIME map

5.5 `workbook.xml` — wire up four sheets

6. Technique B — Single‑sheet XLSX via `cl_salv_table` (the easy route)

How Does It Differ from `@ui.hidden` and `@Consumption.hidden`?