SAP Community - ABAP RESTful Application Programming Model

Deep Insert Payload into a Single table in RAP ABAP

2025-12-24T06:55:42.141000+01:00

This document demonstrates how to design and implement a RAP-based create scenario with a nested payload using the RESTful ABAP Programming Model (RAP). The example focuses on inserting data into a single custom database table using a root entity with a composition child, allowing a structured payload that includes both product and inventory-related information. The solution covers the full RAP flow: creating the database table, defining Interface Views and Projection Views with compositions, implementing managed behavior with an unmanaged save, handling the payload in the behavior saver class, and finally exposing the data through a service definition and service binding. The scenario is validated by consuming the OData service with a JSON payload that creates the record successfully.

Payload to be passed to insert the record

{ 
        "ProductId" : "00000000-0000-0000-0000-000000000987", 
        "Name" : "Kumar111", 
        "to_InventoryReceipt" : 
                         {       
                              "Category" : "Transport", 
                                "Price" : 200, 
                                  "Currency" : "USD" 
                          }, 
        "Discount" : 30
}

Here all the fields' data are from the same table.

1. Create your table in which your payload is to be inserted.

2. Create Interface Views as given below.

@AccessControl.authorizationCheck: #NOT_REQUIRED 
@EndUserText.label: 'product root view' 
@Metadata.ignorePropagatedAnnotations: true 
define root view entity ZI_vbProduct_tmp_vw 
  as select from zvb_product_tmp as product 
composition [0..1] of ZI_InventoryReceipt_IFD_SEG as _InventoryReceipt 
{ 
  key product.product_id      as ProductId, 
      product.name           as Name, 
      product.discount       as Discount, 
      product.createdby      as CreatedBy, 
      _InventoryReceipt 
}

@AbapCatalog.viewEnhancementCategory: [#NONE]  
@AccessControl.authorizationCheck: #NOT_REQUIRED  
@EndUserText.label: 'ZI_InventoryReceipt_IFD_SEG' 
@Metadata.ignorePropagatedAnnotations: true 
@ObjectModel.usageType:{  
serviceQuality: #X,  
sizeCategory: #S,  
dataClass: #MIXED  
}  
define view entity ZI_InventoryReceipt_IFD_SEG 
  as select from zvb_product_tmp  
  association to parent ZI_vbProduct_tmp_vw as _Product 
    on $projection.ProductId = _Product.ProductId 
{ 
  key product_id   as ProductId, 
      category    as Category, 
      price       as Price, 
      currency    as Currency, 
       _Product 
}

Projection Views

Create the projection views for the Interface Views.

@AccessControl.authorizationCheck: #NOT_REQUIRED 
@EndUserText.label: 'product projection view' 
@Metadata.ignorePropagatedAnnotations: true 
define root view entity ZP_Product as projection on ZI_vbProduct_tmp_vw 
{ 
@UI.facet: [{  
purpose: #STANDARD,  
position: 10,  
label: 'Product',  
type: #IDENTIFICATION_REFERENCE  
},  
{  
purpose: #STANDARD,  
position: 20,  
label: 'Inventory',  
type: #LINEITEM_REFERENCE,  
targetElement: '_InventoryReceipt'  
}]  
@UI.lineItem: [{ position: 10, label: 'ProductId' }]  
@UI.identification: [{ position: 10, label: 'ProductId' }]  
    key ProductId, 
    .lineItem: [{ position: 20, label: 'Name' }]  
@UI.identification: [{ position: 20, label: 'Name' }]  
    Name, 
    .lineItem: [{ position: 30, label: 'Discount' }]  
@UI.identification: [{ position: 30, label: 'Discount' }]  
    Discount, 
    .lineItem: [{ position: 40, label: 'CreatedBy' }]  
@UI.identification: [{ position: 40, label: 'CreatedBy' }]  
    CreatedBy, 
    /* Associations */ 
    _InventoryReceipt : redirected to composition child ZP_inventory 
}

@AccessControl.authorizationCheck: #NOT_REQUIRED 
@EndUserText.label: 'ZP_inventory' 
@Metadata.ignorePropagatedAnnotations: true 
define view entity ZP_inventory as projection on ZI_InventoryReceipt_IFD_SEG 
{ 
@UI.facet: [{  
purpose: #STANDARD,  
position: 10,  
label: 'Inventory',  
type: #IDENTIFICATION_REFERENCE  
}]  
@UI.lineItem: [{ position: 50, label: 'ProductId' }]  
@UI.identification: [{ position: 50, label: 'ProductId' }]  
    key ProductId, 
    .lineItem: [{ position: 60, label: 'Category' }]  
@UI.identification: [{ position: 60, label: 'Category' }]  
    Category, 
    .lineItem: [{ position: 70, label: 'Price' }]  
@UI.identification: [{ position: 70, label: 'Price' }]  
    Price, 
    .lineItem: [{ position: 80, label: 'Currency' }]  
@UI.identification: [{ position: 80, label: 'Currency' }]  
    Currency, 
    /* Associations */ 
    _Product   : redirected to parent ZP_Product 
}

Create Behaviour definition on Interface View.

Behaviour Definition for projection views

managed with unmanaged save implementation in class zbp_i_vbproduct_tmp_vw unique; 
strict ( 2 ); 
define behavior for ZI_VBPRODUCT_tmp_VW alias product_tmp 
//late numbering 
lock master 
authorization master ( instance ) 
//etag master <field_name> 
//early numbering 
{ 
  create; 
  update; 
  delete; 
  association _InventoryReceipt { create ; } 
}
define behavior for ZI_INVENTORYRECEIPT_IFD_SEG 
lock dependent by _Product 
//early numbering 
authorization dependent by _Product 
{ 
  association  _Product; 
  update; 
  delete; 
  field ( readonly ) productid; 
}

projection; 
strict ( 2 ); 
define behavior for ZP_Product alias Product 
{ 
  use create; 
  use update; 
  use delete; 
  use association _InventoryReceipt { create; } 
} 
define behavior for ZP_inventory alias Inventory 
{ 
  use update; 
  use delete; 
  use association _Product; 
}

Behaviour Implementation

CLASS lhc_product_tmp DEFINITION INHERITING FROM cl_abap_behavior_handler. 

  PRIVATE SECTION. 
    METHODS get_instance_authorizations FOR INSTANCE AUTHORIZATION 
      IMPORTING keys REQUEST requested_authorizations FOR product_tmp RESULT result. 

*          METHODS earlynumbering_create FOR NUMBERING 
*      IMPORTING entities FOR CREATE ZI_VBPRODUCT_tmp_VW. 

ENDCLASS. 

CLASS lhc_product_tmp IMPLEMENTATION. 
  METHOD get_instance_authorizations. 
  ENDMETHOD. 

*  METHOD earlynumbering_create. 
*  endmethod. 

ENDCLASS. 

CLASS lsc_ZI_VBPRODUCT_TMP_VW DEFINITION INHERITING FROM cl_abap_behavior_saver. 

  PROTECTED SECTION. 

    METHODS save_modified REDEFINITION. 
     METHODS cleanup_finalize REDEFINITION. 
ENDCLASS. 

CLASS lsc_ZI_VBPRODUCT_TMP_VW IMPLEMENTATION. 
  METHOD save_modified. 

*  create-product_tmp 

data: lt_product_tmp type table for change zi_vbproduct_tmp_vw\\product_tmp. 

data: lt_zi_inventoryreceipt_ifd_seg type table for change zi_inventoryreceipt_ifd_seg. 

data: lt_final type table of zvb_product. 
MOVE-CORRESPONDING create-product_tmp to lt_product_tmp. 
MOVE-CORRESPONDING create-zi_inventoryreceipt_ifd_seg to lt_zi_inventoryreceipt_ifd_seg. 
LOOP AT lt_product_tmp into data(ls_product). 
read TABLE lt_zi_inventoryreceipt_ifd_seg into data(ls_invent) index 1. 
append value #( product_id = cl_system_uuid=>create_uuid_x16_static( ) 
                name = ls_product-Name 
                Discount = ls_product-Discount 
                Category = ls_invent-Category 
                currency = ls_invent-Currency 
                price = ls_invent-Price ) to lt_final. 
endloop. 

modify zvb_product from TABLE lt_final. 
  ENDMETHOD. 
  METHOD cleanup_finalize. 
  ENDMETHOD. 
ENDCLASS.

Service Definition

@EndUserText.label: 'SD FOR PRODUCT' 
define service ZSD_PRODUCT_TMP { 
  expose ZP_Product; 
  expose ZP_inventory; 
}

Service Binding

Payload to be passed to insert the record

{ 
        "ProductId" : "00000000-0000-0000-0000-000000000987", 
        "Name" : "Kumar111", 
        "to_InventoryReceipt" : 
     { 
                                                              "Category" : "Transport", 
                                                              "Price" : 200, 
                                                              "Currency" : "USD" 
}, 
        "Discount" : 30 
 
}

URI

/sap/opu/odata/sap/ZSB_PRODUCT_TEMP_V2/ZP_Product

OUTPUT

Conclusion

By using RAP compositions and managed behavior with an unmanaged save implementation, this approach enables handling complex, nested payloads in a clean and extensible way. Even though all fields originate from the same database table, the logical separation into a root entity and a composition child improves API design and aligns with RAP best practices. The service definition and binding expose the entities for OData consumption, making it easy to create records using a single POST request with a structured payload. This design provides flexibility for future enhancements, ensures clear separation of responsibilities, and integrates seamlessly with SAP Fiori applications and external consumers.

Thank You

Bharath Kumar VADDEPALLI

Creating Material Master Data in SAP S/4HANA Using RAP and EML .

2026-01-08T14:06:13.252000+01:00

In SAP S/4HANA, Article (Material) Master Data is one of the most critical master data objects, serving as the foundation for logistics, sales, inventory management, and financial processes. Every procurement transaction, sales order, stock movement, or valuation posting ultimately depends on the correctness and consistency of material master data.

Traditionally, material master records are created using standard transactions such as MM01 or by leveraging classic approaches like BAPIs and IDocs. While these methods are reliable, they are not always well-suited for modern application development, especially when building custom, extensible, and clean-core–compliant solutions.

With the introduction of the RESTful ABAP Programming Model (RAP), SAP provides a standardized and future-ready way to build transactional applications using CDS views, behavior definitions, and Entity Manipulation Language (EML). RAP allows developers to model business objects declaratively while handling transactional consistency, validations, and authorizations in a structured manner.

In this article, we focus on creating Article (Material) Master Data using RAP and EML, by building an unmanaged RAP Business Object on top of standard SAP interface views such as I_Product, I_ProductDescription, and I_ProductPlant. Instead of directly calling classic BAPIs like BAPI_MATERIAL_SAVEDATA, the solution leverages EML operations on I_ProductTP to create and extend product data in a clean and controlled way.

The implementation demonstrates:

How to model a root CDS view entity for product creation
How to enrich it with UI annotations and value helps
How to define behavior logic for create, update, and custom actions
How to use EML to create product header data, descriptions, and plant extensions
How to handle validations, updates, and controlled operations within RAP behavior handlers

This approach enables the creation of a modern, API-driven, and extensible material master solution, which can easily be consumed by custom UIs, Fiori Elements, or external integrations—while remaining aligned with SAP’s clean-core strategy.

At the end of our development our RAP UI app will look like :

Note: Data is blurred out .

Step 1: Create a root CDS view entity

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Product demo with EML'
@Metadata.ignorePropagatedAnnotations: true
@Metadata.allowExtensions: true
@Search.searchable: true
define root view entity ZI_product_demo as select from I_Product as product
association [0..1] to I_ProductDescription as _descrp
on product.Product = _descrp.Product
association [0..*] to I_ProductPlant as _plante
                   on product.Product = _plante.Product
{
    key Product,
    IndustrySector,
    ProductType,
    BaseUnit,
    ProductGroup,
    PackagingMaterialGroup,
    
    _plante.Plant,
    
    _descrp.Language,
    _descrp.ProductDescription // Make association public
}

Step 2: Create a metadata extension for UI

@Metadata.layer: #CUSTOMER
@UI: {
    headerInfo: {
        typeName: 'Manage Products',
        typeNamePlural: 'Products',
        title: { type: #STANDARD, value: 'Product' },
        description: { value: 'ProductDescription' }
    }
}
annotate entity ZI_product_demo with
{
  .facet: [
    { id: 'ProductData', purpose: #STANDARD, type: #IDENTIFICATION_REFERENCE, label: 'Product Details', position: 10 }
  ]

  : { lineItem: [ { position: 10 },
                     { type: #FOR_ACTION, dataAction: 'extendplant', label: 'Extend Plant' } ],
        identification: [ { position: 10, label: 'Product' } ],
        selectionField: [ { position: 10 } ]  }
  @Consumption.valueHelpDefinition: [{  entity: {   name: 'ZC_MAT_PRODUCT_VH' ,
                                                    element: 'Product' } } ]
  Product;
  : { lineItem: [ { position: 20 } ],
       identification: [ { position: 20, label: 'Industry Sector' } ],
       selectionField: [ { position: 20 } ] }
  @Consumption.valueHelpDefinition: [{  entity: {   name: 'ZC_MAT_IndustrySector_VH' ,
                                                          element: 'IndustrySector' } } ]
  IndustrySector;

  : { lineItem: [ { position: 30 } ],
         identification: [ { position: 30, label: 'Product Type' } ],
         selectionField: [ { position: 30 } ] }
  @Consumption.valueHelpDefinition: [{  entity: {   name: 'ZC_MAT_ProductType_VH' ,
                                                          element: 'ProductType' } } ]
  ProductType;

  : { lineItem: [ { position: 40 } ],
         identification: [ { position: 40, label: 'Base Unit' } ],
         selectionField: [ { position: 40 } ] }
  @Consumption.valueHelpDefinition: [{  entity: {   name: 'ZC_MAT_BaseUnit_VH' ,
                                                          element: 'BaseUnit' } } ]
  BaseUnit;

  : { lineItem: [ { position: 50 } ],
         identification: [ { position: 50, label: 'Product Group' } ],
         selectionField: [ { position: 50 } ] }
  @Consumption.valueHelpDefinition: [{  entity: {   name: 'ZC_MAT_ProductGroup_VH' ,
                                                         element: 'ProductGroup' } } ]

  ProductGroup;

  : { lineItem: [ { position: 60 } ],
         identification: [ { position: 60, label: 'Product Description' } ],
         selectionField: [ { position: 60 } ] }
  ProductDescription;

  : { lineItem: [ { position: 70 } ],
       identification: [ { position: 70, label: 'Packaging Material Group' } ],
       selectionField: [ { position: 70 } ] }
  @Consumption.valueHelpDefinition: [{  entity: {   name: 'ZC_MAT_PackMaterialGroup_VH' ,
                                                        element: 'PackagingMaterialGroup' } } ]
  PackagingMaterialGroup;

  : { lineItem: [ { position: 80 } ],
       identification: [ { position: 80, label: 'Plant' } ],
       selectionField: [ { position: 80 } ] }
  @Consumption.valueHelpDefinition: [{  entity: {   name: 'ZC_MAT_PLANT_VH' ,
                                                        element: 'Plant' } } ]

  Plant;

  : { lineItem: [ { position: 90 } ],
      identification: [ { position: 90, label: 'Language' } ],
      selectionField: [ { position: 90 } ] }
  @Consumption.valueHelpDefinition: [{  entity: {   name: 'ZC_MAT_Language_VH' ,
                                                        element: 'Language' } } ]
  Language;
}

Since we are adding a extension to plant feature in our app we will need an abstract entity for plant.

Step 3: create abstract entity for plant

@EndUserText.label: 'abstract entity fo plant'
@Metadata.allowExtensions: true

define abstract entity ZI_PLANT_PARAM

{
  @Consumption.valueHelpDefinition: [{  entity: {   name: 'ZC_MAT_PLANT_VH' ,
                                                        element: 'Plant' } } ]  
        plant : werks_d;
}

Step 4: Behavior definition will look like this, note that in action we have to specify the abstract entity name for plant extension feature :

unmanaged implementation in class zbp_i_product_demo unique;
strict ( 2 );

define behavior for ZI_product_demo //alias <alias_name>
late numbering
lock master
authorization master ( global )
{
  create;
  update;
  delete;

  action extendplant parameter ZI_PLANT_PARAM result [1] $self;
  field ( readonly ) Plant;
  field ( readonly : update  ) Product,  ProductType, IndustrySector , PackagingMaterialGroup, Language;
  field ( mandatory : create ) BaseUnit , Language , ProductDescription, PackagingMaterialGroup,
                               IndustrySector, ProductType;
}

Step 5 : In the behavior implementation class we have to implement create , update, delete & extendplant method .

METHOD create.
    DATA lt_create_product TYPE TABLE FOR CREATE I_ProductTP_2.

*-- Read the data from app
    DATA(ls_entity) = entities[ 1 ].
    lv_product_type = ls_entity-ProductType.

    lt_create_product = VALUE #( (  %cid = 'product1'

                                  Product = ls_entity-Product
                                  ProductType = ls_entity-ProductType
                                  BaseUnit =  ls_entity-BaseUnit
                                  IndustrySector = ls_entity-IndustrySector
                                  PackagingProductGroup = ls_entity-PackagingMaterialGroup
                                  %control-Product = if_abap_behv=>mk-on
                                  %control-ProductType = if_abap_behv=>mk-on
                                  %control-BaseUnit = if_abap_behv=>mk-on
                                  %control-IndustrySector = if_abap_behv=>mk-on
                                  %control-PackagingProductGroup = if_abap_behv=>mk-on )  ).


*-- Call EML to replace BAPI_MATERIAL_SAVEDATA.
    MODIFY ENTITIES OF I_ProductTP_2 PRIVILEGED
           ENTITY Product
           CREATE FROM lt_create_product
           CREATE BY \_ProductDescription
           FIELDS ( Language ProductDescription  ) WITH VALUE #( (   %cid_ref = 'product1'
                                                                     Product = ls_entity-Product
                                                                     %target = VALUE #( (
                                                                     %cid = 'desc1'
                                                                     Product = ls_entity-Product
                                                                  Language = ls_entity-Language
                                                        ProductDescription = ls_entity-ProductDescription
                                                              )    ) ) )
                                                               MAPPED DATA(ls_mapped)
                                                               REPORTED DATA(ls_reported)
                                                               FAILED DATA(ls_failed)..
  ENDMETHOD.


  METHOD update.
    DATA(ls_update_entity) = entities[ 1 ].

*-- Fetch existing data from database.
    SELECT SINGLE a~ProductType,
                  a~BaseUnit,
                  a~ProductGroup,
                  a~IndustrySector,
                  a~PackagingMaterialGroup,
                  b~ProductDescription,
                  b~Language
            FROM I_Product AS a
      INNER JOIN i_productdescription AS b
              ON a~Product = b~Product
           WHERE a~product EQ _update_entity-%key-Product
           INTO (ls_exist_product).

*-- Call EML to modify Product header data
    MODIFY ENTITIES OF I_ProductTP_2 PRIVILEGED
    ENTITY Product
    UPDATE FIELDS ( BaseUnit ProductGroup )
    WITH VALUE #( ( %key-Product = ls_update_entity-Product
                    BaseUnit = COND #( WHEN ls_update_entity-BaseUnit IS INITIAL THEN ls_exist_product-BaseUnit
                                       ELSE ls_update_entity-BaseUnit )

                    ProductGroup = COND #( WHEN ls_update_entity-ProductGroup IS INITIAL THEN ls_exist_product-ProductGroup
                                           ELSE ls_update_entity-ProductGroup )
                     ) )

*-- Call EML to modify product description
     ENTITY ProductDescription
     UPDATE FIELDS ( ProductDescription )
     WITH VALUE #( ( %key-Product = ls_update_entity-Product
                     %key-Language = ls_exist_product-Language
                     ProductDescription = COND #( WHEN ls_update_entity-ProductDescription IS INITIAL THEN ls_exist_product-ProductDescription
                                                  ELSE ls_update_entity-ProductDescription  ) ) )
    MAPPED DATA(ls_mapped)
    REPORTED DATA(ls_reported)
    FAILED DATA(ls_failed).
  ENMETHOD.


  METHOD delete.
*-- Turn off delete functionality
    APPEND VALUE #( %tky = keys[ 1 ]-%tky ) TO failed-zi_product_demo.
    APPEND VALUE #( %tky = keys[ 1 ]-%tky
                    %msg = new_message_with_text( severity = if_abap_behv_message=>severity-error
                                                  text = 'Delete functionality is not enabled' )
                   ) TO reported-zi_product_demo.
  ENDMETHOD.


  METHOD read.
  ENDMETHOD.

  METHOD lock.
  ENDMETHOD.

  METHOD extendplant.

    DATA : lt_product TYPE TABLE FOR READ RESULT zi_product_demo.

    DATA(lt_keys) = keys.
    LOOP AT keys  ASSIGNING FIELD-SYMBOL(<lfs_keys>).

      DATA(lv_plant) = <lfs_keys>-%param-plant.
      DATA(lv_product) = <lfs_keys>-%key-Product.

    ENDLOOP.

*-- Modify the entity with plant
    MODIFY ENTITY I_ProductTP_2
        CREATE BY \_ProductPlant AUTO FILL CID WITH VALUE #( ( Product = lv_product
            %target = VALUE #( ( Product = lv_product
                                   Plant = lv_plant  ) ) ) )
    MAPPED DATA(ls_mapped)
    REPORTED DATA(ls_reported)
    FAILED DATA(ls_failed).

*-- Read the changed data.
    READ ENTITIES OF zi_product_demo IN LOCAL MODE
    ENTITY ZI_product_demo
    ALL FIELDS WITH
    CORRESPONDING #( lt_keys )
     RESULT DATA(lt_result).

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

ENDCLASS.

How To Consume External APIs in S/4HANA Private Cloud Edition (PCE) 2023 via RAP Framework

2026-01-08T14:08:04.222000+01:00

Scenario:
Suppose we need to expose images related to a "PickTicket" from an external system, making them available in SAP via a custom OData service.

Steps Overview

1. Create a Custom Entity CDS View
2. Create Service Definition
3. Create Service Binding
4. Implement ABAP Class to Consume the External API
5. Test the OData Service

1. Create a Custom Entity (CDS View)

Start by defining a **custom entity** to represent the data structure for the API response:

@EndUserText.label: 'Custom Entity for Image Data'
@ObjectModel: {
query: {
implementedBy: 'ABAP:ZCL_IMAGESET'
}
}
define root custom entity ZCE_IMAGESET
{
key pickticketid : abap.char(20);
key urlshortlivedthumbnail : abap.char(255);
trigger_ : abap.char(20);
source : abap.char(40);
imageid : abap.char(20);
urlthumbnail : abap.char(255);
urlshortlived : abap.char(255);
}

This entity acts as a **virtual view**—data retrieval is handled by an ABAP class (see `implementedBy` above).

2. Create a Service Definition

Expose the custom entity in your service definition:

@EndUserText.label: 'zsd_imageset'
define service Zsd_imageset {
expose ZCE_IMAGESET;
}

3. Create a Service Binding

Next, create a **service binding**—for example, `ZSB_IMAGESET` for OData V4—which generates the OData endpoint for your application. *Use the standard RAP tools in Eclipse or ADT to create this binding from the CDS service definition.*

4. Implement the ABAP Class to Handle API Call

Define the ABAP class (`zcl_imageset`) to fetch and provide data from the external API.
Use the **RAP Query Provider Interface** (`if_rap_query_provider`) for custom data provisioning:

Class Definition

CLASS zcl_imageset DEFINITION
PUBLIC
FINAL
CREATE PUBLIC .

PUBLIC SECTION.

TYPES: BEGIN OF ty_imageset,
trigger TYPE char20,
pickticketid TYPE char20,
source TYPE char40,
imageid TYPE char20,
urlthumbnail TYPE char255,
urlshortlived TYPE char255,
urlshortlivedthumbnail TYPE char255,
END OF ty_imageset.

TYPES: tt_imageset TYPE STANDARD TABLE OF ty_imageset WITH EMPTY KEY.

INTERFACES if_rap_query_provider.
PROTECTED SECTION.
PRIVATE SECTION.
ENDCLASS.

Class Implementation

CLASS ZCL_IMAGESET IMPLEMENTATION.

METHOD if_rap_query_provider~select.

DATA lt_images TYPE tt_imageset.
DATA lv_pickticketid TYPE string.

" Get filter (PickTicketId)

DATA(lo_filter) = io_request->get_filter( )->get_as_sql_string( ).
DATA(lv_offset) = io_request->get_paging( )->get_offset( ).
DATA(lv_page_size) = io_request->get_paging( )->get_page_size( ).
DATA(lv_max_rows) = COND #( WHEN lv_page_size = if_rap_query_paging=>page_size_unlimited THEN 0
ELSE lv_page_size ).
DATA(lt_sort_table) = VALUE string_table( FOR ls_sort_element IN io_request->get_sort_elements( )
( ls_sort_element-element_name && COND #( WHEN ls_sort_element-descending = abap_true THEN ` descending` ELSE ` ascending` ) ) ).
CONCATENATE 'PICKTICKETID ' 'SOURCE'
INTO DATA(lv_default_sort) SEPARATED BY ',' .
DATA(lv_sort_string) = COND #( WHEN lt_sort_table IS INITIAL THEN lv_default_sort
ELSE concat_lines_of( table = lt_sort_table sep = ',' ) ).


IF io_request IS BOUND.
DATA(lt_expressions) = io_request->get_filter( )->get_as_ranges( ).


LOOP AT lt_expressions INTO DATA(ls_expr).
IF ls_expr-name = 'PICKTICKETID'.
LOOP AT ls_expr-range INTO DATA(ls_range).
IF ls_range-option = 'EQ'.
lv_pickticketid = ls_range-low.
EXIT.
ENDIF.
ENDLOOP.
EXIT.
ENDIF.
ENDLOOP.

ENDIF.

" Build target URL for the external request
DATA(lv_url) = |https://<external domain url>/pickTickets/{ lv_pickticketid }/images|.

" Create HTTP client and set headers
DATA lo_http_client TYPE REF TO if_http_client.
cl_http_client=>create_by_url(
EXPORTING url = lv_url
IMPORTING client = lo_http_client
).
lo_http_client->request->set_header_field( name = 'client_id' value = '<your_client_id>' ).
lo_http_client->request->set_header_field( name = 'client_secret' value = '<your_client_secret>' ).
lo_http_client->send( ).
lo_http_client->receive( ).
DATA(lv_response) = lo_http_client->response->get_cdata( ).
lo_http_client->close( ).

" Parse JSON response to ABAP table
DATA(lo_json) = NEW /ui2/cl_json( ).
lo_json->deserialize(
EXPORTING json = lv_response
CHANGING data = lt_images
).

" Return the data
io_response->set_total_number_of_records( lines( lt_images ) ).
io_response->set_data( lt_images ).

ENDMETHOD.

ENDCLASS.

*Replace* `<external domain url>`, `<your_client_id>`, and `<your_client_secret>` *with real values.*

5. Publish and Test Your OData Service

Use `/IWFND/MAINT_SERVICE` or the service binding UI in Eclipse/ADT to publish your OData service.
Test the endpoint with a filter on `PickTicketId`:
Example: /sap/opu/odata/sap/ZSB_IMAGESET/ZCE_IMAGESET?$filter= pickticketid eq '123456'

Key Takeaways

Custom Entities in RAP allow you to virtualize data from external sources as standard OData.
You can leverage the **HTTP client functionalities** in ABAP to fetch data from any REST API.
RAP and ABAP Cloud stack are open for API-driven architectures.
Make sure to treat secrets and API credentials securely—avoid hardcoding in productive code.

Conclusion

You now have a **custom OData service** in SAP S/4HANA PCE, powered by the RAP framework, which brings in dynamic data from an **external API**. You can enhance, secure, and extend this pattern for many integration use cases—be it analytics dashboards, mobile apps, or UI5/Fiori apps!

Let me know your feedback, or reach out for specific questions.

Creating a REST API (web service) in SAP for Web App Consumption.

2026-01-08T18:27:24.050000+01:00

Step by step process for creating a rest API (Web Service) in sap, which will be consume by
web based application:

1. Create Table- ZDT_WEB_COMPLAIN

2. Create SNRO Number range object: ZSNRO_WEB

Transaction code: SNRO

Give SNRO name and click on create

enter short text, long text, number length domain, % warning and save.

click on Ranges--> click on change intervals--> click on new entries.

insert the number range and save.

3. Create request handler class : ZCL_WEBCOMPLAINT_REQHANDLR

Go to Transaction Code - SE24 and create request handler class.

enter the superclass as cl_rest_http_handler and click on save.

Go to method section to see super class methods.

select the get_root_handler and click on redefine. Add the below code in between method and endmethod.

DATA(lo_router) = NEW cl_rest_router( ).  
  
    lo_router->attach( EXPORTING  
                       iv_template =  '/webcomplaint' " Unified Name for Reso  
                       iv_handler_class =  'ZCL_WEBCOMPLAINT_REQHANDLR'   " Object Type Name  
                      "  it_parameter  = " Resource contructor parameters

save and activate the class .

4. Create resource provider class: ZCL_WEBCOMPLAINT_REQPROVIDER.

Go to Transaction Code - SE24 and create request provider class.

enter the superclass as cl_rest_resource and click on save.

Go to method section to see super class methods.

select the method 'GET' and click on redefine . Add the below code.

DATA : lv_string1   TYPE vbeln,         "string, 
           lv_string2   TYPE string, 
           gs_complaint TYPE zdt_web_complain. 
 
    lv_string1 = mo_request->get_uri_query_parameter( iv_name = 'DOC_ID' ). 
 
    CALL FUNCTION 'CONVERSION_EXIT_ALPHA_INPUT' 
      EXPORTING 
        input  = lv_string1 
      IMPORTING 
        output = lv_string1. 
 
 
    SELECT SINGLE * FROM zdt_web_complain INTO CORRESPONDING FIELDS OF gs_complaint 
    WHERE doc_id = lv_string1. 
 
 
    /ui2/cl_json=>serialize( 
      EXPORTING 
        data        =  gs_complaint    " Data to serialize 
*       COMPRESS    = ABAP_FALSE    " Skip empty elements 
*       NAME        =     " Object name 
*       PRETTY_NAME =     " Pretty Print property names 
*       TYPE_DESCR  =     " Data descriptor 
      RECEIVING 
        r_json      =   lv_string2  " JSON string 
    ). 
 
    mo_response->create_entity( )->set_string_data( iv_data = lv_string2 ). 
 
 
    mo_response->set_header_field( 
 
      EXPORTING 
        iv_name  =  'Content-Type'   " Header Name 
        iv_value =  'application/json'   " Header Value 
    ). 



save and activate .  

similarly redefine the post method and add the below code. 

  METHOD if_rest_resource~post.
*CALL METHOD SUPER->IF_REST_RESOURCE~POST
*  EXPORTING
*    IO_ENTITY =
*    .

    DATA : lv_string1   TYPE vbeln,         "string,
           lv_string2   TYPE string,
           lv_response  TYPE string,
           gs_complaint TYPE zdt_web_complain.

    DATA(lo_entity)    = mo_request->get_entity( ).
    DATA(lo_response)  = mo_response->create_entity( ).

    "read string data i.e json
    DATA(lv_data) = lo_entity->get_string_data( ).

    /ui2/cl_json=>deserialize(
      EXPORTING
        json                  =  lv_data   " JSON string
*     PRETTY_NAME           =     " Pretty Print property names
      CHANGING
        data                  =  gs_complaint   " Data to serialize
    ).
*   CATCH CX_SY_MOVE_CAST_ERROR.    "

    CALL FUNCTION 'NUMBER_GET_NEXT'
      EXPORTING
        nr_range_nr             = '01'
        object                  = 'ZSNRO_WEB'
        quantity                = '1'
*       SUBOBJECT               = ' '
*       TOYEAR                  = '0000'
*       IGNORE_BUFFER           = ' '
      IMPORTING
        number                  = gs_complaint-doc_id
*       QUANTITY                =
*       RETURNCODE              =
      EXCEPTIONS
        interval_not_found      = 1
        number_range_not_intern = 2
        object_not_found        = 3
        quantity_is_0           = 4
        quantity_is_not_1       = 5
        interval_overflow       = 6
        buffer_overflow         = 7
        OTHERS                  = 8.
    IF sy-subrc <> 0.
* Implement suitable error handling here
    ENDIF.

    gs_complaint-createdby    = sy-uname.
    gs_complaint-createdon    = sy-datum.
    gs_complaint-time         = sy-uzeit.

    INSERT INTO zdt_web_complain VALUES gs_complaint.


    /ui2/cl_json=>serialize(
      EXPORTING
        data        =   gs_complaint    " Data to serialize
*        COMPRESS    = ABAP_FALSE    " Skip empty elements
*        NAME        =     " Object name
*        PRETTY_NAME =     " Pretty Print property names
*        TYPE_DESCR  =     " Data descriptor

      RECEIVING
          r_json   = lv_response
          ).

    " JSON string
    lo_response->set_string_data( iv_data = lv_response ).

ENDMETHOD.

save and activate.

similarly redefine the post method and add the below code.

METHOD if_rest_resource~post.
*CALL METHOD SUPER->IF_REST_RESOURCE~POST
*  EXPORTING
*    IO_ENTITY =
*    .

    DATA : lv_string1   TYPE vbeln,         "string,
           lv_string2   TYPE string,
           lv_response  TYPE string,
           gs_complaint TYPE zdt_web_complain.

    DATA(lo_entity)    = mo_request->get_entity( ).
    DATA(lo_response)  = mo_response->create_entity( ).

    "read string data i.e json
    DATA(lv_data) = lo_entity->get_string_data( ).

    /ui2/cl_json=>deserialize(
      EXPORTING
        json                  =  lv_data   " JSON string
*     PRETTY_NAME           =     " Pretty Print property names
      CHANGING
        data                  =  gs_complaint   " Data to serialize
    ).
*   CATCH CX_SY_MOVE_CAST_ERROR.    "

    CALL FUNCTION 'NUMBER_GET_NEXT'
      EXPORTING
        nr_range_nr             = '01'
        object                  = 'ZSNRO_WEB'
        quantity                = '1'
*       SUBOBJECT               = ' '
*       TOYEAR                  = '0000'
*       IGNORE_BUFFER           = ' '
      IMPORTING
        number                  = gs_complaint-doc_id
*       QUANTITY                =
*       RETURNCODE              =
      EXCEPTIONS
        interval_not_found      = 1
        number_range_not_intern = 2
        object_not_found        = 3
        quantity_is_0           = 4
        quantity_is_not_1       = 5
        interval_overflow       = 6
        buffer_overflow         = 7
        OTHERS                  = 8.
    IF sy-subrc <> 0.
* Implement suitable error handling here
    ENDIF.

    gs_complaint-createdby    = sy-uname.
    gs_complaint-createdon    = sy-datum.
    gs_complaint-time         = sy-uzeit.

    INSERT INTO zdt_web_complain VALUES gs_complaint.


    /ui2/cl_json=>serialize(
      EXPORTING
        data        =   gs_complaint    " Data to serialize
*        COMPRESS    = ABAP_FALSE    " Skip empty elements
*        NAME        =     " Object name
*        PRETTY_NAME =     " Pretty Print property names
*        TYPE_DESCR  =     " Data descriptor

      RECEIVING
          r_json   = lv_response
          ).

    " JSON string
    lo_response->set_string_data( iv_data = lv_response ).

ENDMETHOD.

save and activate.

5. Create SICF service:

Execute Transaction code SICF.

click on execute.

give the service element name and press enter.

enter description and request handler class name [ zcl_webcomplaint_reqhandlr ]and save.

on SICF main screen activate the service.

now before testing add some record in table, then test the service.

Dynamic Language-Dependent Text Retrieval in RAP with Managed Implementation

2026-01-10T19:57:33.033000+01:00

In today’s globalized business environment, applications must cater to users from different linguistic backgrounds. The SAP ABAP RESTful Application Programming (RAP) model provides a robust way to implement dynamic multi-language support in managed scenarios. In this blog, we’ll explore how to achieve this step-by-step, complete with coding examples and output illustrations.

Overview of Multi-Language Support in RAP

RAP applications use language-dependent text tables to store translations. These texts are fetched dynamically based on the user's logon language. Managed scenarios in RAP handle database operations automatically, simplifying the implementation of language-specific features.

Prerequisites

SAP BTP ABAP Environment

ABAP Development Tools (ADT)

Basic RAP Knowledge

Authorization to create CDS views and service definitions

Scenario

We will create an application that manages product descriptions in multiple languages using RAP managed scenarios.

Tables Required:

Main Table: ZPRODUCT Contains product details.

Text Table: ZPRODUCT_TEXT Stores language-dependent product descriptions.

Step-by-Step Implementation
Create Database Tables
Main Table: ZPRODUCT

@EndUserText.label : 'Product table'  
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE  
@AbapCatalog.tableCategory : #TRANSPARENT  
@AbapCatalog.deliveryClass : #A  
@AbapCatalog.dataMaintenance : #RESTRICTED  
define table zna_t_product {  
key product_id : abap.char(10) not null;  
category : abap.char(20);  
price : abap.dec(15,2);  
}

Text Table: ZPRODUCT_TEXT

@EndUserText.label : 'Product text table'  
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE  
@AbapCatalog.tableCategory : #TRANSPARENT  
@AbapCatalog.deliveryClass : #A  
@AbapCatalog.dataMaintenance : #RESTRICTED  
define table zproduct_text {  
key product_id : abap.char(10) not null;  
key language : abap.lang not null;  
description : abap.string(0);  
}

Create CDS Views

Define View for Text Table (ZPRODUCT_TEXT)

@AccessControl.authorizationCheck: #NOT_REQUIRED  
@EndUserText.label: 'Product root view'  
@Metadata.ignorePropagatedAnnotations: true  
define root view entity ZC_NA_PRODUCT as select from zna_t_product 
{  
key product_id as ProductId,  
category as Category,  
price as Price  
}

Combine Root and Text Views

@AccessControl.authorizationCheck: #NOT_REQUIRED  
@EndUserText.label: 'projection view for product text'  
@Metadata.ignorePropagatedAnnotations: true  
define root view entity zna_productwithtext  
provider contract transactional_query as projection on ZC_NA_PRODUCT as _texts  
association [0..*] to ZC_NA_PRODUCT_TEXT on $projection.ProductId = _texts.ProductId  
{  
key ProductId,  
Category,  
Price  
}

Implement Multi-Language Logic in Behavior Definition

Behavior Definition for Root Entity:

managed implementation in class ZBP_Product unique;  
define behavior for ZC_Product alias Product  
persistent table zproduct  
lock master  
authorization master  
{  
  create;  
  update;  
  delete;  
  association _Texts { create; } 
}  
define behavior for ZC_ProductText alias ProductText  
persistent table zproduct_text  
lock dependent by parent Product  
{  
  create; update; delete; 
}  
"Implement Behavior Pool Class  
"Develop the behavior pool class to handle business logic.  
CLASS zbp_product DEFINITION PUBLIC FINAL CREATE PUBLIC.  
  PUBLIC SECTION.  
    INTERFACES: if_abap_behavior_handler.  
  PROTECTED SECTION.  
  PRIVATE SECTION.  
ENDCLASS.  
CLASS zbp_product IMPLEMENTATION.  
METHOD if_abap_behavior_handler~create.  
DATA: ls_product      TYPE zproduct,  
      ls_product_text TYPE zproduct_texts,  
      lt_product_text TYPE TABLE OF zproduct_texts.  
" Loop through incoming data for product creation  
LOOP AT entities INTO DATA(ls_data).  
  "  Step 1: Create Product in Main Table  
  ls_product-product_id = ls_data-product_id.  
  ls_product-category   = ls_data-category.  
  ls_product-price      = ls_data-price.  
  INSERT INTO zproduct VALUES ls_product.  
  "  Step 2: Create Product Texts (in multiple languages if needed)  
  LOOP AT ls_data-_Texts INTO DATA(ls_text_data).  
    CLEAR ls_product_text.  
    ls_product_text-product_id   = ls_data-product_id.  
    ls_product_text-spras        = ls_text_data-spras.  
    ls_product_text-product_name = ls_text_data-product_name.  
    ls_product_text-description  = ls_text_data-description.  
    INSERT INTO zproduct_texts VALUES ls_product_text.  
  ENDLOOP.  
ENDLOOP.  
ENDMETHOD.  
ENDCLASS.

Create Service Definition and Binding

Expose the CDS view through a service definition and bind it to an OData service.

@EndUserText.label: 'Product Service Definition'  
define service ZUI_Product {  
  expose ZC_Product;  
}

English Session:
Product ID: 00001
Category: Electronics
Product Name: Laptop
Description: High-performance laptop

German Session:
Produkt-ID: 00001
Kategorie: Elektronik
Produktname: Laptop
Beschreibung: Hochleistungs-Laptop

Conclusion

This blog demonstrated how to implement dynamic multi-language support in RAP managed scenarios. By leveraging CDS views, associations, and behavior definitions, you can build applications that cater to a diverse user base. This approach ensures scalability, performance, and an excellent user experience.

Print Preview from RAP Action with v4 OData and Multiple Selection

2026-01-10T20:04:09.214000+01:00

Business Requirements

The business needs to implement a print preview functionality that:

Allows users to select multiple documents in a Fiori report
Merges all selected documents into a single PDF file
Enables users to print all selected documents at once

Implementation Steps

Backend Implementation: RAP Action with PDF Generation

Behavior Definition

action PrintPreview result [1] zspdfgeneration ;

Action Implementation

METHOD PrintPreview.
**** Generate the pdf 
....
....
....
    LOOP AT keys into data(keyLine).

      CALL FUNCTION 'FP_JOB_OPEN'
        CHANGING   ie_outputparams = ls_outputparams
        EXCEPTIONS cancel          = 1
                   usage_error     = 2
                   system_error    = 3
                   internal_error  = 4
                   OTHERS          = 5.

      " Call the Function Module Name for the Adobe Form
      TRY.
          CALL FUNCTION 'FP_FUNCTION_MODULE_NAME'
            EXPORTING i_name     = lv_function
            IMPORTING e_funcname = lv_funcname.

          CALL FUNCTION lv_funcname
            EXPORTING  /1bcdwb/docparams   = ls_docparams
....
            IMPORTING  /1bcdwb/formoutput  = ls_formout
            EXCEPTIONS usage_error         = 1
                       system_error        = 2
                       internal_error      = 3
                       OTHERS              = 4.

          ls_meta-title = |YourPrintFileName| & |{ key }|.

          DATA(lv_field_name) = |NameOfYourFile| & |{ {key} }_| & |{ sy-datum }_{ sy-uzeit }.pdf|.

          lv_field_name = condense( val  = lv_field_name
                                    from = ` `
                                    to   = `` ).

          ls_lheader-name  = 'Content-Disposition'.
          ls_lheader-value = |inline; filename={fileName}| & |{ ls_transport_order-TransportationOrderUUID }_|.
          TRY.
              " Create PDF Object.
              lo_fp = cl_fp=>get_reference( ).
              lo_pdfobj = lo_fp->create_pdf_object( connection = 'ADS' ).
              lo_pdfobj->set_document( pdfdata = ls_formout-pdf ).
              lo_pdfobj->set_metadata( metadata = ls_meta ).
              lo_pdfobj->execute( ).

              " Get the PDF content back with title
              lo_pdfobj->get_document( IMPORTING pdfdata = DATA(lv_value) ).
              lo_merger->add_document( ls_formout-pdf ).
              CLEAR lv_value.
            CATCH cx_fp_runtime_internal
                  cx_fp_runtime_system
                  cx_fp_runtime_usage INTO lx_fpex.
          ENDTRY.
        CATCH cx_root.
      ENDTRY.
    ENDLOOP.
   TRY.
        " Merge both documents and receive the result
        DATA(lv_merged_PDF) = lo_merger->merge_documents( ).
      CATCH cx_rspo_pdf_merger INTO DATA(l_exception). " TODO: variable is assigned but never used (ABAP cleaner)
        " Add a useful error handling here
    ENDTRY.
    DATA lv_base64 TYPE string.
    CALL FUNCTION 'SCMS_BASE64_ENCODE_STR'
      EXPORTING input  = lv_merged_PDF
      IMPORTING output = lv_base64.


    READ TABLE keys INTO DATA(keyOne) INDEX 1.
 result = VALUE #( ( %key-DOcType         = keyOne-DOcType
                        %key-WBOriginDoc     = keyOne-WBOriginDoc
                        %key-WBOriginDocItem = keyOne-WBOriginDocItem
                        %param               = VALUE zspdfgenration( field_name  = lv_field_name
mime_type   = 'application/pdf'
pdf_content = lv_base64 ) ) ).

ENDMETHOD.

Metadata Annotation with ChangeSet

: {
  lineItem: [{
    type: #FOR_ACTION,
    dataAction: 'PrintPreview',
    label: 'Print Preview',
    invocationGrouping: #ChangeSet
  }]
}

Frontend Implementation: Controller Extension

Generate a controller extension and a custom action to call our print preview v4 action.

PrintPreviewV4: async function () {

const oExtensionAPI = this.base.getExtensionAPI();
const aSelectedContexts = oExtensionAPI.getSelectedContexts();
// Message if no rows selected
if (!aSelectedContexts || aSelectedContexts.length === 0) {
MessageToast.show("No rows selected.");
return;
}
// Call the action with the rows selected in only one call
try {
const oPageController = this.base.getView().getController();
const oResultContext = await oPageController.editFlow.invokeAction(
      "com.sap.gateway.srvd.yourService.YourAction",
      contexts: aSelectedContexts ,
      invocationGrouping: "ChangeSet"
}
);

const oData = oResultContext[0]?.value?.oBinding?.oCachePromise?.getResult()?.oPromise?.getResult();
// With the file then you can allow preview to the user or download directly 

},

Conclusion

This implementation provides a solution for generating merged PDF previews from multiple selected documents in Fiori applications. The combination of RAP actions with ChangeSet grouping and proper frontend handling ensures good performance and user experience.

Custom Entity With Actions

2026-01-11T23:45:05.274000+01:00

What is a Custom Entity in RAP?

In the ABAP RESTful Application Programming Model (RAP), a Custom Entity is a CDS entity that does not map to a database table. Instead, it represents virtual data provided by custom ABAP logic. It is used when:

You need to expose calculated or external data.

You want to integrate non-database sources (e.g., APIs, external systems).

You require custom operations beyond standard CRUD.

Adding an Action to a Custom Entity allows you to trigger specific business operations directly from the UI.

Now we will look at one practical example for Custom Entity with an Action in RAP, where the action will be performed based on the user click on the button called CustomAction , when user clicks on it the icon will be changed.

First, we will begin by creating a database table with the fields shown in the screenshot below.

Next, we will create a Custom Entity and define its implementation class, as the Custom Entity will be realized through the logic implemented in that class "ZGA_CL_QRY_PRVD_C_ACT".

Now, we will implement the logic in the class and use the mandatory interface IF_RAP_QUERY_PROVIDER to handle data retrieval for the Custom Entity.

To adjust the data, we have implemented another class named ZGA_CL_BS_DEMO_ADJUST_DATA.

Our next task is to create a Behavior Definition for the Custom Entity ZGA_I_CUST_ACT_DEMO to enable actions and logic implementation.

Next, we dive into implementing the Behavior Definition logic in the class ZBP_GA_I_CUST_ACT_DEMO.

The class shown below serves as the buffer class, which we have utilized in our Behavior Implementation class.

Our next task is to create the Service Definition and Service Binding, enabling the UI to consume the Custom Entity and its actions.

Output:

Once an instance is selected, clicking CustomAction will dynamically update the icon, as displayed in the screenshot.

The Reset button is used to restore all icons to their original state.

Conclusion

Custom Entities with Actions in SAP RAP provide a powerful way to implement dynamic, user-driven functionality without relying on database persistence. In this example, we demonstrated how to create a Custom Entity and enhance it with two actions.

By leveraging actions, you can enrich your applications with flexible business logic, improve user engagement, and maintain a clean separation between UI and backend logic. This approach is ideal for scenarios where you need virtual data handling combined with interactive operations.

Research: Unmanaged Transactional Buffer For RESTful Application Programming Model

2026-01-19T12:23:34.134000+01:00

RESEARCH ON UNMANAGED IMPLEMENTATION OF TRANSACTIONAL BUFFER FOR RESTFUL APPLICATION PROGRAMMING MODEL

Ilya Prusakou
ABAP Developer & Researcher

Abstract.

Implementing unmanaged scenarios in the ABAP RESTful Application Programming Model (RAP) remains a significant hurdle for developers due to the opinionated nature of the framework and a lack of production-level examples.
The research addresses the challenge by providing comprehensive blueprint for the unmanaged transactional buffer. This article serves as a practical guide for mastering the internal state management of RAP business objects.

KEYWORDS: Unmanaged Implementation, Transactional Buffer, Buffer Tables, Complex Data Source, Buffer Preparation, Buffer Flags, Draft Buffer, Buffer Access, Transactional Phase, Save Phase, Late Numbering.

Examples.

You can find example of buffer implementation on my github: https://github.com/IlyaPrusakou/rap-unmanaged-buffer-example.git

The specific path is src/zpru_transactional_buffer/zpru_cl_example_buffer.clas.abap
You can also review the buffer class code at the bottom of this article. In this post, I will use term "blueprint" referring to the full code of the example implementation.

Additionally, you can visit my another github rep: https://github.com/IlyaPrusakou/abap-rap-example.git

My unmanaged imlementation class on which I have provided my research is under the path: src/zpru_um_po/zpru_um_po_implmtns/zbp_pru_u_purcorderhdr_tp.clas.locals_imp.abap

There, you can look onto the local class LCL_BUFFER.
To check out how to use the buffer for standard operations, you can visit the local handler class LHC_ORDERTP, specifically methods:

LHC_ORDERTP~CREATE
LHC_ORDERTP~READ
LHC_ORDERTP~UPDATE
LHC_ORDERTP~DELETE
LHC_ORDERTP~RBA_ITEMS_TP
LHC_ORDERTP~CBA_ITEMS_TP

For investigation of the child node, you can open the local handler LHC_ITEMTP, specifically methods:

LHC_ITEMTP~READ
LHC_ITEMTP~UPDATE
LHC_ITEMTP~DELETE
LHC_ITEMTP~RBA_HEADER_TP

It is recomended to have a glance into the local saver class LSC_ZPRU_U_PURCORDERHDR_TP to understand how a trigger calculation works and what role method FINALIZE, CHECK_BEFORE_SAVE and SAVE play.

I also recommend visiting the packages SABAP_DEMOS_RAP and SABAP_DEMOS_RAP_CLOUD to check out various RAP examples, especially BDEF DEMO_RAP_UNMANAGED_DRAFT_ROOT and its associated class.

For the blueprint implementation I have used a RAP business object with an unmanaged implementation type and with four nested levels.
Moreover, I used a late numbering because it requires the maximum implementation effort. I also defined keys using simple character types rather than GUID fields.

Buffer class.

From an implementation perspective a transactinal buffer is ABAP class, usually local class placed in local implementation include of ABAP behavior implementation global class (ABP class). It contains entity buffer tables.
Buffer class can be an ABAP global class as well. However, if you choose this way of implementation you must be aware that global class is considered as external to the ABP class and you will not be able to access internal derived types.

Accessible types	Internal types
keys type table for read import bdef\\entity	keys type table for validation bdef\\entity~validation
entitie type table for create bdef\\entity	keys type table for determination bdef\\entity~determination
keys type table for action import bdef\\entity~action	event type table for event bdef~event
etc.	etc.

Entity buffer tables.

Entity buffer tables are internal tables defined as static attributes in a buffer class. Their rows contain entity fields from the transactional CDS, flags (changed, deleted) and other components(CID, PID etc.)
In the snippet of code below, you can observe entity buffer tables on rows 42 - 45. Besides the tables themselves, there are types for entity keys and types for the buffer rows as well.

CLASS zpru_cl_example_buffer DEFINITION
  PUBLIC FINAL
  CREATE PUBLIC.
   " types for entity keys
    TYPES: BEGIN OF ts_first_node_db_keys, 
             firstkey TYPE zr_pru_1st_node-firstkey,
           END OF ts_first_node_db_keys.

    TYPES: BEGIN OF ts_second_node_db_keys,
             firstkey  TYPE zr_pru_2nd_node-firstkey,
             secondkey TYPE zr_pru_2nd_node-secondkey,
           END OF ts_second_node_db_keys.
*****
*****
    " types for buffer row
    TYPES: BEGIN OF ts_first_node,
             instance  TYPE zr_pru_1st_node,
             cid       TYPE abp_behv_cid,
             pid       TYPE abp_behv_pid,
             final_key TYPE ts_first_node_db_keys,
             changed   TYPE abap_bool,
             deleted   TYPE abap_bool,
           END OF ts_first_node.

    TYPES: BEGIN OF ts_second_node,
             instance  TYPE zr_pru_2nd_node,
             cid       TYPE abp_behv_cid,
             pid       TYPE abp_behv_pid,
             pidparent TYPE abp_behv_pid,
             final_key TYPE ts_second_node_db_keys,
             changed   TYPE abap_bool,
             deleted   TYPE abap_bool,
           END OF ts_second_node.
*****
*****
    " entity buffer tables
    TYPES tt_first_node  TYPE TABLE OF ts_first_node WITH EMPTY KEY.
    TYPES tt_second_node TYPE TABLE OF ts_second_node WITH EMPTY KEY.
    TYPES tt_third_node  TYPE TABLE OF ts_third_node WITH EMPTY KEY.
    TYPES tt_fourth_node TYPE TABLE OF ts_fourth_node WITH EMPTY KEY.

    CLASS-DATA st_first_node  TYPE tt_first_node.
    CLASS-DATA st_second_node TYPE tt_second_node.
    CLASS-DATA st_third_node  TYPE tt_third_node.
    CLASS-DATA st_fourth_node TYPE tt_fourth_node.
*****
*****
ENDCLASS.

Buffer preparation.

The buffer preparation is the process of loading entities from a complex data source (in my case, it is just a transactional CDS) into entity buffer tables, usually executed via static methods (e.g. PREP_ENTITY_NAME) in the buffer class.
Each standard RAP operations will start with the buffer preparation methods. You may know these operations by names such as preloading, fetching, selecting data into the buffer, or even prepopulating the buffer.
Moreover, I want to draw attention to type definitions for the input parameters of the preparation methods - especially to the flag FULL_KEY. The flag belongs to child entities and is used to distinguish between accessing them via association or direct access.

CLASS zpru_cl_example_buffer DEFINITION
  PUBLIC FINAL
  CREATE PUBLIC.
*****
*****
    "structure types for input parameters for buffer preparation methods
    TYPES: BEGIN OF ts_first_node_keys.
             INCLUDE TYPE ts_first_node_db_keys.
    TYPES: END OF ts_first_node_keys.

    TYPES: BEGIN OF ts_second_node_keys.
             INCLUDE TYPE ts_second_node_db_keys.
    TYPES:   full_key TYPE abap_bool,
           END OF ts_second_node_keys.
*****
*****
    "table types for input parameters for buffer preparation methods
    TYPES tt_first_node_keys  TYPE TABLE OF ts_first_node_keys WITH EMPTY KEY.
    TYPES tt_second_node_keys TYPE TABLE OF ts_second_node_keys WITH EMPTY KEY.
*****
*****
    " buffer preparation methods
    CLASS-METHODS prep_first_node_buffer
      IMPORTING !keys TYPE tt_first_node_keys.
    CLASS-METHODS prep_second_node_buffer
      IMPORTING !keys TYPE tt_second_node_keys.
    CLASS-METHODS prep_third_node_buffer
      IMPORTING !keys TYPE tt_third_node_keys.
    CLASS-METHODS prep_fourth_node_buffer
      IMPORTING !keys TYPE tt_fourth_node_keys.
ENDCLASS.

Root preparation

Let's check code inside the preparation method for root entity.

 METHOD prep_first_node_buffer.
    DATA lt_keys_2_read   LIKE keys.
    DATA lt_entity_result TYPE STANDARD TABLE OF zr_pru_1st_node WITH EMPTY KEY.
    LOOP AT keys ASSIGNING FIELD-SYMBOL(<ls_key>).
      IF line_exists( zpru_cl_example_buffer=>st_first_node[ instance-firstkey = <ls_key>-firstkey ] ).
        CONTINUE.
      ELSE.
        APPEND INITIAL LINE TO lt_keys_2_read ASSIGNING FIELD-SYMBOL(<ls_key_2_read>).
        <ls_key_2_read>-firstkey = <ls_key>-firstkey.
      ENDIF.
    ENDLOOP.
    IF lt_keys_2_read IS NOT INITIAL.
      SELECT * FROM zr_pru_1st_node
        FOR ALL ENTRIES IN lt_keys_2_read
        WHERE firstkey = lt_keys_2_read-firstkey
        INTO TABLE lt_entity_result.
      IF sy-subrc = 0.
        LOOP AT lt_entity_result ASSIGNING FIELD-SYMBOL(<ls_result>).
          APPEND INITIAL LINE TO zpru_cl_example_buffer=>st_first_node ASSIGNING FIELD-SYMBOL(<ls_buffer>).
          <ls_buffer>-instance = <ls_result>.
        ENDLOOP.
      ENDIF.
    ENDIF.
  ENDMETHOD.

Root preparation logic is the following:

check if the entry exists in the buffer using the full key
- if yes:
  - do nothing
- if no:
  - collect keys to select data from the data source
  - select data using the full key
  - insert entry into the buffer

Checking existence and reading data based on buffer keys, which can be full or partial and depending on whether we are reading a root or child entity, and whether the access is direct or via association. In the case of a root entity, it is always a full key. Even when we try to access the parent node (especially the root node) from a child entity, we use "to-parent" association and provide the full key. I will explain buffer keys in separate chapter.

Child preparation

Let's check code inside the preparation method for child entity. This is where the flag FULL_KEY comes into play.

  METHOD prep_second_node_buffer.
    DATA lt_full_keys_2_read   LIKE keys.
    DATA lt_part_keys_2_read   LIKE keys.
    DATA lt_full_entity_result TYPE STANDARD TABLE OF zr_pru_2nd_node WITH EMPTY KEY.
    DATA lt_part_entity_result TYPE STANDARD TABLE OF zr_pru_2nd_node WITH EMPTY KEY.
    LOOP AT keys ASSIGNING FIELD-SYMBOL(<ls_key_child>).
      IF <ls_key_child>-full_key = abap_true.
        IF line_exists( zpru_cl_example_buffer=>st_second_node[ instance-firstkey  = <ls_key_child>-firstkey
                                                                instance-secondkey = <ls_key_child>-secondkey ] ).
          CONTINUE.
        ELSE.
          APPEND INITIAL LINE TO lt_full_keys_2_read ASSIGNING FIELD-SYMBOL(<ls_full_key_2_read>).
          <ls_full_key_2_read>-firstkey  = <ls_key_child>-firstkey.
          <ls_full_key_2_read>-secondkey = <ls_key_child>-secondkey.
        ENDIF.
      ELSE.
        IF     line_exists( zpru_cl_example_buffer=>st_first_node[ instance-firstkey = <ls_key_child>-firstkey ] )
           AND VALUE #( zpru_cl_example_buffer=>st_first_node[ instance-firstkey = <ls_key_child>-firstkey ]-deleted OPTIONAL ) IS NOT INITIAL.
          CONTINUE.
        ELSE.
          APPEND INITIAL LINE TO lt_part_keys_2_read ASSIGNING FIELD-SYMBOL(<ls_part_key_2_read>).
          <ls_part_key_2_read>-firstkey = <ls_key_child>-firstkey.
        ENDIF.
      ENDIF.
    ENDLOOP.
    IF lt_full_keys_2_read IS NOT INITIAL.
      SELECT * FROM zr_pru_2nd_node
        FOR ALL ENTRIES IN _full_keys_2_read
        WHERE firstkey  = lt_full_keys_2_read-firstkey
          AND secondkey = lt_full_keys_2_read-secondkey
        INTO TABLE lt_full_entity_result.
      IF sy-subrc = 0.
        LOOP AT lt_full_entity_result ASSIGNING FIELD-SYMBOL(<ls_result>).
          APPEND INITIAL LINE TO zpru_cl_example_buffer=>st_second_node ASSIGNING FIELD-SYMBOL(<ls_buffer>).
          <ls_buffer>-instance = <ls_result>.
        ENDLOOP.
      ENDIF.
    ENDIF.
    IF lt_part_keys_2_read IS NOT INITIAL.
      SELECT * FROM zr_pru_2nd_node
        FOR ALL ENTRIES IN lt_part_keys_2_read
        WHERE firstkey = lt_part_keys_2_read-firstkey
        INTO TABLE lt_part_entity_result.
      IF sy-subrc = 0.
        LOOP AT lt_part_entity_result ASSIGNING <ls_result>.
          IF NOT line_exists( zpru_cl_example_buffer=>st_second_node[ instance-firstkey  = <ls_result>-firstkey                                                                      instance-secondkey = <ls_result>-secondkey ] ).
            APPEND INITIAL LINE TO zpru_cl_example_buffer=>st_second_node ASSIGNING <ls_buffer>.
            <ls_buffer>-instance = <ls_result>.
          ENDIF.
        ENDLOOP.
      ENDIF.
    ENDIF.
  ENDMETHOD.

Let's explore logic.

check if the key is a full key:
- if it is a full key:
  - check if the entry exists in the buffer using the full key:
    - if yes:
      - do nothing
    - if no:
      - collect the key to select data from the data source
      - select data using the full key
      - insert the child entry into the buffer
- if it is a partial key:
  - check if the parent node is marked for deletion in the buffer
    - if yes:
      - do nothing
    - if no:
      - collect the key to select data from the data source
      - select one or multiple child entities using the partial key
      - loop through the selection result:
        check if each processing child entity already exists in the buffer
        if it does not exist: add it into the buffer table

You may ask why we check if the parent node, marked for deletion, exists in the buffer in the partial key logic. The answer is that when we mark for deletion parent node, we must mark for deletion all its children (cascading deletion).
This is the only scenario where we can be certain that all children are already present in the buffer. In other cases, we can't guarantee that all children are buffered; for example only four out of five children might currently be loaded.

You may also ask why we check if a child entry exists before inserting it into the buffer table in the partial key logic. Let me give you an example. We have one parent node and four children:

parent1
- child1
- child2
- child3
- child4

Firstly, you do operation "read child1"; as a result you have child1 inside the buffer table. Then you perform a "read by associations" for the children of parent1.
During child preparation method you will have only the parent key (the partial key logic) and you will select all children of parent1 (child1, child2, child3 and child4). So the next step is to insert all of these children into the buffer table, but child1 is already presented. To avoid duplicates in the buffer table, we check for the existence of the child entity before inserting.

Full Buffer key vs Partial Buffer key.

During checking existence in the buffer or reading data from data source we use either the full key or the partial key of the entity:

The partial key logic: used when we access the entity via composition. The partial key logic take place when we move from parent to child.
The full key logic: used when we access the entity directly or by association inversed direction from child to parent.

While maintaining the buffer is primarily required for compositions, it may also be neccessary in cross-BO scenario where external associations are involved.

Impact of key field data type on buffer handling:

Semantic key (e.g. character, numeric etc. fields): you must handle entire set of the key fields for each level and the set may grow when you are moving dipper in RAP business object tree.
GUID keys(raw16): you only need to process the only technical GUID field for reading, checking entity in the buffer tables.

The full key representation.
This represents the complete primary key required to identify a specific instance.

Level	Semantic keys	GUID keys
first node	FirstKey	FirstGuid
second node	FirstKey, SecondKey	SecondGuid
third node	FirstKey, SecondKey, ThirdKey	ThirdGuid
fourth node	FirstKey, SecondKey, ThirdKey, FourthKey	FourthGuid

The partial key representation.
This represents the keys of the imediate parent, used to fetch all associated children.

Level	Semantic keys	GUID keys
first node	N/A	N/A
second node	FirstKey	FirstGuid
third node	FirstKey, SecondKey	SecondGuid
fourth node	FirstKey, SecondKey, ThirdKey	ThirdGuid

Schematically it can be expressed in the following way:

FULL KEY
NOT GUID
node / key field
1 / 1 
2 / 1, 2
3 / 1, 2, 3
4 / 1, 2, 3, 4 

GUID
node / key field
1 / 1
2 / 2
3 / 3
4 / 4 

PARENT KEY
NOT GUID
node / key field
1 / N/A 
2 / 1
3 / 1, 2
4 / 1, 2, 3
 
GUID
node / key field
1 / N/A 
2 / 1
3 / 2
4 / 3

Complex Data source.

In a managed scenario, data source is defined as a persisted table in the BDEF. In an unmanaged scenario, the data source has a complex structure from which you load entries into the buffer and save entries from the buffer. 'Complex' means it can not be reduced to a single database table. It might be a BAPI, an HTTP response, a legacy API class or a combination of them.
This complexity requires choosing an unmanaged implementation. You will also notice that you can not use keyword 'persistent table' in BDEF for unmanaged implementation type. And that is fair; your data source is not a just database table.

METHOD prep_first_node_buffer.
*****
*****
  IF lt_keys_2_read IS NOT INITIAL.
      " SELECT * FROM zr_pru_1st_node
      " CALL EXTERNAL SOURCE VIA HTTP
      " CALL BAPI
      " CALL LEGACY API
      " UPLOAD FILE
      " COMBINATION OF THEM AND ETC.
      IF sy-subrc = 0.
        LOOP AT lt_entity_result ASSIGNING FIELD-SYMBOL(<ls_result>).
          APPEND INITIAL LINE TO zpru_cl_example_buffer=>st_first_node ASSIGNING FIELD-SYMBOL(<ls_buffer>).
          <ls_buffer>-instance = <ls_result>.
        ENDLOOP.
      ENDIF.
    ENDIF.
ENDMETHOD.

Buffer Components

Buffer flags

Each row of the entity buffer table may contain any flags you require, but the minimum necessary are 'changed' and 'deleted' flags. When you initialize a buffer entry, both flags are false. When you update an entry, you setup the changed flag to true. When you delete an entry, you setup the delete flag to true. Optionally, during deletion, you may set both flags as true, but I don't prefer such way. Finally, in the method SAVE you will sort all buffer entries into two separate internal local tables: one for modifying database, another for deleting from the database.

CLASS zpru_cl_example_buffer DEFINITION
  PUBLIC FINAL
  CREATE PUBLIC.
*****
*****
    TYPES: BEGIN OF ts_first_node,
             instance  TYPE zr_pru_1st_node,
*****
*****
             changed   TYPE abap_bool,
             deleted   TYPE abap_bool,
           END OF ts_first_node.

    TYPES: BEGIN OF ts_second_node,
             instance  TYPE zr_pru_2nd_node,
*****
*****
             changed   TYPE abap_bool,
             deleted   TYPE abap_bool,
           END OF ts_second_node.
*****
*****
ENDCLASS.

Buffer additional components

The entity buffer table row may contain components as CID for handling field %CID, and PID for field %PID field in late numbering scenarios. Since I am using a late nubmering scenario, I have added component FINAL_KEY to preserve the result from ADJUST_NUMBERS method.

CLASS zpru_cl_example_buffer DEFINITION
  PUBLIC FINAL
  CREATE PUBLIC.
*****
*****
    TYPES: BEGIN OF ts_first_node,
             instance  TYPE zr_pru_1st_node,
             cid       TYPE abp_behv_cid,
             pid       TYPE abp_behv_pid,
             final_key TYPE ts_first_node_db_keys,
*****
*****
           END OF ts_first_node.

    TYPES: BEGIN OF ts_second_node,
             instance  TYPE zr_pru_2nd_node,
             cid       TYPE abp_behv_cid,
             pid       TYPE abp_behv_pid,
             pidparent TYPE abp_behv_pid,
             final_key TYPE ts_second_node_db_keys,
*****
*****
           END OF ts_second_node.
*****
*****
ENDCLASS.

Generic pattern of usage.

Buffer handled in the following way:

In transactinal phase in method READ, CREATE, UPDATE, DELETE, RBA AND CBA:
- Prepare buffer using input keys using methods ZPRU_CL_EXAMPLE_BUFFER=>PREP_FIRST_NODE_BUFFER
- read, insert, update, delete(set deleted flag) entry from, in entity buffer table
In save phase:
- Determine values for entries from entity buffer table in method FINALIZE
- Validate values for entries from entity buffer table in method CHECK_BEFORE_SAVE
- Save entries from entity buffer tables to complex data source in method SAVE
- Clean-up buffer tables in method CLEANUP

Buffer access.

From handling perspective transactinal buffer can be accesed directly and indirectly in your unmanaged implementation during different phase.

Buffer access in Transactional phase.

Basically during transactional phase we can access buffer in two flawors in ABP class:

Direct access is used in such methods like read, read by association, create by association, create, update, delete(standard operations).
Indirect access is used in such methods for instance feature, instance authorization, actions, functions and etc. via EML read, modify(non-standard operations)

Buffer access in Save phase

During save phase we access data directly from buffer, the main reason is that methods FINALIZE, CHECK_BEFORE_SAVE, ADJUST_NUMBERS, SAVE, CLEANUP and CLEANUP_FINALIZE are not provided with input entity keys. The only source of eventual keys to process is the buffer tables itself. Also we can use EML to read data taking keys from buffer tables.

Types of access in save phase:

predominantly direct access in methods FINALIZE, CHECK_BEFORE_SAVE, ADJUST_NUMBERS, SAVE, CLEANUP and CLEANUP_FINALIZE.
indirect access via EML read.

  " No input keys
  " To find out what to process we must have a look in the buffer.
  " Finalize execute determinations, be aware that determiantion for draft
  " and active instances are different things. Finalize is mainly 
  " about active data
  methods FINALIZE                 
    changing
      !FAILED type DATA
      !REPORTED type DATA .
  " No input keys
  " This method for validation and again mainly for active data. 
  methods CHECK_BEFORE_SAVE
    changing
      !FAILED type DATA
      !REPORTED type DATA .
  " input keys
  " This method will save active data to source of active data
  " Usually the data source is complex, not just one table or even two tables 
  methods SAVE
    changing
      !REPORTED type DATA optional
      !FAILED type DATA optional .

Transactional buffer vs Draft buffer.

If you business object has draft capabilities, don't conflate transactional buffer implemented by developer and draft buffer handled by managed runtime. They live in parallel and sometimes need to be synchronized via additional implementation for EDIT, ACTIVATE, DISCARD, RESUME. All in all draft processing is carried on by managed runtime despite that you have unmanaged implementation of business object.

Operation aggregation.

Transactional buffer must handle operation aggregation. Operation aggregation means that user can create, update and update one more time, execute action in the same LUW, more over even in one EML statement. One more prominant example of operation aggregation is when user create, delete and then create again entry for RAP business object.

*All CRUD operations must support aggreggation of operations.
*Just for your undestanding there are a lot possible sequences like:
*1. C 2. U 3. D 4. C + U 5. C + D 6. D + C 7. C + U + D 8. U + D + C and etc.
*The following level of complexity is that operations can be repeate multiple *times for the same instance(set of key fields)
*C + C + U + U + U + D and etc.
*There are more caviats that you can think, eg.
*C1 + D + C2 => create with some particalar fields, then mark it as deleted 
*and it is still in our buffer, then create again with the same key but
*another set of data fields

Delete vs Discard vs Remove entry from buffer.

So let's define couple moments:

Delete means to set flag 'deleted' in method DELETE of ABP pool class. Real deletion happens in method SAVE, based on this flag.
Discard - basically the same as delete but it is handled by draft runtime and is provided out-of-box. Developer isn't responsible for discard implementation. We only can add additional implementation to provide additional logic for the method DISCARD.
Remove - sometimes can happend, e.g. in the method CLEANUP or in the method CREATE during attempt to recreate entry with the same keys as previously marked as deleted(delete then create again).

Unmanaged Transactional Buffer Blueprint

At last, we can conclude our research with the publication of the code of the buffer class, the so called unmanaged trasnactional buffer blueprint. You are welcom to utilize and adapt this code for your specific requirements.

CLASS zpru_cl_example_buffer DEFINITION
  PUBLIC FINAL
  CREATE PUBLIC.

  PUBLIC SECTION.

    TYPES: BEGIN OF ts_first_node_db_keys,
             firstkey TYPE zr_pru_1st_node-firstkey,
           END OF ts_first_node_db_keys.

    TYPES: BEGIN OF ts_second_node_db_keys,
             firstkey  TYPE zr_pru_2nd_node-firstkey,
             secondkey TYPE zr_pru_2nd_node-secondkey,
           END OF ts_second_node_db_keys.

    TYPES: BEGIN OF ts_third_node_db_keys,
             firstkey  TYPE zr_pru_3rd_node-firstkey,
             secondkey TYPE zr_pru_3rd_node-secondkey,
             thirdkey  TYPE zr_pru_3rd_node-thirdkey,
           END OF ts_third_node_db_keys.

    TYPES: BEGIN OF ts_fourth_node_db_keys,
             firstkey  TYPE zr_pru_4th_node-firstkey,
             secondkey TYPE zr_pru_4th_node-secondkey,
             thirdkey  TYPE zr_pru_4th_node-thirdkey,
             fourthkey TYPE zr_pru_4th_node-fourthkey,
           END OF ts_fourth_node_db_keys.

    TYPES: BEGIN OF ts_first_node,
             instance  TYPE zr_pru_1st_node,
             cid       TYPE abp_behv_cid,
             pid       TYPE abp_behv_pid,
             final_key TYPE ts_first_node_db_keys,
             changed   TYPE abap_bool,
             deleted   TYPE abap_bool,
           END OF ts_first_node.

    TYPES: BEGIN OF ts_second_node,
             instance  TYPE zr_pru_2nd_node,
             cid       TYPE abp_behv_cid,
             pid       TYPE abp_behv_pid,
             pidparent TYPE abp_behv_pid,
             final_key TYPE ts_second_node_db_keys,
             changed   TYPE abap_bool,
             deleted   TYPE abap_bool,
           END OF ts_second_node.

    TYPES: BEGIN OF ts_third_node,
             instance  TYPE zr_pru_3rd_node,
             cid       TYPE abp_behv_cid,
             pid       TYPE abp_behv_pid,
             pidparent TYPE abp_behv_pid,
             final_key TYPE ts_third_node_db_keys,
             changed   TYPE abap_bool,
             deleted   TYPE abap_bool,
           END OF ts_third_node.

    TYPES: BEGIN OF ts_fourth_node,
             instance  TYPE zr_pru_4th_node,
             pid       TYPE abp_behv_pid,
             pidparent TYPE abp_behv_pid,
             final_key TYPE ts_fourth_node_db_keys,
             changed   TYPE abap_bool,
             deleted   TYPE abap_bool,
           END OF ts_fourth_node.

    TYPES tt_first_node  TYPE TABLE OF ts_first_node WITH EMPTY KEY.
    TYPES tt_second_node TYPE TABLE OF ts_second_node WITH EMPTY KEY.
    TYPES tt_third_node  TYPE TABLE OF ts_third_node WITH EMPTY KEY.
    TYPES tt_fourth_node TYPE TABLE OF ts_fourth_node WITH EMPTY KEY.

    CLASS-DATA st_first_node  TYPE tt_first_node.
    CLASS-DATA st_second_node TYPE tt_second_node.
    CLASS-DATA st_third_node  TYPE tt_third_node.
    CLASS-DATA st_fourth_node TYPE tt_fourth_node.

    TYPES: BEGIN OF ts_first_node_keys.
             INCLUDE TYPE ts_first_node_db_keys.
    TYPES: END OF ts_first_node_keys.

    TYPES: BEGIN OF ts_second_node_keys.
             INCLUDE TYPE ts_second_node_db_keys.
    TYPES:   full_key TYPE abap_bool,
           END OF ts_second_node_keys.

    TYPES: BEGIN OF ts_third_node_keys.
             INCLUDE TYPE ts_third_node_db_keys.
    TYPES:   full_key TYPE abap_bool,
           END OF ts_third_node_keys.

    TYPES: BEGIN OF ts_fourth_node_keys.
             INCLUDE TYPE ts_fourth_node_db_keys.
    TYPES:   full_key TYPE abap_bool,
           END OF ts_fourth_node_keys.

    TYPES tt_first_node_keys  TYPE TABLE OF ts_first_node_keys WITH EMPTY KEY.
    TYPES tt_second_node_keys TYPE TABLE OF ts_second_node_keys WITH EMPTY KEY.
    TYPES tt_third_node_keys  TYPE TABLE OF ts_third_node_keys WITH EMPTY KEY.
    TYPES tt_fourth_node_keys TYPE TABLE OF ts_fourth_node_keys WITH EMPTY KEY.

    CLASS-METHODS prep_first_node_buffer
      IMPORTING !keys TYPE tt_first_node_keys.

    CLASS-METHODS prep_second_node_buffer
      IMPORTING !keys TYPE tt_second_node_keys.

    CLASS-METHODS prep_third_node_buffer
      IMPORTING !keys TYPE tt_third_node_keys.

    CLASS-METHODS prep_fourth_node_buffer
      IMPORTING !keys TYPE tt_fourth_node_keys.

ENDCLASS.


CLASS zpru_cl_example_buffer IMPLEMENTATION.
  METHOD prep_first_node_buffer.
    DATA lt_keys_2_read   LIKE keys.
    DATA lt_entity_result TYPE STANDARD TABLE OF zr_pru_1st_node WITH EMPTY KEY.

    LOOP AT keys ASSIGNING FIELD-SYMBOL(<ls_key>).
      IF line_exists( zpru_cl_example_buffer=>st_first_node[ instance-firstkey = <ls_key>-firstkey ] ).
        CONTINUE.
      ELSE.
        APPEND INITIAL LINE TO lt_keys_2_read ASSIGNING FIELD-SYMBOL(<ls_key_2_read>).
        <ls_key_2_read>-firstkey = <ls_key>-firstkey.
      ENDIF.
    ENDLOOP.

    IF lt_keys_2_read IS NOT INITIAL.
      SELECT * FROM zr_pru_1st_node
        FOR ALL ENTRIES IN lt_keys_2_read
        WHERE firstkey = lt_keys_2_read-firstkey
        INTO TABLE lt_entity_result.
      IF sy-subrc = 0.
        LOOP AT lt_entity_result ASSIGNING FIELD-SYMBOL(<ls_result>).
          APPEND INITIAL LINE TO zpru_cl_example_buffer=>st_first_node ASSIGNING FIELD-SYMBOL(<ls_buffer>).
          <ls_buffer>-instance = <ls_result>.
        ENDLOOP.
      ENDIF.
    ENDIF.
  ENDMETHOD.

  METHOD prep_second_node_buffer.
    DATA lt_full_keys_2_read   LIKE keys.
    DATA lt_part_keys_2_read   LIKE keys.
    DATA lt_full_entity_result TYPE STANDARD TABLE OF zr_pru_2nd_node WITH EMPTY KEY.
    DATA lt_part_entity_result TYPE STANDARD TABLE OF zr_pru_2nd_node WITH EMPTY KEY.

    LOOP AT keys ASSIGNING FIELD-SYMBOL(<ls_key_child>).
      IF <ls_key_child>-full_key = abap_true.
        IF line_exists( zpru_cl_example_buffer=>st_second_node[ instance-firstkey  = <ls_key_child>-firstkey
                                                                instance-secondkey = <ls_key_child>-secondkey ] ).
          CONTINUE.
        ELSE.
          APPEND INITIAL LINE TO lt_full_keys_2_read ASSIGNING FIELD-SYMBOL(<ls_full_key_2_read>).
          <ls_full_key_2_read>-firstkey  = <ls_key_child>-firstkey.
          <ls_full_key_2_read>-secondkey = <ls_key_child>-secondkey.
        ENDIF.
      ELSE.
        IF     line_exists( zpru_cl_example_buffer=>st_first_node[ instance-firstkey = <ls_key_child>-firstkey ] )
           AND VALUE #( zpru_cl_example_buffer=>st_first_node[ instance-firstkey = <ls_key_child>-firstkey ]-deleted OPTIONAL ) IS NOT INITIAL.
          CONTINUE.
        ELSE.
          APPEND INITIAL LINE TO lt_part_keys_2_read ASSIGNING FIELD-SYMBOL(<ls_part_key_2_read>).
          <ls_part_key_2_read>-firstkey = <ls_key_child>-firstkey.
        ENDIF.
      ENDIF.
    ENDLOOP.

    IF lt_full_keys_2_read IS NOT INITIAL.
      SELECT * FROM zr_pru_2nd_node
        FOR ALL ENTRIES IN lt_full_keys_2_read
        WHERE firstkey  = lt_full_keys_2_read-firstkey
          AND secondkey = lt_full_keys_2_read-secondkey
        INTO TABLE lt_full_entity_result.
      IF sy-subrc = 0.
        LOOP AT lt_full_entity_result ASSIGNING FIELD-SYMBOL(<ls_result>).
          APPEND INITIAL LINE TO zpru_cl_example_buffer=>st_second_node ASSIGNING FIELD-SYMBOL(<ls_buffer>).
          <ls_buffer>-instance = <ls_result>.
        ENDLOOP.
      ENDIF.
    ENDIF.

    IF lt_part_keys_2_read IS NOT INITIAL.
      SELECT * FROM zr_pru_2nd_node
        FOR ALL ENTRIES IN lt_part_keys_2_read
        WHERE firstkey = lt_part_keys_2_read-firstkey
        INTO TABLE lt_part_entity_result.
      IF sy-subrc = 0.
        LOOP AT lt_part_entity_result ASSIGNING <ls_result>.
          IF NOT line_exists( zpru_cl_example_buffer=>st_second_node[ instance-firstkey  = <ls_result>-firstkey
                                                                      instance-secondkey = <ls_result>-secondkey ] ).
            APPEND INITIAL LINE TO zpru_cl_example_buffer=>st_second_node ASSIGNING <ls_buffer>.
            <ls_buffer>-instance = <ls_result>.
          ENDIF.
        ENDLOOP.
      ENDIF.
    ENDIF.
  ENDMETHOD.

  METHOD prep_third_node_buffer.
    DATA lt_full_keys_2_read   LIKE keys.
    DATA lt_part_keys_2_read   LIKE keys.
    DATA lt_full_entity_result TYPE STANDARD TABLE OF zr_pru_3rd_node WITH EMPTY KEY.
    DATA lt_part_entity_result TYPE STANDARD TABLE OF zr_pru_3rd_node WITH EMPTY KEY.

    LOOP AT keys ASSIGNING FIELD-SYMBOL(<ls_key_child>).
      IF <ls_key_child>-full_key = abap_true.
        IF line_exists( zpru_cl_example_buffer=>st_third_node[ instance-firstkey  = <ls_key_child>-firstkey
                                                               instance-secondkey = <ls_key_child>-secondkey
                                                               instance-thirdkey  = <ls_key_child>-thirdkey ] ).
          CONTINUE.
        ELSE.
          APPEND INITIAL LINE TO lt_full_keys_2_read ASSIGNING FIELD-SYMBOL(<ls_full_key_2_read>).
          <ls_full_key_2_read>-firstkey  = <ls_key_child>-firstkey.
          <ls_full_key_2_read>-secondkey = <ls_key_child>-secondkey.
          <ls_full_key_2_read>-thirdkey  = <ls_key_child>-thirdkey.
        ENDIF.
      ELSE.
        IF     line_exists( zpru_cl_example_buffer=>st_second_node[ instance-firstkey  = <ls_key_child>-firstkey
                                                                    instance-secondkey = <ls_key_child>-secondkey ] )
           AND VALUE #( zpru_cl_example_buffer=>st_second_node[ instance-firstkey  = <ls_key_child>-firstkey
                                                                instance-secondkey = <ls_key_child>-secondkey ]-deleted OPTIONAL ) IS NOT INITIAL.
          CONTINUE.
        ELSE.
          APPEND INITIAL LINE TO lt_part_keys_2_read ASSIGNING FIELD-SYMBOL(<ls_part_key_2_read>).
          <ls_part_key_2_read>-firstkey = <ls_key_child>-firstkey.
        ENDIF.
      ENDIF.
    ENDLOOP.

    IF lt_full_keys_2_read IS NOT INITIAL.
      SELECT * FROM zr_pru_3rd_node
        FOR ALL ENTRIES IN _full_keys_2_read
        WHERE firstkey  = lt_full_keys_2_read-firstkey
          AND secondkey = lt_full_keys_2_read-secondkey
          AND thirdkey  = lt_full_keys_2_read-thirdkey
        INTO TABLE lt_full_entity_result.
      IF sy-subrc = 0.
        LOOP AT lt_full_entity_result ASSIGNING FIELD-SYMBOL(<ls_result>).
          APPEND INITIAL LINE TO zpru_cl_example_buffer=>st_third_node ASSIGNING FIELD-SYMBOL(<ls_buffer>).
          <ls_buffer>-instance = <ls_result>.
        ENDLOOP.
      ENDIF.
    ENDIF.

    IF lt_part_keys_2_read IS NOT INITIAL.
      SELECT * FROM zr_pru_3rd_node
        FOR ALL ENTRIES IN lt_part_keys_2_read
        WHERE firstkey  = lt_part_keys_2_read-firstkey
          AND secondkey = lt_part_keys_2_read-secondkey
        INTO TABLE lt_part_entity_result.
      IF sy-subrc = 0.
        LOOP AT lt_part_entity_result ASSIGNING <ls_result>.
          IF NOT line_exists( zpru_cl_example_buffer=>st_third_node[ instance-firstkey  = <ls_result>-firstkey
                                                                     instance-secondkey = <ls_result>-secondkey
                                                                     instance-thirdkey  = <ls_result>-thirdkey ] ).
            APPEND INITIAL LINE TO zpru_cl_example_buffer=>st_third_node ASSIGNING <ls_buffer>.
            <ls_buffer>-instance = <ls_result>.
          ENDIF.
        ENDLOOP.
      ENDIF.
    ENDIF.
  ENDMETHOD.

  METHOD prep_fourth_node_buffer.
    DATA lt_full_keys_2_read   LIKE keys.
    DATA lt_part_keys_2_read   LIKE keys.
    DATA lt_full_entity_result TYPE STANDARD TABLE OF zr_pru_4th_node WITH EMPTY KEY.
    DATA lt_part_entity_result TYPE STANDARD TABLE OF zr_pru_4th_node WITH EMPTY KEY.

    LOOP AT keys ASSIGNING FIELD-SYMBOL(<ls_key_child>).
      IF <ls_key_child>-full_key = abap_true.
        IF line_exists( zpru_cl_example_buffer=>st_fourth_node[ instance-firstkey  = <ls_key_child>-firstkey
                                                                     instance-secondkey = <ls_key_child>-secondkey
                                                                     instance-thirdkey  = <ls_key_child>-thirdkey
                                                                     instance-fourthkey =  <ls_key_child>-fourthkey ] ).
          CONTINUE.
        ELSE.
          APPEND INITIAL LINE TO lt_full_keys_2_read ASSIGNING FIELD-SYMBOL(<ls_full_key_2_read>).
          <ls_full_key_2_read>-firstkey  = <ls_key_child>-firstkey.
          <ls_full_key_2_read>-secondkey = <ls_key_child>-secondkey.
          <ls_full_key_2_read>-thirdkey  = <ls_key_child>-thirdkey.
          <ls_full_key_2_read>-fourthkey  = <ls_key_child>-fourthkey.
        ENDIF.
      ELSE.
        IF     line_exists( zpru_cl_example_buffer=>st_third_node[ instance-firstkey  = <ls_key_child>-firstkey
                                                                   instance-secondkey = <ls_key_child>-secondkey
                                                                   instance-thirdkey  = <ls_key_child>-thirdkey ] )
           AND VALUE #( zpru_cl_example_buffer=>st_third_node[ instance-firstkey  = <ls_key_child>-firstkey
                                                                instance-secondkey = <ls_key_child>-secondkey
                                                                instance-thirdkey  = <ls_key_child>-thirdkey ]-deleted OPTIONAL ) IS NOT INITIAL.
          CONTINUE.
        ELSE.
          APPEND INITIAL LINE TO lt_part_keys_2_read ASSIGNING FIELD-SYMBOL(<ls_part_key_2_read>).
          <ls_part_key_2_read>-firstkey = <ls_key_child>-firstkey.
        ENDIF.
      ENDIF.
    ENDLOOP.

    IF lt_full_keys_2_read IS NOT INITIAL.
      SELECT * FROM zr_pru_4th_node
        FOR ALL ENTRIES IN lt_full_keys_2_read
        WHERE firstkey  = lt_full_keys_2_read-firstkey
          AND secondkey = lt_full_keys_2_read-secondkey
          AND thirdkey  = lt_full_keys_2_read-thirdkey
          AND fourthkey = lt_full_keys_2_read-fourthkey
        INTO TABLE lt_full_entity_result.
      IF sy-subrc = 0.
        LOOP AT lt_full_entity_result ASSIGNING FIELD-SYMBOL(<ls_result>).
          APPEND INITIAL LINE TO zpru_cl_example_buffer=>st_fourth_node ASSIGNING FIELD-SYMBOL(<ls_buffer>).
          <ls_buffer>-instance = <ls_result>.
        ENDLOOP.
      ENDIF.
    ENDIF.

    IF lt_part_keys_2_read IS NOT INITIAL.
      SELECT * FROM zr_pru_4th_node
        FOR ALL ENTRIES IN lt_part_keys_2_read
        WHERE firstkey  = lt_part_keys_2_read-firstkey
          AND secondkey = lt_part_keys_2_read-secondkey
          AND thirdkey  = lt_part_keys_2_read-thirdkey
        INTO TABLE lt_part_entity_result.
      IF sy-subrc = 0.
        LOOP AT lt_part_entity_result ASSIGNING <ls_result>.
          IF NOT line_exists( zpru_cl_example_buffer=>st_fourth_node[ instance-firstkey  = <ls_result>-firstkey
                                                                     instance-secondkey = <ls_result>-secondkey
                                                                     instance-thirdkey  = <ls_result>-thirdkey
                                                                     instance-fourthkey = <ls_result>-fourthkey ] ).
            APPEND INITIAL LINE TO zpru_cl_example_buffer=>st_fourth_node ASSIGNING <ls_buffer>.
            <ls_buffer>-instance = <ls_result>.
          ENDIF.
        ENDLOOP.
      ENDIF.
    ENDIF.
  ENDMETHOD.
ENDCLASS.

Clean Core: Building a Flexible Custom Business Configuration for HTTP Endpoints in SAP S/4HANA

2026-01-20T02:51:55.321000+01:00

Introduction

This post presents a technique for creating configuration in SAP S/4HANA that fully respects clean‑core principles, while offering more flexibility than traditional ECC customizing (SM30 or SPRO).

The use case is particularly interesting because it also touches on best practices for connecting SAP S/4HANA to Integration Suite — or more generally, to any public API.
However, the primary goal here is to explain how to build a Custom Business Configuration (CBC) — the clean‑core replacement for SPRO entries — and, more importantly, how to adapt it so that only selected fields are transport‑controlled while others remain editable directly in each environment.

The result is a clean‑core‑compliant solution that is more powerful than legacy SPRO customizing.

Use Case

Connections from S/4HANA to external APIs are increasing significantly with SAP’s “API First” strategy. This is very true on my project: we call Integration Suite, which then calls public APIs while managing authentication and potential transformations.

On S/4HANA on‑premise or private cloud, the recommended practice is to use destinations (transaction SM59, type G for HTTP).
In public cloud, this would instead be done using Communication Arrangements.

A typical ABAP call looks like:

DATA(get_device_auth_destination) =
  cl_http_destination_provider=>create_by_destination(
    i_name = 'DESTINATION_NAME' ).

DATA(http_client) =
  cl_web_http_client_manager=>create_by_http_destination(
    i_destination = get_device_auth_destination ).

http_client->get_http_request( )->set_uri_path(
  i_uri_path = '/path/endpoint' ).

DATA(http_response) =
  http_client->execute( i_method = if_web_http_client=>get ).

DATA(response_text) = http_response->get_text( ).

In this simple example, both the destination and the endpoint path are hard‑coded.

The Problem

Good practice suggests that:

The API endpoint URL should not be stored in the program.
Ideally, there should be one dedicated destination per API, allowing:
- API‑level call authorization
- Authentication configuration (e.g., principal propagation)
- Timeout settings
- Emergency deactivation of an API by disabling the destination

In practice, because most APIs go through Integration Suite, we want to avoid creating dozens of destinations.
We therefore use one common destination but still need the ability to override it when necessary.

To achieve this, we create a custom configuration, allowing us to define — per flow type:

HTTP destination
Endpoint path
English description
Active / inactive flag

Here is the table:

@EndUserText.label : 'HTTP endpoint configuration'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zbct_a_httpendp {
  key client      : abap.clnt not null;
  key flow_id     : zhttp_endpoint_flow_id not null;
  rfc_destination : rfcdest;
  path            : zhttp_endpoint_path;
  is_active       : zhttp_endpoint_is_active;
  description     : zhttp_endpoint_description;
}

The requirement is:

Creating a flow ID with its initial settings must be possible only in the reference client.
But fields like path and active flag must be editable in all environments.

Creating the Custom Business Configuration

Once the table is created, generating a CBC object is straightforward:
open the ABAP Object Generator and select "Maintenance Object".

This automatically generates RAP objects (Restful ABAP Programming Model).

This is where it gets powerful: we can adjust these objects to control precisely which fields are editable depending on the environment.

Adjusting the Behavior Definition

Open the generated behavior definition (in my case ZBP_I_HTTPENDPOINTCONFIGU_S).

Our goal is:

The Edit button must always be enabled.
Some fields must be read‑only outside the reference client:
- RFC Destination
- Description

We simply define this logic in the behavior definition.

Next, open the implementation class (ZBP_…) and go to Local Types.

We remove the default "Edit" restrictions and implement our own logic to disable selected fields when the configuration is opened in a non‑reference environment.

This ensures:

In production (or any non‑reference client):
→ only path and active flag are editable
In the reference client:
→ everything is editable

Testing the Result

Open the Custom Business Configuration app and select your configuration object.

In a productive environment, you will see the expected restrictions: only the intended fields are editable.

In the reference client, all fields remain modifiable.

Step-By-Step Guide: Creating Your First RAP Application using OData V4 and Transporting to Quality

2026-01-20T07:14:41.239000+01:00

Introduction

In this blog, we will walk through the detailed steps to create your first RAP (RESTful ABAP Programming Model) application and correctly move it to the Quality system. This blog also highlights mandatory steps before transport and common mistakes that beginners usually make, based on real project experience.

Target Audience & Prerequisites

ABAP developers who are new to RAP
Basic knowledge of CDS Views and ABAP Development Tools (ADT)
System used: SAP S/4HANA (On-Premise / Private Cloud)
Exposure type: OData V4
Scenario covered: Basic Read-only RAP application
Mandatory Objects in a RAP Application:
- Package
- Interface CDS View
- Projection CDS View (Optional we can directly create service definition on Interface view also)
- Service Definition
- Service Binding

Create Package:
Create a package in ADT:
- Right-click on project → New → ABAP Package
- Enter package name and description
- Do not create it as a local package ($TMP)
- Capture it in a transport request
- Only transportable packages can be moved to Quality and Production systems.
Interface CDS View: A CDS View is a virtual data model in ABAP that defines how data from database tables is accessed and represented. In RAP, it often serves as the “Interface View.”
1. Why It Matters:
  - Reusable logic: Centralizes data access for transactional and analytical purposes.
  - Foundation: Serves as the starting point for business object modeling in RAP.
2. Steps:
  - Right-click your database table (e.g., ZTRAVEL_RAJ_M), select New Data Definition.
  - Provide a name, description, and use the Define View Entity template.
  - Assign to transport, activate, and check for errors.
Service Definition: The Service Definition specifies which data elements (entities) of a RAP business object are exposed as OData services.
1. Why It Matters:
  - Exposure Layer: Decides what consumers (e.g., Fiori apps, external APIs) can interact with.
  - It’s the contract between your backend logic and external consumers.
2. Steps:
  - Right-click on the projection view, select New Service Definition.
  - Name, description, assign transport, and activate.
  - This exposes your RAP objects as a service.
Service Binding: Service Binding links a service definition to an actual communication protocol (such as OData V4) and activation state.
1. Why It Matters:
  - Enables Consumption: Without binding, your service cannot be called or used.
  - Protocol Choice: Determines how front ends communicate with your service (e.g., OData V4 for Fiori/UI5 apps).
2. Steps:
  - Right-click on the service definition, select New Service Binding.
  - Choose OData V4 protocol (for most Fiori/RAP apps).
  - Assign transport, describe, finish, and activate.
Why You Should NOT Publish from ADT: Publishing directly from ADT is meant only for local testing.
1. Issues with ADT Publishing
  - Service is registered as a local ($TMP) object
  - Cannot be transported to Quality or Production
  - Not supported for productive landscapes
2. Correct Way: Publish via /IWFND/V4_ADMIN
  - Transaction /IWFND/V4_ADMIN is the recommended way to publish RAP services.
3. Steps:
  - Open /IWFND/V4_ADMIN and click Publish Service Groups
  - Enter System Alias = LOCAL, Service Binding name click on get service groups
  - Select service and Publish
  - From the service group list, right click on your service group and click on transport publishing. It will prompt for customizing TR enter the transport and save. After that Click on transport routing assignment and capture in the customizing TR.
  - Service is now published
Preview: Finally, let’s preview the application to verify that the service is working as expected.

Conclusion:

In this blog, we learned how to create a basic RAP application and the correct approach to publish and transport OData V4 services to the Quality system.
Using /IWFND/V4_ADMIN ensures transport safety and helps avoid common deployment issues that beginners often face.

Note:

To customize the user interface of your RAP application, add appropriate UI annotations in the CDS view (interface or projection, depending on your design). Common annotations include @ui.headerInfo, @ui.lineItem, and @ui.selectionField.

After publishing the service, share the service URL (available in the Service Binding) with the Fiori development team so they can create the required Fiori tile.
After transporting to the Quality system, SICF activation is a manual step. Without activating the relevant SICF nodes, the service will not be accessible. Coordinate with your Basis team to complete this step.

Your 2026 Roadmap to Getting Started with ABAP AI and ABAP-1

2026-01-21T18:01:36.956000+01:00

The era of "Wait and See" for AI in ABAP development is officially over. With the general availability of Joule for Developers (J4D) and the planned availability of ABAP agentic AI frameworks in 2026, the question isn't if you should use AI, but where you should start.

The "Start Here" Recommendation: For 90% of developers, the best starting point is SAP Joule for Developers integrated within ABAP Development Tools (ADT) for Eclipse. In addition you can also experiment with the first versions of ABAP-1 model to analyze and explain code on your own - but be aware that this is currently not for code generation and only for those which want to be independent of J4D. Therefore starting with J4D is the fastest but also the most powerful way to start with ABAP AI.

Why should I start with Joule for Developers (J4D)?

Contextual Intelligence: Unlike generic LLMs, Joule for Developers is additionally trained on over 250 million lines of proprietary SAP code and is aware of your specific ABAP Cloud context. In general J2D is powered by a combination of third-party foundation models (e.g. OpenAI, Gemini, Anthropic, Mistral AI), alongside SAP-centric models like the LLMs, trained specifically on ABAP and purpose-built for cloud-based SAP development.
It’s Free (For Now): SAP has extended the free promotional period for Joule for Developers until September 2026.
Native Skills: It handles predictive code generation (e.g. RAP generation), "Explain" skills for legacy code, and unit test generation directly within your IDE. So it can do way more then ABAP-1 right now.
J4D is out of the box integrated in Eclipse ADT.

The Three Paths for ABAP AI Evolution:

1. The Standard Path: Joule for Developers in ADT

Best for: Daily coding, documentation, and unit testing.
Action: Request access through your administrator (Material 8019124 for customers and 8019541 for partners) and activate it in ADT.

2. The Innovation Path: ABAP AI SDK & BTP Free Tier

Best for: Building your own AI-powered business applications (e.g., automated invoice processing).
Action: Use the SAP BTP Free Tier to access the Generative AI Hub and the ABAP AI SDK to connect your custom ABAP code to external foundation models.

3. The Modernization Path: VS Code with ABAP Cloud (Roadmap Q2/2026)

Best for: Developers looking for a lightweight, file-based experience and for those which want to be the first to leverage agentic ABAP AI in side-by-side approach.
Action: Explore the new side-by-side ABAP Cloud Extension for VS Code (GA planned for Q2 2026) with built-in Agentic AI assistance powered by an ABAP MCP server. This will support a broader range of SAP S/4HANA Private Editions and provide faster update cycles.

Key Takeaway for 2026:
Don't get bogged down trying to "prompt engineer" experimental models like ABAP-1 for production code generation. Instead, leverage Joule for Developers mature "Explain" and "Generate" skills to maintain a Clean Core and accelerate your migration to SAP S/4HANA.

Here you can learn more:

More high-level insights about Joule for Developers/ABAP AI and ABAP platform can be found here . Here you find more on ABAP- 1,

Mass Update Through Custom Action In RAP

2026-01-23T06:31:27.262000+01:00

Introduction:

With the increasing adoption of the RESTful ABAP Programming Model (RAP), SAP developers are encouraged to move away from classic procedural approaches and design applications that are behavior-driven, scalable, and Fiori-ready. While RAP provides powerful standard operations such as create, update, and delete, real-world business scenarios often require mass processing or bulk updates triggered by user actions.

In this blog, I will walk through a practical implementation of mass update using a custom action in RAP. This approach is especially useful when you need to update multiple records based on business logic that cannot be handled by standard CRUD operations alone.

Solution Overview:

The blog covers:

Why custom actions are required for mass updates in RAP
How to define a custom action in the Behavior Definition
Implementing the action logic in the Behavior Implementation class
Triggering the mass update from a Fiori Elements UI
Key considerations and best practices

Database Table:

@EndUserText.label : 'travel uuid table'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table zuuid_table {

  key client    : abap.clnt not null;
  key travel_id : sysuuid_x16 not null;
  description   : /dmo/description;
  status        : /dmo/travel_status;
  @Semantics.amount.currencyCode : 'zuuid_table.currency_code'
  booking_fee   : /dmo/booking_fee;
  @Semantics.amount.currencyCode : 'zuuid_table.currency_code'
  total_price   : /dmo/total_price;
  currency_code : /dmo/currency_code;
  createdby     : syuname;
  createdat     : timestampl;
  lastchangedby : syuname;
  lastchangedat : abp_locinst_lastchange_tstmpl;

}

Root Entity:

@AccessControl.authorizationCheck: #MANDATORY
@Metadata.allowExtensions: true
@ObjectModel.sapObjectNodeType.name: 'ZUUID_TABLE'
@EndUserText.label: '###GENERATED Core Data Service Entity'
define root view entity ZR_UUID_TABLE
  as select from zuuid_table as R_UUID_TABLE
{
  key travel_id as TravelID,
  description as Description,
  status as Status,
  @Semantics.amount.currencyCode: 'CurrencyCode'
  booking_fee as BookingFee,
  @Semantics.amount.currencyCode: 'CurrencyCode'
  total_price as TotalPrice,
  currency_code as CurrencyCode,
  createdby as Createdby,
  createdat as Createdat,
  lastchangedby as Lastchangedby,
  @Semantics.systemDateTime.localInstanceLastChangedAt: true
  lastchangedat as Lastchangedat
}

Projection View:

@Metadata.allowExtensions: true
@Metadata.ignorePropagatedAnnotations: true
@EndUserText: {
  label: '###GENERATED Core Data Service Entity'
}
@ObjectModel: {
  sapObjectNodeType.name: 'ZUUID_TABLE'
}
@AccessControl.authorizationCheck: #MANDATORY
define root view entity ZC_UUID_TABLE
  provider contract transactional_query
  as projection on ZR_UUID_TABLE
  association [1..1] to ZR_UUID_TABLE as _BaseEntity on $projection.TravelID = _BaseEntity.TravelID
{
  key TravelID,
  Description,
  Status,
  @Semantics: {
    amount.currencyCode: 'CurrencyCode'
  }
  BookingFee,
  @Semantics: {
    amount.currencyCode: 'CurrencyCode'
  }
  TotalPrice,
  CurrencyCode,
  Createdby,
  Createdat,
  Lastchangedby,
  @Semantics: {
    systemDateTime.localInstanceLastChangedAt: true
  }
  Lastchangedat,
  _BaseEntity
}

Metadata Extension:

@ui.lineItem: [ {
    position: 10 , 
    label: 'Modify Status', type: #FOR_ACTION, dataAction: 'UpdateStatus'
  } ]
  @ui.selectionField: [ {
    position: 10 
  } ]

Root Behavior Definition:

define action in BDEF.
parameter which defines inputs for our actions.

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

with draft;

extensible;
define behavior for ZR_UUID_TABLE alias R_UUID_TABLE
persistent table ZUUID_TABLE

extensible
draft table ZUUID_TABLE_D
etag master Lastchangedat

lock master total etag Lastchangedat
authorization master( global )
{
  field ( readonly )
   TravelID,
   Lastchangedat;

  field ( numbering : managed )
   TravelID;


  create;
  update(features : instance );
  delete(features : global);
  action(features : global) UpdateStatus parameter zstatus_str;
  draft action Activate optimized;
  draft action Discard;
  draft action Edit;
  draft action Resume;
  draft determine action Prepare;

  mapping for ZUUID_TABLE corresponding extensible
  {
    TravelID = travel_id;
    Description = description;
    Status = status;
    BookingFee = booking_fee;
    TotalPrice = total_price;
    CurrencyCode = currency_code;
    Createdby = createdby;
    Createdat = createdat;
    Lastchangedby = lastchangedby;
    Lastchangedat = lastchangedat;
  }

}

Parameter For Action:

@EndUserText.label : 'staus structure'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
define structure zstatus_str {

  status : /dmo/travel_status;

}

Implementation:

  METHOD UpdateStatus.


  MODIFY ENTITIES OF zr_uuid_table IN LOCAL MODE ENTITY r_uuid_table
  UPDATE FIELDS ( Status ) WITH VALUE #(  for key in keys
                                            (  %key-TravelID = key-TravelID
                                              Status = key-%param-status ) )
                                              REPORTED data(lt_reported)
                                              FAILED data(lt_failed).

  ENDMETHOD.

Explanation:

MODIFY ENTITIES is the RAP statement used to change data in a behavior-managed entity.
IN LOCAL MODE ensures the operation runs within the current LUW without immediately committing to the database.
UPDATE FIELDS Status explicitly restricts the update to the Status field only, improving clarity and performance.
keys contains all selected instances for which the action is triggered.
The FOR expression loops over each selected key, enabling mass processing in a single statement.
%key-TravelID identifies the record to be updated.
key-%param-status retrieves the action parameter value passed from the UI for ex, a new status selected by the user.
lt_reported captures informational, warning, or success messages generated during the update.
lt_failed contains records that could not be updated due to validation errors, authorization issues, or business rule violations.
These tables are automatically processed by RAP and reflected back to the UI, ensuring proper user feedback.

Projection BDEF:

expose our custom action in projection behavior definition.

projection implementation in class ZBP_C_UUID_TABLE unique;
strict ( 2 );
extensible;
use draft;
use side effects;
define behavior for ZC_UUID_TABLE alias R_UUID_TABLE
extensible
use etag
{
  use create;
  use update;
  use delete;

  use action Edit;
  use action Activate;
  use action Discard;
  use action Resume;
  use action Prepare;
use action UpdateStatus;
}

Preview:

select records and click on modify status button.
Assign any travel status and it will be updated.

Conclusion:

Custom actions in RAP provide a clean and scalable way to handle mass update scenarios that go beyond standard CRUD operations. By leveraging MODIFY ENTITIES, action parameters, and RAP-managed messaging, developers can implement efficient bulk updates while fully adhering to RAP principles. This approach ensures better performance, cleaner code, and seamless integration with Fiori Elements, making it a recommended pattern for real-world business requirements.

ABAP Connectivity ABAP Extensibility SAP BTP ABAP environment

Developing AI Enabled Applications with ABAP AI SDK powered by ISLM

2026-01-23T08:05:00.042000+01:00

SAP Joule for Developers, ABAP AI Capabilities is your intelligent coding companion, bringing deep expertise in ABAP Cloud and AI-driven development. When we talk about ABAP AI use cases, they revolve around three key pillars — Accelerate, Empower, and Transform. Each AI capability is delivered as part of these pillars, helping developers enhance productivity, build smarter applications, and drive innovation. To learn more about SAP Joule for Developers, refer to the blog post Joule speaks ABAP! by Dr. Alexander Rother.

Have you ever wondered how to infuse intelligence into your ABAP-based business applications and move beyond standard transactional scenarios? If yes, you’ve landed at the right place. In this blog, we’ll explore how you can build AI-enabled applications using the ABAP AI SDK powered by Intelligent Scenario Lifecycle Management (ISLM), the main deliverable of the Empower use case.

The Scenario
The goal of this scenario is to infuse generative AI into an ABAP Cloud application to enhance user experience and automate content creation.

Use Case: Build an ABAP Cloud application to generate a travel itinerary for a given city based on user input, along with a budget breakdown, using ABAP AI SDK powered by ISLM.

Which products are supported?

The ABAP AI SDK powered by ISLM is available in:

SAP BTP ABAP Environment

SAP S/4HANA Cloud Public Edition

SAP S/4HANA Cloud Private Edition and SAP S/4HANA OnPrem as of release 2025 via standard delivery. Lower releases of SAP S/4HANA Cloud Private Edition and SAP S/4HANA OnPrem are supported via Transport-based Correction Instructions (TCI), see details in SAP Note 3513374 and the SAP Notes and instructions linked therein.

Overview

To build this application, we’ll bring together several key components:

SAP AI Core – for managing AI scenarios and accessing generative AI capabilities via the generative AI hub.

Communication Arrangement – to establish secure integration between ABAP and AI Core.

ISLM (Intelligent Scenario Lifecycle Management) and ABAP AI SDK – for seamless integration with Generative AI Hub, SAP BTP AI services

Custom ABAP Cloud Application – to embed and expose AI capabilities through a user-friendly application.

Implementation Steps

Set Up the Environment
Configure the AI Core service plan and establish communication arrangements between the ABAP system and AI Core.
Build Custom Travel Plan ABAP Cloud application.
Create and Deploy Intelligent Scenarios
Define the AI scenario in ISLM, train or connect your model, and deploy it for consumption.
Consume Intelligent Scenarios in ABAP
Integrate the deployed scenario within a custom ABAP Cloud application to generate AI-driven outputs - in this case, travel itineraries and budget breakdown.

1. Set Up the Environment

Configure the required entitlements to make SAP AI Core accessible in your subaccount. To use Generative AI capabilities (including the Generative AI Hub and LLM access), choose the extended service plan. To add a Service Plan, see: Add a Service Plan | SAP Help Portal
Download the client default certificate of the ABAP system to create the X.509 service key in AI Core instance. Follow the steps here : Download Certificate | SAP Help Portal
Create a service instance and a service key to access SAP AI Core, where the large language models in the generative AI hub are hosted. The X.509 service key is created with the downloaded client default certificate of the ABAP system passed as parameter. Follow the steps from here: Create SAP BTP Service Instance and Key | SAP Help Portal
Configure the communication system for SAP_COM_0A69. Currently, you can create one instance of the communication scenario per client. Follow the steps from here: How to Configure the Communication System for SAP_COM_0A69 | SAP Help Portal
To create the Communication Arrangement for SAP_COM_0A69. Follow the steps from here: How to Create the Communication Arrangement for SAP_COM_0A69 | SAP Help Portal
After the communication system and communication arrangement are configured, create an intelligent scenario and continue managing the lifecycle of the intelligent scenario. You are required to create an intelligent scenario for your custom-owned Gen AI use cases.

2. Create a custom ABAP Cloud Application to infuse AI Capabilities

2.1 Create Package

In ABAP Development Tools (ADT), go to the Project Explorer, right-click on the package ZLOCAL, and select New → ABAP Package from the context menu.
Maintain the required information:
1. Name: ZTRAVEL_ITINERARY
2. Description: ABAP AI Capabilities
  Select the box Add to favorites package. Choose Next and Finish.

2.2 Create database table

Create a database table to store the Travel Itinerary data.

Right-click on your ABAP package ZTRAVEL_ITINERARY and select New → Other ABAP Repository Object from the context menu.
Search for database table, select it, and choose Next.
Maintain the required information: Name: ZRAP_TRAVEL_DATA Description: Database Table for Travel Itinerary
Choose Next. Choose Finish and replace the default code with the following code snippet:

@EndUserText.label : 'Database table for travel Itinerary'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table zrap_travel_data {
  key client            : abap.clnt not null;
  key travel_id         : sysuuid_x16 not null;
  traveler_name         : abap.char(80);
  starting_point        : abap.char(100);
  destination           : abap.char(100);
  start_date            : /dmo/begin_date;
  end_date              : /dmo/end_date;
  @Semantics.amount.currencyCode : 'zrap_travel_data.budget_curr'
  budget                : abap.curr(15,2);
  budget_curr           : abap.cuky;
  transport_mode        : abap.char(40);
  accommodation_type    : abap.char(50);
  ai_itinerary          : abap.sstring(1333);
  ai_budget_breakdown   : abap.sstring(1000);
  status                : abap.char(20);
  local_created_by      : abp_creation_user;
  local_created_at      : abp_creation_tstmpl;
  local_last_changed_by : abp_locinst_lastchange_user;
  local_last_changed_at : abp_locinst_lastchange_tstmpl;
  last_changed_at       : abp_lastchange_tstmpl;
}

5. Save and activate the changes in the table ZRAP_TRAVEL_DATA

2.3 Generate transactional UI service

Create your OData V4-based UI service with the built-in ADT generator. The generated business service will be transactional, draft-enabled, and enriched with UI semantics for the generation of the SAP Fiori elements app.

Right-click your database table ZRAP_TRAVEL_DATA and select Generate ABAP Repository Objects from the context menu.
Select OData UI Service and choose Next and provide the package details.
Maintain the required information on the Configure Generator dialog to provide the name of your data model and generate them.
For that, navigate through the wizard tree (Business Objects, Data Model, etc…), maintain the artefact names provided and choose Next.
Verify the maintained entries and choose Next to confirm and choose Finish.
The artifacts needed will be generated. Go to the Project Explorer, select your package ZRAP_TRAVEL_ITENERARY, refresh it by choosing F5, and check all generated ABAP repository objects.

ℹ️ NOTE: The names of the artifacts may differ from those shown in this blog post, as they are generated by the wizard.

2.4 Adjust meta data extensions
Open the metadata extension ZC_RAP_TRAVEL_DATA and make the adjustments as shown in the provided code snippet. ZC_RAP_TRAVEL_DATA should look like this:

@Metadata.layer: #CORE
@UI.headerInfo.title.type: #STANDARD
@UI.headerInfo.title.value: 'TravelID'
@UI.headerInfo.description.type: #STANDARD
@UI.headerInfo.description.value: 'TravelID'

annotate view ZC_RAP_TRAVEL_DATA with
{
  .facet: [
    { label: 'General Information', id: 'GeneralInfo', purpose: #STANDARD, position: 10, type: #IDENTIFICATION_REFERENCE },
    { label: 'AI Generated Itinerary', id: 'AIItineraryFacet', purpose: #STANDARD, position: 200, type: #FIELDGROUP_REFERENCE, targetQualifier: 'AI_ITIN' },
    { label: 'AI Budget Breakdown', id: 'AIBudgetFacet', purpose: #STANDARD, position: 210, type: #FIELDGROUP_REFERENCE, targetQualifier: 'AI_BUDGET' }
  ]

  @EndUserText.label: 'TravelID'
  .identification: [ { position: 10, label: 'TravelID' } ]
  .lineItem: [ { position: 10, label: 'TravelID' } ]
  .selectionField: [ { position: 10 } ]
  TravelID;

  @EndUserText.label: 'TravelerName'
  .identification: [ { position: 20, label: 'TravelerName' } ]
  .lineItem: [ { position: 20, label: 'TravelerName' } ]
  .selectionField: [ { position: 20 } ]
  TravelerName;

  @EndUserText.label: 'StartingPoint'
  .identification: [ { position: 30, label: 'StartingPoint' } ]
  .lineItem: [ { position: 30, label: 'StartingPoint' } ]
  .selectionField: [ { position: 30 } ]
  StartingPoint;

  @EndUserText.label: 'Destination'
  .identification: [ { position: 40, label: 'Destination' } ]
  .lineItem: [ { position: 40, label: 'Destination' } ]
  .selectionField: [ { position: 40 } ]
  Destination;

  .identification: [ { position: 50 } ]
  .lineItem: [ { position: 50 } ]
  .selectionField: [ { position: 50 } ]
  StartDate;

  .identification: [ { position: 60 } ]
  .lineItem: [ { position: 60 } ]
  .selectionField: [ { position: 60 } ]
  EndDate;

  @EndUserText.label: 'Budget'
  .identification: [ { position: 70, label: 'Budget' } ]
  .lineItem: [ { position: 70, label: 'Budget' } ]
  .selectionField: [ { position: 70 } ]
  Budget;

  @EndUserText.label: 'TransportMode'
  .identification: [ { position: 80, label: 'TransportMode' } ]
  .lineItem: [ { position: 80, label: 'TransportMode' } ]
  .selectionField: [ { position: 80 } ]
  TransportMode;

  @EndUserText.label: 'AccommodationType'
  .identification: [ { position: 90, label: 'AccommodationType' } ]
  .lineItem: [ { position: 90, label: 'AccommodationType' } ]
  .selectionField: [ { position: 90 } ]
  AccommodationType;


  // FULL-WIDTH AI ITINERARY
  @EndUserText.label: 'Generated Itinerary'
  .fieldGroup: [ { qualifier: 'AI_ITIN', position: 10, label: 'AI Generated Itinerary' } ]
  .multiLineText: true
  AiItinerary;


  // FULL-WIDTH AI BUDGET
  @EndUserText.label: 'Budget Breakdown'
  .fieldGroup: [ { qualifier: 'AI_BUDGET', position: 10, label: 'AI Budget Breakdown' } ]
  .multiLineText: true
  AiBudgetBreakdown;


  @EndUserText.label: 'Status'
  .identification: [ { position: 120, label: 'Status' } ]
  .lineItem: [ { position: 120, label: 'Status' } ]
  .selectionField: [ { position: 120 } ]
  Status;

   @EndUserText.label: '_BaseEntity'
  .identification: [ {
    position: 180 , 
    label: '_BaseEntity'
  } ]
  .lineItem: [ {
    position: 180 , 
    label: '_BaseEntity'
  } ]
  .selectionField: [ {
    position: 180 
  } ]
  _BaseEntity;

  

}

2.5 Preview travel app

1. Publish the local service endpoint of your service binding and start the Fiori elements App Preview. Open your service binding ZUI_RAP_TRAVEL_DATA_O4 and choose Publish.

2. Double-click on the Entity ZC_RAP_TRAVEL_DATA in the Entity Set and Association section to open the Fiori elements App Preview.

For reference: Create Database Table and Generate UI Service | SAP Tutorials

3. Create an Intelligent Scenario (Generative AI)

You first need to create an intelligent scenario for your custom Generative AI use cases. This scenario acts as the central place to manage the entire lifecycle of your AI asset from setup to generating inference results. All lifecycle steps can be executed through the Intelligent Scenario Management app. Here are the key steps to create an intelligent scenario:

3.1 Create ISLM Scenario
An intelligent scenario is an ABAP representation of a predictive business-specific use case. These intelligent scenarios are AI-powered workflows or processes designed to automate and optimize business tasks.

Select your package, right-click, New → Other → Intelligent Scenario → ZINTS_RAP120
Enter a name and description. Select SIDEBYSIDE for Scenario Technology field. Choose Next.
Set the following parameters for the created Intelligent Scenario.

Intelligent Scenario Lifecycle Management supports two primary types of intelligent scenarios:

Embedded Scenarios

Embedded scenarios are built and executed within SAP S/4HANA using the ABAP platform. They rely on the in-database machine learning capabilities of SAP HANA, such as: HANA Predictive Analysis Library (PAL), Automated Predictive Library (APL)

Side-by-Side Scenarios

Side-by-side scenarios, where SAP S/4HANA runs in a separate stack than its machine learning infrastructure provider, such as SAP Business Technology Platform (SAP BTP). These scenarios use external ML services or custom ML models.
Generative AI, SAP AI Core, Data Attribute Recommendation

For our scenario, we will be using the side by side scenarios type, sap SAPGEN AI
Turnkey Enablement: Automatically enable SAP-delivered (turnkey) GenAI use cases with minimal configuration effort.

Field	Value
Intelligent Scenario Type	SAPGENAI
Automate Turnkey Switch On	Check the checkbox
Usage Type	CUSTOMER

Activate the object.

3.2 Create ISLM Model

1. Select your package, right-click, New → Other → Intelligent Scenario Model

2. Fill the Description and Model Name fields. Assign the previously created scenario in Intelligent Scenario Name. Choose Next.

3. Enter the ExecutableID and Large Language Model Name and Large Language Model Version

Field	Possible values
Executable Id	o aicore-sap o aws-bedrock o azure-openai o gcp-vertexai
Large Language Model Name	It depends on the Executable Id
Large Language Model Version	One option is to leave the version field free, then the latest version will be used. This helps to avoid issues in case that the model has been deprecated in AI Core More info: https://me.sap.com/notes/3437766

4. Through the Prompt Library API, we can use predefined prompt templates to generate new prompts. Currently prompt templates are defined through ISLM. To get an instance of the prompt template you want to use, you need to provide the ISLM scenario and the ID of the prompt template. Click on Add and provide the following details:

Prompt Template Name: SYSTEM_PROMPT_ITIN
Prompt Template: System prompt for generating Itinerary
Prompt: You are a professional travel planner. Create a {ISLM_days} day itinerary for a given destination, including daily highlights, must-visit spots and activities. Keep it under 1000 characters.

5. The Prompt Parameters is captured from the prompt template after activation.

6. Add another prompt template for User prompt:

Prompt Template Name: USER_PROMPT_ITIN
Prompt Template: User prompt template
Prompt: Destination: {ISLM_destination} Departure: {ISLM_startingpoint} Travel Dates: {ISLM_startdate} to {ISLM_enddate} Mode of Transport: {ISLM_transportmode} Accommodation Type: {ISLM_accommodationtype} Generate the itinerary now

7. Activate the object
⚠ WARNING : Before you try the ABAP AI SDK out in an ABAP Class, please make sure that the deployment is running.

3.3 In Fiori Launchpad

To use the Intelligent Scenarios and Intelligent Scenario Management apps, you must have the appropriate access rights to the SAP Fiori Launchpad. The access for ISLM is added to the business role of an analytics specialist; BR_ANALYTICS_SPECIALIST.
You can create and manage ISLM Scenarios through Intelligent Scenario Management app.

You can check your previously created scenario in the Intelligent Scenario Management Fiori App.
In the next step instantiate ABAP AI SDK using the created ISLM Scenario

3.4. Consume Intelligent Scenarios in ABAP

ABAP AI SDK
The ABAP AI SDK powered by Intelligent Scenario Lifecycle Management (ISLM) is an ABAP reuse library that supports you in interacting with large language models (LLMs) hosted on the generative AI hub in SAP AI Core. Using the ABAP AI SDK, you can build your own AI-based features in ABAP.

Completion API
This API provides access to the completion API functionality of Large Language Models (LLMs), meaning that it uses an LLM to generate a text response from a prompt.

Prompt Library API
Using the prompt library API, you can use prompt templates predefined via ISLM to generate new prompts.

Catchable Exceptions
The execution of the completion API may cause an error, and therefore, CX_AIC_COMPLETION_API can be caught as a result. When the error is triggered by the LLM itself or by the AI service provider, CX_AIC_COMPLETION_API provides further information about the error.

Add a determination to the Travel Business Object and enhance it with the ABAP AI SDK powered by ISLM. Define the determination generateAIItinerary in the behavior definition ZR_RAP_TRAVEL_DATA and implement it in the behavior implementation class, aka behavior pool ZBP_R_RAP_TRAVEL_DATA.

1. Add the mandatory fields. Go to the Project Explorer and open your behaviour definition ZR_RAP_TRAVEL_DATA.

field ( readonly )
TravelID,
Status,
AiBudgetBreakdown,
AiItinerary,
LocalCreatedBy,
LocalCreatedAt,
LocalLastChangedBy,
LocalLastChangedAt,
LastChangedAt;

field ( mandatory : create )
TravelerName,
EndDate,
StartDate,
Budget,
AccommodationType,
StartingPoint,
TransportMode,
Destination;

determination generateAIItinerary on modify { create; }

Define the generateAIItinerary determination:

Save and activate the changes in ZR_RAP_TRAVEL_DATA.
Declare the required method in the behavior implementation class ZBP_RAP_TRAVEL_DATA using ADT Quick Fix Ctrl/Cmd + 1.
Save and activate the changes in ZBP_R_RAP_TRAVEL_DATA.
Let's implement the determination generateAIItinerary. In your implementation class ZBP_R_RAP_TRAVEL_DATA, in generateAIItinerary method implementation.
Replace the following code. Your code should look like this:

 METHOD generateAIItinerary.
    LOOP AT keys INTO DATA(ls_key).
      READ ENTITIES OF zr_rap_travel_data IN LOCAL MODE
      ENTITY ZrRapTravelData
      FIELDS ( destination startdate enddate transportmode accommodationtype     BudgetCurr ) WITH CORRESPONDING #( keys )
      RESULT DATA(lt_travel).
      LOOP AT lt_travel INTO DATA(ls_travel).
        DATA(days) = ls_travel-enddate - ls_travel-startdate + 1.
        DATA(itinerary) = ``.
        DATA(budget)    = ``.
        IF ls_travel-AiItinerary IS INITIAL OR ls_travel-AiBudgetBreakdown IS INITIAL.
          TRY.

*Calling the Prompt Library API.Through the Prompt Library API, we can use predefined prompt templates to generate new prompts.

              FINAL(sys_prompt_template_instance) =  cl_aic_islm_prompt_tpl_factory=>get( )->create_instance(
                                                   islm_scenario = 'ZINTS_RAP120' template_id = 'SYSTEM_PROMPT_ITIN' ).
              " Add a system prompt based on an ISLM prompt template with one parameter
              FINAL(sys_prompt) = sys_prompt_template_instance->get_prompt( parameters = VALUE #( ( name  = 'ISLM_days'    value = days  ) ) ).

              " Add a user prompt based on an ISLM prompt template with parameters
              FINAL(user_prompt_template_instance) =  cl_aic_islm_prompt_tpl_factory=>get( )->create_instance(
                                                  islm_scenario = 'ZINTS_RAP120' template_id = 'USER_PROMPT_ITIN' ).

              FINAL(user_prompt) = user_prompt_template_instance->get_prompt( parameters = VALUE #(
     ( name  = 'ISLM_startdate'
       value =  |{ ls_travel-startdate }| )
     ( name  = 'ISLM_enddate'
       value = |{ ls_travel-enddate }| )
         ( name  = 'ISLM_startingpoint'
       value = ls_travel-StartingPoint )
           ( name  = 'ISLM_destination'
       value = ls_travel-Destination )
     ( name  = 'ISLM_transportmode'
       value = ls_travel-transportMode )
        ( name  = 'ISLM_accommodationtype'
       value = ls_travel-accommodationtype )
   ) ) .




              FINAL(api_itin) = cl_aic_islm_compl_api_factory=>get( )->create_instance(
                                                      islm_scenario = 'ZINTS_RAP120' ).

*Set the LLM parameters
              FINAL(params) = api_itin->get_parameter_setter( ).
              params->set_maximum_tokens( 800 ).


              FINAL(msg_itin) = api_itin->create_message_container( ).
              msg_itin->set_system_role( sys_prompt ).
              msg_itin->add_user_message( user_prompt ).
              itinerary = api_itin->execute_for_messages( msg_itin )->get_completion( ).
            CATCH cx_aic_api_factory INTO DATA(lx_api_itin).
              itinerary = |AI instance creation failed for itinerary.|.
            CATCH cx_aic_completion_api INTO DATA(lx_comp_itin).
              itinerary = |AI completion call failed for itinerary.|.
          ENDTRY.
          IF itinerary IS NOT INITIAL.
            TRY.

* To pass prompts directly without prompt parameters
* Your ISLM scenario for itinerary

                DATA(system_prompt_budget) =
                  |You are a travel finance advisor. Based on the Itenary , destination, duration, | &&
                  |and total budget, estimate how much to allocate for travel, hotel, | &&
                  |food, sightseeing, and miscellaneous expenses. Output under 500 characters.|.
                DATA(user_prompt_budget) =
                  |Itenerary: { itinerary }| &&
                  |Departure: { ls_travel-StartingPoint }| &&
                 |Destination: { ls_travel-destination }| &&
                  |\nTravel Dates: { ls_travel-startdate } to { ls_travel-enddate }| &&
                  |\nTotal Budget: ₹{ ls_travel-Budget }| &&
                  |\nTotal Budget Currency: ₹{ ls_travel-BudgetCurr }| &&
                  |\nProvide a short, realistic breakdown.|.
                FINAL(api_budget) = cl_aic_islm_compl_api_factory=>get( )->create_instance(
                                                      islm_scenario = 'ZINTS_RAP120' ).
                " Your ISLM scenario for budget
                FINAL(msg_budget) = api_budget->create_message_container( ).
                msg_budget->set_system_role( system_prompt_budget ).
                msg_budget->add_user_message( user_prompt_budget ).
                budget = api_budget->execute_for_messages( msg_budget )->get_completion( ).
              CATCH cx_aic_api_factory INTO DATA(lx_api_budget).
                budget = |AI instance creation failed for budget.|.
              CATCH cx_aic_completion_api INTO DATA(lx_comp_budget).
                budget = |AI completion call failed for budget.|.
            ENDTRY.
          ENDIF.
          MODIFY ENTITIES OF zr_rap_travel_data  IN LOCAL MODE
            ENTITY ZrRapTravelData
           UPDATE FIELDS ( aiitinerary aibudgetbreakdown status )
            WITH VALUE #(
              ( %tky = ls_travel-%tky
                aiitinerary        = itinerary
                aibudgetbreakdown = budget
                status              = 'Generated' )
            ).
        ENDIF.
      ENDLOOP.
    ENDLOOP.

  ENDMETHOD.

Save and activate the changes in ZBP_R_RAP_TRAVEL_DATA.
Preview and test the enhanced Travel Itinerary App with Generative AI Capabilities.

For the latest updates, subscribe to the blog posts below :

ABAP AI - Chapter 2 - SAP Community
Introducing the Next Era of ABAP Development - SAP Community
Joule speaks ABAP! - SAP Community
From Legacy to AI-Powered: RISE Transformation Rev... - SAP Community

Happy Learning!

RAP Draft Action EDIT Contract Violation: Failed not allowed cl_dsp_act_comn_exec_add_impl - Solved

2026-01-23T13:30:38.986000+01:00

Scenarion: Custom RAP unmanaged behavior implementation with draft - strict

 draft action Edit with additional implementation; // additional implementation to provide virtual elements

In this Implementation of EDIT in the Z-behavior pool we checked if a delivery on this items exists, if so we raise a FAILED an a REPOTED Message

Due to changes in the RAP Framework it looks like in the method EDIT with additional behavior, no FAILED is allowed anymore ( See comment below )
The HTTP-Error is the result of a dump: “Contract Violation: Failed not allowed”

The issue is a change in the RAP framework that is not compatible with our current implementation Edit (with additional implementation). During the EDIT operation, an error is detected because the tour has deliveries and the fields FAILED and REPORTED are filled.
However, RAP no longer allows this.

Cass cl_dsp_act_comn_exec_add_impl -> lcl_implementation -> Method lif_implementation~execute are these new lines

These lines raise the short dump if there are failed messages:

Solution

Business Requirement is to do checks right before an entity will be put into edit mode, such that an draft for an active item is created. Using the provided RAP Feature Control is not an option, as:
1. We do not want to check that upfront for all items of the list
2. We wand to do the check in that moment a user requests the draft.

We moved the check into the framework method LOCK, here we are allowed to raise FAILED an Reported.

I am not 100% sure that this is the best place for "Draft Pre-Checks" but I did not find any better.
Pre-Checks are not possible for EDIT actions.

Thanks go out to @Sschlegel & Björn Schulz

Why Document Like it's 1999

2026-01-31T19:19:27.708000+01:00

Your First Day on the New Project

You open the documentation repository. There's an Excel sheet titled “RICEFWInventoryv3FINAL2.xlsx”

You scan through:

Row 47: “Enhancement ZENHMAT001 – Material validation”
Row 89: “Report ZMMSTOCK013 – Stock overview”
Row 134: “Form ZSDORDERPRINT – Order output”
Row 201: “Interface ZIFPRICING002 – Pricing calculation”

Your task: “Fix the credit check bug in sales order creation.”

You stare at the screen. Which row is that?

You search for “credit”. Eight matches. Three are reports. Two are enhancements. One is a workflow you've never heard of.

You ask your colleague: “Where's the credit check logic?”

She sighs. “Check the validation BADI in ZFICO_CUST. Or is it the user exit? Actually, I think there's also a workflow step... let me check my notes from six months ago...”

Three hours later, you still haven't found it.

Sound familiar?

The Problem with RICEFW Documentation

RICEFW Thinks in Technical Artifacts

RICEFW (Reports, Interfaces, Conversions, Enhancements, Forms, Workflows) was invented when SAP development meant: – Modifying a monolithic ECC system – Creating standalone reports – Adding enhancements to standard transactions – Building separate interfaces

Documentation followed the same pattern: categorize by technical artifact type.

This made sense in 1999.

RAP Thinks in Business Capabilities

Fast-forward to 2026. You're building a Sales Order business object in RAP:

ZI_SALESORDER_M (Business Object)
├── Data Model (CDS views)
│   ├── ZI_SALESORDER_M (interface view)
│   └── ZC_SALESORDER_M (projection view)
├── Behavior Definition
│   ├── Validations (validateCustomer, validateCredit)
│   ├── Determinations (calculatePrice)
│   └── Actions (releaseOrder, cancelOrder)
├── Business Events
│   └── OrderCreated, OrderReleased
└── Service
    └── ZUI_SALESORDER_O4 (OData V4)

Everything about Sales Orders in one cohesive business object.

Yet your documentation still says: – “Check Enhancement ZENHSD001” – “See Report ZSDORDERLIST” – “Refer to Form ZSDPRINTORDER”

The disconnect is killing you.

What RAP Actually Gave Us - besides RAP itself

Here's what's often missed in RAP discussions:

RAP isn't just a new technical framework. It's SAP finally embracing domain-driven design principles that the rest of the software world has used for years.

Business objects that model business capabilities
Clean separation of concerns
Event-driven architecture
Clear service boundaries

This is how modern software should be built.

And when you build this way, your documentation can finally match how people hopefully think.

Not “Which enhancement modifies field X?”

But “How does the Sales Order capability work?”

RAP enables the documentation style we should have been using all along.

Now the good stuff - Three Documentation Layers for RAP

Layer 1: Business Object Canvas

The idea: One wiki page per RAP business object. Everything about that capability in one place.

Here's what it actually looks like:

Business Object: Sales Order

Business Capability: Complete sales order lifecycle from customer inquiry through order fulfillment

Location in System: – Package: ZRAP_SD_ORDER – Root Entity: ZI_SALESORDER_M – Projection: ZC_SALESORDER_M – Service Binding: ZUI_SALESORDER_O4 (OData V4, Published) – Fiori App: Sales Order Management – Main Transport: ZTRK900123

Team & Ownership: – Development Team: Retail Sales Team – Product Owner: Jane Smith – Technical Lead: John Doe – Last Major Update: 2025-01-27

Behavior & Operations:

Standard Operations: – Create, Update, Delete (all enabled) – Draft handling: Enabled – ETag field: LastChangedAt

Validations (run on save):

validateCustomer Checks customer exists and is not blocked
validateCreditLimit – Verifies customer credit limit not exceeded
validateMaterial – Ensures material exists and valid for sales
validateDeliveryDate – Must be in the future

Determinations (auto-calculations):

calculateNetAmount – Runs when quantity or price changes
setDefaultPaymentTerms – Runs on create (from customer master)
determineDeliveryDate – Calculates based on material availability

Actions (user-triggered):

releaseOrder – Releases order to warehouse (publishes OrderReleased event)
cancelOrder – Cancels entire order (publishes OrderCancelled event)
splitOrderItem – Splits line item into multiple delivery schedules

Events & Integration:

Events Published:

OrderCreated – When order activated from draft – Subscribers: Inventory BO (reserves stock), Analytics Service
OrderReleased – When release action executed – Subscribers: Warehouse BO (starts picking), Billing BO (creates invoices
OrderCancelled – When cancel action executed – Subscribers: Inventory BO (releases reservation)

Events Subscribed:

StockReserved (from Inventory BO) – Updates order status to “Ready for Release”
StockShortage (from Inventory BO) – Marks order as “Partially Allocated”

Dependencies:

Upstream (What We Consume):

Material Master (I_Product) – Owner: Master Data Team – Access: Read-only via association – Fields used: Product, ProductType, BaseUnit, SalesText – Impact if unavailable: Order creation blocked (validation fails) – Contact: master-data-team@company.com

Customer Master (I_Customer

Owner: Master Data Team
Access: Read-only via association
Fields used: Customer, CustomerName, CreditLimit, PaymentTerms
Impact if unavailable: Order creation blocked (validation fails)
Contact: master-data-team@company.com

Pricing Engine (ZZPRICEENGINE – Function Module)

Owner: Pricing Team – Access: Synchronous RFC call (wrapped in ZCLPRICING_ACL)
Called when: During determination (calculateNetAmount)
Timeout: 5 seconds
Impact if unavailable: Order creation blocked, error shown to user
Why synchronous: [See ADR-018]
Contact: pricing-team@company.com

Downstream (Who Consumes Us):

Inventory BO (subscribes to OrderCreated, OrderCancelled)
Warehouse BO (subscribes to OrderReleased)
Billing BO (reads order data via association, subscribes to OrderReleased)
Analytics Dashboard (reads via OData for reporting)
Mobile Sales App (reads/writes via OData)

Key Architecture Decisions:

[ADR-015] Why we chose managed RAP implementation
[ADR-018] Why pricing happens in determinations (not actions)
[ADR-023] How we handle external pricing service integration
[ADR-032] Why credit check is synchronous (blocks save)

Related Documentation:

API Documentation: OData Service Spec
Process Documentation: Order-to-Cash Process (coming in Part 2 of this series)
Test Data: Customer 1000001, Material MAT-TEST-001

That's the canvas. One page. ~5 minutes to scan. Everything about Sales Orders.

Compare this to hunting through a RICEFW spreadsheet with 200 rows.

Layer 2: Architecture Decision Records (ADRs)

The hard part isn't writing RAP code. It's deciding why to write it a certain way, and later remembering why that decision was taken.

The Industry Solution: Architecture Decision Records

This problem isn't unique to SAP or RAP. It's why organizations like AWS and IBM actively recommend using Architecture Decision Records (ADRs) to capture the reasoning behind technical decisions.

AWS Prescriptive Guidance recommends using architectural decision records to streamline technical decision-making for a software development project. Architectural Decision Records IBM has documented their use of ADRs in production systems, showing how they help teams maintain context over time.

The principle is simple: when you make a significant technical decision, document why you made it, what alternatives you considered, and what consequences you accepted.

Six months later, when someone asks "Why?", you point them to the ADR.

Example ADR:

ADR-018: Calculate Pricing in Determinations (Not Actions)

Date: 2025-01-15
Status: ✅ Accepted
Deciders: Tech Lead, Solution Architect, Senior Developer

Context:

We need to calculate item pricing in Sales Order BO. Two options:

Option A: Determination (automatic) – Runs automatically during save sequence – User sees price immediately when quantity changes – Can't be skipped

Option B: Action (manual) – User must click “Calculate Price” button – More control over when calculation happens – Can be skipped if needed

Current situation: – Pricing engine (ZZPRICE_ENGINE) is legacy FM, ~2 second response time – Business requires instant price feedback for sales reps – Complex pricing rules (discounts, surcharges, customer agreements)

Decision:

Use determination to calculate pricing automatically on quantity/material changes.

Rationale:

Why determination:

Sales reps need instant price visibility
Prevents orders being saved with wrong/missing prices
Aligns with UX requirement: “price updates as you type”
Consistent with standard SAP behavior

Why not action:

Extra click burdens sales reps (average 50 orders/day/rep)
Risk of forgetting to calculate = wrong invoices
User testing showed confusion with manual pricing button

Risks accepted:

2-second save time (acceptable per UX testing)
Pricing service must be highly available (99.9% SLA)

Consequences:

Positive:

Instant price feedback for sales reps
No risk of missing price calculation
Reduced training time (automatic behavior)
Consistent UX across all sales channels

Negative:

Every save calls pricing engine (load concern)
Can't skip pricing for “draft” scenarios
Pricing service downtime blocks all orders

Mitigations:

Pricing service has 5-second timeout (fail-fast)
Fallback: save order with “Price Pending” flag, batch re-price later
Pricing team committed to 99.9% SLA
Monitoring alert if pricing calls >3 seconds

Implementation Notes:

determination calculateNetAmount on modify {
  field Quantity;
  field Material;
  field Customer;
}

In behavior implementation: – Call ZCLPRICINGACL wrapper (not direct FM call) – Wrapper implements circuit breaker pattern – Logs all pricing calls for debugging

Related: – [ADR-023] Anti-corruption layer for pricing service – [ADR-040] Pricing service timeout handling

The principle: Six months from now, when someone asks “Why does save take 2 seconds?”, you point to ADR-018. Everything is documented.

The principle: When Master Data announces “We're changing Material descriptions from 40 to 80 characters,” you know instantly that 12 BOs need coordination.

Part 4: Why This Works

RICEFW Docs BO Canvas Approach

ZTRK900123 – Enhancement for credit check	Sales Order BO → validateCreditLimit
5 spreadsheet tabs	1 wiki page
Technical artifact types	Business capabilities
“Why?” is in meeting notes	“Why?” is in ADRs
Dependencies invisible	Dependency matrix
3 hours to find credit check	3 minutes to find credit check

Real impact:

Onboarding time:

RICEFW: weeks to understand one domain
BO Canvas: days to understand one domain

Incident response:

RICEFW: “Where's the logic?” → hours–
BO Canvas: “Check Sales Order BO canvas” → minutes

Impact analysis:

RICEFW: “Who uses Material Master?” → “¯\(ツ)/¯”
BO Canvas: “Check dependency matrix” → 12 BOs listed

Part 5: What This Doesn't Solve (Yet)

You've documented your Sales Order BO beautifully. Dependencies are clear. Decisions are captured.

Then someone asks: “Walk me through what happens when a customer creates an order. Step by step. Including credit check, stock reservation, pricing, and warehouse handoff.”

You point them to four BO Canvases:

Sales Order BO
Credit Check BO
Inventory BO
Shipping BO

They read all four. They check dependencies. They still don't understand the sequence of events , what happens if credit check fails etc.

Business Object Canvases document capabilities, ADRs document decisions, Dependency matrices document connections.

But none of them document the actual business process flow, ant that's why that's the topic for the next post in this series.

Next in this series: Part 2: Documenting Business Processes – From BOs to Flows

What's your biggest documentation challenge? Drop a comment below.

Updating records using Dialog Box in RAP

2026-02-03T07:30:32.746000+01:00

Description : In this blog, we implement a RAP-based solution to update existing records using a Dialog Box (popup) instead of navigating to a separate page.

In this scenario user need to update the records in list page itself instead of going of going to object page using a dialog box in RAP application

Step 1 : Create a Data base table

@EndUserText.label : 'DB table for Numbering' 
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE 
@AbapCatalog.tableCategory : #TRANSPARENT 
@AbapCatalog.deliveryClass : #A 
@AbapCatalog.dataMaintenance : #RESTRICTED 
define table zfa_dt_num { 
key managed_num : sysuuid_x16 not null; 
key unmanged_id : char10 not null; 
name : char10; 
age : char2; 
attendance_status : char10; 
lastchangedat : abp_locinst_lastchange_tstmpl; 
}

Step2 : create a interface view and projection view upon data base

Interface View

@AbapCatalog.viewEnhancementCategory: [#NONE] 
@AccessControl.authorizationCheck: #NOT_REQUIRED 
@EndUserText.label: 'interface view for numbering' 
@Metadata.ignorePropagatedAnnotations: true 
define root view entity zi_zfa_num as select from zfa_dt_num 
{ 
key managed_num as ManagedNum, 
key unmanged_id as UnmangedId,
name as Name, 
age as Age, 
attendance_status as AttendanceStatus, 
@Semantics.systemDateTime.localInstanceLastChangedAt: true 
lastchangedat as LastChangeAt 
}

Projection View

@AccessControl.authorizationCheck: #NOT_REQUIRED 
@EndUserText.label: 'Projection view num' 
@Metadata.ignorePropagatedAnnotations: true 
@Metadata.allowExtensions: true 
define root view entity zc_zfa_num 
as projection on zi_zfa_num  
{ 
key ManagedNum, 
key UnmangedId, 
Name, 
Age, 
AttendanceStatus, 
@Semantics.systemDateTime.localInstanceLastChangedAt: true 
LastChangeAt

Step3 : create a behavior definition for both interface view and projection view

Interface View Behavior definition

managed implementation in class zbp_i_zfa_num unique; 
strict ( 2 ); 
define behavior for zi_zfa_num //alias <alias_name> 
persistent table zfa_dt_num 
lock master 
authorization master ( instance ) 
etag master LastChangeAt 
late numbering 
{ 
action Updateatt parameter za_zfa_num result[1] $self; 
create ( authorization : global ); 
update; 
delete; 
field ( readonly ) ManagedNum , UnmangedId; 
mapping for zfa_dt_num{ 
ManagedNum = managed_num; 
UnmangedId = unmanged_id; 
Name = name; 
Age = age; 
AttendanceStatus = attendance_status; 
LastChangeAt = lastchangedat; 
} 
}

Projection view Behavior defination

projection; 
strict ( 2 ); 
define behavior for zc_zfa_num //alias <alias_name> 
use etag 
{ 
use create; 
use delete; 
use action Updateatt; 
}

Step4 : implement the behavior pool class

CLASS lhc_zi_zfa_num DEFINITION INHERITING FROM cl_abap_behavior_handler. 
PRIVATE SECTION. 

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

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

METHODS updateatt FOR MODIFY 
IMPORTING keys FOR ACTION zi_zfa_num~updateatt RESULT result.  

ENDCLASS. 

CLASS lhc_zi_zfa_num IMPLEMENTATION.
 
METHOD get_instance_authorizations. 
ENDMETHOD. 

METHOD get_global_authorizations. 
ENDMETHOD.

METHOD Updateatt.
 
data(lt_keys) = keys. 
read eNTITIES OF zi_zfa_num in LOCAL MODE 
ENTITY zi_zfa_num 
fiELDS ( AttendanceStatus Name Age ) wiTH corRESPONDING #( keys ) 
reSULT data(lt_res). 
data(lv_new_status) = lt_keys[ 1 ]-%param-attendance_status. 
data(lv_new_Name) = lt_keys[ 1 ]-%param-name. 
data(lv_new_age) = lt_keys[ 1 ]-%param-age. 
modIFY enTITIES OF zi_zfa_num in LOCAL MODE 
entity zi_zfa_num 
uPDATE fiELDS ( AttendanceStatus Name Age ) 
wITH vaLUE #( ( 
%tky = lt_res[ 1 ]-%tky 
AttendanceStatus = lv_new_status 
Name = lv_new_name 
age = lv_new_age  
) ). 

read eNTITIES OF zi_zfa_num in LOCAL MODE 
ENTITY zi_zfa_num 
all fiELDS wiTH corRESPONDING #( keys ) 
reSULT data(lt_res1). 
result = value #( 
for <lfs_num> in lt_res1 ( 
%tky = <lfs_num>-%tky 
%param = <lfs_num> 
)
). 

ENDMETHOD. 

ENDCLASS.
 
CLASS lsc_ZI_ZFA_NUM DEFINITION INHERITING FROM cl_abap_behavior_saver.
PROTECTED SECTION. 

METHODS adjust_numbers REDEFINITION. 

METHODS cleanup_finalize REDEFINITION. 

ENDCLASS. 

CLASS lsc_ZI_ZFA_NUM IMPLEMENTATION. 

METHOD adjust_numbers. 
DATA(lt_managedid) = cl_uuid_factory=>create_system_uuid( )->create_uuid_x16( ).  
SELECT MAX( unmanged_id ) FROM zfa_dt_num INTO (lv_num).
IF sy-subrc = 0. 
lv_num += 1 . 
ELSE. 
lv_num = 000000001 . 
ENDIF. 
LOOP AT mapped-zi_zfa_num REFERENCE INTO DATA(ls_num). 
ls_num->ManagedNum = lt_managedid. 
ls_num->UnmangedId = lv_num. 
ENDLOOP. 

ENDMETHOD. 

METHOD cleanup_finalize. 

ENDMETHOD. 

ENDCLASS.

Step 5 : For achieving the Dialog box we have to make use of a abstract entity , in this abstract entity declare the fields which you have to update

@EndUserText.label: 'Abstract entity for numbering' 
@Metadata.allowExtensions: true 
define abstract entity za_zfa_num 
// with parameters parameter_name : parameter_type 
{ 
name : char10; 
age : char2; 
attendance_status : char10; 
}

Step 6 : create a metadata for this abstract entity

@Metadata.layer: #CORE 
annotate entity za_zfa_num with 
{ 
@EndUserText.label: ' Update Name' 
name; 
@EndUserText.label: ' Update Age' 
age; 
@EndUserText.label: 'Set Student Status' 
attendance_status; 
}

Step7 : now for displaying the popup we have to make use of custom actions , declare a actions with parameters , in parameter give the abstract entity name

Step8 : now implement the logic for updating the records in action method

METHOD Updateatt. 

data(lt_keys) = keys. 

read eNTITIES OF zi_zfa_num in LOCAL MODE 
ENTITY zi_zfa_num 
fiELDS ( AttendanceStatus Name Age ) wiTH corRESPONDING #( keys ) 
reSULT data(lt_res). 
data(lv_new_status) = lt_keys[ 1 ]-%param-attendance_status. 
data(lv_new_Name) = lt_keys[ 1 ]-%param-name. 
data(lv_new_age) = lt_keys[ 1 ]-%param-age. 

modIFY enTITIES OF zi_zfa_num in LOCAL MODE 
entity zi_zfa_num 
uPDATE fiELDS ( AttendanceStatus Name Age ) 
wITH vaLUE #( ( 
%tky = lt_res[ 1 ]-%tky 
AttendanceStatus = lv_new_status 
Name = lv_new_name 
age = lv_new_age 
) ). 

read eNTITIES OF zi_zfa_num in LOCAL MODE 
ENTITY zi_zfa_num 
all fiELDS wiTH corRESPONDING #( keys ) 
reSULT data(lt_res1). 
result = value #( 
for <lfs_num> in lt_res1 ( 
%tky = <lfs_num>-%tky 
%param = <lfs_num> 
)  
).

ENDMETHOD.

Step9 : Create a service definition and service binding for the projection view and expose it

Here we can see we have 2 records and a button is visible UPDATE RECORDS

Select the button and click on the update record action

Edit the records

Here you can see the records have been updated

Conclusion : Using a Dialog Box in RAP makes record updates faster and more user-friendly by keeping the user on the same screen while still following RAP’s behavior, validations, and transactional processing

Tweaks for RAP BO events addressing filtering (before send) and too small payload (callbacks needed)

2026-02-03T15:18:52.529000+01:00

Are you working on modernizing your SAP integrations, or looking for better ways to integrate with clean core compliance? But when you've looked at "Event Objects" from the SAP Business Accelerator Hub, you have found that it's not exactly matching your needs? Too many events are fired (can I filter?). The callback API is too time-consuming/unwanted. Or maybe you are simply interested in how ABAP RESTful Programming Model (RAP) Events work, how you can use and/or extend SAP Standard events?

In this blog I'll go through first some basic info and then start to showcase some tips / tweaks / workarounds you may or may not be aware about. Let's go.

1 ABAP RESTful Programming Model (RAP) Events Intro

I'll keep this very brief as the meat of this blog is to go into the nitty-gritty details. But, for the uninitiated, RAP BO events are events that have been built with the RAP framework which can easily integrate with event brokers, such as SAP Business Technology Platform's Event Mesh or Advanced Event Mesh. They are a sort of modern version of BTEs. You may refer to a previous blog of mine where I go into one full end-to-end example, showcasing how to find SAP standard events and then use them: Working with RAP BO Events end-to-end . The short version is that all events can be found on the SAP Business Accelerator Hub -> Your SAP Product -> Events.

2 Too many events are fired / I want to filter

This is probably one of the most common discussion points when I work with my customers. More often than not a "Created" or even more interestingly, a "Changed" event is simply fired too often for the actual integration needs. So what can we do here? In essence we have 3 main options:

Integration middleware handles filtering (= no changes in SAP system, use event as is)
1. This can be desirable if there are lots of receiving systems that need to receive information for a certain object, and maybe each of them would like to filter a little different. The middleware receives the event as it happens and can then handle the distribution accordingly. This way 1 single event could be the foundation of several functioning integrations (instead of several point-to-point integrations). The quote-on-quote downside to this is that you would of course increase the complexity in the middleware itself, but again if the same event benefits several receivers, this could be a good option.
Extend SAP standard event to include filtering fields (= extension development in your SAP system, use extended event, not standard)
1. This can be used if you know for sure you always want to filter out certain types of objects, that none of the integrated systems would want to be informed about. The quote-on-quote downside here is that we need to create an extension. Secondly, we first have to check if the SAP Standard RAP BO in question even allows behavior extensions. If not, we cannot use this option at all.
Use custom event in combination with SAP Standard event as a workaround (= custom development in your SAP system, use custom event, not standard)
1. Same as for the previous one, this option can be used if we know for a fact we always want to filter away certain objects. We can use this over the extend option, if for example the extension was not possible, or if the extension possibilities do not suffice (for example we need to add fields that are not easily associated in the RAP BO, or we need some complex logic and checking before we send an event)

As this blog focuses on RAP, I'll skip the first option and let the integration gurus tackle that one. Let's take a closer look at the other two...

2.1 Extend SAP standard event

If we found a suitable SAP standard RAP BO event and all we want is to add a few filter fields, we can do that with what is called Derived Events. Please refer to this page for details: Derived Business Events | SAP Help Portal

For my showcase I'll be using R_SalesOrderTP~Changed event. First of, we need to check if the behavior definition of the BO allows extensions. Open it and check for the word "extensible" somewhere at the beginning of the definition + on the entity which has the event (so we need two extensible).

If it's there, we can proceed. Next we can also check the event itself and the payload (if no parameter statement is written there, the payload is the key field(s) of the BO alone).

2.1.1 Create derived event payload with filter fields

Before we extend the behavior, we need a custom payload that includes our filter fields. Create a new data definition root entity and define your custom payload. For example:

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Sales Ord. ext. event for derived event'
define root view entity ZP_SalesOrder_EventExt as select from I_SalesOrder
{
  key SalesOrder,
  .context.attribute: 'xsapordtype'
  SalesOrderType,
  .context.attribute: 'xsapslsorg'
  SalesOrganization,
  .context.attribute: 'xsapbillplc'
  _BillingPlan.BillingPlanCategory,
  DistributionChannel,
  OrganizationDivision,
  SoldToParty,
  CustomerGroup,
  ShippingCondition,
  IncotermsClassification,
  OverallSDProcessStatus
}

Few points:

Key fields must match the RAP BO you are extending
You can access fields just like the standard RAP BO and also associated fields (I showcase this with BillingPlanCategory above). Note, we focus only flat structures, so the associated field needs to be 1:1 (for deep structures, please refer to chapter 3).
With above, we created exactly 3 filter fields: Sales Order Type, Sales Organization, and Billing Plan Category. Filters must have the annotation "Event.context.attribute" and must start with "xsap"!

2.1.2 Extend standard RAP BO behavior to create a derived event (with our custom payload)

Now we are ready to extend the behavior definition as per usual practice: find/display it in the project explorer - right click - New Behavior Extension. Here type out your derived event, for example:

extension
//using interface i_salesordertp
;
extend behavior for SalesOrder {
  managed event ZZChangedExtended on Changed parameter ZP_SalesOrder_EventExt;
}

Few notes on the above:

First of I want to start with the interface commented away above. Bear with me, this is important to understand!
In RAP it is always best to interact with RAP BOs via their interface, if there is one (not to be confused with a basic interface view, such as I_SalesOrder or I_Customer etc., which reads from the DB table). In the case of R_SalesOrderTP, it has a transactional interface called I_SalesOrderTP. This interface is meant as a stable "API" to interact with the BO, and is usually released with C1/C0 contracts for clean core compliance. So in truth, we should be using the interface as we are extending this BO, but as you see above, it's commented away. That is because we must, in this case. I_SalesOrderTP does not include any of the events, and because we need those, we cannot use the interface in this case. What this means is that my extension behavior definition, as of right now, must be saved as "Standard ABAP" and cannot be assigned to a package with an ABAP Cloud software component. HOWEVER, this is clean core compliant, because R_SalesOrderTP is released with a C0 contract for extension, thus allowing such extensions. The problem is that the syntax check for ABAP for Cloud Development only checks for C1 contracts (which is missing on R_SalesOrderTP behavior), which is why, as of right now, we have to save this as Standard ABAP, meaning a "level B" extension which is clean core compliant (it would have been "level C", if R_SalesOrderTP hadn't had the C0).
The rest is quite straight forward. We say which entity we are extending (SalesOrder, using the alias in the behavior definition) and we are stating the Changed event to be extended with ZZChangedExtended with our own payload we previously created.

2.1.3 Create Event Binding for derived event

Next up we need an Event Binding for our derived event. As a small side note: if you only intend to consume your own derived within your SAP system (the same system) and not send it out to an event broker, then you would not need an event binding.
Create a new Event Binding object (Business Service - Event Binding or just search for event binding in the new ABAP object dialog) and add the event we just created to it:

Note that we of course refer to the SAP Standard RAP BO, which now includes our derived event thanks to the extension we just did.

2.1.4 Configure Event Channel to include your derived event

Lastly, to send our derived event to an event broker, we need to add it to our event channel. Assuming you already prepared an event channel (refer to my other blog linked above for more info on that), go to /n/IWXBE/CONFIG, select your event channel and go to Outbound Bindings.

Click the create button to add the event binding you just created. It could look something like this:

The above means that my Event Mesh on my BTP subaccount receives the SAP standard Sales Order Created event, and my own derived Sales Order Changed event.

And that's it: now we are ready for filtering or for simply getting the larger payload as per our derived event.

2.1.5 Adding Filters

In the same location as we were (/n/IWXBE/CONFIG -> Event Channel -> Outbound Bindings) click on the button Filters at the top. Open up the folder Outbound Bindings for your event channel and click on your derived event. Clicking on the plus-button shows all available filter fields, in this example:

Create a filter, for example that only Sales Order Type "OR" should be sent to out:

2.1.6 Subscribe to the event on your event broker

To receive this derived event for example in Event Mesh on SAP BTP, you need of course a corresponding queue and then add the subscription for this new derived event. In my example:

2.1.6 Test example

I changed a sales order in my system and saved. This now triggered my derived changed event, which I can see in the events monitoring transaction /n/IWXBE/EVENT_MONITOR (select event channel, click on Outbound Events, double-click on derived event)...

...and on SAP BTP Event Mesh where I added the subscription:

Here we can only see what's sitting in the queue. So let me consume the message in the test tool to show the same payload as in our monitor:

Awesome! We succeeded and this concludes the extend event option.

2.2 Use custom event in combination with SAP Standard event

This is an interesting one and in my experience comes with some confusion attached to it. I have heard sentences such as "But can't we just create a custom event instead of the standard one and use that?" And the simple answer to that is yes, but no 😊. Let me explain...

Now of course if we create our own, custom RAP BOs, we can add events to them. That is clear. And within that custom BO you decide when that event is fired. Clear and no problem. But this is all custom.

And now, if you want "your custom event" to be trigged during SAP standard processing, well no, SAP standard can't do that, as it does not know your custom event exists. And if you are thinking to use user exits or BAdIs to do this; think again, because it would be wrong to do so. User exits and BAdIs are called while the processing has not yet completed. Meaning at this point, in theory, something could still go wrong (no update in DB), but you already triggered your event. So, do not do this, ever! The point of the event framework is to inform about a state change. So you only want to do that, if the state change has actually occurred, meaning after the DB is fully updated.

So what else then, you wonder? That's where the SAP standard event comes in (which yes, is fired AFTER the state change occurred and all processing has completed). The SAP Standard event will trigger, and thus if you want more flexibility than just explored in the previous option with the extension of the SAP standard event, that's when we can try to combine standard with custom event.

Essentially, this is the pattern:

SAP standard process does something, which triggers an event for a certain object. This triggering happens at the exact time you want, but the SAP Standard event does not fulfill your requirement (and we can't / don't want to do a derived event)
You will create a custom event on a "dummy" RAP BO which includes the exact payload you need (flat structure for EM, it can be a deep one for AEM).
You will create a local event listener (within your SAP system) for the SAP standard event that triggers at the right moment. Within this local consumption you can now do any ABAP logic you may need. Complex filtering. Complex data collection (calling BAPIs or other things) etc.
Once all your data validation and collection is done, you fill the payload format of your custom event and finally you trigger your custom event (with a slight workaround, as events can only be raised from with the RAP BO itself)
You only configure your custom event in the event channel for the event broker. The event arriving there is ready to be consumed with all needed fields and only events are that are really expected are arriving there.

Let's do this example now. We stick with R_SalesOrderTP, this time using Created as the SAP Standard event.

Let's assume I don't just want to send all sales order that are created. Sales order type filtering is not good enough. In fact, it matters whether a product is sold that has certain characteristics, for example. As a simplified example here, I will only check the product type of the product, but hopefully this gives you some ideas; we could check anything at this point.

2.2.1 Create custom event

Our custom event doesn't need much of a BO. Meaning we don't want to (re)create read/update/delete etc. functionality, but this is purely for defining how the event payload should look like and for triggering the custom event.

In my example I took it a step further: what if I create a generic "event forwarder", that could potentially be used together with many SAP standard objects? Now, this isn't to say that I recommend this approach, in fact quite the opposite. And depending on your exact requirement, this may definitely the wrong approach. But I did this also in an effort to answer if this is at all feasible.

If having an event trigger with only key field information and then having a subsequent callback API later in the integration is a good pattern for you, then this could potentially help you, as you could reuse it for several use cases.

But, if instead you want something very specific, for example only forward my object under certain circumstances and including already all data needed, then of course it makes more sense to create a tailored custom event, with the exact payload of that object you want.

So please bear that in mind as we continue with this example. With this example I handle only a generic key-field based payload.

2.2.1.1 Custom entity data definition

We start of course with the data definition. Custom entity is in my opinion the best, as again we don't actually need any read or update functionality, but we simply describe our event payload at this point (and here you could have a large flat/deep structure):

@EndUserText.label: 'Event Forwarder BO'
define root custom entity ZR_EventForwarder
{
  key ObjectKey  : abap.string;
  key ObjectType : zevent_fwd_object;
}

2.2.1.2 Custom entity behavior definition

Next we need the behavior that will include our custom event:

unmanaged implementation in class zbp_r_eventforwarder unique;
strict ( 2 );

define behavior for ZR_EventForwarder
lock master
authorization master ( instance )
{
  field ( readonly ) ObjectKey, ObjectType;
  event ForwardEvent;
}

Finally, let ADT generate the BP implementation for you (we do not need to fill any of the methods but so it's properly created (again, we need no read/save methods etc.)). So I will not paste the whole Class/or Local Types.

Instead, what we need to do here is now offer an option to "raise" our custom event "ForwardEvent" from outside this BO. The "raise entity event" command is not allowed outside the RAP BO itself. So instead, we need to encapsulate it in a way that ABAP code from outside this behavior pool can call it. For this we need 2 things:

"Local event handler" (not actually inheriting anything => chose this to separate it from other, standard RAP BP behavior methods)
Method in the global class that can be called from other ABAP code

Let's start with the "local event handler". Within the section Local Types of your behavior implementation class, add something this:

class lcl_event_handler definition friends zbp_r_eventforwarder.
  public section.
    class-methods on_forward_event importing it_events type zbp_r_eventforwarder=>tt_events.
endclass.

class lcl_event_handler implementation.
  method on_forward_event.
    raise entity event zr_eventforwarder~forwardevent from it_events.

  endmethod.
endclass.

Note the "friends" command in the class definition. This is needed to be able to access private/protected class variables from the behavior pool (raising our entity event).

And in the Global Class, we change it as follow (full code copied):

class zbp_r_eventforwarder definition public abstract final for behavior of zr_eventforwarder.
  types tt_events type table for event zr_eventforwarder~forwardevent.

  public section.
    constants:
      co_type_salesorder    type zevent_fwd_object value 'SALESORDER'.
    class-methods raise_forward_event
      importing it_events   type tt_events.


endclass.

class zbp_r_eventforwarder implementation.
  method raise_forward_event.
    " tell RAP framework that we are in a SAVE sequence (otherwise it thinks
    " we are in the middle of a MODIFY)
    cl_abap_tx=>save( ).
    " trigger event (only allowed during SAVE)
    lcl_event_handler=>on_forward_event( it_events ).
  endmethod.
endclass.

We did 3 main things: a global type for the event payload table, a constant to distinguish different types of RAP BO that I mean to handle with my generic one (right now only one) and, most importantly, a global class method that can be called from other ABAP code.

2.2.1.3 Event Binding

As before, we need an event binding if we want to forward this to an event broker:

(Namespace, object type etc. can be freely chosen.)

And that's all for our custom event. Remember that the only purpose of this custom event is to offer a way to define the payload and to trigger it. Any functionality, such as filtering, complex validation or data selection etc. we do when the real SAP standard event is triggered. Meaning in the local consumption.

2.2.2 Local consumption of SAP Standard event

Now I won't go into step-by-step on this one, as I have done this already on the above linked blog post of mine. Please check there if the below steps are not enough for you.

I have an ABAP Class, abstract, final with the "for events of" functionality, where once again we must type R_SalesOrderTP here (and not I_SalesOrderTP, which would have been the preferred option). This means my class has to be again saved as "Standard ABAP" and cannot be in an ABAP for Cloud Development package. But this is clean core compliant, as explained above.

In Local Types I have my local class that inherits from cl_abap_behavior_event_handler and I add a method for the Created event:

class lcl_event_cons definition inheriting from cl_abap_behavior_event_handler.

  private section.
    methods:
      consume_created for entity event instances for salesorder~created.
endclass.

And here the implementation of that method (we'll go through it one by one below):

    data: lt_fwd_event  type zbp_r_eventforwarder=>tt_events.
    
    " go through RAP BO entity instances that triggerd the event
    " (should only be 1 as we listend to sales order (header) created)
    loop at instances into data(instance).
      " get data needed for complex filtering
      select salesorderitem, product, \_product-producttype
        from i_salesorderitem
        where salesorder = @instance-salesorder
        into table (lt_items).

      " check if sales order should be handled (forwarded to event broker)
      if line_exists( lt_items[ producttype = 'HAWA' ] ). 
        " this sales order is now filtered OK and will be added to the forwarding instances
        append initial line to lt_fwd_event assigning field-symbol(<fs_event>).
        <fs_event> = value #( objectkey  = instance-salesorder
                              objecttype = zbp_r_eventforwarder=>co_type_salesorder ).
      else.
        continue. " we are not interested in this Sales Order
      endif.
    endloop.

    " now that we checked all instances, only those that we filtered will be forwarded
    if lt_fwd_event is not initial.
      zbp_r_eventforwarder=>raise_forward_event( lt_fwd_event ).
    endif.

We create an internal table of the payload type that is the custom event (we created a global type in the behavior definition)
We loop through all instances that were sent by the SAP standard event (since this is a sales order (header), this will only ever include 1)
As we loop, we select some additional data to do "some complex logic" for checking if this sales order should be forwarded or filtered out.
Once all requirements are met for forwarding the sales order, we fill the custom event payload table.
When the looping is done, we check if any sales orders remained (if we have any custom event payload) and if yes, we now call the method we offered on the custom event RAP BO behavior as global class method and give it the payload we just filled.

And that's all 😲😀

2.2.3 Finishing

As before, we need to configure our custom event (binding) in the event channel in order to forward it to the event broker:

On the event broker, we need to subscribe to that topic, to receive it there:

To summarize, this is what will happen:

A user creates any sales order
R_SalesOrderTP-Created is triggered
Our local consumption of the SAP standard event is called: our local consumption checks if the sales order has any items with products of product type HAWA. If yes, we add it to be forwarded. If no, we disregard it.
If we had any sales order to forward, the ZR_EventForwarder behavior is called via workaround (a little bit nasty by just calling the global class but I could not think of any other way. For example we can't use an action, as actions are invoked via EML MODIFY, which in turn does not allow for RAISE EVENT). This triggers the ZR_EventForwarder-EventForwarded event with our payload
The custom event is forwarded to event broker

2.2.4 Testing

Let's test this. I create a new sales order and I include 1 item that has a product of type HAWA. Meaning my filtering will allow this sales order and eventually trigger my custom event.

Let's see what the event monitor says:

And consuming this message in BTP Event Mesh:

3 I want a larger payload

This is without a doubt the 2nd most discussed topic when talking event based integrations. In order to avoid callback APIs, maybe this is the way to go for you. As of right now, SAP Standard delivers notification events only, meaning small payloads to allow for the creation of fast, simple, integrations that can be easily reused.

You may already noticed that we already covered this in chapter 2. Both when extending the SAP standard event or when creating a custom event to work in combination with standard: I showcased how we can decide our own payload. So far I have only mentioned flat structures, as that is the only type that is supported by Event Mesh on SAP BTP. If you have a need for deep structure payloads, you may want to consider to upgrade to Advanced Event Mesh instead. And instead of creating a brand new example, please check out this blog post by a colleague that goes into deep payload: RAP Events with AEM 3 - Creating Events with deep payload.

Conclusion / Final Words

I hope this blog post helps and gives some ideas how far you can take RAP BO events and influence your integration landscape, in a positive way (of course, that's the end goal).

Is there anything I've missed? Another requirement that you would like to solve with eventing? Or any other questions or comments/feedback? Let me know in the comments and let's see 😊

How to Deliver Customizing as a SaaS Provider using Business Configuration Sets

2026-02-05T09:59:15.458000+01:00

In our previous blog post, How to Provide Customizing as a SaaS Provider, we described a programmatic approach that used EML statements with explicitly coded object templates in application jobs to deliver customizing entries. With release 2511, you can now use Business Configuration Sets instead, removing the need to include explicitly coded customizing data in your business logic.

This blog illustrates how to maintain customizing data in a Business Configuration Maintenance Object, how to maintain customizing translations, importing the created customizing data/translations into a BC Set, implementing an application job for the BC Set activation and finally how to deploy the BC Set content to the relevant customizing table.
We will also have a look into how BC Sets can be updated programmatically for the case when the customizing data was changed and BC Set data needs to be reimported.

This blog presents an alternative method to the Fiori app Upload Business Configuration. One restriction of the Upload Business Configuration app is that it does not validate the customizing data being uploaded.
In contrast, customizing data imported into Business Configuration (BC) Sets via ADT originates from existing customizing requests. This data is created within custom business configuration objects, where it is automatically validated through the underlying BO behavior (for example, error codes greater than 500 are rejected):

This blog covers the following topics:

Create Business Configuration Maintenance Object

The Business Configuration Maintenance Object discussed in this blog can be developed using the following tutorial, which guides you in creating a table for storing error codes:

Create Business Configuration Maintenance Object | SAP Tutorials

Providing Authorization Control for a Business Configuration Maintenance Object

To use the Business Configuration Maintenance Object, the required authorization must be set up. How to do this is explained in this tutorial:

Providing Authorization Control for a Business Configuration Maintenance Object | SAP Tutorials

Creating customizing data & translations

Maintain following customizing data as described in tutorial Use Custom Business Configurations app on a new customizing request:

Error Code	Description
400	Bad Request
401	Unauthorized
403	Forbidden

Afterwards your customizing request should include the primary customizing data as Customizing: Table Contents. Such customizing requests can be used for importing into a BC Set. Corresponding data records and translations will be extracted automatically during the process.

Maintain customizing translations for source language English United States and target language, for example German Germany, for the error codes using the Maintain Customizing Translations app.

Select the text table ZERRCODET_### that was created earlier as text source in your translation project.

Creating a BC Set and importing customizing data & translations

Follow the steps provided in Creating Business Configuration Sets to create a new business configuration set and use the customizing request that was created in the previous step for importing the data.

After successful import from the customizing request the error code data records as well as translations are included:

We can now proceed to implement an application job that can be used activate this BC Set.

Note: To import customizing data into a BC Set, the customizing data needs to be maintained for customizing objects of type Individual Transaction Object. A business configuration maintenance object (CUBCO) is configured as such by defining a transport object definition (TOBJ) in the service configuration settings of the CUBCO. By using the business configuration maintenance object wizard as described in Create Business Configuration Maintenance Object | SAP Tutorials, this prerequisite is fulfilled. For more information, please refer to Generating a Business Configuration Maintenance Object with the Generate ABAP Repository Objects Wizard → BC Management. Configuration changes are then recorded with object type TDAT instead of a TABU.

Those business configuration maintenance objects without existing transport object definition must be migrated, and a transport object definition needs to be created manually. How this can be done is described in the blog post How to enable BC Set support for BC app.

Creating an Application Job for the BC Set activation

In this example, an Application Job is used for creating and updating the customizing entries in a SaaS tenant. The customizing entries are deployed within the Application Job's implementation by activating the business configuration set using the corresponding runtime API.

As a first step, implement the BC Set activation as the business logic of the of the application job with a parameter for the BC Set to be activated and while saving activation messages in the application log:

CLASS zcl_errorcode_set_activate_000 DEFINITION
  PUBLIC FINAL
  CREATE PUBLIC.

  PUBLIC SECTION.
    "! <p class="shorttext synchronized">Error Codes BC Set</p>
    DATA errorcode_bc_set TYPE cl_scpr_cd_bcset_activation=>ty_bcset_id VALUE 'Z_ERROR_CODES_SET_000'.

    INTERFACES if_apj_rt_run.
    INTERFACES if_apj_dt_defaults.

  PRIVATE SECTION.
    CONSTANTS log_object    TYPE cl_bali_header_setter=>ty_object    VALUE 'Z_ERRORCODE_SET_000'.
    CONSTANTS log_subobject TYPE cl_bali_header_setter=>ty_subobject VALUE 'ACTIVATE'.
ENDCLASS.

CLASS zcl_errorcode_set_activate_000 IMPLEMENTATION.
  METHOD if_apj_dt_defaults~fill_attribute_defaults.
    errorcode_bc_set = 'Z_ERROR_CODES_SET_000'.
  ENDMETHOD.

  METHOD if_apj_rt_run~execute.
    TRY.
        DATA(lo_bali_log) = cl_bali_log=>create_with_header(
                                header = cl_bali_header_setter=>create( object    = log_object
                                                                        subobject = log_subobject ) ).
        TRY.
            DATA(lo_bcset_activate) = cl_scpr_cd_bcset_activation=>of( errorcode_bc_set ).
          CATCH cx_scpr_object_not_permitted INTO DATA(lx_scpr_object_not_permitted).
            lo_bali_log->add_item(
                item = cl_bali_exception_setter=>create( severity  = if_bali_constants=>c_severity_error
                                                         exception = lx_scpr_object_not_permitted ) ).
        ENDTRY.

        DATA(lo_activation_handler) = lo_bcset_activate->get_activate_handler( ).

        DATA(lo_activation_result) = lo_activation_handler->local( )->add_activation_options( )->start( ).

        DATA(lt_activation_messages) = lo_activation_result->get_messages( ).

        LOOP AT lt_activation_messages INTO DATA(ls_msg).
          lo_bali_log->add_item( item = cl_bali_message_setter=>create_from_bapiret2( message_data = ls_msg ) ).
        ENDLOOP.

        cl_bali_log_db=>get_instance( )->save_log_2nd_db_connection( log                        = lo_bali_log
                                                                     assign_to_current_appl_job = abap_true ).

      CATCH cx_bali_runtime INTO DATA(lx_bali_runtime).
        RAISE EXCEPTION TYPE cx_apj_rt_content USING MESSAGE
          EXPORTING previous = lx_bali_runtime.
    ENDTRY.
  ENDMETHOD.
ENDCLASS.

Then create a catalog entry and job template for the class with the business logic: Creating a Job Catalog Entry and a Job Template. Also create an application log object and sub object according to the job logic implementation: Working with Application Log Objects.

To run the application job for BC Set activation, users must have the authorization provided by a business catalog. In this case we will reuse the business catalog Z_ERROR_CODES_### that was already created as part of the tutorial Providing Authorization Control for a Business Configuration Maintenance Object.

The business catalog Z_ERROR_CODES_### already includes the IAM App of type MBC (Business Configuration App) that was created for the CUBCO. During creation of the job catalog entry for the BC Set activation job, another IAM app with name <job catalog entry name>_SAJC is automatically created (refer to Setting up the Authorizations). This IAM app, to start the application job, is added to the existing business catalog so that the catalog provides authorizations to maintain error codes in the CUBCO as well as to start the BC Set activation job:

The BC Set activation implemented in the activation job using the CL_SCPR_CD_BCSET_ACTIVATION API requires table access for all entities used in the BC Set, so for both the primary tables as well as text tables. This can be achieved by adding the names of the tables in the TABLE authorization field of the existing S_TABU_NAM authorization in the _MBC IAM app: in this case ZERRCODET_000 (text table) and ZERRCODE_000 (primary table):

Hint: If you plan to run the BC Set activation job in your development system, do not forget to publish your changes to the business catalog locally.

Deploying the BC Set content by running the application job

Make sure that the user that shall run the BC Set activation job has following business roles/catalogs assigned in the ABAP tenant (for example your SaaS consumer tenant):

Business Role	Business Catalog	Purpose
SAP_BR_ADMINISTRATOR	SAP_CORE_BC_APJ_JCE	For scheduling jobs in the Application Jobs app
SAP_BR_BPC_EXPERT	SAP_CORE_BC_BCT_MBC_PC	To use the Custom Business Configurations app
ZBR_ERROR_CODES_EXPERT_###	Z_ERROR_CODES_###	To maintain error codes in the Custom Business Configurations app and to start the BC Set activation job. As created in tutorial Providing Authorization Control for a Business Configuration Maintenance Object

Open the Application Job App and select "Create" to create a new Application Job, then
choose the Application Job Template. Maintain the scheduling options and provide a valid BC Set in the parameter. Schedule the Application Job by clicking "Schedule".

Check the Application Job Log to determine if the BC Set content was deployed correctly:

Users assigned to the required business roles (see above) can now check in the Custom Business Configurations App whether the customizing has been inserted and updated correctly:

Maintaining customizing data programmatically in BC Sets

You might want to automate the lifecycle of your customizing data. For instance, you can update a BC Set with the latest customizing data after some changes. To do this, maintain your changes in EML within the configuration object on a customizing request. Then read the latest data from the underlying customizing tables and finally update the BC Set.

You can programmatically create a customizing request using the XCO CTS module. EML will then be used to maintain the data on that customizing request. Additionally, you have the option to programmatically release the customizing request afterward.

CLASS zcl_errorcode_generate_000 DEFINITION
  PUBLIC FINAL
  CREATE PUBLIC.

  PUBLIC SECTION.
    INTERFACES if_oo_adt_classrun.

  PRIVATE SECTION.
    TYPES tyt_errorcodes            TYPE STANDARD TABLE OF zerrcode_000 WITH KEY error_code.
    TYPES tyt_errorcodestext        TYPE STANDARD TABLE OF zerrcodet_000 WITH KEY langu error_code.
    TYPES tyt_errorcodes_update     TYPE TABLE FOR UPDATE ZI_ErrorCode000.
    TYPES tyt_errorcodestext_update TYPE TABLE FOR UPDATE ZI_ErrorCode000Text.

    METHODS delete_errorcodes
      IMPORTING transportrequest TYPE trkorr.

    METHODS create_errorcodes
      IMPORTING transportrequest      TYPE trkorr
                it_errorcodes_crt     TYPE tyt_errorcodes
                it_errorcodestext_crt TYPE tyt_errorcodestext.

    METHODS update_errorcodes
      IMPORTING transportrequest         TYPE trkorr
                it_errorcodes_update     TYPE tyt_errorcodes_update
                it_errorcodestext_update TYPE tyt_errorcodestext_update.

    CONSTANTS co_cust_transport_target      TYPE if_xco_transport_target=>tv_value      VALUE ''.                                          " LOCAL
    CONSTANTS co_cust_transport_description TYPE sxco_ar_short_description              VALUE 'Maintain new error codes programmatically'.
ENDCLASS.


CLASS zcl_errorcode_generate_000 IMPLEMENTATION.
  METHOD if_oo_adt_classrun~main.
    " Create customizing transport request
    DATA(lo_customizing_request) = xco_cp_cts=>transports->customizing( co_cust_transport_target )->create_request(
        co_cust_transport_description ).

    " Programmatically create new error codes using EML
    create_errorcodes( transportrequest      = lo_customizing_request->value
                       it_errorcodes_crt     = VALUE tyt_errorcodes( ( error_code = '404' )
                                                                     ( error_code = '405' )
                                                                     ( error_code = '406' ) )
                       it_errorcodestext_crt = VALUE tyt_errorcodestext(
                           ( langu  = 'D' error_code  = '404' description = 'Not Found' )
                           ( langu  = 'E' error_code  = '404' description = 'Nicht gefunden' )
                           ( langu  = 'D' error_code  = '405' description = 'Method Not Allowed' )
                           ( langu  = 'E' error_code  = '405' description = 'Methode nicht erlaubt' )
                           ( langu  = 'D' error_code  = '406' description = 'Not Acceptable' )
                           ( langu  = 'E' error_code  = '406' description = 'Nicht akzeptabel' ) ) ).

    " Release customizing tasks and customizing request
    DATA(lt_transport_tasks) = lo_customizing_request->get_tasks( ).

    LOOP AT lt_transport_tasks INTO DATA(lo_transport_task).
      IF lo_transport_task->get_status( ) <> xco_cp_transport=>status->modifiable.
        CONTINUE.
      ENDIF.

      lo_transport_task->release( ).
    ENDLOOP.

    lo_customizing_request->release( ).

  ENDMETHOD.

  METHOD create_errorcodes.
    DATA lt_errorcode_create TYPE TABLE FOR CREATE ZI_ErrorCode000_S\_ErrorCode000.
    TYPES tys_errorcode_create LIKE LINE OF lt_errorcode_create.
    DATA ls_errorcode_create      TYPE tys_errorcode_create.

    DATA lt_errorcodestext_create TYPE TABLE FOR CREATE ZI_ErrorCode000\_ErrorCode000Text.
    TYPES tys_errorcodestext_create LIKE LINE OF lt_errorcodestext_create.
    DATA ls_errorcodestext_create TYPE tys_errorcodestext_create.

    LOOP AT it_errorcodes_crt INTO DATA(wa_errorcode_crt).

      ls_errorcode_create = VALUE #( SingletonID = 1
                                     %target     = VALUE #( ( ErrorCode          = wa_errorcode_crt-error_code
                                                              %control-ErrorCode = if_abap_behv=>mk-on ) ) ).
      APPEND ls_errorcode_create TO lt_errorcode_create.

    ENDLOOP.

    LOOP AT it_errorcodestext_crt INTO DATA(wa_errorcodestext_crt).
      ls_errorcodestext_create = VALUE #(
          %tky-ErrorCode = wa_errorcodestext_crt-error_code
          %target        = VALUE #( ( Langu                = wa_errorcodestext_crt-langu
                                      %control-Langu       = if_abap_behv=>mk-on
                                      Description          = wa_errorcodestext_crt-description
                                      %control-Description = if_abap_behv=>mk-on ) ) ).

      APPEND ls_errorcodestext_create TO lt_errorcodestext_create.

    ENDLOOP.

    MODIFY ENTITIES OF ZI_ErrorCode000_S
           ENTITY ErrorCode000All
           UPDATE
           FIELDS ( TransportRequestID )
           WITH VALUE #( ( SingletonId        = 1
                           TransportRequestID = transportrequest ) )

           ENTITY ErrorCode000All
           CREATE BY \_ErrorCode000 FROM lt_errorcode_create
           REPORTED DATA(r_errorcodes_crt)
           FAILED   DATA(f_errorcodes_crt)
           MAPPED   DATA(m_errorcodes_crt) ##NEEDED.

    MODIFY ENTITIES OF ZI_ErrorCode000_S
           ENTITY ErrorCode000
           CREATE BY \_ErrorCode000Text FROM lt_errorcodestext_create
           REPORTED DATA(r_errorcodestext_crt)
           FAILED   DATA(f_errorcodestext_crt)
           MAPPED   DATA(m_errorcodestext_crt) ##NEEDED.

    COMMIT ENTITIES
           BEGIN RESPONSE OF ZI_ErrorCode000_S
           FAILED DATA(failed_create)
           REPORTED DATA(reported_create) ##NEEDED.
    COMMIT ENTITIES END.
  ENDMETHOD.

  METHOD delete_errorcodes.
    MODIFY ENTITIES OF ZI_ErrorCode000_S
           ENTITY ErrorCode000All
           UPDATE
           FIELDS ( TransportRequestID )
           WITH VALUE #( ( SingletonId        = 1
                           TransportRequestID = transportrequest ) )

           FAILED DATA(f_delete_tr)
           MAPPED DATA(m_delete_tr)
           REPORTED DATA(r_delete_tr) ##NEEDED.

    MODIFY ENTITIES OF ZI_ErrorCode000_S
           ENTITY ErrorCode000All
           CREATE FIELDS ( TransportRequestID ) WITH VALUE #( ( TransportRequestID  = transportrequest ) )
           DELETE FROM VALUE #( ( SingletonID = 1 ) )
           FAILED DATA(f_delete)
           MAPPED DATA(m_delete)
           REPORTED DATA(r_delete) ##NEEDED.

    COMMIT ENTITIES
           BEGIN RESPONSE OF ZI_ErrorCode000_S
           FAILED DATA(failed_delete)
           REPORTED DATA(reported_delete) ##NEEDED.
    COMMIT ENTITIES END.
  ENDMETHOD.

  METHOD update_errorcodes.
    DATA lt_errorcodestext_update_i TYPE TABLE FOR UPDATE ZI_ErrorCode000Text.

    IF it_errorcodes_update IS NOT INITIAL OR it_errorcodestext_update IS NOT INITIAL.
      LOOP AT it_errorcodestext_update INTO DATA(ls_errorcodetext_update).
        ls_errorcodetext_update-%control-Description = if_abap_behv=>mk-on.
        APPEND ls_errorcodetext_update TO lt_errorcodestext_update_i.
      ENDLOOP.
    ENDIF.

    MODIFY ENTITIES OF ZI_ErrorCode000_S
           ENTITY ErrorCode000All
           UPDATE
           FIELDS ( transportrequestid )
           WITH VALUE #( ( SingletonID        = 1
                           TransportRequestID = transportrequest ) )

           ENTITY ErrorCode000Text
           UPDATE FROM lt_errorcodestext_update_i

           REPORTED DATA(r_errorcodes_upd)
           FAILED   DATA(f_errorcodes_upd)
           MAPPED   DATA(m_errorcodes_upd) ##NEEDED.

    COMMIT ENTITIES
           BEGIN RESPONSE OF ZI_ErrorCode000_S
           FAILED DATA(failed_update)
           REPORTED DATA(reported_update) ##NEEDED.
    COMMIT ENTITIES END.
  ENDMETHOD.
ENDCLASS.

The advantage of using EML to create, update, and delete customizing entries is that all validations of the business configuration object (BCO) are performed. This approach also supports both customizing entries of type table data (TABU) and individual transaction object (TDAT) since API adapters are available for both cases to be used in the behavior implementation of the BCO (for example, mbc_cp_api=>rap_tdat_cts()). For further information, refer to Transport Handling.

After updating the customizing data in the Business Configuration Object (BCO) using EML, the latest customizing data can be retrieved from the underlying customizing tables for further processing. Once the up-to-date customizing data is obtained, it can be directly maintained in the BC Set. This process utilizes the XCO generation APIs for BC Sets.

CLASS zcl_errorcode_generate_000 DEFINITION
  PUBLIC FINAL
  CREATE PUBLIC.

  PUBLIC SECTION.
    INTERFACES if_oo_adt_classrun.

  PRIVATE SECTION.
    CONSTANTS co_workbench_request          TYPE trkorr                                 VALUE ''.                                          " ZLOCAL
    CONSTANTS co_error_codes_set_name       TYPE if_xco_business_cnfgrtn_set=>tv_name   VALUE 'Z_ERROR_CODES_SET_000'.

    CONSTANTS co_error_codes_entity_primary TYPE if_xco_bcs_entity=>tv_name             VALUE 'ZERRCODE_000'.
    CONSTANTS co_error_codes_entity_text    TYPE if_xco_bcs_entity=>tv_name             VALUE 'ZERRCODET_000'.
    CONSTANTS co_error_codes_tobj           TYPE if_xco_bcs_customizing_object=>tv_name VALUE 'ZERRORCODE000'.

ENDCLASS.

CLASS zcl_errorcode_generate_000 IMPLEMENTATION.
  METHOD if_oo_adt_classrun~main.
    " Read latest error codes from customizing tables
    SELECT * FROM zerrcode_000 WHERE error_code < 500 INTO TABLE (lt_errorcodes).
    ASSERT sy-subrc = 0.

    SELECT * FROM zerrcodet_000 WHERE error_code < 500 INTO TABLE (lt_errorcodes_text).
    ASSERT sy-subrc = 0.

    " Retrieve error codes BC set and make sure it exists
    DATA(lo_business_configuration_set) = xco_cp_abap_repository=>object->scp1->for( co_error_codes_set_name ).
    ASSERT lo_business_configuration_set->if_xco_ar_object~exists( ).

    " Create BC Set patch operation and change specification to remove existing error codes customizing object (all its Entities and corresponding records)
    DATA(lo_patch_operation_delete) = xco_cp_generation=>environment->dev_system( co_workbench_request )->for-scp1->create_patch_operation( ).
    DATA(lo_change_specification_delete) = lo_patch_operation_delete->add_object( co_error_codes_set_name )->create_change_specification( ).
    lo_change_specification_delete->for-delete->add_individual_transaction_obj( co_error_codes_tobj ).

    " Create BC Set patch operation and change specification to insert latest error codes using latest customizing data
    DATA(lo_patch_operation_insert) = xco_cp_generation=>environment->dev_system( co_workbench_request )->for-scp1->create_patch_operation( ).
    DATA(lo_change_specification_insert) = lo_patch_operation_insert->add_object( co_error_codes_set_name )->create_change_specification( ).
    DATA(lo_tobj_insert) = lo_change_specification_insert->for-insert->add_individual_transaction_obj(
                               co_error_codes_tobj ).
    lo_tobj_insert->for-insert->add_entity( co_error_codes_entity_primary )->for-insert->add_records(
                                                                              REF #( lt_errorcodes[] ) ).
    lo_tobj_insert->for-insert->add_entity( co_error_codes_entity_text )->for-insert->add_records(
                                                                           REF #( lt_errorcodes_text[] ) ).

    " After preparing the change specifications, execute the PATCH operations
    TRY.
        DATA(lo_result_delete) = lo_patch_operation_delete->execute( ) ##NEEDED.
        DATA(lo_result_insert) = lo_patch_operation_insert->execute( ) ##NEEDED.

      CATCH cx_xco_gen_patch_exception INTO DATA(lo_xco_gen_patch_exception).

        LOOP AT lo_xco_gen_patch_exception->findings->get( ) ASSIGNING FIELD-SYMBOL(<fs_finding>) ##NEEDED.
          " Process errors/exceptions raised from the PATCH operation
        ENDLOOP.
    ENDTRY.
  ENDMETHOD.

ENDCLASS.

This section of using the XCO generation API for BC Sets to update BC set data requires customizing entries of type individual transaction object (TDAT). This is because it’s a requirement for importing any data into a BC Set. BC Sets are workbench objects and can be delivered alongside other development objects in your development software components.

Hint: In productive scenarios remove the ##NEEDED pragma from the code examples and implement proper error handling!

Prefilling a Value Help Filter from the Parent Entity in RAP

2026-02-10T01:23:19.551000+01:00

In a RAP application, I recently encountered a common requirement: pre‑filter a Value Help on a child entity field using a value coming from the parent entity (in my case, the CompanyCode from the header).

The scenario looks simple, but RAP currently cannot evaluate an association inside an additionalBinding. I tried the expected annotation:

@Consumption.valueHelpDefinition: [
  {
    entity: { name : 'I_PurchaseOrderAPI01', element : 'PurchaseOrder' },
    additionalBinding: [
      { element: 'CompanyCode', localElement: '_Header.CompanyCode', usage: #FILTER }
    ]
  }
]
PurchaseOrder;

Unfortunately, the framework does not resolve the _Header association, and the filter is not applied.

There is an even more fundamental issue: When creating a child record, the child entity simply does not exist yet. So you cannot push CompanyCode into the child entity and bind from there—there’s no child instance at that moment.

Because of this, annotations alone cannot solve the problem.

Workaround: Inject the Filter from a Fiori Elements Controller Extension

The most pragmatic solution is to extend the Object Page controller and add the filter programmatically when the Value Help opens. This avoids backend limitations and works well during create flows.

Why my case is simpler

In my application, the PurchaseOrder field is a multi‑input on the header, not inside a table. That means:

There is one single generated field,
Easy to identify,
Easy to attach the opened event to its Value Help.

For tables, the logic is still possible but more dynamic (details below).

Implementation – Header Multi‑Input Scenario

Step 1 — Add a controller extension

In the Object Page, add a controller extension (via the page map in Fiori Tools).

The generated extension usually provides an onInit method override. Insert a call to your custom method:

onInit: function () {
  this._extendPurchaseOrderValueHelp();
}

Step 2 — Locate the generated field + attach a handler

Use Chrome DevTools to retrieve the generated ID for the multi‑input field. Then:

_extendPurchaseOrderVH: function () {

            const oView = this.base.getView();

            // 1) Get generated MDC field for PurchaseOrder
            const sPurchaseOrderId = "my.app::DocumentObjectPage--fe::FormContainer::FileTemplate::FormElement::DataField::_TemplatePurchaseOrder::PurchaseOrder::MultiValueField"; 
            let oField = oView.byId(sPurchaseOrderId);
            if (!oField) {
                return; // not rendered yet
            }

            // 2) Get MDC value help attach method to opened event
            const sPurchaseOrderValueHelpId = oField.getValueHelp && oField.getValueHelp(); // can return an id
            const oPurchaseOrderValueHelp = sPurchaseOrderValueHelpId ? oView.byId(sPurchaseOrderValueHelpId) : null;
            if (!oPurchaseOrderValueHelp) {
                return;
            }
            oPurchaseOrderValueHelp.attachOpened(this._onOpenPurchaseOrderValueHelp);

        }

This function:

Retrieves the generated MDC field,
Retrieves its Value Help,
Hooks into the opened event.

Step 3 — Inject the parent’s CompanyCode into the Value Help

        _onOpenPurchaseOrderValueHelp: function (oEvent) {

			// Read company code from parent
			const oCtx = oEvent.getSource().getBindingContext();
			const sCompanyCode = oCtx && oCtx.getObject() && oCtx.getObject().CompanyCode;
			if (!sCompanyCode) return;

			//Get value help object
			const oContainer = oEvent.getParameter("container");
			const aContents = oContainer && oContainer.getContent ? oContainer.getContent() : [];
			const oFilterBar = aContents
				.map(c => c.getFilterBar && c.getFilterBar())
				.find(Boolean);
			if (!oFilterBar) return;

			//Apply condition on the model
			const sCM = oFilterBar.getConditionModelName ? oFilterBar.getConditionModelName() : "$filters";
			const oCM = oFilterBar.getModel(sCM);
			const Condition = sap.ui.mdc && sap.ui.mdc.condition && sap.ui.mdc.condition.Condition;
			if (!oCM || !Condition) return;

			oCM.removeAllConditions && oCM.removeAllConditions("CompanyCode");
			oCM.addCondition && oCM.addCondition("CompanyCode", Condition.createCondition("EQ", [sCompanyCode]));
			oCM.checkUpdate && oCM.checkUpdate(true);

			//trigger search again
			oFilterBar.triggerSearch?.();

        }

A note about the table (item) scenario

In many applications, the Value Help is not in the header but inside a table row. This is actually the more common case.

However, the logic becomes a bit different because:

Each row generates its own instance of the field,
These controls appear dynamically as the table renders,
IDs are not static like a header field,
You must find each row’s field and attach the event individually,
You cannot rely on a fixed ID.

This makes the implementation slightly more complex, but still entirely doable.

Triggering SAP Datasphere/BDC Task Chains from SAP BTP ABAP Cloud using the Task Chain REST API

2026-02-10T16:44:24.061000+01:00

Our modern data landscapes thrive on automation. In this post, we’ll walk end-to-end through a real-life integration scenario that tackles one of the building blocks in this context:

Starting a SAP Datasphere Task Chain remotely from SAP BTP ABAP Cloud using OAuth 2.0 Client Credentials and the Datasphere Task Chain REST API

The goal is to orchestrate Datasphere data processing flows directly from ABAP Cloud — securely, programmatically, and fully automated.

We will cover the below points:

Creating a Task Chain in Datasphere
Configuring OAuth clients in Datasphere
Setting up Communication System & Arrangement in ABAP Cloud
Executing the Task Chain remotely: Consume REST API from ABAP Cloud

1 Architecture Overview

Solution Architecture

ABAP Cloud Task Chain Execution: ABAP Cloud acts as the caller. Datasphere exposes the Task Chain API protected by OAuth.

2 Prerequisites

You must have:

SAP Datasphere tenant with developer + admin access
A Task Chain to trigger
SAP BTP ABAP Environment (ABAP Cloud) with developer access
BTP ABAP: Authorization to configure OAuth clients and Communication Arrangements

3 Creating a Task Chain in SAP Datasphere

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

In the given example:

The Task Chain starts with a Begin node
Executes a Replication Flow for loading dimension data
(Can be extended with transformations, views, or further flows)

SAP Datasphere Task Chain with Replication Flow inside

Main takeaways:

Task Chain must be Deployed
Note the Technical Name (used later by API)
Verify it runs manually before you automate via the API

4 Configuring OAuth Client in SAP Datasphere

To allow ABAP Cloud to call Datasphere APIs securely, we create an OAuth Client in Datasphere Administration.

Navigation Path

Datasphere → Administration → App Integration → OAuth Clients

OAuth Endpoints Provided

Amongst others, SAP Datasphere automatically exposes:

Authorization URL
Token URL

These are required for OAuth2 token retrieval. Moreover you must create a technical user that has access to the Datasphere space and is able to run the task chains that are in scope. Typically this is done by assigning a scoped role.

Configured OAuth Client (based on Technical User)

Menu Path Datasphere

This is where you see the OAuth Client specific URLs - take note of them for later configuration in ABAP BTP:

OAuth Client Generation

Your specific OAuth client for consumption from ABAP BTP. The secret key is only shown once upon creation - keep this in mind!

OAuth Client Details

Important settings:

Parameter	Value
Grant Type	Client Credentials
Purpose	Technical User
Roles	space access must be given (e.g. by scope role in DSP)
Token Lifetime	e.g. 60 minutes

Save the Client ID and Client Secret — this is used in ABAP Cloud later on.

5 Creating a Communication System in ABAP Cloud

Now we configure the outbound technical connection from ABAP Cloud to Datasphere.

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

ABAP Cloud Web Access

ABAP Cloud Communication Systems

The hostname is your Datasphere tenant URL. Outbound OAuth URLs (like Token/Authentication) can be found on the Datasphere side under Administration -> App Integration (previous step).

ABAP Cloud Communication Systems Details

You have to add a user "OAuth 2.0 (Basic)":

ABAP Cloud Communication Systems Users

Key fields:

Field	Example
System ID	DSP_REST
Host Name	<your-datasphere-host> (tenant URL)
Port	443
OAuth 2.0 Endpoints	From Datasphere for Token & Authorization URL (Audience URL not required)
Client ID	Datasphere OAuth Client ID
Client Secret	Datasphere Secret (you must take note of this when creating the OAuth Client)

6 Creating a Communication Arrangement in SAP ABAP Cloud

Now we bind the Communication System to a Communication Scenario that allows REST calls.

Navigation: Communication Management → Communication Arrangements

Arrangement Example: ZDSP_CS_REST

ABAP Cloud Communication Arrangements

Note the service path: The dynamic parts of the path are set from ABAP (this is to keep the space + task chain flexible and controllable from the actual caller: ABAP).

ABAP Cloud Communication Arrangements Detailed Configuration

What this provides:

Preconfigured service URL
OAuth token handling by ABAP runtime
Secure outbound API consumption

7 Calling the Datasphere Task Chain API from ABAP Cloud

Now comes the fun part: consuming the REST API. Datasphere exposes endpoints such as:

POST /api/v1/datasphere/tasks/chains/<space_id>/run/<task_chain_technical_name>
GET /api/v1/datasphere/tasks/logs/<space_id>/<log_id>

Which triggers a new execution or reads the status of a task chain run.

ABAP Cloud Implementation Pattern

In ABAP Cloud when working with REST API to integrate external services, you typically:

Create HTTP destination automatically from the created Communication Arrangement
Use CL_WEB_HTTP_CLIENT_MANAGER
Perform POST/GET requests
Parse response (run ID, status)

The code snippet performs the following parts in more detail:

Run as a class-run program (IF_OO_ADT_CLASSRUN) -> you can execute directly from ADT and print to the console.
Locate the configured Communication Arrangement (bound to our Communication System DSP_REST) using CL_COM_ARRANGEMENT_FACTORY.
Create an HTTP destination from the Communication Arrangement using CL_HTTP_DESTINATION_PROVIDER=>CREATE_BY_COMM_ARRANGEMENT.
Create an HTTP client from the destination (CL_WEB_HTTP_CLIENT_MANAGER).
POST request to the Task Chain “run” endpoint:

triggers a new run
receives a JSON response containing a LogId

WAIT a few seconds.
GET the log endpoint using the returned LogId:

retrieves the execution status (RUNNING, later SUCCESS / FAILED, etc.)

Print everything in the ABAP Console.

ABAP-Code Snippet:

CLASS zcl_dsp_rest_api DEFINITION PUBLIC FINAL CREATE PUBLIC.
   PUBLIC SECTION.
    INTERFACES if_oo_adt_classrun.

    CLASS-DATA:
      out TYPE REF TO if_oo_adt_classrun_out.
    CLASS-METHODS:
      call_dsp
        RAISING
          cx_http_dest_provider_error
          cx_web_http_client_error.
ENDCLASS.

CLASS zcl_dsp_rest_api IMPLEMENTATION.
  METHOD if_oo_adt_classrun~main.
    zcl_dsp_rest_api=>out = out.

    TRY.
        call_dsp( ).
      CATCH cx_web_http_client_error
            cx_http_dest_provider_error INTO DATA(exception).
        out->write( exception->get_text( ) ).
    ENDTRY.

  ENDMETHOD.

  METHOD call_dsp.

    TYPES: BEGIN OF ty_log,
             logId  TYPE i,
           END OF ty_log.

    DATA: ls_log TYPE ty_log.
    DATA(communication_system) = 'DSP_REST'.
    DATA(arrangement_factory) = cl_com_arrangement_factory=>create_instance( ).

    DATA(comm_arrangement_range) = VALUE if_com_arrangement_factory=>ty_query-cs_id_range(
      ( sign = 'I' option = 'EQ' low = communication_system ) ).

    arrangement_factory->query_ca(
      EXPORTING
        is_query = VALUE #( cs_id_range = comm_arrangement_range )
      IMPORTING
        et_com_arrangement = DATA(arrangements) ).

    DATA(arrangement) = arrangements[ 1 ].

    DATA(destination) = cl_http_destination_provider=>create_by_comm_arrangement(
      comm_scenario  = 'ZDSP_CS_REST'
      service_id     = 'ZDSP_REST_SRV_REST'
      comm_system_id = arrangement->get_comm_system_id( ) ).

    DATA(http_client) = cl_web_http_client_manager=>create_by_http_destination( destination ).
    DATA(request) = http_client->get_http_request( ).
    request->set_uri_path( '/chains/BDCPOC/run/TC_DIM2_A001' ).

    DATA(response) = http_client->execute( if_web_http_client=>post ).

    CALL METHOD /ui2/cl_json=>deserialize
      EXPORTING
        json = response->get_text( )
      CHANGING
        data = ls_log.

    data(log_str) = CONV string( ls_log-logId ).
    out->write( 'Task Chain started. LogId created:' && log_str ).

    WAIT UP TO 10 SECONDS.

    CONCATENATE '/logs/BDCPOC/' log_str INTO DATA(uri).

    clear: request, response, http_client.
    http_client = cl_web_http_client_manager=>create_by_http_destination( destination ).
    request = http_client->get_http_request( ).
    request->set_uri_path( uri ).
    response = http_client->execute( if_web_http_client=>get ).
    out->write( 'Task Chain Log REST API - via GET - Task Chain Status:' && response->get_text( ) ).

  ENDMETHOD.
ENDCLASS.

Once triggered:

Datasphere creates a new Task Chain run
Execution can be monitored in Datasphere UI
API returns run ID and status

Follow-up calls can fetch:

Execution status
Logs
Completion result

8 Execution Results

ABAP Cloud Console Log: Results

The Task Chain in Datasphere is in Running status:

SAP Datasphere Task Chain Running Status

9 Conclusion/Outlook & Further aspects:

Overview of the major building blocks:

Capability	Result
Secure Auth	OAuth 2.0 Client Credentials
No hardcoded secrets	via Communication Arrangements/System
Remote orchestration	Creating an end-to-end orchestrated chain of tasks
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)
CI/CD data pipelines
API-driven analytical data refresh

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/274f2736465c4c48a091c675880502a2.html?locale=en-US
ABAP Cloud - how to call external APIs: https://jacekw.dev/blog/2022/oauth-client-credentials-from-abap-cloud/

These are your main takeaways to further sharpen the solution:

Use short token lifetimes
Separate technical OAuth users
Monitor task runs via API from ABAP
Handle retries & failures in ABAP
Log run IDs for observability

If you have any aspects, comments and/or concerns, please raise them and let's discuss. I'm happy and proud that this article was written by at least 90% human and only 10% AI 🙂