SAP Community - ABAP RESTful Application Programming Model

How to create a RAP application using a parameterized CDS view

2026-03-17T10:38:18.358000+01:00

Hello everyone, recently I came across a somewhat unusual requirement where I needed to use a parameter in a RAP application. As we know, this isn’t natively supported with Fiori Elements, so I had to look for a way to make it work. After some research and a few tests, I ended up with a solution that I consider quite innovative: using a Fiori Freestyle approach.

The best part is that it requires only a minimal amount of code, something that any ABAP developer can implement without much effort, and it becomes extremely useful whenever you need to work with parameters that are not directly linked to the data exposed by the CDS view.

The idea behind this solution is simple:

Since projection views in RAP do not support CDS parameters directly, we expose a parameterized interface CDS view through a service definition and service binding.

Then, using a Fiori Freestyle application with a Smart Table, we dynamically inject the parameter into the table binding path before the data request is sent to the backend.

This allows the RAP service to consume the parameterized CDS view without requiring complex workarounds.

Let’s go through the required steps:

1) Since it’s not possible to add WITH PARAMETERS to a projection view, we need to create an interface CDS view and use it as our “projection.”

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: '<your cds description>'
@Metadata.ignorePropagatedAnnotations: false
@Metadata.allowExtensions: true

define view entity <your_parameterized_interface_cds>
  with parameters
    p_date : abap.char(8)

as select from <your_source_cds_or_table>
(
  p_date : $parameters.p_date
)
{
    key <your_key_field>,
        <your_field_1>,
        <your_field_2>,
        <your_field_3>
}

2) Create our service definition normally

3) Create Service Binding ( Odata V2 )

4) Now we have to create the freestyle app with the fiori generator application

5) Now just connect to the S4 and select the service binding created earlier

At this point, you can see the project structure in the Explorer panel on the left. We’ll focus only on the view and controller folders.

First, we need to create our Smart Table in the view folder. Inside the SmartFilterBar, we must set the entitySet from our service binding. After that, we add a customControl in my case, I used a DatePicker, but you can use any control that fits your requirement. I also attached an onDateChange event to the DatePicker so we can capture and manipulate the selected date whenever it changes.

Within the Smart Table, we also need to define the same entitySet. Another very important point here is the beforeRebindTable event. This is the hook that allows us to pass the parameter to the CDS view. It will trigger the onBeforeRebindTable method in the controller, where we can dynamically inject the parameter into the binding before the data is requested.

<mvc:View
    xmlns:table="sap.ui.table"
    xmlns="sap.ui.comp.smartfilterbar"
    xmlns:f="sap.f"
    xmlns:m="sap.m"
    xmlns:mvc="sap.ui.core.mvc"
    xmlns:smartTable="sap.ui.comp.smarttable"
    controllerName="<your.app.namespace>.controller.Main"
    height="100%">

<f:DynamicPage
    id="dynamicPage"
    fitContent="true"
    title="{i18n>appTitle}">

<f:header>
<f:DynamicPageHeader>

<SmartFilterBar
    id="smartFilterBar"
    entitySet="<your_entity_set>">

    <controlConfiguration>

        <ControlConfiguration
            key="<your_parameter_field>"
            visibleInAdvancedArea="true"
            label="<your_filter_label>"
            mandatory="true">

            <customControl>

                <m:DatePicker
                    id="datePicker"
                    displayFormat="dd/MM/yyyy"
                    valueFormat="yyyyMMdd"
                    placeholder="dd/mm/yyyy"
                    width="100%"
                    required="true"
                    change="onDateChange"/>

            </customControl>

        </ControlConfiguration>

    </controlConfiguration>

</SmartFilterBar>

</f:DynamicPageHeader>
</f:header>

<f:content>

<smartTable:SmartTable
    id="smartTable"
    beforeRebindTable="onBeforeRebindTable"
    showRowCount="true"
    enableAutoBinding="false"
    entitySet="<your_entity_set>"
    smartFilterId="smartFilterBar"
    useVariantManagement="true"
    tableType="Table"
    initiallyVisibleFields="<your_fields>"
    enableAutoColumnWidth="true"
    showTablePersonalisation="true">

    <smartTable:customToolbar>

        <m:OverflowToolbar design="Transparent">
            <m:ToolbarSpacer/>
        </m:OverflowToolbar>

    </smartTable:customToolbar>

</smartTable:SmartTable>

</f:content>

</f:DynamicPage>

</mvc:View>

7) In this step, we implement the logic inside the onBeforeRebindTable method, which is responsible for dynamically passing the parameter to the CDS view before the Smart Table triggers the data request.

First, the code retrieves the value entered in the DatePicker using byId. This value will be used as the parameter for the CDS. A local variable (sDate) is initialized to store the selected date.

Next, a validation is performed to ensure that the date field is filled in. Since this parameter is mandatory for the query, if no value is provided the DatePicker is set to the Error state and a validation message is displayed. At the same time, the table binding is stopped using:

oBindingParams.preventTableBind = true;

This prevents the Smart Table from calling the backend without the required parameter, avoiding unnecessary requests and possible errors.

If the date is correctly filled in, any previous error state is cleared by setting the ValueState back to None.

Finally, the most important part happens: the table binding path is updated dynamically. Here we pass the selected date to the parameterized CDS by changing the binding path of the Smart Table:

setTableBindingPath("/<EntitySet>(p_date='${sDate}')/Set")

This is what allows the RAP application to consume a CDS with parameters, because the parameter is injected at runtime just before the data is requested from the backend.

onBeforeRebindTable: function (oEvent) {

    let oDatePicker = this.byId("datePicker");
    let sDate = "";

    if (oDatePicker) {
        sDate = oDatePicker.getValue();
    }

    if (!sDate) {

        if (oDatePicker) {
            oDatePicker.setValueState("Error");
            oDatePicker.setValueStateText("Please inform the date.");
        }

        let oBindingParams = oEvent.getParameter("bindingParams");

        if (oBindingParams) {
            oBindingParams.preventTableBind = true;
        }

        return;
    }

    if (oDatePicker) {
        oDatePicker.setValueState("None");
    }

    this.getView()
        .byId("smartTable")
        .setTableBindingPath("/<your_entity_set>(p_date='" + sDate + "')/Set");

}

And Vooooalá!

Conclusion

Although RAP and Fiori Elements provide powerful tools for building enterprise applications, there are still scenarios where certain features are not directly supported, such as consuming parameterized CDS views in projection layers.

By combining RAP services with a lightweight Fiori Freestyle approach, we can overcome this limitation in a simple and flexible way. Using events like beforeRebindTable and dynamically modifying the binding path allows parameters to be passed to the CDS view at runtime.

This approach requires only a small amount of additional UI code and can be implemented quickly by ABAP developers who are already familiar with RAP and Fiori.

I hope this solution helps others facing similar challenges when working with parameterized CDS views in RAP applications.

RAP Unmanaged Draft: Early Numbering and Associations for Unique IDs

2026-03-19T15:23:41.063000+01:00

INTRODUCTION

In RAP, Implementing numbering mechanisms during these operations is essential to ensure unique identifiers for newly created entities.
This blog is exposure the best for numbering during Creation and Creation by Association, in Unmanaged Scenario with Draft. How to handle number creation with Draft Scenario's.

Some Information about Numbering
Basically, Numbering is the concept to process assigning unique values to the key fields of business entities during Create and Create By Association Operations.

Unmanaged Early Numbering:

Developers need to implement custom code logic to create and assign keys values during the creation and create by association operation.
%is_draft – It is a component of the transactional key (%tky) in RAP.
- It tells the framework whether to operate on the draft table or the active persistent table for a given operation.
- %is_draft = mk-on reads from draft table
- %is_draft = mk-off reads from active table

Problem Statement

A sales clerk begins creating a Sales Order in Fiori. The order header is saved as a draft, but items need to be added immediately under that draft. To ensure consistency, the system must generate a unique Sales Order ID right away and assign incremental item numbers without waiting for activation.

Importance:

Early numbering guarantees unique identification across drafts and active records.
Associations ensure header–item linkage is preserved.
Draft handling allows users to save incomplete transactions safely and activate later without losing data integrity.

Behavior Definition of Root Entity

early numbering → enables key generation during root creation.

unmanaged implementation in class zbp_i_vd_head unique;
strict ( 2 );
with draft;

define behavior for ZI_VD_HEAD alias Header
draft table zdft_vd_head
lock master
total etag CreatedOn
authorization master ( instance )
early numbering // Early numbering declaration in root entity
{
  create;
  update;
  delete;
  association _item { create; }
  field ( readonly : update ) CustNo;

  draft action Edit;
  draft action Activate optimized;
  draft action Resume;
  draft action Discard;
  draft determine action Prepare;
}
mapping for zvd_t_hsale {
  CustNo     = cust_no;
  SalesOrder = sales_order;
  CreatedOn  = created_on;
  EntryTime  = entry_time;
  Name       = name;
  DocCat     = doc_cat;
}

Behavior Definition of Item Entity

early numbering → enables key generation during item creation.

define behavior for ZI_VD_ITEM alias Item
draft table zdft_vd_item
lock dependent by _head
authorization dependent by _head
early numbering // Early numbering declaration in item entity
{
  update;
  delete;
  field ( readonly ) CustNo;
  association _head;

  mapping for zvd_t_isale {
    CustNo     = cust_no;
    SalesOrder = sales_order;
    DocItem    = doc_item;
    MatNumber  = mat_number;
    MatGroup   = mat_group;
    CreatedOn  = created_on;
  }
}

Behavior Pool Implementation

This method ensures that every new entity gets a unique identifier (CustNo) during creation if it wasn’t already provided.

UUID Generation:

cl_system_uuid=>create_uuid_x16_static( ) generates a globally unique key.
This avoids collisions and guarantees uniqueness across drafts and active records.

Mapped Root:

%cid → correlates client-side temporary IDs with backend entities.
%key → holds the generated or existing key.
%is_draft → ensures draft state is preserved.
CustNo → the actual business key stored in the entity.

METHOD earlynumbering_create.
   LOOP AT entities INTO DATA(entity).
      DATA(lv_custno) = entity-custno.
      IF lv_custno IS INITIAL.
        TRY.
            lv_custno = cl_system_uuid=>create_uuid_x16_static( ).
          CATCH cx_uuid_error.
            "handle exception
        ENDTRY.
      ENDIF.
      APPEND VALUE #(
          %cid      = entity-%cid
          %key      = VALUE #( custno = lv_custno )
          %is_draft = entity-%is_draft
          custno    = lv_custno
      ) TO mapped-header.
    ENDLOOP.
ENDMETHOD.

Mapped Item:

This method handles early numbering when creating items via association (CREATE-BY-ASSOCIATION).

First, it retrieves the maximum cust_no from the database table zvd_t_isale for the current entity.

%cid → client-side correlation ID.
%key → generated key with CustNo.
%is_draft → preserves draft state.
CustNo → ensures linkage to the root entity.

METHOD earlynumbering_cba_item.
  LOOP AT entities INTO DATA(entity).
      " Get current max Customer Number from DB
      SELECT MAX( cust_no )
        INTO (lv_max)
        FROM zvd_t_isale
        WHERE cust_no = -%key-custno.

      LOOP AT entity-%target INTO DATA(t_item).
        APPEND VALUE #(
            %cid      = t_item-%cid
            %key      = VALUE #(
                            custno = entity-%key-custno )
            %is_draft = t_item-%is_draft
            custno    = entity-%key-custno
        ) TO mapped-item.
      ENDLOOP.
    ENDLOOP.
ENDMETHOD.

Item inherits lock and authorization from the header.
Early numbering ensures item keys are generated consistently.
Association links items back to the header BO.

Persistence Methods

Create Method

METHOD create.
  LOOP AT entities INTO DATA(entity).
    DATA(header) = CORRESPONDING zvd_t_hsale( entity MAPPING FROM ENTITY ).

    header-created_on = sy-datum.
    header-entry_time = sy-datum.
    header-name       = sy-uname.

    APPEND header TO gt_hsale.
  ENDLOOP.
ENDMETHOD.

Create-By-Association Method

METHOD cba.
  LOOP AT entities_cba INTO DATA(entity_cba).
    LOOP AT entity_cba-%target INTO DATA(target_item).
      DATA(item) = CORRESPONDING zvd_t_isale( target_item MAPPING FROM ENTITY ).

      item-cust_no   = entity_cba-%key-CustNo.
      item-created_on = sy-datum.

      APPEND item TO gt_isale.
    ENDLOOP.
  ENDLOOP.
ENDMETHOD.

Result

Conclusion

By combining Draft Handling, Associations, and Early Numbering, RAP unmanaged scenarios can support complex business objects like Sales Orders, Purchase Orders. This approach ensures flexibility, control, and consistency in transactional applications.

Thank You...

RAP: Factory Action to copy Billing Header and its Item(s) using Create by association

2026-03-25T10:31:08.744000+01:00

In this blog, I am going to explain how we can use create by association with factory action in SAP RAP environment for complex use case like copying duplicate billing header with its associated child entities.

Let's understand what action in RAP is, and what is factory action first.

If you want to perform any operation other than those four basic operations (CRUD), we can use action keyword in RAP. It helps us to do custom action like approve billing doc or change any field value like status.

We have three types of actions in RAP:

Instance Action: we need to select a record to perform action.
Static Actions: that are not tied to a specific instance.
Factory Actions: used for creating the copy of already existing instance. We will see this more in details.

Create by Association: In scenario where we cannot create child entity as it is depend on header, we need to use create by association. Used to create deep entity.

So, let's start with the steps to generate our basic application. Please have a look.

1. My header table look like this: 👇

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

  key client         : abap.clnt not null;
  key bill_id        : abap.numc(10) not null;
  bill_type          : abap.char(4);
  bill_date          : abap.dats;
  customer_id        : kunnr;
  @Semantics.amount.currencyCode : 'ztb_billheader.currency'
  net_amount         : abap.curr(15,2);
  currency           : waers;
  sales_org          : vkorg;
  createdby          : syuname;
  createdat          : timestamp;
  lastchangedby      : syuname;
  lastchangedat      : timestamp;
  locallastchangedat : timestamp;
  status             : abap.char(1);
  statustext         : abap.char(10);

}

I am not using managed numbering here as I want custom Bill Id.

2. My Item table look like this: 👇

@EndUserText.label : 'Billing Item'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table ztb_billitem {

  key client         : abap.clnt not null;
  key bill_id        : abap.char(10) not null;
  key item_no        : abap.numc(6) not null;
  material_id        : matnr;
  description        : abap.char(40);
  @Semantics.quantity.unitOfMeasure : 'ztb_billitem.uom'
  quantity           : abap.quan(13,3);
  @Semantics.amount.currencyCode : 'ztb_billitem.currency'
  item_amount        : abap.curr(15,2);
  currency           : waers;
  uom                : meins;
  createdby          : syuname;
  createdat          : timestamp;
  lastchangedby      : syuname;
  lastchangedat      : timestamp;
  locallastchangedat : timestamp;

}

3. I have created interface view on top of header table: You can skip that also. It looks like this: 👇

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Interface View for Bill header'
@Metadata.ignorePropagatedAnnotations: true
define view entity ZI_BillHeader as select from ztb_billheader
{
    key bill_id as BillId,
    bill_type as BillType,
    bill_date as BillDate,
    customer_id as CustomerId,
    @Semantics.amount.currencyCode: 'Currency'
    net_amount as NetAmount,
    currency as Currency,
    sales_org as SalesOrg,
    createdby as Createdby,
    createdat as Createdat,
    lastchangedby as Lastchangedby,
    lastchangedat as Lastchangedat,
    locallastchangedat as Locallastchangedat,
    status as status,
    statustext as StatusText
}

4. I have created root view on top of header interface view: 👇

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Root View Bill Header'
@Metadata.ignorePropagatedAnnotations: true
define root view entity ZR_BillHeader as select from ZI_BillHeader
composition[0..*] of ZI_BillItem as _Item
{
    key BillId,
    BillType,
    BillDate,
    CustomerId,
    @Semantics.amount.currencyCode: 'Currency'
    NetAmount,
    Currency,
    SalesOrg,
    Createdby,
    Createdat,
    Lastchangedby,
    Lastchangedat,
    Locallastchangedat,
    status,
    StatusText,
    _Item // Make association public
}

5. I have created interface view on top of item table: 👇

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Interface View for Bill Item'
@Metadata.ignorePropagatedAnnotations: true

define view entity ZI_BillItem 
as select from ztb_billitem
association to parent ZR_BillHeader as _header on $projection.BillId = _header.BillId
{
    key bill_id as BillId,
    key item_no as ItemNo,
    material_id as MaterialId,
    description as Description,
    @Semantics.quantity.unitOfMeasure: 'Uom'
    quantity as Quantity,
    @Semantics.amount.currencyCode: 'Currency'
    item_amount as ItemAmount,
    currency as Currency,
    uom as Uom,
    createdby as Createdby,
    createdat as Createdat,
    lastchangedby as Lastchangedby,
    lastchangedat as Lastchangedat,
    locallastchangedat as Locallastchangedat,
    _header
}

6. Created projection view on top of root view: 👇

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Projection View Bill Header'
@Metadata.ignorePropagatedAnnotations: true
@Metadata.allowExtensions: true
define root view entity ZP_BillHeader
  provider contract transactional_query
  as projection on ZR_BillHeader
{
  key BillId,
      BillType,
      BillDate,
      CustomerId,
      @Semantics.amount.currencyCode: 'Currency'
      NetAmount,
      Currency,
      SalesOrg,
      Createdby,
      Createdat,
      Lastchangedby,
      Lastchangedat,
      Locallastchangedat,
      @ObjectModel.text.element: ['StatusText']
      status,
      StatusText,
      /* Associations */
      _Item : redirected to composition child ZP_BillItem
}

7. Similarly created projection view for item entity: 👇

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Projection View Bill Item'
@Metadata.ignorePropagatedAnnotations: true
@Metadata.allowExtensions: true
define view entity ZP_BillItem
  as projection on ZI_BillItem
{
  key BillId,
  key ItemNo,
      MaterialId,
      Description,
      @Semantics.quantity.unitOfMeasure: 'Uom'
      Quantity,
      @Semantics.amount.currencyCode: 'Currency'
      ItemAmount,
      Currency,
      Uom,
      Createdby,
      Createdat,
      Lastchangedby,
      Lastchangedat,
      Locallastchangedat,
      /* Associations */
      _header : redirected to parent ZP_BillHeader
}

8. My metadata looks like this: 👇 (Please make sure I haven't given labels for each field, so in UI for few field it will missing. My core agenda is to elaborate factory action)

Header:

@Metadata.layer: #CORE
@UI.headerInfo:{
typeName: 'Billing Document',
typeNamePlural: 'Billing Documents',
title: { type: #STANDARD, label: 'Biiling Document', value: 'BillId' }}
annotate entity ZP_BillHeader with
{
@UI.facet: [{ //id: 'BillDocHeader',
  label: 'Billing header',
  position: 10,
  purpose: #STANDARD,
  type: #IDENTIFICATION_REFERENCE
   },
   { //id: 'BillDocItem',
   label: 'Bill Item',
   position: 20,
   purpose: #STANDARD,
   type: #LINEITEM_REFERENCE,
   targetElement: '_Item'
   }]

@UI.lineItem: [{ position:10 },
   { position: 10,
   type: #FOR_ACTION,
  dataAction: 'ApproveBill',
  label: 'Approve Bill' },
     { position: 20,
   type: #FOR_ACTION,
  dataAction: 'CopyBilldoc',
  label: 'Copy Bill' }]
@UI.selectionField: [{position: 1  }]
@UI.identification: [{ position: 1  }]
  BillId;
@UI.lineItem: [{ position:20 }]
@UI.identification: [{ position: 2  }]
  BillType;
@UI.lineItem: [{ position:30 }]
  BillDate;
@UI.lineItem: [{ position:40 }]
@UI.identification: [{ position: 3  }]
  CustomerId;
@UI.lineItem: [{ position:50 }]
@UI.identification: [{ position: 4  }]
  NetAmount;
@UI.lineItem: [{ position:60 }]
@UI.identification: [{ position: 5 }]
  Currency;
@UI.lineItem: [{ position:70 }]
@UI.identification: [{ position: 6  }]
  SalesOrg;
@UI.lineItem: [{ position:80 }]
@UI.identification: [{ position: 7  }]
@UI.textArrangement: #TEXT_ONLY
  status;

}

Item:

@Metadata.layer: #CORE
annotate entity ZP_BillItem with
{
  @ui.facet: [ {
    id:       'BillDocItem',
    purpose:  #STANDARD,
    type:     #IDENTIFICATION_REFERENCE,
    label:    'Billing Doc Item',
    position: 10
  }]
@UI.lineItem: [{ position:10 }]
@UI.identification: [{ position: 1 }]
BillId;
@UI.lineItem: [{ position:20 }]
@UI.identification: [{ position: 1 }]
  ItemNo;
@UI.lineItem: [{ position:30 }]
@UI.identification: [{ position: 1 }]
  MaterialId;
@UI.lineItem: [{ position:40 }]
  Description;
@UI.lineItem: [{ position:50 }]
  Quantity;
@UI.lineItem: [{ position:70 }]
  ItemAmount;
@UI.lineItem: [{ position:80 }]
  Currency;
@UI.lineItem: [{ position:60 }]
  Uom;
@UI.lineItem: [{ position:90 }]
  Createdby;
@UI.lineItem: [{ position:100 }]
  Createdat;
@UI.lineItem: [{ position:110 }]

  /* Associations */
  _header;

}

Now we have basic structure ready !!! Main steps for our topic start from here.

9. Create behavior definition on top of root entity. Just right click on the root view entity and select new behavior definition as shown below 👇

Once behavior definition is generated, use quick fix to implement behavior class.

10. Now add below syntax in behavior definition:

  factory action CopyBilldoc [1];

The whole behavior definition looks like this:

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

with draft;
define behavior for ZR_BillHeader //alias <alias_name>
persistent table ztb_billheader
draft table ztb_billhdr_drf
lock master total etag Lastchangedat
authorization master ( instance, global )
etag master Locallastchangedat
{
  create;
  update;
  delete;
  draft action Edit;
  draft action Resume;
  draft determine action Prepare;
  draft action Activate optimized;
  draft action Discard;
  field ( readonly : update, mandatory : create ) BillId;


  action ( features : instance ) ApproveBill result [1] $self;
  factory action CopyBilldoc [1];
  side effects
  {
    action CopyBilldoc affects $self;
  }
  association _Item { create; with draft; }

  mapping for ztb_billheader
    {
      BillId             = bill_id;
      BillType           = bill_type;
      BillDate           = bill_date;
      CustomerId         = customer_id;
      NetAmount          = net_amount;
      Currency           = currency;
      SalesOrg           = sales_org;
      CreatedBy          = createdby;
      CreateDat          = createdat;
      LastChangedBy      = lastchangedby;
      LastChangeDat      = lastchangedat;
      LocalLastChangeDat = locallastchangedat;
      status             = status;
      StatusText         = statustext;
    }
}

define behavior for ZI_BillItem //alias <alias_name>
persistent table ztb_billitem
draft table ztb_billitem_drf
lock dependent by _header
authorization dependent by _header
//etag master <field_name>
{
  update;
  delete;
  field ( readonly : update, mandatory : create ) BillId, ItemNo;
  association _header { with draft; }

  mapping for ztb_billitem
    {
      BillId             = bill_id;
      ItemNo             = item_no;
      MaterialId         = material_id;
      Description        = description;
      Quantity           = quantity;
      ItemAmount         = item_amount;
      Currency           = currency;
      Uom                = uom;
      CreatedBy          = createdby;
      CreateDat          = createdat;
      LastChangedBy      = lastchangedby;
      LastChangeDat      = lastchangedat;
      LocalLastChangeDat = locallastchangedat;
    }
}

Here, I have added extra things like draft, custom action and side effects. But for now, just focus on the line number 24.

11. Activate and use quick fix to generate this method in behavior class.

12. Use below code inside the generated factory action method. 👇

METHOD CopyBilldoc.

    " Declaration of internal tables.

    DATA: lt_bill     TYPE TABLE FOR CREATE ZR_BillHeader\\ZR_BillHeader,
          lt_billitem TYPE TABLE FOR CREATE ZR_BillHeader\_item.

    DATA: lv_billId TYPE c LENGTH 10.
   " Reading highest existing bill id and incrementing it by 1 to use as new bill id
    SELECT BillId FROM ZR_BillHeader ORDER BY BillId DESCENDING
        INTO _billid UP TO 1 ROWS.
    ENDSELECT.

    lv_billId = lv_billId + 1.

   " Read by association 

    READ ENTITIES OF ZR_BillHeader  IN LOCAL MODE
    ENTITY ZR_BillHeader
    ALL FIELDS WITH CORRESPONDING #( keys )
    RESULT DATA(lt_data1)
    ENTITY ZR_BillHeader BY \_item
    ALL FIELDS WITH CORRESPONDING #( keys )
    RESULT DATA(lt_data2)
    FAILED failed.
   
   " Appending to create a new structure
    LOOP AT lt_data1 ASSIGNING FIELD-SYMBOL(<ls_data1>).

      APPEND VALUE #( %cid = keys[ KEY entity %key = <ls_data1>-%key ]-%cid

                      "%is_draft = keys[ KEY entity %key = <ls_data1>-%key ]-%param-%is_draft

                      %data = CORRESPONDING #( <ls_data1> EXCEPT BillId )

                      ) TO lt_bill ASSIGNING FIELD-SYMBOL(<new_bill_doc>).

      <new_bill_doc>-BillId = CONV #( lv_billId ).
      <new_bill_doc>-BillDate = cl_abap_context_info=>get_system_date(  ).

      LOOP AT lt_data2 INTO DATA(ls_data2).
        APPEND VALUE #(
        %cid_ref = <new_bill_doc>-%cid
        "BillId = <new_bill_doc>-BillId
        %target = VALUE #( ( %cid = <new_bill_doc>-%cid
        BillId = <new_bill_doc>-BillId
        MaterialId = ls_data2-MaterialId
        ItemNo = ls_data2-ItemNo ) )
         ) TO lt_billitem ASSIGNING FIELD-SYMBOL(<new_bill_item>).

      ENDLOOP.

    ENDLOOP.

    "Create BO instance by copy.

    MODIFY ENTITIES OF ZR_BillHeader IN LOCAL MODE
    ENTITY ZR_BillHeader
    CREATE FIELDS ( BillId BillDate BillType Currency CustomerId NetAmount SalesOrg )
    WITH VALUE #( (
    %cid = <new_bill_doc>-%cid
    BillId = <new_bill_doc>-BillId
    BillDate = <new_bill_doc>-BillDate
    Currency = <new_bill_doc>-Currency
    CustomerId = <new_bill_doc>-CustomerId
    NetAmount = <new_bill_doc>-NetAmount
    SalesOrg = <new_bill_doc>-SalesOrg ) )
    CREATE BY \_item FIELDS ( ItemNo MaterialId )
    WITH VALUE #( (
    %cid_ref = <new_bill_doc>-%cid
    %target = VALUE #( FOR i IN lt_billitem
        FOR j IN i-%target (
    %cid = j-ItemNo
    ItemNo = j-ItemNo
    MaterialId = j-MaterialId
) ) ) )
    MAPPED DATA(mapped_create).

    " Set values to front end.

    mapped-ZR_BillHeader = mapped_create-ZR_BillHeader.


  ENDMETHOD.

The whole my behavior class looks like this: 👇

CLASS lhc_ZR_BillHeader DEFINITION INHERITING FROM cl_abap_behavior_handler.
  PRIVATE SECTION.

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

    METHODS get_global_authorizations FOR GLOBAL AUTHORIZATION
      IMPORTING REQUEST requested_authorizations FOR ZR_BillHeader RESULT result.
    METHODS ApproveBill FOR MODIFY
      IMPORTING keys FOR ACTION ZR_BillHeader~ApproveBill RESULT result.
    METHODS get_instance_features FOR INSTANCE FEATURES
      IMPORTING keys REQUEST requested_features FOR ZR_BillHeader RESULT result.
    METHODS copybilldoc FOR MODIFY
      IMPORTING keys FOR ACTION zr_billheader~copybilldoc.

ENDCLASS.

CLASS lhc_ZR_BillHeader IMPLEMENTATION.

  METHOD get_instance_authorizations.
  ENDMETHOD.

  METHOD get_global_authorizations.
  ENDMETHOD.

  METHOD ApproveBill.
    MODIFY ENTITIES OF ZR_BillHeader IN LOCAL MODE
               ENTITY ZR_BillHeader
                  UPDATE FROM VALUE #( FOR key IN keys
                  ( %tky = key-%tky
                    status = 'A' " Approved
                    StatusText = 'Approved'
                    %control-status = if_abap_behv=>mk-on
                    %control-StatusText = if_abap_behv=>mk-on ) )
                  FAILED failed
                  REPORTED reported.

    "Read changed data for action result
    READ ENTITIES OF ZR_BillHeader IN LOCAL MODE
      ENTITY ZR_BillHeader
      ALL FIELDS WITH
      CORRESPONDING #( keys )
      RESULT DATA(billheaders).

    result = VALUE #( FOR billheader IN billheaders
             ( %tky   = billheader-%tky
               %param = billheader ) ).

  ENDMETHOD.

  METHOD get_instance_features.
    READ ENTITIES OF ZR_BillHeader IN LOCAL MODE
  ENTITY ZR_BillHeader
     FIELDS (  BillId status )
     WITH CORRESPONDING #( keys )
   RESULT DATA(BillHeaders)
   FAILED failed.

    result =
      VALUE #( FOR BillHeader IN BillHeaders
        ( %key = BillHeader-%key
          %features-%action-ApproveBill = COND #( WHEN BillHeader-status = 'A'
                                                        THEN if_abap_behv=>fc-o-disabled
                                                        ELSE if_abap_behv=>fc-o-enabled )
         ) ).
  ENDMETHOD.

  METHOD CopyBilldoc.

    " Copy records assigned to internal table.

    DATA: lt_bill     TYPE TABLE FOR CREATE ZR_BillHeader\\ZR_BillHeader,
          lt_billitem TYPE TABLE FOR CREATE ZR_BillHeader\_item.

    DATA: lv_billId TYPE c LENGTH 10.

    SELECT BillId FROM ZR_BillHeader ORDER BY BillId DESCENDING
        INTO _billid UP TO 1 ROWS.
    ENDSELECT.

    lv_billId = lv_billId + 1.


    READ ENTITIES OF ZR_BillHeader  IN LOCAL MODE
    ENTITY ZR_BillHeader
    ALL FIELDS WITH CORRESPONDING #( keys )
    RESULT DATA(lt_data1)
    ENTITY ZR_BillHeader BY \_item
    ALL FIELDS WITH CORRESPONDING #( keys )
    RESULT DATA(lt_data2)
    FAILED failed.

    LOOP AT lt_data1 ASSIGNING FIELD-SYMBOL(<ls_data1>).

      APPEND VALUE #( %cid = keys[ KEY entity %key = <ls_data1>-%key ]-%cid

                      "%is_draft = keys[ KEY entity %key = <ls_data1>-%key ]-%param-%is_draft

                      %data = CORRESPONDING #( <ls_data1> EXCEPT BillId )

                      ) TO lt_bill ASSIGNING FIELD-SYMBOL(<new_bill_doc>).

      <new_bill_doc>-BillId = CONV #( lv_billId ).
      <new_bill_doc>-BillDate = cl_abap_context_info=>get_system_date(  ).

      LOOP AT lt_data2 INTO DATA(ls_data2).
        APPEND VALUE #(
        %cid_ref = <new_bill_doc>-%cid
        "BillId = <new_bill_doc>-BillId
        %target = VALUE #( ( %cid = <new_bill_doc>-%cid
        BillId = <new_bill_doc>-BillId
        MaterialId = ls_data2-MaterialId
        ItemNo = ls_data2-ItemNo ) )
         ) TO lt_billitem ASSIGNING FIELD-SYMBOL(<new_bill_item>).

      ENDLOOP.

    ENDLOOP.

    "Create BO instance by copy.

    MODIFY ENTITIES OF ZR_BillHeader IN LOCAL MODE
    ENTITY ZR_BillHeader
    CREATE FIELDS ( BillId BillDate BillType Currency CustomerId NetAmount SalesOrg )
    WITH VALUE #( (
    %cid = <new_bill_doc>-%cid
    BillId = <new_bill_doc>-BillId
    BillDate = <new_bill_doc>-BillDate
    Currency = <new_bill_doc>-Currency
    CustomerId = <new_bill_doc>-CustomerId
    NetAmount = <new_bill_doc>-NetAmount
    SalesOrg = <new_bill_doc>-SalesOrg ) )
    CREATE BY \_item FIELDS ( ItemNo MaterialId )
    WITH VALUE #( (
    %cid_ref = <new_bill_doc>-%cid
    %target = VALUE #( FOR i IN lt_billitem
        FOR j IN i-%target (
    %cid = j-ItemNo
    ItemNo = j-ItemNo
    MaterialId = j-MaterialId
) ) ) )
    MAPPED DATA(mapped_create).

    " Set values to front end.

    mapped-ZR_BillHeader = mapped_create-ZR_BillHeader.


  ENDMETHOD.

ENDCLASS.

13. Create behavior projection on top of root projection view. It will look like this 👇

projection;
strict ( 2 );

use draft;
define behavior for ZP_BillHeader //alias <alias_name>
{
  use create;
  use update;
  use delete;
  use action Edit;
  use action Activate;
  use action Discard;
  use action Resume;
  use action Prepare;
  use action ApproveBill;
  use action CopyBilldoc;
  use association _Item { create; with draft;}
}

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

  use association _header { with draft; }
}

14. Now create the service definition and expose both header and item projection:

@EndUserText.label: 'Service Definition for Billing Doc'
define service ZSD_BillingDocument {
  expose ZP_BillHeader as BillingHeader;
  expose ZP_BillItem   as BillingItem;
}

15. On top of service definition, create a service binding. I have use Odata V4 as I am using draft functionality.

16. Finally, it's a result time. Have a first look of our application. 👇

17. Now select any record and click on copyBill. I am selecting second record.

18. Once I clicked on copyBill, We can see a new BillId is generated with same line items as of source record.

Conclusion: So, we have come to the end of our blog. We have seen how we can implement an use case related to factory action. I want to summarise important steps again required to implement factory action:

Declare factory action in behavior definition and activate it.
Use quick fix to generate the method in implementation class.
Use Read by association to read both header and child entity.
Append the new structure.
Create new duplicate BO entry by using create by association.

Thank You for reading my blog. Do comment if you have any doubt or if you know any better way to do this. Good Bye 👋

Dump When Checking Faulty RAP Object Based On Union CDS-View (OnPremise 2023 SP01)

2026-03-25T11:29:21.883000+01:00

Dear Community,

Recently I found a bug when checking/activating a RAP object which is based on a union CDS-View and has an error across multiple artifacts. I would like to describe and summarize this for reporting and to save other people’s time during analysis.

Initial Situation

Let's say I want to consolidate different findings from our beloved sflight. For this purpose, I created the following union view:

@AbapCatalog.viewEnhancementCategory: [ #NONE ]
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Unifies different validation findings'
@Metadata.ignorePropagatedAnnotations: true

define root view entity ZI_FLIGHT_FINDINGS_UNION
  as select from ZI_DELAYED_FLIGHTS

{
  key Carrid,
  key Connid,
  key Fldate,

      ValidationResult,
      ValidationCategory,
      DelayInMinutes,
      -1                  as MaxPassengers,
      -1                  as BookedPassengers
}

union
  select from ZI_OVERBOOKED_FLIGHTS

{
  key Carrid,
  key Connid,
  key Fldate,

      ValidationResult,
      ValidationCategory,
      -1                  as DelayInMinutes,
      MaxPassengers,
      BookedPassengers
}

Based on that union, I want to create a simple Fiori Elements app in which the user can see all the different findings and is able to create comments via an action. For the action we create the following Behavior Definition:

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

define behavior for ZI_FLIGHT_FINDINGS_UNION

lock master
authorization master ( instance )

{
  action addComment parameter char200;
}

I decided to go for an unmanaged implementation, because unions do not easily support CRUD operations (and they are not needed for the business case yet). The handler class in the class pool looks like this:

CLASS lhc_ZI_FLIGHT_FINDINGS_UNION DEFINITION INHERITING FROM cl_abap_behavior_handler.
  PRIVATE SECTION.
    METHODS get_instance_authorizations FOR INSTANCE AUTHORIZATION
      IMPORTING keys REQUEST requested_authorizations FOR zi_flight_findings_union RESULT result.

    METHODS addComment FOR MODIFY
IMPORTING keys FOR ACTION zi_flight_findings_union~addComment.

    METHODS read FOR READ
      IMPORTING keys FOR READ zi_flight_findings_union RESULT result.
ENDCLASS.


CLASS lhc_ZI_FLIGHT_FINDINGS_UNION IMPLEMENTATION.
  METHOD get_instance_authorizations.
  ENDMETHOD.

  METHOD addComment.
    "Create comment by EML ....
  ENDMETHOD.

  METHOD read.
  ENDMETHOD.
ENDCLASS.

Everything works, everything can be activated. But now silly me wants to save additional data from our ZI_FLIGHT_FINDINGS_UNION object. Reading with EML isn't possible yet, because read isn't implemented. To avoid implementing the read method myself, I got the idea to change the Behavior Definition to managed with unmanaged save (would this even work?):

managed with unmanaged save implementation in class zbp_i_flight_findings_union unique;
strict ( 2 );

define behavior for ZI_FLIGHT_FINDINGS_UNION
lock master
authorization master ( instance )
{
  action addComment parameter char200;
}

Now I introduced some inconsistencies, because the handler still contains the read method.
But these errors are hidden now.

There is no warning inside the behavior definition, but activating leads to the following error:

By checking ST22 we can see that we get for every syntax check and every activation the following dump:

If we don't know the mistake we made inside the behavior definition and its implementation we have no indication of what went wrong.

How this dump happens

The dump happens inside the Class CL_CSP_MD_ANNOTATION_READER in method create_by_metadata:

    lo_instance->mt_element_annotation = CORRESPONDING #( is_cds_annotations_md-elements MAPPING element_name     = elementname
                                                                                                 annotation_name  = annoname
                                                                                                 annotation_value = value ).

This statement tries to write values from is_cds_annotations_md-elements to lo_instance->mt_element_annotation. That table expects a unique key with annotation_name and element_name.

But this uniqueness is not given:

The reason is in table DDFIELDANNO in which the assigned annotations are stored. The annotation ABAPCATALOG.INTERNAL.ISMANDT is stored twice, because of our union:

Workaround

Caution: Be careful when working in this area, especially when debugging or activating the object. I cannot guarantee that it won’t lead to inconsistencies or other issues in your system. You do everything at your own risk.

At the end of method IF_CSP_WRP_DD_ANNOTATION~GET_ANNOS_MASS in class CL_CSP_WRP_DD_ANNOTATION I placed a Breakpoint, triggered the check (not the activation!) and was able to remove the duplicate line. After that, I was able to get the real finding:

"Class can't be analyzed during BDEF implementation check. Inconsistencies or errors exist: "ZI_FLIGHT_FINDINGS_UNION" has the implementation type "managed", hence the implementation type "READ" is superfluous."

Conclusion

With this workaround it's possible to avoid the dump and retrieve the actual finding.

To fix the dump, the duplicate entry must be prevented. I assume that either the selection (method _GET_DRCT_ANNS_4_ENTT_ELMNTS_M in class CL_DD_DDL_ANNOTATION_SERVICE) or the merging of the annotations (method MERGE_ENTITIES_ELMNTS_ANNOS in class CL_DD_DDL_ANNOTATION_MERGER) might be the relevant place to fix it.

I'm also creating an incident and keep you updated. If it's already fixed after 2023 SP01, please let me know.

Thank you for reading and best regards
Marc

Fiori List Report: The "Process All" Dilemma — Parsing OData $filter in ABAP

2026-03-26T18:27:35.306000+01:00

The Problem

This scenario is more common than you might think.

In the old SAP GUI world, ALV lists frequently had buttons like "Execute All" or "Process All" defined in the GUI Status, or users could simply "Select All" rows and trigger an action. The entire dataset was right there in memory — stateful, accessible, simple.

Unfortunately, the same approach is still often requested in Fiori Elements List Reports. The reason? There's still a widespread difficulty in understanding the fundamental difference between stateful and stateless, between a classic ALV list and a Fiori List Report.

When we try to explain that there's an OData protocol with pagination behind the scenes, that "Select All" doesn't truly select all rows, or that an "Execute All" action has no knowledge of which records to process — unlike in ALV where the entire internal table was available — we can often steer the design away from this pattern. But sometimes, we can't.

The Fiori warning message helps users understand that "Select All" is only partial — it's no longer the same as it was with ALV lists.

There are legitimate use cases where, after filtering a dataset, reviewing it, validating it, the user needs to "confirm" an action or a status change to be applied to that specific result set they're currently looking at.

I won't go into the details of how the action should be implemented in ABAP — there could be timeout concerns, and often these actions are executed via background tasks or jobs. I want to focus specifically on the approach for capturing the "snapshot" of what the user has filtered.

As we said, "Select All" is not a viable option. In the modern world we have pagination, and we can't expect the user to scroll all the way to the bottom of the list. Retrieving all row identifiers from the frontend is simply not feasible.

Our Approach

The best solution we've implemented (together with @SimoneLicciardi ) is to pass the applied filter criteria back to a Static Action — essentially the same filters that were active when the user pressed "Go".

We can define an Abstract Entity as the import parameter for the RAP action. If the action dialog already has other parameters, this is simply an additional hidden parameter (@UI.hidden: true) that we can call FilterString.

define abstract entity ZA_ProcessAllParams {
  @UI.hidden: true
  FilterString : abap.string(4000);
  // ... other action parameters if needed
}

The Fiori Elements Extension

On the Fiori Elements List Report side, we need custom action logic that does two things when the user triggers the action: capture the current $filter string and inject it into the hidden parameter.

This can be achieved through a custom action defined in the manifest.json (or via a controller extension, depending on your app setup).

The _getFilterString method extracts the $filter from the current table row binding — this is exactly the same filter the framework sent to the backend when the user pressed "Go".

function _getFilterString(oView) {
    // Table ID follows Fiori Elements convention: 
    // "<appId>::<ListReportPage>--fe::table::<EntitySet>::LineItem"
    var oTable = oView.byId("<your-table-control-id>");
    if (oTable) {
        var oRowBinding = oTable.getRowBinding();
        if (oRowBinding) {
            var sPath = oRowBinding.getDownloadUrl();
            if (sPath) {
                var iFilterStart = sPath.indexOf("$filter=");
                if (iFilterStart > -1) {
                    var sFilter = sPath.substring(iFilterStart + 8);
                    var iNextParam = sFilter.indexOf("&");
                    if (iNextParam > -1) {
                        sFilter = sFilter.substring(0, iNextParam);
                    }
                    return decodeURIComponent(sFilter);
                }
            }
        }
    }
    return "";
}

Then in the action handler, we invoke the static action and pass the $filter string as the hidden parameter:

onPressExecuteAll: function () {
    var oView = this.editFlow.getView();
    var sActionName = "<your action bound context>";
    var sFilterString = _getFilterString(oView);

    var oInvokeParams = {
        controlId: "<your-table-control-id>",
        bStaticAction: true,
        invocationGrouping: "Isolated",
        parameterValues: [{
            name: "FilterString",
            value: sFilterString
        }]
    };

    this.editFlow.invokeAction(sActionName, oInvokeParams)
        .then(function (oResult) {
            // handle success
        }).catch(function (oError) {
            console.error("Action error:", oError);
        });
}

The key point: the parameterValues array injects the filter string into the hidden FilterString field of the Abstract Entity. The user never sees it — the action dialog shows only the visible parameters (if any), while the filter criteria travel silently to the backend.

Note: this was tested on S/4HANA 2023 with OData V4 and SAPUI5 1.120.

The ABAP Parser

On the backend, the action handler receives the $filter string and needs to parse it into ABAP range tables to re-execute the query with the same criteria.

We looked for standard solutions — for example, the method ODATA_FILTER2SELECT_OPTION of class CL_CLB2_TOOLS — but it only supports OData V2.

So we built a custom reusable class: ZCL_ODATA_FILTER_PARSER, which handles both V2 and V4 syntax and converts the $filter string directly into ABAP range tables.

DATA(lo_parser) = NEW zcl_odata_filter_parser(
  iv_filter  = lv_filter_string
  iv_version = zcl_odata_filter_parser=>gc_version-v4
).

DATA(lt_r_plant) = lo_parser->get_range( 'Plant' ).
DATA(lt_r_mat)   = lo_parser->get_range( 'Material' ).
DATA(lt_r_date)  = lo_parser->get_range( 'DeliveryDate' ).

The class is open source, includes ABAP Unit tests and is installable via abapGit. You can find the usage examples in the repository:

https://github.com/alespad/abap-odata-filter-parser

This is how we approached solving this problem. If you know of better approaches, closer to standard functionality, we'd love to hear about them — please share in the comments!

Custom Business Configurations (F4579): Define default grouping and sorting

2026-03-27T13:50:03.260000+01:00

Introduction

The Custom Business Configurations (CUBCO) app serves as an entry point to the Business Configuration Maintenance Object (SMBC) provided by custom applications or partners.

This blog explains how to define the default grouping and sorting for the tables of the business configuration object.
The basic procedure is already explained here, but we apply it directly to the result of the ADT wizard.

This blog is relevant for

Example scenario

Company codes are defined in the configuration table ZDEMO_CC. In the CUBCO app, the rows are to be grouped and sorted by country.

@EndUserText.label : 'Company Code'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zdemo_cc {
  key client            : abap.clnt not null;
  key company_code      : abap.numc(4) not null;
  country               : land1;
  last_changed_at       : abp_lastchange_tstmpl;
  local_last_changed_at : abp_locinst_lastchange_tstmpl;
}

Define presentation variant

First you use the ADT wizard to generate a Business Configuration Maintenance Object for this table.

In the generated CDS view ZI_COMPANYCODE_S of the Singleton entity, you change the facet type from #LINEITEM_REFERENCE to #PRESENTATIONVARIANT_REFERENCE and add the targetQualifier attribute:

  .facet: [ {
    id: 'ZI_CompanyCode', 
    purpose: #STANDARD, 
    type: #PRESENTATIONVARIANT_REFERENCE, 
    targetQualifier: 'myVariant',
    label: 'Company Codes', 
    position: 1 , 
    targetElement: '_CompanyCode'
  } ]
  .lineItem: [ {
    position: 1 
  } ]
  key 1 as SingletonID,

In the metadata extension ZI_COMPANYCODE of the company code entity, add the following presentation variant:

.presentationVariant: [
  {
    qualifier: 'myVariant',
    sortOrder: [
      {
        by: 'Country',
        direction: #ASC
      }
    ],
    groupBy: [ 'Country' ],
    visualizations: [{type: #AS_LINEITEM}]
  }
]
annotate view ZI_CompanyCode with

Finally, open the generated SMBC object ZCOMPANYCODE in ADT and open the table settings section. Change the table type attribute from Grid Table to Responsive Table because grouping is not supported for grid tables. If you only need the default sorting, you can continue to use the grid table.

Our 2026 Roadmap for Joule for Developers ABAP AI capabilities

2026-03-28T20:13:48.908000+01:00

Sapphire 2026 is approaching quickly and as usual it will bring lots of new announcements. So now is the right point in time to recap what has been announced already until Q2/2026 and prepare for the ABAP AI sessions.

The ABAP Platform AI (covering both SAP BTP ABAP Environment and SAP S/4HANA) transitions from a set of independent AI skills to full-scale Agentic AI. The roadmap focuses heavily on increasing developer productivity via agents in Joule for Developers ABAP (J4D ABAP) and the modernization of ABAP development tools.

The key benefits for customers and partners of the roadmap until Q2/2026 are:

ABAP development tools with AI Agents in VS Code with ABAP MCP Server.
ABAP AI for lower releases of SAP S/4HANA Cloud Private Edition (i.e. 2021, 2022, 2023 and 2025).
Simplified customer on-boarding of ABAP AI via SAP for Me and Central Business Configuration.
Faster innovation with Side-by-Side consumption of SAP and 3rd party Agentic IDEs and LLMs
(e.g. Microsoft, Amazon, IBM, OpenAI, Anthropic, Google, Mistral…)

The biggest shift in 2026 will be the move toward Agentic AI, where the existing ABAP AI skills doesn't just explain, complete or generate code (e.g. RAP, CDS, Tests) independently but acts as an autonomous collaborator. This includes built-in ABAP MCP (Model Context Protocol) server. The introduction of VS Code as IDE can only be a start as the depth and breath of Eclipse which we achieved in so many years cannot be reached with one or two steps in VS Code. It'll be a journey which starts with first providing End-to-end UI services development with agents.

The new ABAP AI side-by-side architecture is designed to provide a scalable and future‑proof foundation for ABAP AI capabilities across heterogeneous SAP landscapes. It enables customers to consume ABAP AI services side‑by‑side, independent of the underlying S/4HANA release, ensuring access even for lower‑release Private Edition systems.

A core benefit of the architecture is also its simplified enablement model through SAP for Me and Central Business Configuration, reducing on-boarding effort and ensuring consistent lifecycle management across environments.
In addition, the architecture allows us to accelerate innovation speed by allowing to leverage SAP‑provided ABAP AI models alongside leading third‑party LLMs (e.g., Microsoft, Amazon, IBM, OpenAI, Anthropic, Google, Mistral) more independently from releases. This flexibility ensures rapid adoption of new capabilities without dependency on individual release cycles.

If you missed the highlights we delivered in Q1/2026 have a look into what Olga Dolinskaja shared about ABAP AI ATC finding explain and custom code explain and proposals. Although this will be a focus also for our future roadmap we will also not stop investing into AI app generators like the Embedded Analytics model generator.

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,

The Agentic Revolution Is Here — And Your ABAP Code Is the Foundation

2026-04-03T18:00:00.017000+02:00

Three Waves in Two Years

To understand where we are, you need to understand the three inflection points Jensen described. They happened faster than anyone expected.

Wave 1: Generative AI (2022–2023)

ChatGPT changed computing from retrieval-based to generative. Instead of a database returning a record, a model generates an answer. Jensen put it bluntly: "Computing used to be retrieval-based. Now it's generative." The architecture implications of that sentence are enormous and still rippling through every layer of enterprise software.

Wave 2: Reasoning AI (2024)

OpenAI's o1 model introduced something that made generative AI trustworthy: the ability to think. To reflect. To decompose a problem it couldn't solve into steps it could. To ground itself on facts before answering. Reasoning AI made large language models genuinely useful for complex, multi-step work — not just creative writing and summarisation.

Wave 3: Agentic AI (2025–2026)

This is the one that changes your job. Jensen cited Claude Code — the very AI assistant many of us now use daily — as the breakthrough moment:

"Claude Code has revolutionised software engineering. There is not one software engineer at NVIDIA today who is not assisted by an AI coding agent."

The shift is fundamental. With generative AI, you ask a question. With agentic AI, you give a task. The agent reads your files, writes code, compiles it, tests it, finds the failures, fixes them, and iterates — autonomously, in a loop, until the work is done or it needs your input.

Computing demand, Jensen said, has grown one million times in the last two years. That is not a typo. The explosion is driven by agentic inference: every time an agent thinks, plans, reads a file, calls a tool, or generates an output, it burns tokens.

GTC 2026 Keynote — Jensen Huang's enterprise agentic architectures slide (02:02:57). SAP is bottom-left. Each diagram is a production blueprint, not a roadmap.

What Jensen Showed at 02:02:57

At just over two hours into the keynote, Jensen showed a slide he called a renaissance. Each of the twelve architecture diagrams was a real, production blueprint. Not a roadmap. Not a vision. Each company had already rebuilt its product around AI agents.

"This is a reinvention. A renaissance of enterprise IT. Every single SaaS company will become an Agentic as a Service company. No question about it."

He compared it to three previous platform shifts:

When Linux arrived → every company needed a Linux strategy
When HTML/HTTP arrived → every company needed a web strategy
When Kubernetes arrived → every company needed a cloud-native strategy
Now Now OpenClaw (the open-source agentic OS) has arrived → every company needs an agentic strategy

NemoClaw and SAP: A Security Partnership

Jensen announced NemoClaw as NVIDIA's enterprise-hardened version of OpenClaw. To understand where it fits in the SAP picture, it helps to be precise about what it is — and what it is not.

OpenClaw is, in Jensen's words, "the operating system of agentic computers." It handles task decomposition, sub-agent spawning, tool calling, file access, cron scheduling, multi-modal I/O, and LLM orchestration. It reached more GitHub stars in a few weeks than Linux achieved in thirty years.

The enterprise problem with a system that can "access sensitive information, execute code, and communicate externally" is obvious. You cannot deploy raw OpenClaw in an SAP landscape and have it reach your vendor master, financial postings, and HR records without controls.

NemoClaw solves this by adding three security layers on top of OpenClaw:

Layer	What It Does
OpenShell	Sandboxes agent execution; controls what it can read, write, and call
Policy Engine	Enforces the enterprise's own business rules
Network Guardrail + Privacy Router	Prevents data leaving the enterprise boundary

Important clarification: NemoClaw is not the foundation SAP Joule is built on. Joule is SAP's own product, with its own architecture, models, and AI infrastructure running on BTP and SAP AI Core. NemoClaw is NVIDIA technology that SAP — as a launch enterprise partner — is integrating as an optional security and governance layer within BTP, tied specifically to Joule Studio. It is available for customers who require the strongest possible compliance controls when agents interact with sensitive ERP, financial, or supply chain data.

The architecture looks like this:

The bottom line for ABAP developers remains unchanged regardless of which security envelope is in play: when an agent needs to do something in SAP — read a purchase order, create a vendor, trigger a workflow, query a cost centre — it calls your ABAP.

Your BAPIs. Your CDS views. Your OData services.

What This Means in Practice

Let me make this concrete with an example that exists today.

A procurement manager asks Joule: "Which of our top twenty suppliers have delivery performance below 90% this quarter, and what is the total open invoice value against them?"

In the pre-agentic world, someone writes a report in SE38, schedules it, exports to Excel, and manually cross-references two tables. Elapsed time: hours, or days if it hits a queue.

In the agentic world, Joule:

Decomposes the question into sub-tasks
Calls a procurement agent → queries I_SupplierDeliveryPerformance CDS view via OData
Calls a finance agent → queries I_SupplierOpenItemMD CDS view via OData
Synthesises both results
Returns a structured answer in seconds

The entire chain runs through NemoClaw's policy engine and your ABAP authorization framework. The agent's service user has only the authorizations you have granted. Every CDS view it accesses must have the proper access control annotation and a corresponding DCL.

The Four Things Your ABAP Must Get Right
If agents are going to call your code — and they are — four things matter more than they ever did before.

1. Clean, Annotated CDS Views

CDS views are the primary structured data interface for AI agents in SAP. An agent does not navigate transaction codes. It calls OData endpoints backed by CDS. If your CDS views lack semantic annotations, have incomplete access control, or expose data structures that predate any logical data model, they become a liability.The minimum bar for agent-ready CDS:

@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Supplier Delivery Performance'
@VDM.viewType: #CONSUMPTION
@OData.publish: true
define view entity I_SupplierDeliveryPerformance
  as select from ...
{
  @Semantics.businessPartner.role: #SUPPLIER
  SupplierID,

  @Semantics.quantity.unitOfMeasure: 'DeliveryUnit'
  ConfirmedDeliveryQty,

  @Semantics.percentage
  OnTimeDeliveryRate
}

Semantic annotations tell the LLM what each field means. Without them, the agent is guessing from column names. With them, it can reason correctly.

2. Authority Checks on Every Agent-Callable Interface

NemoClaw's policy engine delegates final security enforcement to ABAP. This is not a weakness — it is the correct architecture. The LLM should not be trusted with authorization decisions. ABAP should.
Every function module, BAPI, and method that an agent can call must perform an explicit authority check:

METHOD get_supplier_invoice_data.
  AUTHORITY-CHECK OBJECT 'F_LFA1_BUK'
    ID 'BUKRS' FIELD iv_company_code
    ID 'ACTVT' FIELD '03'.

  IF sy-subrc <> 0.
    RAISE EXCEPTION TYPE cx_sy_authorization_check
      EXPORTING
        textid = cx_sy_authorization_check=>no_authorization.
  ENDIF.

  " ... proceed with data retrieval
ENDMETHOD.

An agent running as a service user with overly broad authorizations is an insider threat waiting to happen. Lock it down at the ABAP layer.

3. Machine-Speed Performance

A human clicks a button every thirty seconds. An agent may call your BAPI ten thousand times per hour. An interface that performs acceptably under human load may collapse completely under agent load.
Review your agent-callable interfaces against these criteria:
• No SELECT * in performance-critical paths — agents fetch data in loops, field-level selects only.
• Buffer vendor master, material master, and configuration data where appropriate.
• Avoid dialogue modules and unnecessary commits in agent-exposed interfaces — agents expect atomic, stateless calls.
• Consider ABAP Cloud compatibility — if you are on S/4HANA, agent integrations will increasingly come via BTP.

4. Reliable, Structured Error Returns

Agents chain multiple tool calls into a single business process. If step three of a five-step chain fails silently — no exception raised, just a blank result set — the agent may proceed with corrupted state and complete a transaction based on missing data.
Your interfaces need to fail loudly, clearly, and catchably:

METHOD create_purchase_requisition.
TRY.
" ... BAPI call
IF lt_return[] IS NOT INITIAL.
LOOP AT lt_return INTO ls_return
WHERE type = 'E' OR type = 'A'.
RAISE EXCEPTION TYPE cx_pr_creation_failed
EXPORTING
message = ls_return-message
message_id = ls_return-id
number = ls_return-number.
ENDLOOP.
ENDIF.
CATCH cx_sy_authorization_check INTO DATA(lx_auth).
RAISE EXCEPTION TYPE cx_pr_creation_failed
EXPORTING message = 'Authorization check failed'.
ENDTRY.
ENDMETHOD.

A well-structured exception gives the orchestration layer the information it needs to retry, compensate, or escalate. A dump gives it nothing.

Physical AI: Why EWM and IBP Developers Should Pay Close Attention

Jensen spent a significant portion of the keynote on physical AI — robots, autonomous vehicles, digital twins. At first glance this might seem distant from ABAP. It is not.

He announced partnerships with ABB, KUKA, Universal Robots, BYD, Hyundai, Nissan, and Geely — collectively representing the automation of manufacturing floors and logistics networks at a scale never seen before. These physical systems will generate transactions. Inventory movements, goods receipts, production confirmations, delivery completions — triggered by machines at machine speed, not by warehouse workers scanning barcodes.

If you work in SAP Extended Warehouse Management, SAP Integrated Business Planning, or SAP Manufacturing Integration and Intelligence, the interfaces you build today will be called by robots tomorrow. The same four principles apply — and the performance requirement becomes even more acute.

Your Learning Roadmap

The field is moving fast. But not everything needs to be learned at once. Here is how I would prioritise it.

Start Now — Zero Extra Investment Required

AI tools today. Use AI coding tools on real ABAP work — every unit test, every code review, every CDS view.
Learn what SAP Joule can already do. Log into your BTP account and explore the Joule capabilities available today.
Audit your CDS views. Run a quick check across your landscape for CDS views with @AccessControl.authorizationCheck: #NOT_REQUIRED — these are potential agent-accessible data leaks.

Next Three to Six Months

ABAP RAP (RESTful Application Programming Model). If you have been deferring it, stop. RAP is the model that produces the OData V4 services that Joule agents consume.
SAP AI Core and SAP BTP basics. You do not need to become a BTP developer. Understand the platform well enough to design ABAP interfaces that integrate cleanly with it.
Python literacy. Not fluency — literacy. Most AI tooling and agent orchestration frameworks are Python-first. Being able to read a Python agent script is now a professional responsibility.

Strategic Awareness

OpenClaw and MCP (Model Context Protocol). OpenClaw is the open-source agent OS. MCP is the protocol that defines how agents discover and call tools. SAP Joule implements MCP under the hood.
HANA Vector Engine. HANA Cloud's vector engine brings unstructured data (PDFs, emails, contracts) directly into your SAP data layer.

The Part Nobody Is Saying Loudly Enough

Jensen made a prediction that deserves more attention than it received.

In the near future, every engineer at NVIDIA will receive an annual token budget — roughly equivalent to half their salary in additional compensation — because AI-amplified engineers are demonstrably ten times more productive. Engineers are already asking: "How many tokens come with this job?"

Here is the part that matters for us specifically:

AI tokens without SAP domain expertise produce plausible-looking but wrong ABAP. An LLM that does not understand the difference between a financial posting document and a parked document will generate code that compiles, passes basic tests, and silently corrupts your general ledger. It will call RFC_READ_TABLE in production because it found an example online. It will bypass the credit check in a sales order because it did not know the check existed.

Your twenty years of knowing where the bodies are buried in SAP — that is not a liability in an AI-augmented world. It is the irreplaceable ingredient that makes the AI's output correct and trustworthy.

The developers who will thrive are not the ones who resist this shift. And they are not the ones who hand everything to an LLM and hope for the best. They are the ones who treat AI as a powerful amplifier of their own judgment — who know enough to direct it well, verify its output, and design the systems it integrates with.

That combination — deep SAP domain knowledge plus AI tool fluency — is genuinely rare right now. The window to build it is open. It will not stay open long.

Wrapping Up

GTC 2026 was not a technology conference for GPU enthusiasts. It was a signal that the enterprise software industry has passed an inflection point. Jensen's slide showing SAP, Salesforce, ServiceNow, and Siemens side by side — each with a production agentic architecture — was not a prediction of what is coming. It was a photograph of what has already happened.

SAP has placed its bet. Joule is real, BTP is the platform, and the structured data of your SAP landscape — managed, modelled, and secured by ABAP code — is what gives every agent running on top of it the ground truth it needs to be useful.

Action Items

✓ Write clean CDS views.

✓ Lock down your authority checks.

✓ Tune for machine-speed consumption.

✓ Raise clear exceptions.

✓ Learn RAP.

✓ Open Claude Code.

The revolution is not coming for your job. It is coming for the parts of your job that should have been automated years ago. What remains — and what becomes more valuable — is everything that requires judgment, domain knowledge, and the ability to see when the AI is confidently wrong.

That is the ABAP developer of 2026.

Moving from Hub Gateway to Direct S/4HANA OData V4: A Customized Reusable RAP Processing Framework

2026-04-07T05:11:24.260000+02:00

In SAP landscapes using a Gateway Hub architecture, OData services are typically exposed through a separate Gateway system, with data processing handled in the backend S/4HANA system via RFC calls. While this architecture has been widely used, it introduces additional system dependencies and layers of communication.

With the adoption of ABAP RESTful Application Programming Model (RAP) and OData V4, services can now be exposed directly from S/4HANA, allowing developers to simplify the architecture and implement more structured service processing patterns.

In this article, I share a framework concept I have used in my developments to organize how requests to RAP Custom Entities are handled. The approach introduces a reusable processing structure for request handling, data extraction, transformation, and response construction.

This concept is intended to improve maintainability, extensibility, and consistency when building RAP-based services, using existing ABAP objects.

End-to-End Implementation

The framework is implemented as a base processing class that contains the common request handling logic such as entity configuration loading, request context extraction, data transformation, and response construction.

This class is not intended to be used directly. Instead, it is designed to be subclassed for each specific service implementation, where entity-specific logic such as data extraction and transformations can be implemented.

To better understand how the framework works, let's walk through the runtime execution flow when a client calls the OData V4 service.

Custom Entity Implementation

@EndUserText.label: 'Sales Order Details (OData V4)'
@AccessControl.authorizationCheck: #NOT_REQUIRED
@Metadata.allowExtensions: true

@ObjectModel.query: {
  implementedBy: 'ABAP:ZCL_V4_SALESORDER_QUERY'
}

define root custom entity ZCE_SalesOrderDetails
{
  key SalesOrder        : vbeln;
  key SalesOrderItem    : posnr;
      Material          : matnr;
      Customer          : kunnr;
      OrderQuantity     : abap.quan(13,3);
      OrderUnit         : meins;
      NetPrice          : abap.curr(15,2);
      Currency          : waers;
      CreatedBy         : syuname;
      CreatedOn         : abap.dats;
      DeliveryDate      : abap.dats;

      _ScheduleLines : composition [0..*] of ZCE_SalesOrderSchedule;
}

Using the Framework Class as a Superclass

The class ZSV00CL_CE_V2TOV4_CONVERSION acts as a generic processing framework for RAP Custom Entities. It provides reusable logic for handling the complete request lifecycle, including request handling, data retrieval orchestration, payload extraction, entity transformation, and response construction.

To use this framework for a specific business entity, a child class must be created that inherits from the framework class. For example:

ZCL_V4_SALESORDER_QUERY

This class is defined as:

CLASS zcl_v4_salesorder_query DEFINITION
PUBLIC
INHERITING FROM zsv00cl_ce_v2tov4_conversion
FINAL
CREATE PUBLIC.

By inheriting from the framework class, the child class automatically gains access to the entire processing pipeline implemented in the superclass, including the implementation of the RAP interface method:

IF_RAP_QUERY_PROVIDER~SELECT

This means the child class does not need to reimplement the standard request processing logic.

RAP Custom Entity Processing Framework – Method Responsibilities

MethodLayerWhen It Is CalledPurposeKey Actions

Method	Layer	When its called	Purpose	Key Actions
IF_RAP_QUERY_PROVIDER~SELECT	RAP Entry Layer	Triggered when OData V4 service is called	Entry point for RAP query processing	Checks if data is requested, loads entity configurations, and starts request handling
LOAD_ENTITY_CONFIGURATIONS	Configuration Layer	Immediately after SELECT	Loads metadata configuration for entities	Defines entity mapping, source entity set, source/target types, and field mappings
HANDLE_DATA_REQUEST	Processing Controller	After configurations are loaded	Main orchestrator for request execution	Calls context extraction, determines entity type, and triggers fetch + transformation logic
GET_REQUEST_CONTEXT	Context Layer	Early in request handling	Extracts request parameters from RAP request	Reads filters, paging info, entity name, and key values
IS_ROOT_ENTITY	Routing Layer	After context extraction	Determines whether request is root or child entity	Controls whether data must be fetched or extracted from existing payload
HANDLE_DATA_FETCH	Data Retrieval Layer	When root entity is requested	Retrieves data from backend sources	Builds request keys, identifies main source entity set, and triggers backend retrieval (RFC / OData V2 / API)
CALL_RFC_FOR_POST (optional)	Integration Layer	During data fetch if backend logic needed	Calls external logic such as RFC or API	Used for backend system communication
EXTRACT_DATA	Payload Layer	After backend data is retrieved	Extracts entity-specific data from payload container	Dynamically unwraps source entity data into ABAP structures/tables
HANDLE_ENTITY_CONVERSIONS_GET	Transformation Controller	After data extraction	Controls transformation process	Determines if source data is structure or table and calls appropriate conversion method
TRANSFORM_STRUCTURE_DATA	Transformation Layer	When source payload is a structure	Converts single record structure from V2 → V4	Applies field mapping and conversion exits
TRANSFORM_TABLE_DATA	Transformation Layer	When source payload is a table	Converts multiple records from V2 → V4	Iterates over rows and applies field mapping
CONVERSION_EXIT	Business Logic Layer	During transformation	Applies custom logic for specific fields	Handles timestamp conversion, code mapping, calculated fields
SET_RESPONSE_DATA	Response Layer	Final step before returning result	Sends processed data back to RAP framework	Sets data and total record count in response object

High-Level Runtime Flow

Detailed Method Execution Sequence

Below is the exact order of method execution when the OData V4 service is called.

Step 1 — RAP Query Trigger

When a consumer calls the Custom Entity OData V4 service, RAP invokes :

METHOD if_rap_query_provider~select.

Example implementation:

METHOD if_rap_query_provider~select.

  IF io_request->is_data_requested( ).

    load_entity_configurations( ).

    handle_data_request(
      ii_request  = io_request
      ii_response = io_response ).

  ENDIF.

ENDMETHOD.

What happens here?

RAP checks if data is requested.
Entity mappings are loaded.
The main processing method is called.

Step 2 - Loading Configurations

The method initializes the processing setup for the requested entity. It determines the entity being requested and loads the relevant configuration that defines how the framework should retrieve, process, and transform the data.

This step allows the framework to dynamically control entity-specific logic while keeping the main request handling flow generic and reusable.

Method:

LOAD_ENTITY_CONFIGURATIONS

Example:

gt_entity_config = VALUE #( ( entity_id       = 'oDataV4 Entity 1 '
                              entity_set      = 'oDataV2 Entity Set'
                              src_type        = 'Table Type for oDataV2 Entity 1'
                              trg_type        = 'Table Type for oDataV4 Entity 1'
                              src_type_structure = abap_true
                              src_is_entity_set = abap_true
                              field_map       = VALUE ty_abap_map_tab(  ( src_field = 'oData V2 Field 1'  trg_field = 'oData V4 Field 1' )
                                                                        ( src_field = 'oData V2 Field 2'  trg_field = 'oData V4 Field 2'  ) ) )
                            ( entity_id       = 'oDataV4 Entity 2 '
                              entity_set      = 'oDataV2 Entity Set'
                              src_type        = 'Table Type for oDataV2 Entity 2'
                              trg_type        = 'Table Type for oDataV4 Entity 2'
                              src_type_structure = abap_true
                              src_is_entity_set = abap_true
                              field_map       = VALUE ty_abap_map_tab( ( src_field = 'oData V2 Field 1' trg_field = 'oData V4 Field 1' )
                                                                       ( src_field = 'oData V2 Field 2' trg_field = 'oData V4 Field 2' ) ) ) .

Step 2 — Request Context Extraction

The framework extracts important request parameters.

Method called:

GET_REQUEST_CONTEXT

Example:

DATA(ls_context) = get_request_context( ii_request ).

The context contains:

Filters
Page size
Entity ID
Key values

Structure example:

Entity ID
Filter Conditions
Paging Information
Keys

Step 3 — Identify Root Entity

The framework checks whether the request is for a root entity or a child entity. You can write your own logic here on how the root can be determined.

Method:

IS_ROOT_ENTITY

Why is this needed?

Because root entities trigger the initial data retrieval, while child entities use already available payload data.

Step 4 — Fetch Source Data

If the request is for the root entity, the following method is executed:

HANDLE_DATA_FETCH

Example implementation:

METHOD handle_data_fetch.

  build_keys(
    iv_fieldname = 'FIELD_ID'
    iv_value     = 'FIELD_VALUE' ).

  is_main_source_entity_set( ).

ENDMETHOD.

Responsibilities of this method:

Build request keys
Determine the main source entity set
Trigger backend data retrieval (custom implementation)
This method is typically redefined in subclasses.

Step 5 — Convert Entity Data

Next, the framework converts the source payload to the target entity.

Method:

HANDLE_ENTITY_CONVERSIONS_GET

This method performs the main transformation workflow.

Example:

    FIELD-SYMBOLS: <lfs_t_output_data> TYPE STANDARD TABLE.
    FIELD-SYMBOLS: <lfs_t_source_data> TYPE STANDARD TABLE.
    FIELD-SYMBOLS: <lfs_source_data> TYPE any.
    FIELD-SYMBOLS: <lfs_output_data> TYPE any.
    DATA: lr_data TYPE REF TO data.

    " Extract source data for the  entity
    DATA(lr_child_data) = extract_data( is_context-entity_id ).
    CHECK lr_child_data IS BOUND.

    READ TABLE gt_entity_config INTO DATA(ls_entity_config) WITH KEY entity_id          = is_context-entity_id
                                                                     src_is_entity_set  = mv_main_source_entity_set.
    CHECK sy-subrc = 0.

    IF ls_entity_config-src_type_structure = abap_true.
      ASSIGN lr_child_data->* TO <lfs_source_data>.
    ELSE.
      ASSIGN lr_child_data->* TO <lfs_t_source_data>.
    ENDIF.

    DATA(lr_transformed_data) = COND #( WHEN ls_entity_config-src_type_structure = abap_true AND <lfs_source_data> IS ASSIGNED
                                          THEN transform_structure_data(  iv_entity_id   = is_context-entity_id
                                                                          iv_source_data = <lfs_source_data> )
                                        WHEN <lfs_t_source_data> IS ASSIGNED
                                          THEN transform_table_data(  iv_entity_id   = is_context-entity_id
                                                                      iv_source_data = <lfs_t_source_data> ) ).

    CHECK lr_transformed_data IS BOUND.

    IF ls_entity_config-src_type_structure = abap_true.
      CREATE DATA lr_data TYPE STANDARD TABLE OF (ls_entity_config-trg_type).

      ASSIGN lr_transformed_data->* TO <lfs_output_data>.
      ASSIGN lr_data->* TO <lfs_t_output_data>.

      CHECK <lfs_output_data> IS ASSIGNED AND <lfs_t_output_data> IS ASSIGNED.

      APPEND <lfs_output_data> TO  <lfs_t_output_data>.

    ELSE.
      ASSIGN lr_transformed_data->* TO <lfs_t_output_data>.
      CHECK <lfs_t_output_data> IS ASSIGNED.
    ENDIF.

    set_response_data( ii_response = ii_response
                       it_data     = <lfs_t_output_data> ).

    IF <lfs_source_data> IS  ASSIGNED.
      UNASSIGN <lfs_source_data>.
    ENDIF.
    IF <lfs_t_output_data> IS ASSIGNED.
      UNASSIGN <lfs_t_output_data>.
    ENDIF.
    IF <lfs_t_output_data> IS ASSIGNED.
      UNASSIGN <lfs_t_output_data>.
    ENDIF.

Execution inside the method:

Step 6 — Extract Payload Data

Source data is extracted from the payload container.

Method:

EXTRACT_DATA

Example:

    FIELD-SYMBOLS: <lfs_t_reftable> TYPE any.

    DATA(lv_type) = VALUE #( gt_entity_config[ entity_id          = iv_entity_id
                                               src_is_entity_set  = mv_main_source_entity_set ]-src_type OPTIONAL ).

    DATA(lv_entity_set) = VALUE #( gt_entity_config[  entity_id         = iv_entity_id
                                                      src_is_entity_set = mv_main_source_entity_set ]-entity_set OPTIONAL ).

    CREATE DATA rr_data TYPE (lv_type).
    ASSIGN rr_data->* TO <lfs_t_reftable>.

    IF <lfs_t_reftable> IS ASSIGNED.
      unwrap( EXPORTING it_data        = VALUE #( gt_payload[ entity_set_name = lv_entity_set ]-data OPTIONAL )
                        iv_entity_set  = lv_entity_set
              IMPORTING ev_data        = <lfs_t_reftable> ).
      UNASSIGN <lfs_t_reftable>.
    ENDIF.

This returns a dynamic data reference.

Step 7 — Transform the Data

The framework determines whether the payload is:

A structure
A table

Structure Conversion

Method:

TRANSFORM_STRUCTURE_DATA

Example:

    FIELD-SYMBOLS: <lfs_source> TYPE any,
                   <lfs_target> TYPE any.

    DATA: lr_source_ref TYPE REF TO data,
          lr_target_ref TYPE REF TO data.

    READ TABLE gt_entity_config INTO DATA(ls_entity_cfg) WITH KEY entity_id         = iv_entity_id
                                                                  src_is_entity_set = mv_main_source_entity_set.
    IF sy-subrc <> 0.
      RETURN.
    ENDIF.

    CREATE DATA lr_source_ref TYPE (ls_entity_cfg-src_type)."Creation of Reference Structure for V2 Structure
    CREATE DATA lr_target_ref TYPE (ls_entity_cfg-trg_type)."Creation of Reference Structure for V4 Structure

    ASSIGN lr_source_ref->* TO <lfs_source>.
    <lfs_source> = CORRESPONDING #( iv_source_data ).

    ASSIGN lr_target_ref->* TO <lfs_target>.

    LOOP AT ls_entity_cfg-field_map ASSIGNING FIELD-SYMBOL(<lfs_field_map>).
      ASSIGN COMPONENT <lfs_field_map>-src_field OF STRUCTURE <lfs_source> TO FIELD-SYMBOL(<lfs_src_val>).
      ASSIGN COMPONENT <lfs_field_map>-trg_field OF STRUCTURE <lfs_target> TO FIELD-SYMBOL(<lfs_trg_val>).

      IF <lfs_src_val> IS ASSIGNED AND <lfs_trg_val> IS ASSIGNED.
        DATA(lv_conv_val) = conversion_exit( EXPORTING iv_source     = <lfs_source>
                                                       iv_entity_id  = iv_entity_id
                                                       iv_field_name = <lfs_field_map>-trg_field ).

        <lfs_trg_val> = COND #( WHEN lv_conv_val IS NOT INITIAL THEN lv_conv_val
                               ELSE <lfs_src_val> ).
      ENDIF.
    ENDLOOP.

    CREATE DATA rr_data LIKE <lfs_target>.
    rr_data->* = <lfs_target>.

Table Conversion

Method:

TRANSFORM_TABLE_DATA

Example:

    FIELD-SYMBOLS: <lfs_t_target_table> TYPE STANDARD TABLE,
                   <lfs_source_row>     TYPE any,
                   <lfs_target_row>     TYPE any.

    DATA: lr_source_table_ref TYPE REF TO data,
          lr_target_table_ref TYPE REF TO data.

    READ TABLE gt_entity_config INTO DATA(ls_entity_config) WITH KEY  entity_id         = iv_entity_id
                                                                      src_is_entity_set = mv_main_source_entity_set.
    IF sy-subrc <> 0.
      RETURN.
    ENDIF.

    CREATE DATA lr_source_table_ref TYPE (ls_entity_config-src_type)."Creation of Reference Table for V2 Structure
    CREATE DATA lr_target_table_ref TYPE (ls_entity_config-trg_type)."Creation of Reference Table for V4 Structure

    ASSIGN lr_source_table_ref->* TO <lfs_t_target_table>.
    <lfs_t_target_table> = CORRESPONDING #( iv_source_data ).

    ASSIGN lr_target_table_ref->* TO <lfs_t_target_table>.

    LOOP AT lr_source_table_ref->* ASSIGNING <lfs_source_row>.
      CREATE DATA lr_target_table_ref LIKE LINE OF <lfs_t_target_table>.
      ASSIGN lr_target_table_ref->* TO <lfs_target_row>.

      LOOP AT ls_entity_config-field_map ASSIGNING FIELD-SYMBOL(<lfs_field_mapping>). "#EC CI_NESTED.
        ASSIGN COMPONENT <lfs_field_mapping>-src_field OF STRUCTURE <lfs_source_row> TO FIELD-SYMBOL(<lfs_source_value>).
        ASSIGN COMPONENT <lfs_field_mapping>-trg_field OF STRUCTURE <lfs_target_row> TO FIELD-SYMBOL(<lfs_target_value>).
        DATA(lv_converted_value) = conversion_exit( EXPORTING iv_source     = <lfs_source_row>
                                                              iv_entity_id  = iv_entity_id
                                                              iv_field_name = <lfs_field_mapping>-src_field ).

        <lfs_target_value> = COND #( WHEN lv_converted_value IS NOT INITIAL THEN lv_converted_value
                                    ELSE <lfs_source_value> ).

      ENDLOOP.

      APPEND <lfs_target_row> TO <lfs_t_target_table>.
    ENDLOOP.

    CREATE DATA rr_data LIKE <lfs_t_target_table>.
    rr_data->* = <lfs_t_target_table>.

Step 8 — Apply Custom Field Conversions

Before assigning values, the framework checks for custom conversions.

Method:

CONVERSION_EXIT

Example:

    "Redefine and write your own conversions. Example:If any logic was written in D24 for a field, you can write it here.
    CASE iv_entity_id.
      WHEN 'Entity ID 1'.
        ASSIGN COMPONENT iv_field_name OF STRUCTURE iv_source TO FIELD-SYMBOL(<lfs_source_value>).
        IF iv_field_name = 'FIELD NAME'.
          rv_field_value = 'Custom Logic' ##NO_TEXT.
        ENDIF.
      WHEN OTHERS.
    ENDCASE.

This allows transformations such as:

Timestamp conversion
Code translation
Business logic fields

Step 9 — Send Response Back to RAP

Finally, the transformed data is sent to the RAP response object.

Method:

SET_RESPONSE_DATA

Example:

    ii_response->set_total_number_of_records( lines( it_data ) ).
    ii_response->set_data( it_data ).

RAP then returns the result to the OData V4 service consumer.

Key Takeaway

The framework follows a layered execution approach:

Layer	Responsibility
RAP Layer	Entry point for OData V4 request
Context Layer	Extract request parameters
Data Layer	Retrieve V2 payload
Transformation Layer	Convert V2 → V4
Response Layer	Return RAP response

This design ensures the framework is:

Reusable
Extensible
Entity independent
Compatible with RAP architecture

Custom Business Configurations (F4579): Collaborative draft

2026-04-08T10:55:35.536000+02:00

Introduction

The Custom Business Configurations (CUBCO) app serves as an entry point to the Business Configuration Maintenance Object (SMBC) provided by custom applications or partners.

When you use the ADT wizard to generate a Business Configuration Maintenance Object, the singleton pattern is used when generating the draft enabled RAP BO. One characteristic of this pattern is that all child entities are locked together, so it is not possible for multiple users to work with the same configuration at the same time.

This blog describes how to avoid this restriction by using collaborative draft.

This blog is relevant for

Example scenario

In the configuration table ZDEMO_CC, the company codes are stored.

@EndUserText.label : 'Company Code'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zdemo_cc {
  key client            : abap.clnt not null;
  key company_code      : abap.numc(4) not null;
  country               : land1;
  last_changed_at       : abp_lastchange_tstmpl;
  local_last_changed_at : abp_locinst_lastchange_tstmpl;
}

Enable collaborative draft

In the generated behavior definition, add "collaborative" to the draft annotation:

managed with additional save implementation in class ZBP_I_COMPANYCODE_S unique;
strict;
with collaborative draft;

Add the draft query annotation and the share action to the singleton entity definition:

define behavior for ZI_CompanyCode_S alias CompanyCodeAll
draft table ZDEMO_CC_D_S query ZR_DEMO_CC_CD
[...]
{
  draft action Share;
  [...]
}

Right-click the singleton draft table and choose New Data Definition to create the CDS view for the draft query:

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Draft Query View'
define view entity ZR_DEMO_CC_CD
  as select from zdemo_cc_d_s
{
  key singletonid                   as Singletonid,
      lastchangedatmax              as Lastchangedatmax,
      transportrequestid            as Transportrequestid,
      draftentitycreationdatetime   as Draftentitycreationdatetime,
      draftentitylastchangedatetime as Draftentitylastchangedatetime,
      draftadministrativedatauuid   as Draftadministrativedatauuid,
      draftentityoperationcode      as Draftentityoperationcode,
      hasactiveentity               as Hasactiveentity,
      draftfieldchanges             as Draftfieldchanges
}

You need to enhance the authorization of the involved users. In SAP BTP ABAP environment and SAP S/4HANA Public Cloud Edition you assign business catalog SAP_CORE_BC_RAP_DRAFT_PC to the user, in SAP S/4HANA Private Cloud Edition authorization object S_DRAFT.

Collaboration

User TB is creating a new company code 400 while at the same time user PW is editing company code 100. All changes are recorded on the same transport request.

Since the collaborative draft is enabled for the singleton root entity, the save and discard draft action are applied to all object changes. In this example, users PW and TB process two different company codes, which are logically different objects. Technically, however, they process the same singleton root entity. In practice, this means that discarding the draft or saving must be aligned between the users involved, as the save action persists the changes in all company codes.
For completely independent editing of individual objects, you must develop a RAP BO without a singleton pattern.

Transaction cannot be revived after delayed abortion(RAP_RUNTIME 019) - Must ROLLBACK After Failures

2026-04-08T11:52:21.989000+02:00

1. Symptom (ST22 / Dump Keywords)

A typical dump looks like this (same category as in your case):

Runtime Error: RAISE_SHORTDUMP
Exception: CX_SADL_DUMP_APPL_MODEL_ERROR
T100: RAP_RUNTIME / 019
Short Text: Transaction cannot be revived after delayed abortion (BO: I_ENTERPRISEPROJECTTP_2)

When debugging you may also notice RAP internal state like:

CL_RAP_BHV_PROCESSOR->IF_RAP_LEGACY_TRANSACTION~MV_ABORT = abap_true

Meaning: RAP has already marked the logical transaction as aborted (delayed abortion). It must not be reused.

2. Root Cause: RAP Transaction State + Delayed Abortion

A RAP EML “logical transaction” typically consists of two phases:

Transaction phase

MODIFY ENTITIES runs validations/determinations/checks.
Errors are usually returned in FAILED / REPORTED

Save phase

COMMIT ENTITIES triggers the save sequence (finalize/save, etc.).
Errors again come back via FAILED / REPORTED (in the commit response this is the LATE response).

If anything fails in either phase, RAP can enter delayed abortion:
Your ABAP code continues running,but the RAP logical transaction becomes unusable.
Any subsequent EML using that aborted transaction context may lead to RAP_RUNTIME 019.

MODIFY ENTITIES OF <BO> ... FAILED ls_failed_tx REPORTED ls_reported_tx.
COMMIT ENTITIES ... FAILED ls_failed_save REPORTED ls_reported_save.

" If commit failed but you don't rollback here,
" next EML call can dump (RAP_RUNTIME 019)
MODIFY ENTITIES OF <BO> ...

Key point: Never continue with another EML step after a failure without rollback.

5. Correct Example Using `I_EnterpriseProjectTP_3`

*&---------------------------------------------------------------------*
*& Report zdemo_rap_eml_epp3
*&---------------------------------------------------------------------*
*&
*&---------------------------------------------------------------------*
REPORT zdemo_rap_eml_epp3.

PARAMETERS:
      p_uuid TYPE sysuuid_c36 OBLIGATORY,
      p_desc TYPE string      DEFAULT 'Demo update from EML'.

START-OF-SELECTION.

  DATA lv_uuid_x16 TYPE sysuuid_x16.

  TRY.
              cl_system_uuid=>convert_uuid_c36_static(
                  EXPORTING
                      uuid     = p_uuid
                  IMPORTING
                      uuid_x16 = lv_uuid_x16 ).
        CATCH cx_uuid_error.
              WRITE: / 'Invalid UUID format. Use 36-char UUID (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx).'.
              RETURN.
  ENDTRY.

  DATA:
        ls_failed_tx     TYPE RESPONSE FOR FAILED   i_enterpriseprojecttp_3,
        ls_reported_tx   TYPE RESPONSE FOR REPORTED i_enterpriseprojecttp_3,
        ls_failed_save   TYPE RESPONSE FOR FAILED   LATE i_enterpriseprojecttp_3,
        ls_reported_save TYPE RESPONSE FOR REPORTED LATE i_enterpriseprojecttp_3.

  TRY.
              " Transaction phase
              MODIFY ENTITIES OF i_enterpriseprojecttp_3
                  ENTITY EnterpriseProject
                  UPDATE FIELDS ( ProjectDescription )
                  WITH VALUE #(
                      ( %key-ProjectUUID      = lv_uuid_x16
                          ProjectDescription    = p_desc )
                  )
                  FAILED   ls_failed_tx
                  REPORTED ls_reported_tx.

              IF ls_failed_tx IS NOT INITIAL.
                    WRITE: / 'MODIFY ENTITIES failed (transaction phase) -> ROLLBACK ENTITIES'.
                    ROLLBACK ENTITIES.
                    RETURN.
              ENDIF.

              " Save phase
              COMMIT ENTITIES
                  BEGIN RESPONSE OF i_enterpriseprojecttp_3
                  FAILED   ls_failed_save
                  REPORTED ls_reported_save.
              COMMIT ENTITIES END.

              IF ls_failed_save IS NOT INITIAL.
                    WRITE: / 'COMMIT ENTITIES failed (save phase) -> ROLLBACK ENTITIES'.
                    ROLLBACK ENTITIES.
                    RETURN.
              ENDIF.

              WRITE: / 'COMMIT ENTITIES OK.'.

        CATCH cx_root INTO DATA(lx_root).
              WRITE: / 'Unexpected exception:', lx_root->get_text( ).
              " Keep the EML contract: if anything goes wrong, end the logical transaction.
              ROLLBACK ENTITIES.
  ENDTRY.

Two important details in this example

COMMIT ENTITIES requires LATE response types

RESPONSE FOR FAILED LATE i_enterpriseprojecttp_3
RESPONSE FOR REPORTED LATE i_enterpriseprojecttp_3

“Fail fast” with rollback

If FAILED is not initial in either phase, rollback and end the logical transaction.
Start the next business step in a new logical transaction context.

8. FAQ: Why not `ROLLBACK WORK`?

In RAP EML, use the EML-compatible statement:

Errors in EML logical transaction → ROLLBACK ENTITIES

ROLLBACK WORK is lower-level LUW handling and can lead to semantic mismatches with RAP’s logical transaction handling. The dump you saw is fundamentally about the RAP logical transaction being aborted and still being reused.

CAP, RAP, or Both: Stop Hiding Behind 'It Depends'

2026-04-09T02:05:37.595000+02:00

I've read every major article on this topic. They all end the same way:

"Both models are complementary. Choose based on your context. Use each for the right scenario."

That is a technically accurate, professionally safe, and completely useless answer.

This article gives you the framework I actually use with clients — including the uncomfortable parts most posts skip: the staffing bias that impact architecture decisions, what to do when your client has thousands of Z-objects, why migrating RAP to CAP is not a refactor, and why CAP is the only model that enforces the Clean Core promise architecturally.

One thing upfront: this is not an anti-ABAP article. ABAP knowledge — deep understanding of business processes, transactional models, and SAP data structures accumulated over years — is one of the most valuable assets in enterprise

What We're Actually Debating

RAP (ABAP RESTful Application Programming Model) is SAP's extension model for the S/4HANA core and ABAP Cloud environments. It's ABAP-native, optimized for extending standard SAP Business Objects with transactional consistency. SAP's answer to "how do I extend S/4HANA without modifying standard code."

CAP (Cloud Application Programming Model) is SAP's framework for building cloud-native services on SAP BTP. Node.js and Java, BTP Cloud Foundry and Kyma, multitenancy, eventing, and OData/GraphQL out of the box. SAP's answer to "how do I build new business capabilities that live outside the S/4HANA core."

Same goal — Clean Core, BTP-native development. Fundamentally different execution contexts.

The Uncomfortable Truth First

Most teams choosing between CAP and RAP are not making a pure architectural decision.

They're making a decision shaped by team composition.

An ABAP-heavy organization will present RAP as the natural choice for almost any BTP extension. The justification will sound architectural: "We need access to S/4HANA data," "We want to leverage existing ABAP logic," "RAP is Clean Core approved." All of those statements can be true and still be a rationalization. The real driver is often simpler: the team knows ABAP, so RAP wins.

This is a systemic pattern worth naming explicitly — because when staffing drives architecture, the decisions look reasonable one at a time and catastrophic in aggregate. The job of a principal architect is to separate these two questions before the decision is made.

When RAP Is Genuinely the Right Answer

1. Extending Standard SAP Business Objects

If you need to extend standard S/4HANA entities — Sales Orders, Purchase Requisitions, Business Partners, Material Documents — RAP is purpose-built for this. Proper lock handling, transactional consistency, draft management, clean integration with standard SAP workflows. Trying to replicate this via CAP calling S/4HANA APIs introduces latency, complexity, and consistency gaps that are difficult to manage at scale. For tight S/4HANA core extensions, RAP's native access is a genuine advantage, not just familiarity.

2. On-Premise + Cloud Parity Requirements

RAP runs on both on-premise ABAP Platform and ABAP Cloud. CAP is cloud-only. Hybrid deployment, phased cloud migration, regulated industries with on-premise constraints — RAP is the only viable option when parity is required.

3. Maximizing Existing ABAP Investment

Complex, well-tested ABAP business logic that needs to be exposed as a service can be wrapped with a Clean Core API facade in RAP without rewriting it. Legitimate — with the caveat covered in the Z section below.

4. Simple, Bounded In-App Extensions

A single-source, single-consumer extension with no external integrations and no scalability concerns does not need the infrastructure overhead of CAP. Don't over-engineer.

When CAP Is the Right Answer — Which Is More Often Than You Think

1. Multi-Source Data Scenarios

The moment your extension needs data from more than one system, CAP is the correct choice. CAP's service layer was designed for data federation. RAP operating across multiple external sources becomes a manual integration exercise.

2. Independent Scalability

Side-by-side BTP extensions with variable load profiles should not be constrained by ABAP runtime characteristics. CAP on BTP Cloud Foundry or Kyma scales horizontally.

3. Talent Pool and Long-Term Maintainability

The global Node.js and Java developer pool is orders of magnitude larger than ABAP Cloud specialists. But the real point is different: the scarce resource in SAP programs is not syntax knowledge — it's SAP business process knowledge. An architecture that requires ABAP Cloud specialists to maintain it creates organizational dependency risk. An ABAP architect who already has the process knowledge and adds CAP to their toolkit is the most valuable person in the room.

4. Multi-Tenant SaaS and Reusable Services

CAP's multitenancy model is production-grade out of the box. RAP was not designed for this.

5. Non-SAP Ecosystem Integration

When your extension lives at the intersection of SAP and non-SAP systems, CAP's polyglot nature is a structural advantage. Building this in RAP means engineering brittle ABAP-to-external-API bridges.

6. Survival of SAP Upgrade Cycles

CAP extensions communicate with S/4HANA via stable, versioned APIs. They have no ABAP lifecycle. This connects directly to the Clean Core argument below.

The Big Z Problem

Most clients don't arrive at this debate with a clean slate. They arrive with 1,000, 2,000, sometimes 5,000 Z-objects accumulated over decades of ECC customization. The first proposal is almost always: "Let's migrate the Zs to RAP."

This is the wrong answer — and it is expensive.

The right question, before any migration decision, is: why does each Z-object exist?

Category 1 — SAP now covers it natively (retire it)
A significant portion of Z-objects from ECC exist because SAP didn't have that functionality in 2005. S/4HANA and BTP may have it natively today. Before migrating anything, check whether SAP standard now covers the need. If it does: retire the Z. Don't migrate what you should delete.

Category 2 — Genuine core business object extension (evaluate RAP)
Some Z-objects encode real business logic tightly coupled to SAP transactional objects — custom validations on Sales Orders, derivations on Financial documents, extensions to MM flows. These are legitimate RAP candidates because the coupling is intentional and the transactional integrity requirement is real.

Category 3 — Side-by-side logic that never belonged in the core (evaluate CAP with bias)
Many Z-objects are reporting utilities, data extraction routines, integration helpers, or workflow logic placed inside the ABAP stack out of convenience, not architecture. These should be evaluated for CAP first — finally living where they should have lived from the beginning. One qualifier: if the logic requires HANA-native pushdown on large datasets (financial close, ATP, margin analysis at scale), or participates in SAP's transactional determination chain, evaluate before rebuilding. The default is still CAP. The exception needs justification.

The Big Z is not a RAP migration backlog. It's a forcing function to finally answer which of your customizations your business actually needs, which SAP now covers natively, and which were architectural accidents waiting to be corrected.

And for the Zs that survive the triage but can't be rewritten this quarter — wrap them. A clean API boundary around legacy logic is not technical debt; it's the first act of modernization. What you cannot afford is leaving Z-code directly exposed. That's how "temporary" becomes permanent.

The CAP First Decision Protocol

CAP First means the burden of proof shifts. The default is CAP. RAP must earn its place by satisfying a specific gate.

The only gate that stops CAP: transactional consistency with a standard SAP Business Object, bounded to S/4HANA data, with no external systems, no multi-tenancy, and no independent scalability requirements.

One honest prerequisite: CAP First is the right posture for organizations that have already invested in BTP platform maturity — an operational subaccount, CI/CD for Node.js or Java, and the operational capability for Cloud Foundry or Kyma workloads. For organizations that haven't built that foundation yet, CAP First is still the right destination — it comes with a deliberate enablement journey first. The posture doesn't change. The timeline does.

Why does the default posture matter? Because the cost of the wrong decision is asymmetric.

The Real Cost of Getting the Model Wrong

A clarification worth making explicitly, because ABAP architects will correctly challenge a weaker version of this argument:

Upgrading S/4HANA with existing RAP extensions is relatively low cost — if your RAP uses only ABAP Cloud Released APIs (C1), which is what Clean Core RAP should do. SAP guarantees stability on released APIs across versions. ABAP teams who make this point are correct.

The cost argument I'm making is different. It's about switching models — what happens when you built in RAP and later discover that CAP was the right choice: multi-source data appeared, scalability became a requirement, the business needs this as a multi-tenant service.

RAP is ABAP. CAP is Node.js or Java. These are not different versions of the same language — different runtimes, different deployment models, different ecosystems entirely. When you migrate a RAP service to CAP:

The CDS data model needs to be rewritten in CAP CDS (similar syntax, different runtime behavior)
All business logic needs to be reimplemented in Node.js or Java — not ported, reimplemented
The deployment pipeline, CI/CD, monitoring, and operational model all change
The ABAP artifacts are retired, not converted

For a medium-complexity service: weeks to months. For a large one: a quarter or more. For a portfolio that grew because nobody pushed back: a program, not a project.

The cost of the wrong default is asymmetric. Not because RAP upgrades are expensive — they're not. But because choosing the wrong model and needing to switch is. CAP First reduces the risk of landing on that side.

One variable that changes this equation: AI. Claude Code connected to SAP ADT via MCP can analyze RAP logic and generate CAP equivalents faster than before — it lowers the code generation cost. It does not replace the authorization model revalidation, the test suite rebuild, or the operational cutover, which is where most of the real effort lives. The fear factor drops. The effort doesn't disappear. That full conversation is a follow-up article.

CAP Enforces the Clean Core Promise. RAP Requires Discipline to Maintain It.

SAP's official definition of Clean Core: don't modify standard code, use the approved extensibility models. RAP is on that list — and a RAP extension using only ABAP Cloud Released APIs (C1) is genuinely Clean Core compliant by SAP's own definition. Let's be precise about this.

But Clean Core has a purpose beyond compliance: the ability to upgrade your SAP core without touching your business logic. Faster upgrades. Lower risk. Smaller impact windows.

Here is the real distinction between RAP and CAP on this point — and it is not about compliance. It is about enforcement.

Both models can satisfy the Clean Core compliance definition when implemented with discipline. The difference is what happens when discipline breaks down. In RAP, a team under delivery pressure can find paths to unreleased ABAP internals — friend class patterns, dynamic calls, legacy function module invocations. The architectural boundary exists as a rule, not a wall. In CAP, you are physically outside the ABAP stack. You cannot access unreleased internals because there is no path to them from a Node.js or Java runtime. The boundary is enforced by the architecture itself.

RAP requires discipline to stay Clean Core. CAP makes it structurally difficult to leave.

This is not a criticism of ABAP developers. It is a recognition that architectural guardrails matter most under pressure — and pressure is the normal operating condition of enterprise SAP programs.

A valid counterpoint here: ABAP Cloud on BTP — the ABAP Environment as a side-by-side deployment — does break the S/4HANA lifecycle dependency. The toolchain enforces Released APIs syntactically via the language version check, so the "discipline" argument partially weakens. But there is a distinction worth making: ABAP Cloud on BTP decouples you from S/4HANA's runtime lifecycle. CAP decouples you from the ABAP architecture itself. If your constraints are about upgrade survival, both work. If your constraints are about talent pool, integration patterns, and long-term architectural independence away from the ABAP stack — only one of them gets you there.

A CAP service communicates with S/4HANA through stable, versioned OData or API endpoints. It does not know what version of S/4HANA is running underneath. It has no ABAP lifecycle. It can be upgraded, redeployed, and scaled completely independently. RAP is the right direction. CAP is the destination. The difference is whether Clean Core survives contact with reality.

This Is Not Anti-ABAP. It's a Call to Deploy ABAP Knowledge Differently.

Deep ABAP expertise — understanding transactional models, business process flows, SAP data structures built over decades — is irreplaceable. The scarce resource in SAP programs is not syntax knowledge. It is SAP business process knowledge. A Node.js developer learns the CAP framework in weeks. They do not learn how SAP processes an intercompany stock transfer in weeks. ABAP architects already have the hard part.

The problem is not ABAP knowledge. The problem is when that knowledge becomes a reason to avoid CAP rather than a foundation for it.

In 2026, with Claude Code connected to SAP ADT via MCP and Joule for Developers embedded in the SAP ecosystem, an experienced ABAP developer can build a production-grade CAP service with AI assistance in a fraction of the time it would have taken two years ago. The language gap has never been smaller to bridge. The "we don't have CAP developers" argument has never been weaker.

And the most mature SAP architectures don't choose one model. They use both deliberately: RAP as the API layer of S/4HANA — the clean, stable interface that exposes core business objects. CAP as the orchestration and composition layer above it — multi-source, scalable, independently deployable. That is not a compromise. That is the target state. ABAP architects who understand both are positioned to design it.

A Challenge for Your Next Architecture Review

Before your team decides on RAP — or commits to a Z-to-RAP migration program — answer four questions publicly in the room:

For Z-objects: Does each Z exist because SAP lacked functionality that it now has natively? If yes: retire it, don't migrate it.
For new extensions: Does this require transactional consistency with a standard SAP Business Object, bounded to S/4HANA data only? If yes: RAP is correct.
For new extensions: Does this require data from outside S/4HANA, independent scalability, or multi-tenant deployment? If yes: CAP is correct.
Before committing to either: Is RAP on the table because of architectural justification — or because of who is in the room?

Question 4 is the one that changes the outcome. And it takes organizational courage to ask it out loud.

The CAP vs. RAP debate is not a technology debate. It's an organizational clarity debate — and more often than not, an organizational courage debate. The teams that get this right are the ones willing to name what's actually driving the decision, separate ABAP expertise from ABAP default, and deploy both models where they genuinely belong.

References

Walter Aguero Machado —SAP Enterprise Architect | SAP BTP SME at Globant | SAP Certified Solution Architect & BTP Administrator | ASUG Speaker

XML Annotations: The Essentials Before Adapting Documentation Samples to Your Project

2026-04-09T23:10:50.984000+02:00

The Problem

When building Fiori Elements apps, you sometimes need to add XML annotations on the UI side. The usual approach is to search for examples in the UI5 Demo Kit. For instance, you might find something like this:

Disabling the Search filter

<Annotations Target="SAP__self.Container/SalesOrder">
   <Annotation Term="SAP__capabilities.SearchRestrictions">
      <Record>
         <PropertyValue Property="Searchable" Bool="false" />
      </Record>
   </Annotation>
</Annotations>

However, simply copying this into your annotation.xml won't work. To figure out what needs to be changed, you need to understand the basic structure of annotations.

What You Need to Know

1. Annotation Targets

The target of an annotation varies depending on the annotation you want to apply. Here are the most common ones:

Target	Syntax for Target attribute	Example in UI5 Documentation
EntityType	{Namespace}.{EntityType}	Common for UI annotations (`UI.FieldGroup`, `UI.HeaderInfo`, etc.). Note: documentation examples often show only the inner `<Annotation>` element, omitting the outer `<Annotations Target="...">` wrapper.
EntitySet	{Namespace}.{EntityContainer}/{EntitySet}	TravelService.EntityContainer/Travel [1]
Property	{Namespace}.{EntityType}/{Property}	Z0020_CDS.Z0020Type/CountryID [3]
NavigationProperty	{Namespace}.{EntityContainer}/{EntitySet}/{NavigationProperty}	myService.EntityContainer/SalesOrderManage/_Item [2]
Action (Bound)	{Namespace}.{Action}({BindingParameterType})	com.c_salesordermanage_sd.CreateWithSalesOrderType(com.c_salesordermanage_sd.SalesOrderManage) [2]
Action (Unbound)	{Namespace}.{Action}	SAP__self.CreateWithSalesOrderType [2]
Action Parameter	{Namespace}.{Action}/{Parameter}	SalesOrder.CreateWithSalesOrderType/SalesOrganization [2]
EntityContainer	{Namespace}.{EntityContainer}	namespace.EntityContainer [4]

[1] Disabling the Editing Status Filter
[2] Actions
[3] In / Out Mappings in the ValueList Annotation
[4] Adapting the Filter Bar

The Namespace, EntityType, EntitySet, and other names used in the Target attribute can all be found in your service's metadata.xml document. When developing a Fiori Elements app, this file is typically located in your project folder.

CAP Example

In a CAP service, open metadata.xml and look for the following:

<Schema Namespace="QuoteService" ...>  <!-- Namespace -->

    <EntityContainer Name="EntityContainer">  <!-- EntityContainer name -->
        <EntitySet Name="Quotations" EntityType="QuoteService.Quotations">  <!-- EntitySet name -->
            <NavigationPropertyBinding Path="attachments" Target="Quotations_attachments"/>
        </EntitySet>
    </EntityContainer>

    <EntityType Name="Quotations">  <!-- EntityType name -->
        <Property Name="Description" Type="Edm.String"/>  <!-- Property name -->
        <NavigationProperty Name="attachments" .../>  <!-- NavigationProperty name -->
    </EntityType>

</Schema>

From this, you can construct your target values:

Target	Value
EntityType	QuoteService.Quotations
EntitySet	QuoteService.EntityContainer/Quotations
Property	QuoteService.Quotations/Description
NavigationProperty	QuoteService.Quotations/attachments
EntityContainer	QuoteService.EntityContainer

RAP Example

In a RAP service, the structure is similar, but notice the Alias attribute on the Schema element:

<Schema Namespace="com.sap.gateway.srvd.dmo.flight_r.v0001" Alias="SAP__self">  <!-- Namespace & Alias -->

    <EntityContainer Name="Container">  <!-- EntityContainer name -->
        <EntitySet Name="Connection" EntityType="...ConnectionType">
            <NavigationPropertyBinding Path="_Flight" Target="Flight"/>
        </EntitySet>
    </EntityContainer>

    <EntityType Name="ConnectionType">  <!-- EntityType name -->
        <Property Name="AirlineID" Type="Edm.String"/>  <!-- Property name -->
        <NavigationProperty Name="_Flight" Type="Collection(...FlightType)"/>  <!-- NavigationProperty name -->
    </EntityType>

</Schema>

In RAP, the Target attribute uses the Alias (SAP__self) instead of the full Namespace. The Alias is always SAP__self in RAP services, so you can use it as-is.

Target	Value
EntityType	SAP__self.FlightType
EntitySet	SAP__self.Container/Flight
Property	SAP__self.FlightType/AirlineID
NavigationProperty	SAP__self.ConnectionType/_Flight
EntityContainer	SAP__self.Container

Note: The UI5 documentation does not indicate whether an annotation example is based on CAP or RAP. This can be a source of confusion — for example, SAP__self and Container in the Target attribute are RAP conventions, while CAP uses the full Namespace and EntityContainer. Always check your own service's metadata.xml to determine the correct values.

2. Annotations require a Reference definition

This is why simply copying a snippet from the documentation into your annotation.xml won't work.

For example, to use the annotation shown at the beginning of this post, you need to add the following Reference:

<edmx:Edmx xmlns:edmx="http://docs.oasis-open.org/odata/ns/edmx" Version="4.0">
    <edmx:Reference Uri="https://oasis-tcs.github.io/odata-vocabularies/vocabularies/Org.OData.Capabilities.V1.xml">
        <edmx:Include Namespace="Org.OData.Capabilities.V1" Alias="Capabilities"/>
    </edmx:Reference>
    ...
</edmx:Edmx>

OData vocabularies used in Fiori Elements are defined in two locations:

sap.github.io: https://sap.github.io/odata-vocabularies/
oasis-tcs.github.io: https://oasis-tcs.github.io/odata-vocabularies/

Here are the vocabularies you will encounter most often when working with Fiori Elements.

SAP vocabularies

Alias	Namespace	URI
UI	com.sap.vocabularies.UI.v1	https://sap.github.io/odata-vocabularies/vocabularies/UI.xml
Common	com.sap.vocabularies.Common.v1	https://sap.github.io/odata-vocabularies/vocabularies/Common.xml
HTML5	com.sap.vocabularies.HTML5.v1	https://sap.github.io/odata-vocabularies/vocabularies/HTML5.xml

OASIS vocabularies

Alias	Namespace	URI
Core	Org.OData.Core.V1	https://oasis-tcs.github.io/odata-vocabularies/vocabularies/Org.OData.Core.V1.xml
Capabilities	Org.OData.Capabilities.V1	https://oasis-tcs.github.io/odata-vocabularies/vocabularies/Org.OData.Capabilities.V1.xml

Tip: If you want to dig deeper, the vocabulary specification files are available at the URIs listed above. Each annotation term definition includes an AppliesTo attribute, which tells you exactly which target types the annotation can be applied to.

For example, in Org.OData.Capabilities.V1.xml:

<Term Name="SearchRestrictions" Type="Capabilities.SearchRestrictionsType" Nullable="false" AppliesTo="EntitySet Collection">
<Annotation Term="Core.AppliesViaContainer"/>
<Annotation Term="Core.Description" String="Restrictions on search expressions"/>
</Term>

This tells you that SearchRestrictions can be applied to an EntitySet target.

Step-by-step: Applying a Documentation Sample to Your annotation.xml

Let's walk through how to actually apply the following annotation — the same one from the beginning of this post — to your own project.

<Annotations Target="SAP__self.Container/SalesOrder">
   <Annotation Term="SAP__capabilities.SearchRestrictions">
      <Record>
         <PropertyValue Property="Searchable" Bool="false" />
      </Record>
   </Annotation>
</Annotations>

Step 1: Understand the annotation target

Target="SAP__self.Container/SalesOrder"

This follows the format {Namespace or Alias}.{EntityContainer}/{EntitySet}.

You can look up the exact values in your service's metadata.xml:

Replace SAP__self with your service's Namespace (CAP) or keep it as-is (RAP)
Replace Container with your EntityContainer name
Replace SalesOrder with your EntitySet name

Result:

<Annotations Target="MyService.EntityContainer/MyEntity">
   <Annotation Term="SAP__capabilities.SearchRestrictions">
      <Record>
         <PropertyValue Property="Searchable" Bool="false" />
      </Record>
   </Annotation>
</Annotations>

Step 2: Add the Reference

The term SAP__capabilities tells you this is a Capabilities vocabulary annotation. Add the following Reference inside the root <edmx:Edmx> element of your annotation.xml, before the <Annotations> block:

<edmx:Edmx xmlns:edmx="http://docs.oasis-open.org/odata/ns/edmx" Version="4.0">

    <!-- Add the Reference here -->
    <edmx:Reference Uri="https://oasis-tcs.github.io/odata-vocabularies/vocabularies/Org.OData.Capabilities.V1.xml">
        <edmx:Include Namespace="Org.OData.Capabilities.V1" Alias="Capabilities"/>
    </edmx:Reference>

    <!-- Your annotations go below -->
    <Annotations Target="...">
        ...
    </Annotations>

</edmx:Edmx>

Also, replace the SAP__capabilities prefix in the annotation term with the Alias you defined in the Reference. In this case, SAP__capabilities becomes Capabilities. The final annotation will look like this:

<edmx:Edmx xmlns:edmx="http://docs.oasis-open.org/odata/ns/edmx" Version="4.0">
    <edmx:Reference Uri="https://oasis-tcs.github.io/odata-vocabularies/vocabularies/Org.OData.Capabilities.V1.xml">
        <edmx:Include Namespace="Org.OData.Capabilities.V1" Alias="Capabilities"/>
    </edmx:Reference>

    <Annotations Target="MyService.EntityContainer/MyEntity">
        <Annotation Term="Capabilities.SearchRestrictions">
            <Record>
                <PropertyValue Property="Searchable" Bool="false" />
            </Record>
        </Annotation>
    </Annotations>
</edmx:Edmx>

Conclusion

XML annotations can feel intimidating at first, but there are really just two things you need to get right before applying any annotation from the documentation to your project:

The Target — identify your Namespace, EntityContainer, EntitySet, and other names from your service's metadata.xml file
The Reference — add the correct edmx:Reference for the vocabulary you are using

Once you have these two in place, any annotation snippet you find in the UI5 documentation can be adapted to your project. Happy annotating!

Custom Sorting for Virtual Elements in RAP

2026-04-10T00:06:47.289000+02:00

Introduction

In the ABAP RESTful Application Programming Model (RAP), virtual elements are essential for displaying computed data that doesn't exist in the database—such as deriving a month or year from a timestamp. However, because these elements are calculated at runtime, they lack standard OData capabilities like server-side sorting and filtering. In this article, we will explore how to overcome these limitations by implementing a SADL exit. We’ll walk through how to enable full sorting and calculation capabilities for virtual elements, ensuring a seamless experience for the end user.

What are Virtual Elements in RAP?

In the ABAP RESTful Application Programming Model (RAP), a virtual element is a field defined in a CDS (Core Data Services) projection view that does not have a corresponding column in the underlying database table.

Real-Time Business Scenario: Sales Period Reporting

In many SAP implementations, the business requires reports segmented by Month and Year (e.g., for Monthly Sales Performance). While the underlying database table stores a precise (Created On) date, it does not store the Month or Year as separate columns.

The Problem

If we create a Fiori Elements app and want to show "Sales Month" and "Sales Year" as separate columns:

Simple Virtual Elements can calculate these strings (e.g., "January", "2024").
The Failure: When a user tries to sort the "Sales Month" column, the UI will throw an error or do nothing because the OData service doesn't know how to sort a field that doesn't exist in the database.

The Solution

By using a SADL Exit, we "map" the virtual Month/Year fields back to the physical Sales date field. This allows the database to perform the sort on the actual date, while the user sees the sorted Month or Year on their screen.

Implementation Steps

Step 1: Create a database table

Define the physical storage. This is where the raw data lives before any calculations happen.

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

  key client      : abap.clnt not null;
  key sales_uuid  : sysuuid_x16 not null;
  sales_id        : abap.char(10);
  sales_date      : abap.dats;
  @Semantics.amount.currencyCode : 'zsales_table.currency'
  total_amount    : abap.curr(15,2);
  currency        : abap.cuky;
  last_changed_at : timestampl;

}

Step 2: Create a interface view on top of database table.

This layer projects the database fields into a clean, business-oriented structure.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Interface view for sales table'
@Metadata.ignorePropagatedAnnotations: true
@ObjectModel.usageType:{
    serviceQuality: #X,
    sizeCategory: #S,
    dataClass: #MIXED
}
define root view entity zi_sales_table
  as select from zsales_table
{
  key sales_uuid      as SalesUuid,
      sales_id        as SalesId,
      sales_date      as SalesDate,
      @Semantics.amount. currencyCode: 'Currency'
      total_amount    as TotalAmount,
      currency        as Currency,
      last_changed_at as LastChangedAt
}

Step 3: Create a Consumption view

This is where the Virtual Elements are defined. We use annotations to link the UI to the specific ABAP logic for calculation and sorting.

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Projection view for sales table'
@Metadata.ignorePropagatedAnnotations: true

define root view entity ZP_SALESPROJ
  provider contract transactional_query
  as projection on zi_sales_table
{
      .facet: [{ type: #IDENTIFICATION_REFERENCE,
                    position: 10,
                    label: 'Salestable',
                    targetQualifier: 'GENERAL',
                    purpose: #STANDARD }]
                    
      .lineItem: [{ position: 10, label: 'Sales Uuid' }]
  key SalesUuid,

      .lineItem: [{ position: 20, label: 'Sales Id' }]
      .identification: [{ position: 20, label: 'Sales Id' }]
      SalesId,

      .lineItem: [{ position: 30, label: 'Sales order date' }]
      .identification: [{ position: 30, label: 'Sales order date', qualifier: 'GENERAL' }]
      SalesDate,

      .lineItem: [{ position: 40, label: 'Sales order year' }]
      .identification: [{ position: 40, label: 'Sales order year', qualifier: 'GENERAL' }]
      @ObjectModel.virtualElement: true
      @ObjectModel.virtualElementCalculatedBy: 'ABAP:ZCL_SALES_VE_HANDLER'
      @ObjectModel.sort.transformedBy: 'ABAP:ZCL_SALES_VE_HANDLER'
  virtual SalesYear  : abap.char(4),

      .lineItem: [{ position: 50, label: 'Sales order month' }]
      .identification: [{ position: 50, label: 'Sales order month' , qualifier: 'GENERAL' }]
      @ObjectModel.virtualElement: true
      @ObjectModel.virtualElementCalculatedBy: 'ABAP:ZCL_SALES_VE_HANDLER'
      @ObjectModel.sort.transformedBy: 'ABAP:ZCL_SALES_VE_HANDLER'
  virtual SalesMonth : abap.char(2),

      .lineItem: [{ position: 60, label: 'Total amount' }]
      .identification: [{ position: 60, label: 'Total amount' }]
      @Semantics.amount.currencyCode: 'Currency'
      TotalAmount,

      Currency
}

Step 5: The Handler Class Logic

This class implements two critical interfaces: if_sadl_exit_calc_element_read for the calculation and if_sadl_exit_sort_transform to enable sorting.

CLASS zcl_sales_ve_handler DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC .

  PUBLIC SECTION.

    INTERFACES if_sadl_exit_calc_element_read.
    INTERFACES if_sadl_exit_sort_transform.
  PROTECTED SECTION.
  PRIVATE SECTION.
ENDCLASS.



CLASS zcl_sales_ve_handler IMPLEMENTATION.
  METHOD if_sadl_exit_calc_element_read~get_calculation_info.
    IF line_exists( it_requested_calc_elements[ table_line = 'SALESYEAR' ] ) OR
           line_exists( it_requested_calc_elements[ table_line = 'SALESMONTH' ] ).
      APPEND 'SALESDATE' TO et_requested_orig_elements.

    ENDIF.
  ENDMETHOD.

  METHOD if_sadl_exit_calc_element_read~calculate.
    DATA lt_data TYPE TABLE OF zp_salesproj WITH DEFAULT KEY.
    lt_data = CORRESPONDING #( it_original_data ).


    LOOP AT lt_data ASSIGNING FIELD-SYMBOL(<fs_row>).
      <fs_row>-SALESYEAR  = <fs_row>-salesdate(4).
      <fs_row>-SALESMONTH = <fs_row>-salesdate+4(2).
    ENDLOOP.
    ct_calculated_data = CORRESPONDING #( lt_data ).
  ENDMETHOD.

  METHOD if_sadl_exit_sort_transform~map_element.
    CASE iv_element.
      WHEN 'SALESYEAR' OR 'SALESMONTH'.
        " Map the UI sort request to the database field 'SALESDATE'
        APPEND VALUE #( name = 'SALESDATE' ) TO et_sort_elements.
    ENDCASE.
  ENDMETHOD.

ENDCLASS.

Result:

With the handler class implemented, the Sales order month and Sales order year ( Virtual Elements) now behaves like a standard database fields.

Implementing Determination Using Association in SAP RAP

2026-04-13T07:22:47.901000+02:00

Introduction

In SAP RESTful Application Programming Model (RAP), determinations are a powerful mechanism that automatically derive or calculate field values based on changes to other fields within a business object. They play a central role in enforcing business logic, keeping data consistent, and reducing manual input errors.

While determinations are commonly implemented using direct field references within the same entity, a more advanced and often necessary pattern involves leveraging associations — navigational links between related business object nodes or external CDS entities. This approach becomes essential when the value you need to derive depends not on the current entity alone, but on data that lives in an associated entity.

This blog walks through the concept and practical implementation of determinations that use associations in SAP RAP.

I have implemented a scenario where the non-editable Total Amount field in the header entity is automatically determined based on the Price and Quantity fields maintained in the associated item entity.

Below is the Header entity, which includes the Total Amount field

Below is the item entity, which includes quantity and price field

In the behavior definition, the Total Amount field is configured as non-editable using feature control, ensuring that it cannot be explicitly modified by the user.

Determination has been defined in the behavior definition of the Item entity.

The determination logic is implemented in the local handler class of the Item entity.

  METHOD calculate_total_price.

    DATA lt_header_update TYPE TABLE FOR UPDATE zi_nk_header.

*Step 1 : Read changed items
    READ ENTITIES OF zi_nk_header IN LOCAL MODE
      ENTITY zi_nk_item
        FIELDS ( soid quantity price currency )
        WITH CORRESPONDING #( keys )
      RESULT DATA(lt_items)
      FAILED DATA(lf).

    DATA lt_header_keys TYPE TABLE FOR UPDATE zi_nk_header.

    LOOP AT lt_items ASSIGNING FIELD-SYMBOL(<item>).
*Step 2 :Navigate to parent headers using back-association
      READ ENTITIES OF zi_nk_header IN LOCAL MODE
        ENTITY zi_nk_item BY \_header
          FIELDS ( soid totalamount currency )
          WITH VALUE #( ( %tky = <item>-%tky ) )
        RESULT DATA(lt_header_result)
        FAILED DATA(lf_h).

      LOOP AT lt_header_result ASSIGNING FIELD-SYMBOL(<hdr>).
*Step 3 : Read all items under those headers
        READ ENTITIES OF zi_nk_header IN LOCAL MODE
          ENTITY zi_nk_header BY \_salesitem
            FIELDS ( quantity price currency )
            WITH VALUE #( ( %tky = <hdr>-%tky ) )
          RESULT DATA(lt_all_items)
          FAILED DATA(lf2).

*Step 4 : Calculate the total amount
*Here i have used decfloat34 to avoid the loss of decimal values and incorrect totals

        DATA(lv_total) = REDUCE decfloat34(
          INIT sum = CONV decfloat34( '0' )
          FOR <it> IN lt_all_items
          NEXT sum = sum + ( <it>-quantity * <it>-price )
        ).

        APPEND VALUE #(
          %tky        = <hdr>-%tky
          totalamount = lv_total
          currency    = <item>-currency
          %control    = VALUE #( totalamount = if_abap_behv=>mk-on )
        ) TO lt_header_update.

      ENDLOOP.
    ENDLOOP.

*Step 5 : Update the header entity
    MODIFY ENTITIES OF zi_nk_header IN LOCAL MODE
      ENTITY zi_nk_header
        UPDATE FIELDS ( totalamount currency )
        WITH lt_header_update
      FAILED DATA(lf3)
      REPORTED DATA(lr).

  ENDMETHOD.

The Total Amount and Currency fields are rendered as read-only, preventing any direct user modification.

In the Item entity, users provide input for Quantity and Price, based on which the Total Amount is determined and automatically updated in the associated Header entity.

Output:-

Conclusion:-

This approach ensures data consistency, reduces redundancy, and keeps the business logic modular and maintainable. It is especially useful in scenarios like calculating header totals based on item data, where changes in one entity automatically reflect in another.

RAP Validation Extension in SAP – Step-by-Step Guide

2026-04-15T11:23:15.567000+02:00

Introduction

In the SAP RAP (RESTful ABAP Programming Model), extensibility is a powerful concept that allows developers to enhance standard Business Objects (BOs) without modifying the original code.

One such enhancement is the Validation Extension, which enables you to add custom validation logic during the save process.

This is especially useful when:

You do not own the standard Business Object

You want to enforce additional business rules

You must avoid modifying the base implementation

Scenario

Assume you are working with a standard RAP Business Object, and you want to validate a field:

The “Name” field should not contain numeric values

Even though you don’t own the base BO, you can still implement this validation using RAP Validation Extension.

RAP Extensibility Overview

RAP extensibility involves two main roles:

Extensibility Enabler

The original developer of the BO

Enables the BO for extension

Extensibility Provider

The developer who creates extensions

Adds custom logic like:

Fields (Data Model Extension)

Validations / Determinations (Behavior Extension)

Nodes

Note: Extensibility must be enabled first; otherwise, extensions are not possible.

Step 1: Extensibility Enabler (Base BO Preparation)

Enable Extensibility in Base Behavior Definition

managed implementation in class zbp_nvt_i_act1 unique;
strict ( 2 );
extensible
{
    with additional save;
    with determinations on modify;
    with determinations on save;
    with validations on save;
}

Enable Node-Level Extensibility

define behavior for znvt_i_act1 //alias <alias_name>
persistent table znvt_dt_act1
lock master
authorization master ( instance )
extensible
{
  create;
  update;
  delete;

Maintain Field Mapping (Extensible)

  mapping for znvt_dt_act1{
  Name = name;
  Orderid = orderid;
  Quantity = quantity;
  Status = zzstatus;
  }
}

Note: If new fields have the same name in CDS and DB table, no mapping extension is required.

Enable Projection Behavior Extensibility

projection;
strict ( 2 );
extensible;

define behavior for znvt_c_act1 //alias <alias_name>
extensible
{
  use create;
  use update;
  use delete;
}

Step 2: Extensibility Provider (Create Validation Extension)

1. Create Behavior Definition Extension

Go to base BDEF: znvt_i_act1

Right-click → New Behavior Extension

Provide:
- Package
- Extension Name (e.g., znvt_ext1)
- Description

2. System-Generated Template, for extending the Base Behavior

extension implementation in class zbp_nvt_ext1 unique;

extend behavior for znvt_i_act1
{
   
}

3. Add the Validation Logic

Inside the extension block, define a validation with:

Trigger: on save

Field: Name
Operation: create

extension implementation in class zbp_nvt_ext1 unique;

extend behavior for znvt_i_act1
{
    validation val_method on save { field Name; create; }
}

Step 3: Implement Validation Logic

1. Create Behavior Implementation Class

Use quick fix (Ctrl + 1) on the implementation class

This will generate class: zbp_nvt_ext1
Implement your validation logic inside this class

CLASS lhc_znvt_i_act1 DEFINITION INHERITING FROM cl_abap_behavior_handler.
  PRIVATE SECTION.

    METHODS val_method FOR VALIDATE ON SAVE
      IMPORTING keys FOR znvt_i_act1~val_method.

ENDCLASS.

Implementation:

CLASS lhc_znvt_i_act1 IMPLEMENTATION.

  METHOD val_method.
    read entity in local mode znvt_i_act1
    aLL FIELDS WITH corrESPONDING #( keys )
    reSULT data(lt_data).

    data(ls_data) = lt_data[ 1 ].

    if ls_data-Name ca '1234567890'.
    appEND vaLUE #( %tky = ls_data-%tky
                    %element-Name = if_abap_behv=>mk-on
                    %msg = new_message_with_text( severity = if_abap_behv_message=>severity-error
                    text = 'the Name field can not contain numbers'
                 ) ) to reported-znvt_i_act1.
    endIF.

  ENDMETHOD.

ENDCLASS.

Optional: Projection Behavior Extension

You can also extend the projection layer if needed.

However, for validation scenarios, this step is usually not required.

Output

When a user enters numeric values in the "Name" field

And tries to save the data

The system throws an error message: "The Name field cannot contain numbers" .

Conclusion

RAP Validation Extensions provide a clean and upgrade-safe way to implement custom validations without modifying the original Business Object.

By properly using:

Extensibility Enabler

Behavior Extensions

Validation Methods

Triggering Background Jobs from RAP Actions – A Practical Guide

2026-04-15T11:24:21.616000+02:00

Introduction:

In the SAP ABAP RESTful Application Programming Model (RAP), actions are typically executed within a single transactional request. However, resource-intensive operations are not suitable for synchronous execution as they impact performance and user experience. To handle this, background job processing can be used to execute heavy logic asynchronously. This blog demonstrates how a RAP action can trigger a background job to keep the main transaction lightweight.

What is a RAP Action?
An action in RAP is a non-standard operation used to change data or trigger specific business logic. By default, these are synchronous, meaning the UI waits for the logic to finish before the user can continue.

What is Background Processing (BG)?
Background processing allows the system to run tasks in a separate session without user interaction. It is ideal for "fire-and-forget" scenarios or resource-intensive tasks that would otherwise cause a timeout in a web session.

Scenario: Bulk Asynchronous Processing in RAP
A business user needs to process multiple records simultaneously in a SAP Fiori application—such as updating statuses for a large batch of background job entries. While a simple status change is quick, the underlying business logic (like complex data validation or external system integration) is resource-intensive and long-running.

Problem Statement
Executing heavy synchronous logic directly within RAP actions causes poor user experience, performance degradation, and potential transaction timeouts.

Solution
Trigger an asynchronous background job from the RAP action. The action marks the records as "In Progress," and the Saver Class calls a Function Module IN BACKGROUND TASK to schedule a background report. This offloads the processing to a separate session, allowing the main UI transaction to remain lightweight and responsive.

Implementation Steps

Step 1: Create a database table

@EndUserText.label : 'DATABASE TABLE FOR BACKGROUND JOB' 
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE 
@AbapCatalog.tableCategory : #TRANSPARENT 
@AbapCatalog.deliveryClass : #A 
@AbapCatalog.dataMaintenance : #RESTRICTED 

define table zaf_dt_backjob { 

key id : uuid not null; 
description : abap.char(50); 
status : abap.char(10); 
job_name : abap.char(32); 
job_count : abap.char(10); 
start_time : timestampl; 
end_time : timestampl; 
error_message : abap.char(255); 
created_by : abap.char(12);
created_at : abp_creation_tstmpl; 
last_changed_at : abp_lastchange_tstmpl; 

}

Step 2: Create a interface view on top of database table.

@AbapCatalog.viewEnhancementCategory: [#NONE] 
@AccessControl.authorizationCheck: #NOT_REQUIRED 
@EndUserText.label: 'BACKGROUND job interface view' 
@Metadata.ignorePropagatedAnnotations: true 

define root view entity zi_AF_backjob as select from zaf_dt_backjob 

{ 
key id as Id, 
description as Description, 
status as Status, 
job_name as JobName, 
job_count as JobCount, 
start_time as StartTime, 
end_time as EndTime, 
error_message as ErrorMessage, 
created_by as CreatedBy, 
created_at as CreatedAt, 
last_changed_at as LastChangedAt, 
case status 
when 'DONE' then 3 
when 'INPR' then 2 
when 'NEW' then 1 
when 'ERR' then 4 
else 0 
end as StatusCriticality 

}

Step 3: Create a Consumption view

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Background job projection view'
@Metadata.ignorePropagatedAnnotations: true
@Metadata.allowExtensions: true
@UI.headerInfo: {
  typeName: 'Background Job',
  typeNamePlural: 'Background Jobs',
  title: { type: #STANDARD, value: 'Description' }
}
define root view entity zc_af_backjob
provider contract transactional_query
as projection on zi_AF_backjob
{

key Id,
  Description,
  Status,
  JobName,
  JobCount,
  StartTime,
  EndTime,
  ErrorMessage,
  CreatedAt,
  LastChangedAt,
  StatusCriticality

}

Step 4: Metadata Extension file

@Metadata.layer: #CORE
annotate entity zc_af_backjob with 
{
  .facet: [
    {
      id: 'General',
      purpose: #STANDARD,
      type: #IDENTIFICATION_REFERENCE,
      label: 'General Information',
      position: 10
    }
  ]

  .lineItem: [{ position: 10, label: 'UUID' }]
  .identification: [{ position: 10, label: 'UUID' }]
  .selectionField: [{ position: 10 }]
  Id;

  .lineItem: [{ position: 20, label: 'Description' }]
  .identification: [{ position: 20, label: 'Description' }]
  Description;

  .lineItem: [
    { position: 30, label: 'Status' },
    { type: #FOR_ACTION, dataAction: 'StartProcessing', label: 'Start Job' }
  ]
  .identification: [{ position: 30, label: 'Status' }]
  .selectionField: [{ position: 30 }]
  .dataPoint: {
    title: 'Status',
    criticality: 'StatusCriticality'
  }
  Status;

  .lineItem: [{ position: 40, label: 'Job Name' }]
  .identification: [{ position: 40, label: 'Job Name' }]
  .selectionField: [{ position: 40 }]
  JobName;

  .lineItem: [{ position: 50, label: 'Job Count' }]
  .identification: [{ position: 50, label: 'Job Count' }]
  JobCount;

  .lineItem: [{ position: 60, label: 'Start Time' }]
  .identification: [{ position: 60, label: 'Start Time' }]
  StartTime;

  .lineItem: [{ position: 70, label: 'End Time' }]
  .identification: [{ position: 70, label: 'End Time' }]
  EndTime;

  .lineItem: [{ position: 80, label: 'Error Message' }]
  .identification: [{ position: 80, label: 'Error Message' }]
  ErrorMessage;

  .hidden: true
  CreatedAt;

  .hidden: true
  LastChangedAt;

  .hidden: true
  StatusCriticality;
}

Step 5: Create a Behavior Definition on top of interface View

unmanaged implementation in class zbp_i_af_backjob unique;
strict ( 2 );
with draft;

define behavior for zi_AF_backjob 
lock master
total etag LastChangedAt
draft table zaf_draft_bg
authorization master ( instance )
early numbering

{
  create;
  update;
  delete;

     draft action activate optimized;
     draft action resume;
     draft action Edit;
     draft action Discard;
     draft determine action Prepare;

    action StartProcessing result [1] $self;

  determination SetInitialStatus on modify { create; }

 field ( readonly ) Id;
  field ( readonly ) Status, JobName, JobCount, StartTime, EndTime, ErrorMessage;
  field ( readonly ) CreatedAt, LastChangedAt, CreatedBy;

  field ( mandatory ) Description;


mapping for zaf_dt_backjob{

CreatedAt = created_at;
CreatedBy = created_by;
Description = description;
EndTime = end_time;
ErrorMessage = error_message;
Id = id;
JobCount = job_count;
JobName = job_name;
LastChangedAt = last_changed_at;
StartTime = start_time;
Status = status;

}
}

Step 6: Create implementation class

CLASS lhc_zi_af_backjob DEFINITION INHERITING FROM cl_abap_behavior_handler.

  PUBLIC SECTION.
    TYPES: tt_backjob_db TYPE STANDARD TABLE OF zaf_dt_backjob WITH EMPTY KEY.

    " Buffer for CRUD and Job Scheduling
    CLASS-DATA: mt_buffer_upsert TYPE tt_backjob_db,
                mt_buffer_delete TYPE tt_backjob_db,
                gt_jobs          TYPE STANDARD TABLE OF zaf_dt_backjob-id.

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

    METHODS earlynumbering_create FOR NUMBERING
      IMPORTING entities FOR CREATE zi_af_backjob.

    METHODS create FOR MODIFY
      IMPORTING entities FOR CREATE zi_af_backjob.

    METHODS update FOR MODIFY
      IMPORTING entities FOR UPDATE zi_af_backjob.

    METHODS delete FOR MODIFY
      IMPORTING keys FOR DELETE zi_af_backjob.

    METHODS read FOR READ
      IMPORTING keys FOR READ zi_af_backjob RESULT result.

    METHODS lock FOR LOCK
      IMPORTING keys FOR LOCK zi_af_backjob.

    METHODS StartProcessing FOR MODIFY
      IMPORTING keys FOR ACTION zi_af_backjob~StartProcessing RESULT result.

    METHODS SetInitialStatus FOR DETERMINE ON MODIFY
      IMPORTING keys FOR zi_af_backjob~SetInitialStatus.

ENDCLASS.

CLASS lhc_zi_af_backjob IMPLEMENTATION.

  METHOD get_instance_authorizations.
  ENDMETHOD.

  METHOD earlynumbering_create.
    LOOP AT entities INTO DATA(ls_entity).
      IF ls_entity-id IS NOT INITIAL.
        CONTINUE.
      ENDIF.

      DATA(lv_uuid) = cl_system_uuid=>create_uuid_x16_static( ).

      APPEND VALUE #(
        %cid      = ls_entity-%cid
        %is_draft = ls_entity-%is_draft
        id        = lv_uuid
      ) TO mapped-zi_af_backjob.
    ENDLOOP.
  ENDMETHOD.

  METHOD create.
    LOOP AT entities INTO DATA(ls_entity).
      APPEND VALUE #(
        id          = ls_entity-id
        description = ls_entity-Description
        status      = 'NEW'
        created_by  = sy-uname
      ) TO mt_buffer_upsert.
    ENDLOOP.
  ENDMETHOD.

  METHOD update.
    LOOP AT entities INTO DATA(ls_entity).
      " In unmanaged, we must fetch current state to apply partial updates
      SELECT SINGLE * FROM zaf_dt_backjob WHERE id = _entity-id INTO (ls_db).

      IF ls_entity-%control-Description = if_abap_behv=>mk-on.
         ls_db-description = ls_entity-Description.
      ENDIF.

      IF ls_entity-%control-Status = if_abap_behv=>mk-on.
         ls_db-status = ls_entity-Status.
      ENDIF.

      GET TIME STAMP FIELD ls_db-last_changed_at.
      APPEND ls_db TO mt_buffer_upsert.
    ENDLOOP.
  ENDMETHOD.

  METHOD delete.
    LOOP AT keys INTO DATA(ls_key).
      APPEND VALUE #( id = ls_key-id ) TO mt_buffer_delete.
    ENDLOOP.
  ENDMETHOD.

  METHOD read.
    IF keys IS INITIAL. RETURN. ENDIF.
    SELECT * FROM zaf_dt_backjob FOR ALL ENTRIES IN  WHERE id = -id INTO TABLE (lt_data).

    result = CORRESPONDING #( lt_data MAPPING
      Id = id Description = description Status = status JobName = job_name
      JobCount = job_count StartTime = start_time EndTime = end_time
      ErrorMessage = error_message CreatedBy = created_by CreatedAt = created_at
      LastChangedAt = last_changed_at ).
  ENDMETHOD.

  METHOD lock.
    
  ENDMETHOD.

  METHOD StartProcessing.
    LOOP AT keys INTO DATA(ls_key).
      " 1. Mark status as 'INPR' immediately in the database
      UPDATE zaf_dt_backjob SET status = 'INPR' WHERE id = _key-id.

      " 2. Add to global job queue for the SAVE phase
      INSERT ls_key-id INTO TABLE gt_jobs.
    ENDLOOP.

    result = VALUE #( FOR key IN keys ( Id = key-id %param = CORRESPONDING #( key ) ) ).
  ENDMETHOD.

  METHOD SetInitialStatus.
    LOOP AT keys INTO DATA(ls_key).
      SELECT SINGLE * FROM zaf_dt_backjob WHERE id = _key-id INTO (ls_db).
      IF ls_db-status IS INITIAL.
        ls_db-status = 'NEW'.
        APPEND ls_db TO mt_buffer_upsert.
      ENDIF.
    ENDLOOP.
  ENDMETHOD.

ENDCLASS.

" --- Saver Class Implementation ---
CLASS lsc_zi_af_backjob DEFINITION INHERITING FROM cl_abap_behavior_saver.
  PROTECTED SECTION.
    METHODS finalize REDEFINITION.
    METHODS check_before_save REDEFINITION.
    METHODS save REDEFINITION.
    METHODS cleanup REDEFINITION.
    METHODS cleanup_finalize REDEFINITION.
ENDCLASS.

CLASS lsc_zi_af_backjob IMPLEMENTATION.

  METHOD finalize.
  ENDMETHOD.

  METHOD check_before_save.
  ENDMETHOD.

  METHOD save.
    " 1. Standard DB Persistence
    IF lhc_zi_af_backjob=>mt_buffer_delete IS NOT INITIAL.
      DELETE zaf_dt_backjob FROM TABLE @lhc_zi_af_backjob=>mt_buffer_delete.
    ENDIF.

    IF lhc_zi_af_backjob=>mt_buffer_upsert IS NOT INITIAL.
      MODIFY zaf_dt_backjob FROM TABLE @lhc_zi_af_backjob=>mt_buffer_upsert.
    ENDIF.

    " 2. Trigger Async logic using the reference pattern
    LOOP AT lhc_zi_af_backjob=>gt_jobs INTO DATA(lv_id).
      CALL FUNCTION 'ZAF_FM_BACKJOB'
        IN BACKGROUND TASK
        DESTINATION 'NONE'  " Critical for separate LUW execution
        EXPORTING
          iv_id = lv_id.
    ENDLOOP.
  ENDMETHOD.

  METHOD cleanup.
    " Clear all buffers after the LUW is complete
    CLEAR: lhc_zi_af_backjob=>mt_buffer_upsert,
           lhc_zi_af_backjob=>mt_buffer_delete,
           lhc_zi_af_backjob=>gt_jobs.
  ENDMETHOD.

  METHOD cleanup_finalize.
  ENDMETHOD.

ENDCLASS.

Step 7: Create behavior definition on Consumption view

projection;
strict ( 2 );
use draft;

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

  use action StartProcessing;

  use action activate;
  use action resume;
  use action Edit;
  use action Discard;
  use action Prepare;
}

Step 8: Create service Definition on top of Consumption view

@EndUserText.label: 'service defination for background job'
define service Zsevd_bg_job {
  expose zc_af_backjob;
}

Step 9: Create service binding on top of service defination

Step 10: Create Function Module

FUNCTION zaf_fm_backjob.
*"----------------------------------------------------------------------
*"  IMPORTING VALUE(IV_ID) TYPE ZAF_DT_BACKJOB-ID
*"----------------------------------------------------------------------
  DATA: lv_jobname   TYPE tbtcjob-jobname,
        lv_jobcount  TYPE tbtcjob-jobcount,
        lv_timestamp TYPE timestampl.

  " 1. Dynamic Job Name for better monitoring in SM37
  lv_jobname = |ZAF_BG_{ iv_id+0(8) }|.

  CALL FUNCTION 'JOB_OPEN'
    EXPORTING jobname = lv_jobname
    IMPORTING jobcount = lv_jobcount.

  IF sy-subrc = 0.
    GET TIME STAMP FIELD lv_timestamp.

    " 2. Update DB with system metadata immediately
    UPDATE zaf_dt_backjob
      SET job_name   = _jobname,
          job_count  = _jobcount,
          status     = 'INPR',
          start_time = _timestamp
      WHERE id = _id.

    " 3. Push data to UI so it's visible while report processes
    COMMIT WORK.
  ENDIF.

  " 4. Schedule the report
  SUBMIT zaf_bg_job_report WITH p_id = iv_id
    VIA JOB lv_jobname NUMBER lv_jobcount AND RETURN.

  " 5. Release job
  CALL FUNCTION 'JOB_CLOSE'
    EXPORTING jobname = lv_jobname jobcount = lv_jobcount strtimmed = 'X'.
ENDFUNCTION.

Step 11: Create a Report Program

REPORT zaf_bg_job_report.

PARAMETERS: p_id TYPE zaf_dt_backjob-id.

DATA: lv_timestamp TYPE timestampl.

START-OF-SELECTION.

  IF p_id IS INITIAL.
    RETURN.
  ENDIF.

  WAIT UP TO 5 SECONDS.

  GET TIME STAMP FIELD lv_timestamp.

  " Update final status to match the reference 'DONE'
  UPDATE zaf_dt_backjob
    SET status        = 'DONE',
        end_time      = _timestamp,
        error_message = ''
    WHERE id = @p_id.

  COMMIT WORK.

Result :

Select Multiple Records then click Action Button Start Job.

Conclusion :

This approach demonstrates how the SAP ABAP RESTful Application Programming Model (RAP) can be extended beyond standard transactional processing to meet demanding real-world requirements. By leveraging the Saver Class to trigger asynchronous background jobs, you ensure that resource-intensive operations—such as bulk status updates in SD or MM—are executed efficiently without affecting the performance of the main transaction.

From Idea to App in Minutes: Generating SAP Fiori Elements Applications with the Project Accelerator

2026-04-15T12:00:49.174000+02:00

The SAP Fiori tools Project Accelerator is an AI-assisted capability that transforms business requirements provided as text, image, or a combination of both into a SAP Fiori elements application. The generated application can be backed by either the SAP Cloud Application Programming Model (CAP) or ABAP RESTful Application Programming Model (RAP).

The Project Accelerator automates the generation of data models, services, UI scaffolding, and mock data, enabling you to quickly turn ideas from brainstorming or whiteboarding sessions into tangible applications that can be immediately previewed and iterated upon.

Where it fits in the SAP Fiori Tools ecosystem

The Project Accelerator is built directly into SAP Fiori tools and can be used within SAP BAS.

It complements existing SAP Fiori tools capabilities such as project generation, application preview, and annotation editing. By generating initial project artifacts directly from business requirements, the Project Accelerator helps you quickly establish a solid project structure.

What the Project Accelerator Generates

Depending on the selected programming model, the Project Accelerator generates the following artifacts:

CAP:

For CAP-based applications, the Project Accelerator generates:

An SAP Fiori elements application
Data models and services
Local mock data

RAP :

For RAP-based applications, the Project Accelerator generates:

An SAP Fiori elements application
A RAP back-end artifact
An OData V4 service endpoint
Local mock data

Important note: Business logic is not automatically generated in either CAP or RAP projects. Developers must implement the application logic manually after the initial scaffolding is created.

Step-by-step guide for the RAP Accelerator Through Business Application Studio (BAS)

In this guide, we will generate an SAP Fiori elements app for managing sports games using the RAP Accelerator with image input. This app will allow users to view game schedules, team information, and game details. Later, we will modify the application to target soccer.

1) Prepare your input

Before starting the generation process, gather your business requirements, which are the inputs you prove to the Project Accelerator.

The Input can be in the following formats:

Text

You can write a clear description of your application, including:

The purpose of the app
Entities and their relationships
Fields and properties
Labels and restrictions
Desired UI layout

Tip: Field values, logic, and restrictions are usually easier to describe using text.

Images

You can upload images to describe the desired structure or layout, such as:

A data model diagram
A UI mockup
A List Report layout showing columns
Object Page sections or tables
Screenshots of an existing application

Tip: Layouts and visual structures are easier to describe using images.

I'll use the following image to build a sports game management scenario. Users will be able to see which teams are playing against each other, the league and age group, and where and when the game takes place. The app will also display team details, including the trainer and players.

Figure 1. Database model for sports game management scenario

When I first generated the application without specifying a sport type, the underlying LLM inferred the context and generated soccer-related mock data. To see how changes to the input such as specifying the sport type affects the output, I regenerated the application with several modifications to the original image. The results, shown in the Appendix , demonstrate how the AI adapts the generated data based on more specific input.

Using Multimedia Input

It is important to keep in mind that the accelerator accepts a single file as input. If you want to upload both text and images, or multiple images, you should first combine them into a single document, either as a word document file (.docx) or as a markdown (.md) file and later upload the file to the accelerator as the business requirement.

If you are using a .md file, you should also upload the images to your workspace folder.

2) Set up your environment:

To access the Project Accelerator, you need to be in Dev Space with the necessary extensions installed.

Prerequisites

You need to have access to SAP Build Code (What is SAP Build Code | SAP Help Portal) or signed in for (SAP Build Code Test Drive | SAP Tutorials)
You need to use SAP Business Application Studio as your integrated development environment

Required Extensions

Based on your programming model, ensure your Dev Space includes the appropriate extensions:

(If you are creating a new Dev Space, you can select an application type that includes the extensions you need: creating a new Dev Space.)

For CAP:

Dev Space must include:

CAP Tools
SAP Fiori Tools

For RAP

Dev must include:

SAP Fiori Tools

RAP Backend Requirements:

For RAP projects, ensure the following prerequisites are met:

RAP backend should be version 2602 or higher
You should be connected to the backend system by configuring the destination in SAP Business Application Studio
S_DEVELOP authorization

Creating a Dev Space

Now, moving on with the creation of a Dev Space:

Open SAP Build
1. Click the icon with small squares on the top-right corner
2. Select Dev Space ManagerFigure 2. How to access the Dev Space Manager
Create a New Dev Space
- Enter a name for your Dev Space
- Select the application type
  - Each application type includes a predefined set of extensions.
  - Select the application type based on the extensions it provides and whether they are required for your programming model or not.
  - For this example, I selected the Full-Stack ABAP Application.
- Click on “Create Dev Space” Figure 3. How to create a Dev Space
After creating your dev space, you will be redirected to the Dev Space Manager, where you can see the newly created dev space and access any other dev spaces you may have created.Figure 4. Dev Space with status "starting"
Wait until the status changes to "Running"
Click on the Dev Space name to start developing

Image 5. Dev Space with status "running"

3) Launching the Project Accelerator

Once you are in your Dev Space, you can launch the Project Accelerator in multiple ways. One of them being:

Using the Template Wizard

Choose “New Project from Template”Figure 6. Step 1 of launching the Project Accelerator
Select “SAP Fiori Generator" and click "Start"Figure 7 . Step 2 of launching the Project Accelerator
On the next screen, click on the “Project Accelerator” to begin

Figure 8. Step 3 of launching the Project Accelerator

4) Choose your programming model accelerator

When using the Project Accelerator, you can either select CAP Accelerator or RAP Accelerator tab depending on your programming model.

RAP Configuration

For RAP projects, you must:

Specify the Destination:
1. Select a destination system from the dropdown
2. Verify your user authentication (user and password for the backend system)
  - OAuth2 authentication can also be configured via the SAP BTP CockpitFigure 9. Accessing the RAP Accelerator
Configure Backend Connection

After successful authentication, additional fields will appear:

Here, you should specify your SAPUI5 repository, the package for RAP backend artifact creation, and the transport request if it is required.

Figure 10. Configuring the backend connection

For more information regarding these fields, please refer to: Generating an Application Using an Image | SAP Help Portal

5) Enter Your Business Requirements

After choosing your accelerator and specifying your destination, you can upload the input prepared in Step 1 into the business requirements field.

You can either:

Upload files to the workspace and then select them using "Choose File" under the business requirements input area
Drag and drop documents directly from the file explorer

Hold the Shift key while dragging

Figure 11. Entering the Business Requirements

Note: The clearer and more structured your input is, the better the generated result will be.

6) Generating the Project

Note: By default, the application is generated in the currently open folder. If you want the project to be created in a different location, you can specify a Project Folder Path before starting the generation.

Click Generate below the input field:
- The tool will interpret your requirements and generate the project artifacts.Figure 12. Generating the project
- The interface switches to a generation view displaying progress. Generation may take some time depending on the complexity of your requirementsFigure 13. Generation view
- Once the generation is complete, the Application Information page will appear.Figure 14. Application Information page
- If the project is not in a workspace folder, BAS may display a dialog asking whether to add it after the generation is complete.Figure 15. Adding the project into a workspace
  In this case, you can choose either:
  - “Open Folder”, which creates a new folder for the project, or
  - “Add Project to Workplace”, adding the project to the existing folder. Selecting one of these options adds the project to the workspace and lands you to the Application Information page.

7) Preview of the Application

To preview the application:

Select “Preview Application”Figure 16. Previewing the application
Choose “Start Fiori Run” from the context menu
This launches the generated UI.Figure 17. Preview of the application

Note: At this stage, the preview only shows the application structure, without any data.

Edge Case: Running the Preview from the ABAP Backend

Make sure that you run the preview directly from SAP Business Application Studio (BAS) when previewing the generated application.

If you launch the preview from the ABAP backend instead of BAS, the UI will not render correctly. This is expected behavior as the Project Accelerator stores UI annotations in the local “annotation.xm” file of your Fiori project, not in backend Metadata Extensions. Therefore, the backend cannot render the UI properly without these local annotations.

If the preview is executed from the ABAP backend, the result will appear similar to the following:

Figure 18. Preview of the application when rendered from the ABAP backend example 1

Figure 19. Preview of the application when rendered from the ABAP backend example 2

8 ) Generate and Preview with Local Mock Data

You can also preview the application with locally generated mock data:

Open the terminal
Enter Ctrl + C to terminate the current process
Select “Preview Application”
Choose “Start-Mock Fiori Run” from the context menuFigure 20. Previewing the application with locally generated mock data
After restarting, you may need to log in again for system authorization.
The UI will now display generated mock data, allowing you to:

Figure 21. Preview of the application with mock dataFigure 22. Preview of the application with mock data - game object page

Figure 23. Preview of the application with mock data - team object page

9) Review and Refine

After generation, review the application and refine the configuration as needed. You can adjust field names, labels, page sections, and UI layout using the Page Map:

Click on "Open Page Map"Figure 24. Navigating to Page Map
Select the pencil icon next to the location you want to modify
Make your changes.
The preview will automatically refresh and update

Example 1: Editing Column Names

Since the business requirement was for general sports, and soccer uses fields (not courts), let's change the column name from "court" to "field."

Scenario: Change the field name “Home Court” to “Home Field”

Click on Open Page Map
Click on the pencil icon of “Teams Object Page”Figure 25. Navigating to "Teams" Object Page
Expand the “Table” section
Expand the “Columns” subsection
Click on the “Home Court” field
On the right-hand side (RHS), find the “Label” field and change it to “Home Field”Figure 26. How to change the field name
The preview will automatically refresh and update

Figure 27. Changing the field name in "Team" Object Page

Note: Renaming the column in the Teams Object Page only changes how it appears on the Teams Object Page. The “Home Court” column on the Games Object Page won’t update automatically:

Figure 28. Display of unchanged field name in "Game" Object Page

To change it on the Games Object Page as well, you’ll need to rename the column in the Game Object Page. You can do this just by repeating the steps above for Games Object Page.

Example 2: Adding a Description to an Object Page

Scenario: Add the description “Game Information” to the Game Object Page.Figure 29. Empty description space in "Game" Object Page

Click on Open Page Map
Select “Games Object Page”Figure 30. Navigating to "Game" Object Page
Click on “Header”.
On the RHS, find Description Type and select “Text” from the dropdown.Figure 31. Navigating to Description Type dropdown

Choosing “Text” allows you to enter custom free text. Alternatively, you can select “Property” to pick from predefined fields or objects.

In this case, I selected the “Text” option because “Game Information” is not a predefined feature of any existing object in the application.

5. Type “Game Information” into the Description field.

Figure 32. How to add a text to the description space

6. The UI will automatically refresh and update

Figure 33. Preview of "Game" Object Page with description text

Example 3: Adding an Icon to an Object Page

Scenario: Adding a soccer icon to the Game object page

Click on Open Page Map
Select the “Games Object Page”
Find the icon sectionFigure 34. Navigating to the Icon Explorer
Click the link to the Icon Explorer
Search for “soccer”Image 35. View of the Icon Explorer and searching for the term "soccer"You can also browse the available icons and select the one that fits your goalsFigure 36. Overview of the existing SAPUI5-supported icons
Copy the soccer ball icon’s URL

Figure 37. Copying the soccer ball icon's URL

7. Switch to your Dev Space and paste the URL into the icon fieldFigure 38. Pasting the copied URL into the Icon field8. The UI will refresh automatically and display the iconFigure 39. Preview of the "Game" Object Page with the soccer ball icon

Next steps:

After you are satisfied with the UI Layout;

For CAP: Add business logic in service handlers; enrich annotations; refine data model.
RAP: Implement behavior logic, validation, determinations; adjust annotations; refine UI.

For more information:

Official documentation page:

Generating an Application with the Project Accelerator Using SAP Fiori Tools AI | SAP Help Portal

Appendix

1) Specifying the sport type as volleyball

To see how specifying the sport type affects the generated mock data, I added additional requirements database model I originally used:Figure 40. Updated database model, sport type specified as volleyball

The generated mock data became more volleyball-oriented, as reflected in the “Team” and “Place” names:

Figure 41. Preview with volleyball-specific mock data

I was also interested to see if the number of players would change based on the specified sport type, for example:

a volleyball team having at least 6 players
a soccer team having 11
a basketball team having 5

However, the number of players did not change compared to the original input.

Figure 42. "Team" Object Page displaying players

If you want to have specific number of instances, you can explicitly include this in your business requirements:Figure 43. Data model diagram with amount of team members specified

Figure 44. "Team" Object Page with 6 players

2) Using Mock UI

For the Mock UI, I uploaded an image intended to represent the list of all games and the corresponding object page:

Figure 45. Mock UI - First attempt

However, the LLM did not recognize this image as one of its supported input types and returned an error:

If you are providing a Mock UI, the input should be clear and focused to avoid such errors.

Figure 46. Error message for unsupported images

In my experience, Mock UIs produce the best results when the input is as simple and clear as possible. For example, the image below worked well:

Figure 47. Mock UI - Second attempt

The Project Accelerator successfully generated the list report and even added “Players” and “Teams” objects to the object page, which was a positive surprise:

Figure 48. Successfully generated application with Mock UIImage 49. Successfully generated application with Mock UI - Object Page

3) Using Multimedia Input: Multiple images

I combined the input material into a single .docx document and uploaded it to the accelerator:Figure 50. The two images, combined in a single document

You can upload the .docx or .md files the same way as you would for images.

The following application was generated:Figure 51. Preview of the application generated with multi-media input

Figure 52. Preview of the application generated with multi-media input - Object Page

Mismatch in object fields

When combining multiple input sources, such as database tables and Mock UI images, it is important that these models are consistent. Inconsistencies between the data model and the UI definition can lead to incorrect or incomplete application generation:

Figure 53. Multi-media input with mismatching fields

Figure 54. Preview of the application generated with the input shown in Figure 53

The following issue occurred due to such a mismatch:

The “Game” entity contains additional fields in the database model that are not represented in the UI.
The “Team” entity is missing a role field in the database model that is expected by the UI.

Handling Dynamic Fields in SAP RAP using JSON Payload in CDS Custom Entity

2026-04-15T22:52:03.905000+02:00

Introduction

Core Data Services (CDS) entities in the ABAP RESTful Application Programming Model (RAP) are usually constructed using statically set parameters. Although this guarantees robust typing and clarity, it becomes restrictive when programs have to deal with dynamic inputs like changing fields, tables, or runtime-driven filters.

Such adaptability is crucial in many real-world situations. Nevertheless, dynamic parameter structures are not supported by CDS natively, which frequently results in complicated and difficult-to-maintain designs.

This blog describes an adaptable method that passes dynamic field data as a single parameter and processes it at the ABAP layer using a JSON payload inside a CDS Custom Entity. This keeps the CDS design straightforward while enabling more flexible and scalable RAP solutions.

What are CDS Custom Entities in RAP?

A CDS Custom Entity is a unique kind of CDS entity that does not read data directly from the database in the ABAP RESTful Application Programming Model (RAP). Rather, an ABAP class is used to accomplish it, and the developer has complete control over the data retrieval mechanism.

In contrast to Standard CDS Views:

Custom Entities enable ABAP's dynamic data processing.
When logic cannot be managed only at the database level, they are usually employed.
They offer the freedom to execute intricate or unconventional scenarios, including external integrations or dynamic queries.

Because the data is fetched and processed in the ABAP layer, Custom Entities are well-suited for scenarios where:

Input parameters need to be interpreted dynamically
Data sources or structures vary at runtime
Standard CDS capabilities are not sufficient

Real-Time Business Scenario: Dynamic Field Validation

In some SAP applications, there is a requirement to validate fields dynamically based on user input.

For instance, a user or an outside system might submit a request such as:

Verify if a table contains the specified fields.
During runtime, dynamically provide field values
Tables and fields are not predetermined.

One Sample input would be:

Table: SFLIGHT
Fields: FLDATE and CARRID
Values: LH, 20260313

The table and fields can be entirely different in a different request. This means that any table and any field must be handled dynamically by the application without the need for preset parameters.

The Problem

If we attempt to use normal CDS to implement this:

Each field would require its own set of parameters.
As fields alter, the number of parameters would increase.
Unknown or dynamic fields cannot be handled.

The Restrictions:
Flexible structures like a "list of fields" cannot be dynamically accepted by CDS. Because of this, the design is inflexible and challenging to scale.

The Solution

We use a single argument (FieldValuesJson) to deliver all field details as a JSON payload in order to resolve this.

There are other entries in this JSON, such as:

Table name
field name
field value

In the ABAP Implementation:

An internal table is created by parsing the JSON.
Every field is dynamically verified using the Data Dictionary (DD03L).
The existence of the field is indicated by the result that is returned.

Without altering the CDS definition, this method enables the application to dynamically handle any table and any field.

Implementation Using CDS Custom Entity

Step 1: Create CDS Custom Entity

First, define a CDS Custom Entity to accept input parameter and return results.

@EndUserText.label: 'Dynamic Field Filter Custom Entity'
@ObjectModel.query.implementedBy: 'ABAP:ZCL_DYN_FIELD_QUERY'

define root custom entity ZI_DYN_FIELD_ENTITY
{
  .selectionField: [{ position: 10 }]
  @EndUserText.label: 'Object Type'
  key ObjectType      : abap.char(30);

  .selectionField: [{ position: 20 }]
  @EndUserText.label: 'Policy Type'
  key PolicyType      : abap.char(20);
  
  @EndUserText.label: 'Table Name'
  key Tabname         : abap.char(30);

  @EndUserText.label: 'Field Name'
  key Fieldname       : abap.char(30);

  .selectionField: [{ position: 30 }]
  @EndUserText.label: 'Get Destructible'
  GetDestructible     : abap.char(1);

  .selectionField: [{ position: 40 }]
  @EndUserText.label: 'Field Values JSON'
  FieldValuesJson     : abap.char(1333);

  @EndUserText.label: 'Field Value'
  FieldValue          : abap.char(100);

  @EndUserText.label: 'Result Info'
  ResultInfo          : abap.char(200);
}

Explanation:

FieldValuesJson is used to pass dynamic field data as JSON
Output fields (Tabname, Fieldname, FieldValue, ResultInfo) hold processed results
The annotation @ObjectModel.query.implementedBy links to the ABAP class

Step 2: Create Behavior Definition (Unmanaged)

Define a behavior Definition for the custom entity:

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

define behavior for ZI_DYN_FIELD_ENTITY
authorization master ( global )
lock master
{
  field ( readonly ) ObjectType;
  field ( readonly ) PolicyType;
  field ( readonly ) Tabname;
  field ( readonly ) Fieldname;
}

Explanation:

Unmanaged behavior is used since logic is fully handled in ABAP
Fields are marked as readonly because this is a read-only scenario
No CRUD operations are required

Step 3: Implement Query Provider Class

Create the ABAP Class and implement IF_RAP_QUERY_PROVIDER:

CLASS zcl_dyn_field_query DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC.

  PUBLIC SECTION.
  " RAP Query Provider Interface for Custom Entity
    INTERFACES if_rap_query_provider.

  " Structure to hold dynamic field input from JSON
    TYPES:
      BEGIN OF ty_s_field_input,
        tabname   TYPE string,
        fieldname TYPE string,
        value     TYPE string,
      END OF ty_s_field_input,
      ty_t_field_input TYPE STANDARD TABLE OF ty_s_field_input
                       WITH DEFAULT KEY.

  PRIVATE SECTION.
   " Result structure based on CDS Custom Entity
    TYPES ty_t_result TYPE STANDARD TABLE OF zi_dyn_field_entity
                      WITH DEFAULT KEY.

   " Method to parse JSON payload into internal table
    METHODS parse_field_values_json
      IMPORTING iv_json      TYPE string
      RETURNING VALUE(rt_fv) TYPE ty_t_field_input.

   " Method to apply validation logic on dynamic fields
    METHODS apply_rules
      IMPORTING it_field_values TYPE ty_t_field_input
                iv_object_type  TYPE string
                iv_policy_type  TYPE string
                iv_destructible TYPE string
      RETURNING VALUE(rt_result) TYPE ty_t_result.

ENDCLASS.

CLASS zcl_dyn_field_query IMPLEMENTATION.

  METHOD if_rap_query_provider~select.

   " Variables to hold filter inputs
    DATA lv_object_type  TYPE string.
    DATA lv_policy_type  TYPE string.
    DATA lv_destructible TYPE string.
    DATA lv_json         TYPE string.
    DATA lt_result       TYPE ty_t_result.

    " 1. Extract filters from the Odata request
    TRY.
        DATA(lo_filter)      = io_request->get_filter( ).
        DATA(lt_filter_cond) = lo_filter->get_as_ranges( ).

        LOOP AT lt_filter_cond INTO DATA(ls_filter).
          CASE ls_filter-name.
            WHEN 'OBJECTTYPE'.
              lv_object_type  = ls_filter-range[ 1 ]-low.
            WHEN 'POLICYTYPE'.
              lv_policy_type  = ls_filter-range[ 1 ]-low.
            WHEN 'GETDESTRUCTIBLE'.
              lv_destructible = ls_filter-range[ 1 ]-low.
            WHEN 'FIELDVALUESJSON'.
              lv_json         = ls_filter-range[ 1 ]-low.
          ENDCASE.
        ENDLOOP.
      CATCH cx_root.
        " Optional: Handle Invalid filter scenario
    ENDTRY.

    " 2. Convert JSON payload into internal table
    DATA(lt_fv) = parse_field_values_json( lv_json ).

    " 3. Execute dynamic validation logic
    lt_result = apply_rules(
      it_field_values = lt_fv
      iv_object_type  = lv_object_type
      iv_policy_type  = lv_policy_type
      iv_destructible = lv_destructible ).

    " 4. Handle case where no valid input is provided
    IF lt_result IS INITIAL.
      APPEND VALUE #(
        objecttype      = lv_object_type
        policytype      = lv_policy_type
        getdestructible = lv_destructible
        fieldvaluesjson = lv_json
        resultinfo      = 'No valid JSON fields provided'
      ) TO lt_result.
    ENDIF.

   " 5. Handle total record count (for paging support)
    DATA lv_total TYPE int8.
    lv_total = lines( lt_result ).

    IF io_request->is_total_numb_of_rec_requested( ).
      io_response->set_total_number_of_records( lv_total ).
    ENDIF.

   " 6. Apply paging and return response data
    IF io_request->is_data_requested( ).
      DATA(lo_paging) = io_request->get_paging( ).
      DATA(lv_offset) = lo_paging->get_offset( ).
      DATA(lv_limit)  = lo_paging->get_page_size( ).

      IF lv_limit = if_rap_query_paging=>page_size_unlimited.
        io_response->set_data( lt_result ).
      ELSE.
        DATA lt_paged LIKE lt_result.

        " Apply offset + limit slicing
        APPEND LINES OF lt_result FROM ( lv_offset + 1 ) TO ( lv_offset + lv_limit ) TO lt_paged.
        io_response->set_data( lt_paged ).
      ENDIF.
    ENDIF.

  ENDMETHOD.

  METHOD parse_field_values_json.
    " Return empty if no JSON is provided
    IF iv_json IS INITIAL.
      RETURN.
    ENDIF.

    " Deserialize JSON into ABAP structure
    /ui2/cl_json=>deserialize(
      EXPORTING
        json = iv_json
      CHANGING
        data = rt_fv
    ).
  ENDMETHOD.

  METHOD apply_rules.

    " Loop through each dynamic field input
    LOOP AT it_field_values INTO DATA(ls_fv).
      DATA ls_result TYPE zi_dyn_field_entity.
      CLEAR ls_result.

      " Check if field exists in Data Dictionary
      SELECT SINGLE fieldname
        FROM dd03l
        WHERE tabname   = _fv-tabname
          AND fieldname = _fv-fieldname
        INTO (lv_fname).

      " Map input and context data to result structure
      ls_result-objecttype      = iv_object_type.
      ls_result-policytype      = iv_policy_type.
      ls_result-getdestructible = iv_destructible.
      ls_result-tabname         = ls_fv-tabname.
      ls_result-fieldname       = ls_fv-fieldname.
      ls_result-fieldvalue      = ls_fv-value.

      " Set validation result message
      IF sy-subrc = 0.
        ls_result-resultinfo = |Found: { ls_fv-tabname }-{ ls_fv-fieldname }|.
      ELSE.
        ls_result-resultinfo = |Error: { ls_fv-tabname }-{ ls_fv-fieldname } not in DDIC|.
      ENDIF.

      APPEND ls_result TO rt_result.
    ENDLOOP.
  ENDMETHOD.

ENDCLASS.

Result:

Field inputs given as a JSON payload can be dynamically processed by the service once the CDS Custom Entity and query provider logic have been implemented.

When the following request is made to the service:

/sap/opu/odata4/.../ZI_XXXXX?
$filter=
ObjectType eq 'BC_SFLIGHT'
and PolicyType eq 'DEMO'
and GetDestructible eq 'X'
and FieldValuesJson eq
'[{"tabname":"SFLIGHT","fieldname":"CARRID","value":"LH"},{"tabname":"SFLIGHT","fieldname":"FLDATE","value":"20260313"}]'

Conclusion

In this blog, we explored the challenge of handling dynamic fields in RAP when working with statically defined CDS parameters. We discussed a real-time scenario where field names, tables, and values are not fixed and need to be processed dynamically.

To address this, we implemented a solution using a CDS Custom Entity and passed dynamic input as a JSON payload, which is parsed and processed in the ABAP query provider class. This allowed us to validate fields against the Data Dictionary without modifying the CDS structure.

Overall, this approach provides a flexible and reusable solution for dynamic field handling in RAP, making it easier to adapt to changing requirements while keeping the design simple and maintainable.

Handling Cross Business Object Transactions in RAP Using Actions

2026-04-16T12:34:56.887000+02:00

Introduction

In the SAP RAP, most examples focus on single Business Object (BO) operations. However, real-world enterprise applications rarely operate in isolation. A single business transaction often impacts multiple BOs—for example, creating a Delivery should trigger Billing, updating inventory, and possibly financial postings.
In this blog, we explore how to implement cross-BO interaction using RAP Actions, where:

A Delivery BO triggers creation in a Billing BO
Both operations are executed within the same LUW (Logical Unit of Work)
Data consistency is preserved using RAP’s transactional buffer

Business Scenario

Consider a typical Order-to-Cash process:

A Delivery is created for a customer.
Once the delivery is confirmed, a Billing document must be generated.
The system should:
- Automatically create a Billing record
- Update the Delivery status to DELIVERED
- Ensure both operations succeed or fail together

Implementation Steps

STEP 1: Create a Data base Table

Data base table For Delivery Details

@EndUserText.label : 'delivery details' 
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE 
@AbapCatalog.tableCategory : #TRANSPARENT 
@AbapCatalog.deliveryClass : #A 
@AbapCatalog.dataMaintenance : #RESTRICTED 
define table zte_t_delivery_s { 
key delivery_id : abap.char(10) not null; 
customer_id : abap.char(5); 
material : abap.char(20); 
price : abap.char(10); 
delivery_date : abap.dats; 
delivery_status : abap.char(15); 
}

Data Base table for Billing Details

@EndUserText.label : 'Billing Details' 
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE 
@AbapCatalog.tableCategory : #TRANSPARENT 
@AbapCatalog.deliveryClass : #A 
@AbapCatalog.dataMaintenance : #RESTRICTED 
define table zte_t_billing_s { 
key billing_id : abap.char(10) not null; 
customer_id : abap.char(5); 
delivery_id : abap.char(10); 
material : abap.char(20); 
price : abap.char(10); 
}

STEP 2: Create root CDS views for both tables

Root view For Delivery Details

@AccessControl.authorizationCheck: #NOT_REQUIRED 
@EndUserText.label: 'Delivery Details' 
@Metadata.ignorePropagatedAnnotations: true 
define root view entity ZI_T_DELIVERY_S as select from zte_t_delivery_s 
{ 
key delivery_id as DeliveryId, 
customer_id as CustomerId, 
material as Material, 
price as Price, 
delivery_date as DeliveryDate, 
delivery_status as DeliveryStatus 
}

Root view For Billing Details

@AccessControl.authorizationCheck: #NOT_REQUIRED 
@EndUserText.label: 'Billing Details' 
@Metadata.ignorePropagatedAnnotations: true 
define root view entity ZI_T_BILLING_S as select from zte_t_billing_s 
{ 
key billing_id as BillingId, 
customer_id as CustomerId, 
delivery_id as DeliveryId, 
material as Material, 
price as Price 
}

STEP 3: Create Projection View

Add UI Annotations
Add Action Button In Delivery Projection

Projection View For Delivery Details

@AccessControl.authorizationCheck: #NOT_REQUIRED 
@EndUserText.label: 'Delivery Details' 
@Metadata.ignorePropagatedAnnotations: true 
define root view entity ZC_T_DELIVERY_S 
provider contract transactional_query as projection on ZI_T_DELIVERY_S 
{ 
@UI.facet: [{ id: 'deliverdetails',  
position: 1,  
label: 'Order Details',  
type: #IDENTIFICATION_REFERENCE  
} ] 
@UI.lineItem: [ 
{ importance: #MEDIUM}, 
{ position: 10, type : #FOR_ACTION, label : 'Available', dataAction : 'create_delivery' }, 
{ position: 1, label : 'Delivery ID' }]  
@UI.identification: [{ position: 1, label : 'Delivery ID' }] 
key DeliveryId, 
@UI.lineItem: [{ position: 2, label : 'Customer ID' }]  
@UI.identification: [{ position: 2, label : 'Customer ID' }] 
CustomerId, 
@UI.lineItem: [{ position: 3, label : 'Material' }]  
@UI.identification: [{ position: 3, label : 'Material' }] 
Material, 
@UI.lineItem: [{ position: 4, label : 'Price' }]  
@UI.identification: [{ position: 4, label : 'Price' }] 
Price, 
@UI.lineItem: [{ position: 5, label : 'Delivery Date' }]  
@UI.identification: [{ position: 5, label : 'Delivery Date' }] 
DeliveryDate, 
@UI.lineItem: [{ position: 6, label : 'Delivery Status' }]  
@UI.identification: [{ position: 6, label : 'Delivery Status' }] 
DeliveryStatus 
}

Projection View for Billing Details

@AccessControl.authorizationCheck: #NOT_REQUIRED 
@EndUserText.label: 'Billing Details' 
@Metadata.ignorePropagatedAnnotations: true 
define root view entity ZC_T_BILLING_S 
provider contract transactional_query as projection on ZI_T_BILLING_S 
{ 
@UI.facet: [{ id: 'Billingdetails',  
position: 1,  
label: 'Billing Details',  
type: #IDENTIFICATION_REFERENCE  
} ] 
@UI.lineItem: [{ position: 1, label : 'Billing Id' }]  
@UI.identification: [{ position: 1, label : 'Billing Id' }] 
key BillingId, 
@UI.lineItem: [{ position: 2, label : 'Customer Id' }]  
@UI.identification: [{ position: 2, label : 'Custoomer Id' }] 
CustomerId, 
@UI.lineItem: [{ position: 3, label : 'Delivery Id' }]  
@UI.identification: [{ position: 3, label : 'Delivery Id' }] 
DeliveryId, 
@UI.lineItem: [{ position: 4, label : 'Material' }]  
@UI.identification: [{ position: 4, label : 'Material' }] 
Material, 
@UI.lineItem: [{ position: 5, label : 'Price' }]  
@UI.identification: [{ position: 5, label : 'Price' }] 
Price 
}

STEP 4: Define Behavior Definitions
Delivery BO behavior

Enable CRUD operation
Declare a non-factory action

This Action is responsible for creating Billing data and updating delivery status

managed implementation in class zbp_i_t_delivery_s unique; 
strict ( 2 ); 
define behavior for ZI_T_DELIVERY_S //alias <alias_name> 
persistent table zte_t_delivery_s 
lock master 
authorization master ( instance ) 
//etag master <field_name> 
{ 
create; 
update; 
delete; 
action create_delivery result [1] $self; 
mapping for zte_t_delivery_s 
{ 
DeliveryId = delivery_id; 
CustomerId = customer_id; 
Material = material; 
Price = price; 
DeliveryDate = delivery_date; 
DeliveryStatus = delivery_status; 
} 
}

Billing BO behavior

Enable CRUD operations
use Late Numbering for auto-generating Billing Id

managed implementation in class zbp_i_t_billing_s unique; 
strict ( 2 ); 
define behavior for ZI_T_BILLING_S //alias <alias_name> 
persistent table zte_t_billing_s 
lock master 
authorization master ( instance ) 
late numbering 
//etag master <field_name> 
{ 
create; 
update; 
delete; 

mapping for zte_t_billing_s 
{ 
BillingId = billing_id; 
DeliveryId = delivery_id; 
CustomerId = customer_id; 
Material = material; 
Price = price; 
} 
}

STEP 5: Define Projection behavior

Delivery BO projection behavior

projection; 
strict ( 2 ); 
define behavior for ZC_T_DELIVERY_S //alias <alias_name> 
{ 
use create; 
use update; 
use delete; 
use action create_delivery; 
}

Billing BO projection behavior

projection; 
strict ( 2 ); 
define behavior for ZC_T_BILLING_S //alias <alias_name> 
{ 
use create; 
use update; 
use delete; 
}

STEP 6: Implement Behavior Logic

Delivery Class

CLASS lhc_ZI_T_DELIVERY_S DEFINITION INHERITING FROM cl_abap_behavior_handler. 

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

METHODS create_delivery FOR MODIFY 
IMPORTING keys FOR ACTION zi_t_delivery_s~create_delivery RESULT result. 
ENDCLASS.
 
CLASS lhc_ZI_T_DELIVERY_S IMPLEMENTATION. 
METHOD get_instance_authorizations. 
ENDMETHOD. 

METHOD create_delivery. 
READ ENTITIES OF ZI_T_DELIVERY_S 
IN LOCAL MODE 
ENTITY ZI_T_DELIVERY_S 
FIELDS ( DeliveryId CustomerId Material Price ) 
WITH CORRESPONDING #( keys ) 
RESULT DATA(lt_delivery). 
LOOP AT lt_delivery INTO DATA(ls_delivery). 

"Create Billing Entry 
MODIFY ENTITIES OF ZI_T_BILLING_S 
ENTITY ZI_T_BILLING_S 
CREATE 
FIELDS ( DeliveryId CustomerId Material Price ) 
WITH VALUE #( 
( 
%cid = 'BILL1' 
DeliveryId = ls_delivery-DeliveryId 
CustomerId = ls_delivery-CustomerId 
Material = ls_delivery-Material 
Price = ls_delivery-Price 
) 
) 
FAILED DATA(ls_failed) 
REPORTED DATA(ls_reported). 

IF ls_failed IS NOT INITIAL. 
reported = CORRESPONDING #( ls_reported ). 
RETURN. 
ENDIF. 

"Update Delivery Status 
MODIFY ENTITIES OF ZI_T_DELIVERY_S 
IN LOCAL MODE 
ENTITY ZI_T_DELIVERY_S 
UPDATE FIELDS ( DeliveryStatus ) 
WITH VALUE #( 
( 
DeliveryId = ls_delivery-DeliveryId 
DeliveryStatus = 'DELIVERED' 
) 
). 
ENDLOOP.
ENDMETHOD. 
ENDCLASS.

Billing Class

CLASS lhc_ZI_T_BILLING_S DEFINITION INHERITING FROM cl_abap_behavior_handler. 
PRIVATE SECTION. 
METHODS get_instance_authorizations FOR INSTANCE AUTHORIZATION 
IMPORTING keys REQUEST requested_authorizations FOR zi_t_billing_s RESULT result. 
ENDCLASS. 

CLASS lhc_ZI_T_BILLING_S IMPLEMENTATION. 
METHOD get_instance_authorizations. 
ENDMETHOD. 
ENDCLASS. 

CLASS lsc_ZI_T_BILLING_S DEFINITION INHERITING FROM cl_abap_behavior_saver. 
PROTECTED SECTION. 
METHODS adjust_numbers REDEFINITION. 
METHODS cleanup_finalize REDEFINITION. 
ENDCLASS. 

CLASS lsc_ZI_T_BILLING_S IMPLEMENTATION. 
METHOD adjust_numbers. 
SELECT FROM ZTE_T_Billing_S FIELDS MAX( billing_id ) INTO (ls_mat_num). 
DATA(lv_num) = ls_mat_num+3(4). 
LOOP AT mapped-zi_t_billing_s ASSIGNING FIELD-SYMBOL(<fs_material>). 
lv_num += 1. 
<fs_material>-BillingId = |BIL{ lv_num ALPHA = IN WIDTH = 4 }|. 
ENDLOOP. 
ENDMETHOD. 
METHOD cleanup_finalize. 
ENDMETHOD. 
ENDCLASS.

STEP 7: Service Defination

Expose Both Behavior objects

@EndUserText.label: 'Delivery and billing details' 
define service ZSD_T_DETAILS { 
expose ZC_T_DELIVERY_S; 
expose ZC_T_BILLING_S; 
}

STEP 8 : Service Binding

create service binding
Activate and publish

STEP 9: RESULT

Create a record and click on the Action Button the delivery Status will be updated and Billing records will be created

Billing details when Action is trigged and Delivery status updated to Delivery

Conclusion

Cross Business Object operations in RAP are essential for building real-world enterprise applications. While RAP abstracts much of the complexity, designing such interactions requires a clear understanding of:

Transactional behavior
BO independence vs coordination
Framework-driven data consistency By leveraging RAP Actions and EML, we can safely orchestrate multi-BO updates without compromising on clean architecture or data integrity.

This example demonstrates how a simple Delivery trigger can drive Billing creation, showcasing a scalable pattern that can be extended to more complex business processes.