SAP Community - ABAP Development

CALL BAPI IN CUSTOM ENTITY THROUGH RAP

2025-12-09T11:29:06.943000+01:00

Hi RAP Developers, Good Day

Introduction:

In many business scenarios, we need to expose BAPI-based data to SAP Fiori applications without creating database tables or CDS-based persistency. With the RESTful ABAP Programming Model (RAP), this can be achieved efficiently using Custom Entities, which allow us to call ABAP logic directly—such as BAPIs—and return the data as an OData service.

In this blog, I will walk through how to build a Custom Entity that fetches bank details by calling a BAPI, how to annotate it for UI consumption, and how to expose it seamlessly to a Fiori Elements application. This approach is useful whenever you want to reuse existing BAPIs and business logic while keeping your RAP model clean, lightweight, and high-performing.

Solution Overview:

This solution demonstrates how RAP can seamlessly integrate with classic SAP functionality by exposing BAPI output through a Custom Entity. Instead of relying on database tables or CDS views, the Custom Entity acts as a virtual data source whose data is supplied dynamically via an ABAP class.

When a Fiori Elements UI requests the entity, RAP forwards the query to the ABAP implementation class. This class reads the query parameters (filters, sorting, pagination) and uses them to call BAPI_BANK_GETDETAIL. The BAPI returns the bank’s address, master data, and related details, which are then transformed into the response structure expected by the Custom Entity.

The result is an OData-based, read-only endpoint capable of delivering real-time data from a BAPI with full RAP features such as filtering, sorting, paging, and total count support. This approach makes it easy to modernize existing SAP data retrieval logic while still leveraging stable, proven BAPIs in the backend.

Custom Entity:

custom entity not underlying any data source.
data preview is not possible, becuase this should be implemented in seperate class.
suitable for paging,calling bapi's and external api's.

@EndUserText.label: 'Custom Entity calling bapi'
@ObjectModel: {
    query: {
        implementedBy: 'ABAP:ZCL_BAPI_BANK'
    }
}

@UI: {
    headerInfo: {
        typeName: 'Banks',
        typeNamePlural: 'Banks',
        title: { value: 'bank_ctry' },
        description: { value: 'bank_ctry' }
    }
}

@UI: {
    presentationVariant: [{
        sortOrder: [{
            by: 'bank_ctry',
            direction: #ASC
        }],
        visualizations: [{
            type: #AS_LINEITEM
        }]
    }]
}
define root custom entity ZCE_BANK
{
      .facet                : [
      {
          id      : 'Bank_data',
          purpose : #STANDARD,
          type    : #IDENTIFICATION_REFERENCE,
          label   : 'Bank Details',
          position: 10 }
      ]
      .lineItem             : [{ position: 10 }]
      .selectionField       : [{position: 10}]
      .identification       : [{position: 10}]
  key bank_ctry                : banks;
      .lineItem             : [{ position: 20 }]
      .selectionField       : [{position: 20}]
      .identification       : [{position: 20}]
  key bank_key                 : bankk;

      .lineItem             : [{ position: 30 }]
      .identification       : [{position: 30}]
      bank_name                : banka;

      .lineItem             : [{ position: 40 }]
      .identification       : [{position: 40}]
      street                   : stras_gp;

      .lineItem             : [{ position: 50 }]
      .identification       : [{position: 50}]
      city                     : ort01_gp;

      .lineItem             : [{ position: 60 }]
      .identification       : [{position: 60}]
      BANK_NO                  : bankl;

      .lineItem             : [{ position: 70 }]
      .identification       : [{position: 70}]
      CREAT_DATE               : erdat_bf;

      .lineItem             : [{ position: 80 }]
      .identification       : [{position: 80}]
      creator                  : ernam_bf;
}

Implementation:

CLASS ZCL_BAPI_BANK DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC .

  PUBLIC SECTION.
    " RAP interface for query implementation
    INTERFACES IF_RAP_QUERY_PROVIDER.
  PROTECTED SECTION.
  PRIVATE SECTION.
ENDCLASS.


CLASS ZCL_BAPI_BANK IMPLEMENTATION.

  METHOD IF_RAP_QUERY_PROVIDER~SELECT.

    "----------------------------------------------------------------------
    " Local type used to return data back to Custom Entity ZCE_BANK
    "----------------------------------------------------------------------
    TYPES: BEGIN OF TY_BANK_RESULT,
             BANK_CTRY  TYPE BANKS,
             BANK_KEY   TYPE BANKK,
             BANK_NAME  TYPE BANKA,
             STREET     TYPE STRAS_GP,
             CITY       TYPE ORT01_GP,
             BANK_NO    TYPE BANKL,
             CREAT_DATE TYPE ERDAT_BF,
             CREATOR    TYPE ERNAM_BF,
           END OF TY_BANK_RESULT.

    DATA: LT_RESULT  TYPE TABLE OF TY_BANK_RESULT,
          LS_RESULT  TYPE TY_BANK_RESULT,
          LS_ADDRESS TYPE BAPI1011_ADDRESS,
          LS_DETAIL  TYPE BAPI1011_DETAIL,
          LS_RETURN  TYPE BAPIRET2.

    " Proceed only if the consumer has requested data
    IF IO_REQUEST->IS_DATA_REQUESTED( ).

      "---------------------------------------------------------------
      " Read pagination details (TOP and SKIP)
      "---------------------------------------------------------------
      DATA(LV_TOP)  = IO_REQUEST->GET_PAGING( )->GET_PAGE_SIZE( ).
      DATA(LV_SKIP) = IO_REQUEST->GET_PAGING( )->GET_OFFSET( ).

      "---------------------------------------------------------------
      " Prepare ORDER BY clause based on sort request from UI
      "---------------------------------------------------------------
      DATA(LT_SORT) = IO_REQUEST->GET_SORT_ELEMENTS( ).
      DATA LV_ORDERBY TYPE STRING.

      IF LT_SORT IS NOT INITIAL.
        CLEAR LV_ORDERBY.

        LOOP AT LT_SORT INTO DATA(LS_SORT).
          IF SY-TABIX > 1.
            LV_ORDERBY = |{ LV_ORDERBY }, |.
          ENDIF.

          " Construct ORDER BY element (ASCENDING/DESCENDING)
          LV_ORDERBY =
            |{ LV_ORDERBY }{ LS_SORT-ELEMENT_NAME } {
               COND #( WHEN LS_SORT-DESCENDING = ABAP_TRUE
                       THEN 'DESCENDING'
                       ELSE 'ASCENDING' ) }|.
        ENDLOOP.
      ENDIF.

      "---------------------------------------------------------------
      " Derive SQL filter string from UI filter (if any)
      "---------------------------------------------------------------
      DATA(lv_conditions) = io_request->get_filter( )->get_as_sql_string( ).

      "---------------------------------------------------------------
      " Read bank master records (BNKA) based on filters
      "---------------------------------------------------------------
      SELECT BANKS AS bank_ctry,
             BANKL AS bank_key,
             BNKLZ AS bank_no,
             ERDAT AS creat_date,
             ERNAM AS creator
        FROM BNKA
        WHERE (lv_conditions)
        ORDER BY (lv_orderby)
        INTO TABLE @DATA(lt_banks)
        UP TO @LV_top ROWS
        OFFSET @LV_skip.

      "---------------------------------------------------------------
      " Loop through each BNKA record and enrich details using BAPI
      "---------------------------------------------------------------
      LOOP AT lt_banks INTO DATA(ls_bank).

        " Get detailed bank address info
        CALL FUNCTION 'BAPI_BANK_GETDETAIL'
          EXPORTING
            bankcountry  = ls_bank-bank_ctry
            bankkey      = ls_bank-bank_key
          IMPORTING
            bank_address = ls_address
            bank_detail  = ls_detail
            return       = ls_return.

        " Prepare output row
        LS_RESULT-bank_ctry   = ls_bank-bank_ctry.
        LS_RESULT-bank_key    = ls_bank-bank_key.
        LS_RESULT-bank_name   = ls_address-bank_name.
        LS_RESULT-street      = ls_address-street.
        LS_RESULT-city        = ls_address-city.
        LS_RESULT-bank_no     = ls_bank-bank_no.
        LS_RESULT-creat_date  = ls_bank-creat_date.
        LS_RESULT-creator     = ls_bank-creator.

        APPEND LS_RESULT TO LT_RESULT.

        CLEAR: ls_result, ls_address, ls_detail, ls_return.

      ENDLOOP.

      "---------------------------------------------------------------
      " Return total count for UI pagination (if requested)
      "---------------------------------------------------------------
      IF IO_REQUEST->IS_TOTAL_NUMB_OF_REC_REQUESTED( ).
        SELECT COUNT(*)
          FROM BNKA
          WHERE (lv_conditions)
          INTO @DATA(lv_count).

        IO_RESPONSE->SET_TOTAL_NUMBER_OF_RECORDS( lv_count ).
      ENDIF.

      "---------------------------------------------------------------
      " Send final result back to RAP framework
      "---------------------------------------------------------------
      IO_RESPONSE->SET_DATA( LT_RESULT ).

    ENDIF.

  ENDMETHOD.

ENDCLASS.

Conclusion:
this approach highlights how RAP can modernize SAP applications by exposing classic BAPI data through Custom Entities. It enables real-time, read-only access with full OData capabilities—filtering, sorting, paging—without changing existing backend logic, bridging the gap between proven SAP functionality and modern Fiori UIs.
Thanks For Reading, Best Wishes

Date Hierarchy Using Tree ALV(FM & OOPS )

2025-12-09T11:37:56.809000+01:00

Hi Everyone

Introduction:

The user needs an interactive Date Hierarchy display in SAP that provides a structured view of years, months, and individual dates.This helps users quickly navigate through large date ranges and select specific dates for downstream operations such as data extraction, reporting, or analysis.

Solution Overview:

The screen should display a hierarchical Tree ALV titled “DATE HIERARCHY”.
The top-level nodes represent Years (e.g., 2021 to 2025).
When the user expands a Year, the 12 months (January to December) are displayed as child nodes.
When the user expands a Month, all valid calendar dates for that month are dynamically generated and displayed.
Each date node should display the date in user’s local format (DD.MM.YYYY).
The user should be able to:
- Expand/collapse nodes dynamically.
- View all levels of hierarchy.

TABLES : BKPF.

"Internal table and work area for tree nodes
DATA: IT_NODE TYPE TABLE OF SNODETEXT,
      WA_NODE TYPE SNODETEXT.

"Variables for Year, Month, Date calculations
DATA: LV_YEAR  TYPE GJAHR,
      LV_MONTH TYPE NUMC2,
      LV_DATE  TYPE DATUM,
      LV_DAYS  TYPE I,
      LV_DAY   TYPE NUMC2.

"Keys for hierarchy levels
DATA: LV_YEAR_KEY  TYPE CHAR10,
      LV_MONTH_KEY TYPE CHAR15,
      LV_DATE_KEY  TYPE CHAR20.

"Selection range for fiscal year
SELECT-OPTIONS: S_GJAHR FOR BKPF-GJAHR DEFAULT '2021' TO '2025'.

START-OF-SELECTION.

  CLEAR: WA_NODE, IT_NODE.

"------------------------------------------------------------"
" Root Node Creation                                         "
"------------------------------------------------------------"
WA_NODE-TYPE    = 'T'.             "Tree title
WA_NODE-NAME    = 'DATE HIERARCHY'.
WA_NODE-TLEVEL  = '01'.
WA_NODE-NLENGTH = '18'.
WA_NODE-COLOR   = '05'.
APPEND WA_NODE TO IT_NODE.
CLEAR WA_NODE.

"------------------------------------------------------------"
" Build Year → Month → Date Hierarchy                       "
"------------------------------------------------------------"
LOOP AT S_GJAHR.
  DO.
    "Loop through each year within the selected range
    LV_YEAR = S_GJAHR-LOW + SY-INDEX - 1.
    IF LV_YEAR > S_GJAHR-HIGH.
      EXIT.
    ENDIF.

    "--------------------------------------------------------"
    " Year Node (Level 02)                                   "
    "--------------------------------------------------------"
    LV_YEAR_KEY = LV_YEAR.
    WA_NODE-TYPE    = 'P'.
    WA_NODE-ID      = LV_YEAR_KEY.
    CONCATENATE LV_YEAR ' ' INTO WA_NODE-NAME SEPARATED BY SPACE.
    WA_NODE-TLEVEL  = '02'.
    WA_NODE-NLENGTH = STRLEN( WA_NODE-NAME ).
    WA_NODE-COLOR   = '03'.
    APPEND WA_NODE TO IT_NODE.
    CLEAR WA_NODE.

    "--------------------------------------------------------"
    " 12 Months Loop (Level 03)                              "
    "--------------------------------------------------------"
    DO 12 TIMES.
      LV_MONTH = SY-INDEX.
      CONCATENATE LV_YEAR_KEY LV_MONTH INTO LV_MONTH_KEY.

      WA_NODE-TYPE = 'P'.
      WA_NODE-ID   = LV_MONTH_KEY.

      "Month Name Assignment"
      CASE LV_MONTH.
        WHEN '01'. WA_NODE-NAME = 'January'.
        WHEN '02'. WA_NODE-NAME = 'February'.
        WHEN '03'. WA_NODE-NAME = 'March'.
        WHEN '04'. WA_NODE-NAME = 'April'.
        WHEN '05'. WA_NODE-NAME = 'May'.
        WHEN '06'. WA_NODE-NAME = 'June'.
        WHEN '07'. WA_NODE-NAME = 'July'.
        WHEN '08'. WA_NODE-NAME = 'August'.
        WHEN '09'. WA_NODE-NAME = 'September'.
        WHEN '10'. WA_NODE-NAME = 'October'.
        WHEN '11'. WA_NODE-NAME = 'November'.
        WHEN '12'. WA_NODE-NAME = 'December'.
      ENDCASE.

      WA_NODE-TLEVEL  = '03'.
      WA_NODE-NLENGTH = STRLEN( WA_NODE-NAME ).
      WA_NODE-COLOR   = '04'.
      APPEND WA_NODE TO IT_NODE.
      CLEAR WA_NODE.

      "------------------------------------------------------"
      " Determine number of days in the month                "
      "------------------------------------------------------"
      CONCATENATE LV_YEAR LV_MONTH '01' INTO LV_DATE.
      CALL FUNCTION 'SLS_MISC_GET_LAST_DAY_OF_MONTH'
        EXPORTING
          DAY_IN            = LV_DATE
        IMPORTING
          LAST_DAY_OF_MONTH = LV_DATE.

      LV_DAYS = LV_DATE+6(2). "Extract day part → last day of month

      "------------------------------------------------------"
      " Date Nodes (Level 04)                                "
      "------------------------------------------------------"
      DO LV_DAYS TIMES.
        LV_DAY = SY-INDEX.
        CONCATENATE LV_YEAR LV_MONTH LV_DAY INTO LV_DATE_KEY.

        WA_NODE-TYPE    = 'P'.
        WA_NODE-ID      = LV_DATE_KEY.
        CONCATENATE LV_DAY '.' LV_MONTH '.' LV_YEAR INTO WA_NODE-NAME.
        WA_NODE-TLEVEL  = '04'.
        WA_NODE-NLENGTH = STRLEN( WA_NODE-NAME ).
        WA_NODE-COLOR   = '06'.
        APPEND WA_NODE TO IT_NODE.
        CLEAR WA_NODE.

      ENDDO.

    ENDDO.

  ENDDO.
ENDLOOP.

"------------------------------------------------------------"
" Display the Tree Output                                    "
"------------------------------------------------------------"
CALL FUNCTION 'RS_TREE_CONSTRUCT'
  TABLES
    NODETAB = IT_NODE.

CALL FUNCTION 'RS_TREE_LIST_DISPLAY'
  EXPORTING
    CALLBACK_PROGRAM = SY-REPID.

Output:

OOPS Approach:

TABLES: MARA, BKPF.

*---------------------------------------------------------------------*
* Data Declarations
*---------------------------------------------------------------------*
"ALV Tree objects
DATA: GO_TREE      TYPE REF TO CL_GUI_ALV_TREE,
      GO_CONTAINER TYPE REF TO CL_GUI_CUSTOM_CONTAINER.

"ALV field catalog and layout
DATA: GT_FIELDCAT TYPE LVC_T_FCAT,
      GS_FIELDCAT TYPE LVC_S_FCAT,
      GS_LAYOUT   TYPE LVC_S_LAYO.

"Output structure for tree text
TYPES: BEGIN OF TY_OUTPUT,
         COLUMN1 TYPE CHAR255,  "Single text column for tree nodes
       END OF TY_OUTPUT.

DATA: GT_OUTPUT TYPE TABLE OF TY_OUTPUT,
      GS_OUTPUT TYPE TY_OUTPUT.

"Variables used for Year → Month → Date hierarchy
DATA: LV_YEAR       TYPE GJAHR,
      LV_MONTH      TYPE NUMC2,
      LV_DATE       TYPE DATUM,
      LV_LAST_DATE  TYPE DATUM,
      LV_DAYS       TYPE I,
      LV_DAY        TYPE NUMC2,
      LV_YEAR_KEY   TYPE LVC_NKEY,
      LV_MONTH_KEY  TYPE LVC_NKEY,
      LV_DATES_LINE TYPE STRING.

"Node layout (folder / item)
DATA: LS_NODE_LAYOUT TYPE LVC_S_LAYN.

"Year range for hierarchy
SELECT-OPTIONS: S_GJAHR FOR BKPF-GJAHR DEFAULT '2021' TO '2025'.

*---------------------------------------------------------------------*
* Selection Screen Trigger
*---------------------------------------------------------------------*
START-OF-SELECTION.
  CALL SCREEN 100.  "Call main screen

*---------------------------------------------------------------------*
* PBO: Set status and create tree
*---------------------------------------------------------------------*
MODULE STATUS_0100 OUTPUT.
  SET PF-STATUS 'ZSTANDARD'.

  "Create the tree only once
  IF GO_CONTAINER IS INITIAL.
    PERFORM CREATE_AND_FILL_TREE.
  ENDIF.
ENDMODULE.

*---------------------------------------------------------------------*
* PAI: Handle user commands
*---------------------------------------------------------------------*
MODULE USER_COMMAND_0100 INPUT.
  CASE SY-UCOMM.
    WHEN 'BACK' OR 'EXIT' OR 'CANCEL'.
      "Release frontend controls
      PERFORM FREE_RESOURCES.
      LEAVE TO SCREEN 0.
  ENDCASE.
ENDMODULE.

*---------------------------------------------------------------------*
* Create container, tree control, root node and load hierarchy
*---------------------------------------------------------------------*
FORM CREATE_AND_FILL_TREE.

  "Create custom container inside screen element 'CONTAINER'
  CREATE OBJECT GO_CONTAINER
    EXPORTING
      CONTAINER_NAME = 'CONTAINER'.

  "Build ALV field catalog
  PERFORM BUILD_FIELDCAT.

  "Create ALV tree control
  CREATE OBJECT GO_TREE
    EXPORTING
      PARENT              = GO_CONTAINER
      NODE_SELECTION_MODE = CL_GUI_COLUMN_TREE=>NODE_SEL_MODE_SINGLE
      ITEM_SELECTION      = 'X'
    EXCEPTIONS
      OTHERS              = 1.

  "Bind output table and field catalog to tree
  CALL METHOD GO_TREE->SET_TABLE_FOR_FIRST_DISPLAY
    CHANGING
      IT_OUTTAB       = GT_OUTPUT
      IT_FIELDCATALOG = GT_FIELDCAT.

  "---------------------------------------------------------------*
  " Create Root Node (DATE HIERARCHY)
  "---------------------------------------------------------------*
  CLEAR: LS_NODE_LAYOUT, GS_OUTPUT.
  LS_NODE_LAYOUT-ISFOLDER  = 'X'.
  LS_NODE_LAYOUT-N_IMAGE   = '@AV@'.
  LS_NODE_LAYOUT-EXP_IMAGE = '@AV@'.
  GS_OUTPUT-COLUMN1        = 'DATE HIERARCHY'.

  "Add root node
  CALL METHOD GO_TREE->ADD_NODE
    EXPORTING
      I_RELAT_NODE_KEY = ''  "Root level
      I_RELATIONSHIP   = CL_GUI_COLUMN_TREE=>RELAT_LAST_CHILD
      IS_OUTTAB_LINE   = GS_OUTPUT
      IS_NODE_LAYOUT   = LS_NODE_LAYOUT
    IMPORTING
      E_NEW_NODE_KEY   = LV_YEAR_KEY.

  "Build full tree under root node
  PERFORM BUILD_TREE_NODES USING LV_YEAR_KEY.

  "Auto-expand root node
  CALL METHOD GO_TREE->EXPAND_NODE
    EXPORTING
      I_NODE_KEY = LV_YEAR_KEY.

  CALL METHOD GO_TREE->FRONTEND_UPDATE.

ENDFORM.

*---------------------------------------------------------------------*
* Create field catalog for ALV tree
*---------------------------------------------------------------------*
FORM BUILD_FIELDCAT.
  CLEAR GS_FIELDCAT.
  GS_FIELDCAT-FIELDNAME = 'COLUMN1'.
  GS_FIELDCAT-COLTEXT   = 'Description'.
  GS_FIELDCAT-OUTPUTLEN = 255.
  APPEND GS_FIELDCAT TO GT_FIELDCAT.
ENDFORM.

*---------------------------------------------------------------------*
* Build YEAR → MONTH → DAY hierarchy inside ALV Tree
*---------------------------------------------------------------------*
FORM BUILD_TREE_NODES USING IV_ROOT_KEY TYPE LVC_NKEY.

  DATA: LV_PARENT_YEAR  TYPE LVC_NKEY,
        LV_PARENT_MONTH TYPE LVC_NKEY,
        LV_MONTH_NAME   TYPE STRING,
        LV_CHUNK        TYPE STRING,
        LV_CHUNK_COUNT  TYPE I,
        GV_GROUP_SIZE   TYPE I VALUE 10,  "Group 10 days per line
        LV_DATE_STRING  TYPE STRING.

  "Loop through selected year range
  LOOP AT S_GJAHR.
    DO.
      LV_YEAR = S_GJAHR-LOW + SY-INDEX - 1.
      IF LV_YEAR > S_GJAHR-HIGH.
        EXIT.
      ENDIF.

      "---------------------------------------------------------------*
      " Create YEAR Node
      "---------------------------------------------------------------*
      CLEAR: LS_NODE_LAYOUT, GS_OUTPUT.
      LS_NODE_LAYOUT-ISFOLDER  = 'X'.
      LS_NODE_LAYOUT-N_IMAGE   = '@AV@'.
      LS_NODE_LAYOUT-EXP_IMAGE = '@AV@'.
      GS_OUTPUT-COLUMN1        = |Year: { LV_YEAR }|.

      CALL METHOD GO_TREE->ADD_NODE
        EXPORTING
          I_RELAT_NODE_KEY = IV_ROOT_KEY      "Attach to root
          I_RELATIONSHIP   = CL_GUI_COLUMN_TREE=>RELAT_LAST_CHILD
          IS_OUTTAB_LINE   = GS_OUTPUT
          IS_NODE_LAYOUT   = LS_NODE_LAYOUT
        IMPORTING
          E_NEW_NODE_KEY   = LV_PARENT_YEAR.

      "---------------------------------------------------------------*
      " Create MONTH Nodes under each Year
      "---------------------------------------------------------------*
      DO 12 TIMES.
        LV_MONTH = SY-INDEX.

        "Month name mapping
        CASE LV_MONTH.
          WHEN 1.  LV_MONTH_NAME = 'January'.
          WHEN 2.  LV_MONTH_NAME = 'February'.
          WHEN 3.  LV_MONTH_NAME = 'March'.
          WHEN 4.  LV_MONTH_NAME = 'April'.
          WHEN 5.  LV_MONTH_NAME = 'May'.
          WHEN 6.  LV_MONTH_NAME = 'June'.
          WHEN 7.  LV_MONTH_NAME = 'July'.
          WHEN 8.  LV_MONTH_NAME = 'August'.
          WHEN 9.  LV_MONTH_NAME = 'September'.
          WHEN 10. LV_MONTH_NAME = 'October'.
          WHEN 11. LV_MONTH_NAME = 'November'.
          WHEN 12. LV_MONTH_NAME = 'December'.
        ENDCASE.

        CLEAR: LS_NODE_LAYOUT, GS_OUTPUT.
        LS_NODE_LAYOUT-ISFOLDER  = 'X'.
        LS_NODE_LAYOUT-N_IMAGE   = '@2L@'.
        LS_NODE_LAYOUT-EXP_IMAGE = '@2L@'.
        GS_OUTPUT-COLUMN1        = LV_MONTH_NAME.

        "Add Month node
        CALL METHOD GO_TREE->ADD_NODE
          EXPORTING
            I_RELAT_NODE_KEY = LV_PARENT_YEAR
            I_RELATIONSHIP   = CL_GUI_COLUMN_TREE=>RELAT_LAST_CHILD
            IS_OUTTAB_LINE   = GS_OUTPUT
            IS_NODE_LAYOUT   = LS_NODE_LAYOUT
          IMPORTING
            E_NEW_NODE_KEY   = LV_PARENT_MONTH.

        "-----------------------------------------------------------*
        " Determine last day of month
        "-----------------------------------------------------------*
        CONCATENATE LV_YEAR LV_MONTH '01' INTO LV_DATE.
        CALL FUNCTION 'LAST_DAY_OF_MONTHS'
          EXPORTING
            DAY_IN            = LV_DATE
          IMPORTING
            LAST_DAY_OF_MONTH = LV_LAST_DATE.

        LV_DAYS = LV_LAST_DATE+6(2).  "Extract number of days

        "-----------------------------------------------------------*
        " Add DAY Nodes grouped (10 days per node)
        "-----------------------------------------------------------*
        CLEAR: LV_CHUNK, LV_CHUNK_COUNT.

        DO LV_DAYS TIMES.
          LV_DAY = SY-INDEX.

          "Format date string: DD.MM.YYYY
          LV_DATE_STRING = |{ LV_DAY WIDTH = 2 }.{ LV_MONTH WIDTH = 2 }.{ LV_YEAR }|.

          "Build chunk of 10 dates
          IF LV_CHUNK IS INITIAL.
            LV_CHUNK = LV_DATE_STRING.
          ELSE.
            CONCATENATE LV_CHUNK LV_DATE_STRING INTO LV_CHUNK SEPARATED BY SPACE.
          ENDIF.

          ADD 1 TO LV_CHUNK_COUNT.

          "Add one group node after every 10 days OR last day
          IF LV_CHUNK_COUNT >= GV_GROUP_SIZE OR LV_DAY = LV_DAYS.

            CLEAR: LS_NODE_LAYOUT, GS_OUTPUT.
            LS_NODE_LAYOUT-ISFOLDER = ''.   "Leaf node
            LS_NODE_LAYOUT-N_IMAGE  = '@3C@'.
            GS_OUTPUT-COLUMN1       = LV_CHUNK.

            "Add day-chunk node
            CALL METHOD GO_TREE->ADD_NODE
              EXPORTING
                I_RELAT_NODE_KEY = LV_PARENT_MONTH
                I_RELATIONSHIP   = CL_GUI_COLUMN_TREE=>RELAT_LAST_CHILD
                IS_OUTTAB_LINE   = GS_OUTPUT
                IS_NODE_LAYOUT   = LS_NODE_LAYOUT.

            CLEAR: LV_CHUNK, LV_CHUNK_COUNT.
          ENDIF.
        ENDDO.

      ENDDO.  "End Month Loop

    ENDDO.
  ENDLOOP.

ENDFORM.

*---------------------------------------------------------------------*
* Release frontend controls
*---------------------------------------------------------------------*
FORM FREE_RESOURCES.
  IF GO_TREE IS BOUND.
    CALL METHOD GO_TREE->FREE.
    FREE GO_TREE.
  ENDIF.

  IF GO_CONTAINER IS BOUND.
    CALL METHOD GO_CONTAINER->FREE.
    FREE GO_CONTAINER.
  ENDIF.
ENDFORM.

Conclusion:
This solution showcases a practical and user-friendly way to visualize date structures by building a dynamic Year–Month–Day hierarchy using the ALV Tree control. By grouping daily entries and leveraging container-based GUI elements, the approach delivers a clean, scalable, and intuitive navigation experience. It also demonstrates how classic ABAP techniques—selection screens, tree controls, and month/day calculations—can be combined to create interactive UI components that enhance data exploration within SAP GUI.

Collective Value Helps in RAP: V2 and V4 Implementation Guide - Part 2

2025-12-09T15:35:14.655000+01:00

In Part 1 of this series, we explored the fundamentals of Collective Value Helps in RAP, covering implementation patterns across OData V2 and V4 service bindings. The community response has been overwhelming, with particular interest in hierarchical implementations for complex business scenarios.

While CDS hierarchies are extensively documented in the SAP ecosystem and widely used for representing parent-child relationships across business objects, a critical implementation gap exists: there are virtually no practical examples of incorporating hierarchical display patterns within Collective Value Helps. Part 2 bridges this gap by demonstrating how to seamlessly integrate hierarchical search templates into the collective value help framework we built in Part 1.

Watch the demonstration video below to see hierarchical value helps in action, including how they work alongside existing flat list search templates, in a Collective Value Help:

System Requirements

**Hierarchical Value Help Dialogs require: **

**SAP S/4HANA Cloud**
--Minimum Release: 2311
--Protocol: OData V4 service binding

**SAP S/4HANA On-Premise/Private Edition: **
--Minimum Release : S/4HANA 2025 onwards
--Protocol: OData V4 service binding

**Important: ** OData V2 does not support hierarchical visualization out of the box via CDS Hierarchy due to protocol limitations. CDS hierarchical patterns require OData V4.

CDS Hierarchies: Foundation for Hierarchical Value Helps

CDS (Core Data Services) hierarchies are well-established patterns in the SAP landscape for representing parent-child relationships. SAP provides comprehensive documentation and numerous community resources for learning hierarchy fundamentals:

This article focuses specifically on utilizing CDS hierarchies within RAP-compliant value helps and demonstrating how to incorporate hierarchical search templates alongside the flat templates created in Part 1.

Key Use Case: Hierarchies are particularly powerful in domains like Asset Management, where technical objects form complex parent-child structures that users need to navigate when making selections.

Business Context: Asset Management-> Hierarchical Relationships

In Asset Management, technical objects naturally form hierarchical structures that reflect real-world installations and organizational relationships:

Functional Location Hierarchies:

Parent functional locations contain child functional locations
Example: TATM → TATM-UT3 → TATM-UT3-001
Represents physical plant structure and organizational grouping

Equipment Hierarchies:

Equipment can be installed under functional locations
Equipment can be installed under other equipment (sub-assemblies)
Example: Main equipment (11947458) contains sub-equipment (11947627)

Mixed Hierarchies:

Equipment installed at functional locations
Sub-equipment installed under main equipment
Creates complex parent-child navigation requirements

A sample Hierarchy in Asset Management:

Transaction: IH01 - Structure List

Why Hierarchical Value Helps Matter:

When users select technical objects in business processes (work orders, maintenance notifications, asset transfers), they need to:

Understand the installation hierarchy
Navigate parent-child relationships visually
Select objects while seeing their organizational context
Identify relationships between equipment and functional locations

Standard flat list value helps lose this critical hierarchical context, making object selection difficult and error-prone in complex asset structures.

Implementation: Building the Hierarchical VDM Model

Step 1: Interface View (I-View) with Parent Association

The foundation of any CDS hierarchy is a self-association that establishes the parent-child relationship.

I-View

Critical Elements:

Self-Association _ParentNode: Establishes the many-to-one parent relationship
Cardinality [0..1]: Each node has either zero (root) or one parent
Join Condition: Links child's SuperiorTechnicalObject to parent's TechnicalObject

This I-View serves as the data foundation, providing the parent-child relationship that the hierarchy view will consume.

Step 2: Hierarchy View Definition

The hierarchy view transforms the I-View's parent association into an actual hierarchical structure with defined traversal rules.

Hierarchy View

Critical Hierarchy Annotations:

source ZAR_I_TechObjHierarchy: References the I-View containing the parent association
child to parent association _ParentNode: Specifies which association defines the hierarchy
start where SuperiorTechnicalObject is initial: Defines root nodes (no parent = top of hierarchy)
siblings order by TechnicalObject: Sorts nodes at the same level
multiple parents not allowed: Enforces strict tree structure (each node has max one parent)

This hierarchy view establishes the traversal logic and structural rules for displaying the parent-child relationships.

Step 3: Consumption (C-View) Definition

The consumption view serves as the bridge between the CDS hierarchy and the collective value help framework. It exposes the hierarchy as a searchable value help provider while maintaining the hierarchical data structure.

C-View

Critical Annotations:

@ObjectModel.supportedCapabilities
#VALUE_HELP_PROVIDER: Enables this view to provide value help data
#SEARCHABLE_ENTITY: Allows search functionality within the value help dialog
These capabilities are essential for user interaction
@odata.hierarchy.recursiveHierarchy: [{ entity.name: 'ZAR_I_TechObjHierarchyView' }]
THE CRITICAL HIERARCHICAL LINK
Note: The entity name should reference the Hierarchy View (from Step 2), not the I-View or C-View itself.
Points to the CDS hierarchy view created in Step 2
Instructs OData V4 service to use hierarchical structure
Without this annotation, hierarchy won't display in value help
association of many to one ... as _ParentNode
Recreates the parent association in the consumption layer
Must match the join conditions from the I-View
Required for OData V4 hierarchy metadata generation
Links both TechnicalObject AND TechObjIsEquipOrFuncnLoc (composite key)

Step 4: Including Hierarchical Template in Collective Value Help

Now we integrate the hierarchical search template into our existing collective value help framework from Part 1:

CVH V2 Metadata Extension

CVH V4 Metadata Extension

Service Definition

OData V2 Service Binding: The Limitation

Service Binding OData V2

This eliminates the possibility of incorporating hierarchical search templates via CDS hierarchy in V2 collective value helps. OData V2's protocol limitations prevent hierarchy visualization in value help dialogs

OData V4 Service Binding: The Solution Path

Service Binding OData V4

The V4 service binding successfully exposes the hierarchical template without errors.

The Problem - Flat List Display

Even with a properly defined hierarchy view exposed in V4, the initial preview reveals an unexpected result:

Flat List Display (as opposed to expected Hierarchical display)

The Problem:
Despite having a hierarchical CDS view, the value help displays data as a flat list without any parent-child visualization. Users see individual records but lose all hierarchical context.

Why This Happens:
Creating a CDS hierarchy view is necessary but not sufficient for hierarchical display in value helps. The RAP framework requires explicit UI presentation instructions to render hierarchy in the value help dialog.

The Missing Piece: The framework needs explicit instructions via presentation variant annotations to understand that this data should be rendered as a hierarchy tree, not a flat table. Without these annotations, OData V4 treats the hierarchy view as just another data source.

The Solution - Presentation Variant Annotations
To provision hierarchical display in value helps, we must add specific presentation variant annotations that declare hierarchical visualization intent.

Consumption View (C-View) Annotations

C-View (Presentation Variant Added)

A presentation variant annotation needs to be included here which will contain the InitialExpansionLevel for the hierarchy and a property RecursiveHierarchyQualifier.

RecursiveHierarchyQualifier - This annotation contains a string with the name of the hierarchy view and make possible that the data is then shown on UI as tree table. The projection view should also have the annotation

InitialExpansionLevel - This annotation indicates up to which level a display hierarchy shall be initially expanded.

Collective Value Help Metadata Extension

CVH V4 Metadata Extension (Presentation Variant annotation added)

A presentationVariantQualifier annotation needs to be included here, which should've the same value as the Qualifier in the C-View, i.e., 'HIERARCHY', in this case. This annotation indicates how the value help result should be displayed.

The Result: Hierarchical Value Help in Action

Hierarchical value help display

Success! The hierarchical variant now displays:

Parent-child relationships visualized as tree structure
Expand/collapse controls for navigation
Indentation showing hierarchy levels
Seamless integration with flat templates from Part 1
Full hierarchy traversal in value help dialog

User Experience - End Users can now:

Switch between flat and hierarchical search templates
Navigate parent-child relationships visually
Expand/collapse hierarchy nodes and even the entire Tree View
Select objects while understanding their organizational context
See equipment installation hierarchies and functional location structures

Key Takeaways: When to Use Hierarchical Collective Value Helps

Use Hierarchical Patterns When:

Parent-Child Relationships Matter: Business objects naturally form hierarchies (org structures, location hierarchies etc)
Context Aids Selection: Users need to see relationships to make correct selections
Navigation is Important: Users need to browse up/down hierarchies during selection
OData V4 is Available: V2 protocol does not support hierarchy visualization

Implementation Checklist:

Define I-View with self-association (_ParentNode)
Create hierarchy view with traversal rules (start where, siblings order by)
Use OData V4 service binding (V2 not supported)
Add presentation variant in C-View
Reference presentation variant in CVH metadata extension
Test expand/collapse and hierarchy navigation

Key Implementation points:

Cardinality Enforcement: multiple parents not allowed ensures tree structure
Root Node Definition: start where clause correctly identifies top-level nodes
Presentation Variant annotation must be added in C-View and CVH metadata
Qualifier Consistency: Same qualifier in C-View and CVH metadata

Series Conclusion
This two-part series has explored the complete spectrum of collective value helps in RAP:
Part 1 established the foundation:

Basic collective value help concepts and structure
Implementation across OData V2 and V4 service bindings
Service binding architectural differences
Nested value help workarounds
Multi-dimensional search capabilities

Part 2 extended to advanced patterns:

Hierarchical CDS view construction
VDM model for hierarchy-enabled value helps
OData V2 protocol limitations
Presentation variant configuration for hierarchy visualization
Seamless integration of flat and hierarchical search templates

Together, these patterns enable user-centric, multi-criteria search capabilities that leverage RAP's full value help framework while maintaining clean architectural separation and reusability.

Key Architectural Insight:
Collective value helps in RAP provide a powerful, user-centric approach to value help management by enabling multi-criteria search through a single, reusable model. The addition of hierarchical display patterns extends this capability to complex business scenarios requiring parent-child navigation—delivering a comprehensive search experience that adapts to diverse user needs.

Conclusion
Hierarchical collective value helps represent the convergence of RAP's value help framework with CDS hierarchy capabilities, enabling rich, context-aware search experiences for complex business objects. While implementation requires careful attention to presentation variant configuration and V4 protocol requirements, the result is a powerful pattern applicable across any SAP domain where parent-child relationships drive user decision-making.
Whether you're building asset management applications, organizational hierarchies, material master navigation, or any scenario requiring hierarchical context during selection, this pattern provides the foundation for delivering intuitive, efficient user experiences.
The combination of CDS hierarchies, collective value helps, and RAP's presentation variant framework creates a powerful combination for solving complex data selection challenges-no custom coding required, just optimal usage of key annotations.
Thank you for following this two-part series. I welcome your feedback, and experiences implementing collective value helps in your own RAP applications.

You Are Standing in an Open Field... Inside SAP GUI

2025-12-09T17:51:44.456000+01:00

How I ported Zork to ABAP in one day and made 46-year reunion of two mainframe legends possible.

1979 was quite a year for the mainframe: In Germany, SAP released R/2, the integrated ERP system that would define enterprise computing. In Massachusetts, Infocom was founded to commercialize Zork, the text adventure born on MIT's PDP-10 mainframes.

For 46 years, they ran on parallel tracks. Until last month.

Microsoft released the original source code for Zork I. The stars aligned. It was time for a family reunion.

I got nostalgic. I wanted to play Zork I: The Great Underground Empire. But I didn't want to play it in a browser or a terminal. I wanted to play it where I spend my time: In SAP GUI.

So, I decided to port the Z-Machine (Infocom's Virtual Machine) into SAP S/4HANA.

The Z-Namespace destiny... you knew it. In SAP development, every custom object must start with the letter Z: (Also Y, but Y is not used widely. And no one knows why Y is not used)

The Machine: Z-Machine.
The Transaction: ZORK.
The Package: $ZORK.

So it felt like it was meant to be here.

Building a VM in One Day (The "How")

"Alice," you say, "Writing a Virtual Machine in ABAP takes weeks of reading bit-level specs."

It took one day.

And I wrote almost none of it:

ZORK T-CODE in SAP GUI

99% Vibe coded

I used VSP (Vibing-Steampunk) — my open-source bridge that gives Claude (or Copilot/Codex/Mistral Vibe - any other Assistant) direct access to the SAP system via MCP. I treated the AI not as a chatbot, but as a Senior ABAP Developer who loves retro specs.

Here is what happened when my Z-Machine crashed on the first turn:

Me: "It crashes when I try to LOOK. Plz debug."

Claude didn't guess. Using VSP, Claude:

Set a breakpoint in the ABAP code.
Ran the game inside SAP.
Inspected the memory (finding a Big-Endian vs Little-Endian mismatch in the object table).
Fixed the code.

This isn't just generating text. This is Digital Archaeology assisted by Artificial Intelligence.

Why This Matters

I now have Zork running in S/4HANA.

But the real story isn't the game. It's the capability.

If an AI agent can read a 1980s technical spec, navigate a custom ABAP stack, and debug runtime errors to reunite two pieces of 1979 history...

...imagine what it can do for your 2005 legacy code ^_^ (Yes, even with ECC).

The Repo (ZORK-ABAP): https://github.com/oisee/zork-abap
The Tool (VSP): https://github.com/oisee/vibing-steampunk - ADT-to-MCP bridge.

Credits:

Infocom (1979) for the Z-Machine.
SAP (1979) for the R/2 legacy that led us here.
Graham Nelson for the Z-Machine Standards Document.
Claude (2025) for writing the code.

P.S. West of House. There is a transport request here.

#SAP #ABAP #Zork #RetroGaming #AI #MCP #DigitalArchaeology #OpenSource #Microsoft

Shout out to Scott Hanselman: Tnx for driving Open Source initiative ^_^

HANA-Powered AMDP CRUD Framework: A Complete Workflow from ADT Development to ABAP Execution

2025-12-09T19:16:17.595000+01:00

1.Introduction

In modern SAP applications, performance-critical database operations can be executed directly in SAP HANA using AMDP (ABAP Managed Database Procedures). This approach allows complex CRUD (Create, Read, Update, Delete) operations to be processed efficiently in HANA while keeping the ABAP code clean and maintainable. In this guide, we explain how to implement a full CRUD solution using an AMDP class (ZCRUD_PROCEDURE) and consume it from an ABAP report with Data Base object.

By the end, you will understand:

How to design an AMDP class for CRUD operations
How to call AMDP methods from ABAP
How to handle different modes: Read, Update, Create, Delete
How to display results or messages to users

2.Business Requirement

A business user needs to manage order data stored in the custom table ZCDS_CRUD. The requirements include:

Read: Display existing records in display-only mode.
Update: Pre-fill existing records and allow editing of fields.
Create: Insert new records with input from the user.
Delete: Remove a record and display a success/failure message.
Performance: All operations should execute directly on HANA using AMDP for speed.

To achieve this, we implement:

An AMDP class containing HANA SQL Script logic for all CRUD operations.
An ABAP report that interacts with the AMDP class and provides an interactive interface for users.

3.Technical Components

ABAP Class (AMDP): ZCRUD_PROCEDURE

Interface: IF_AMDP_MARKER_HDB

Methods: READ_DATA, READ_ALL_DATA, INSERT_DATA, UPDATE_DATA, DELETE_DATA

SQLScript logic for CRUD directly on HANA

ABAP Report: ZCRUD_REPORT_AMDP

Selection screen for input fields and CRUD mode checkboxes

Calls AMDP methods
Handles display, editable fields, empty fields for creation, and delete confirmation

4.Application Flow

User opens report ZCRUD_REPORT_AMDP.
User enters an Order Number (P_ORD) and optionally Item, UOM, Quantity.
User selects one or more operation modes: Read, Create, Update, Delete.
Report calls AMDP class methods depending on the selected mode.

Read:

Calls READ_DATA

Displays record in display-only format

Update:

Calls READ_DATA to fetch record

Prefills fields with existing data

Updates using UPDATE_DATA

Create:

Uses empty or input fields to call INSERT_DATA

Delete:

Calls DELETE_DATA
Displays success/failure message

5.Key Logic Implementation

5.1 AMDP Class Definition

CLASS zcrud_procedure DEFINITION 
  PUBLIC 
  FINAL 
  CREATE PUBLIC. 
 
PUBLIC SECTION. 
  TYPES: tt_type TYPE TABLE OF zcds_crud. 
  INTERFACES if_amdp_marker_hdb. 
 
  CLASS-METHODS read_data 
    IMPORTING VALUE(iv_order) TYPE zcds_crud-order_number 
    EXPORTING VALUE(it_data) TYPE tt_type. 
 
  CLASS-METHODS read_all_data 
    EXPORTING VALUE(it_data) TYPE tt_type. 
 
  CLASS-METHODS insert_data 
    IMPORTING VALUE(iv_order) TYPE zcds_crud-order_number 
              VALUE(iv_item)  TYPE zcds_crud-item_number 
              VALUE(iv_uom)   TYPE zcds_crud-uom 
              VALUE(iv_qty)   TYPE zcds_crud-quantity. 
 
  CLASS-METHODS update_data 
    IMPORTING VALUE(iv_order) TYPE zcds_crud-order_number 
              VALUE(iv_item)  TYPE zcds_crud-item_number 
              VALUE(iv_uom)   TYPE zcds_crud-uom 
              VALUE(iv_qty)   TYPE zcds_crud-quantity. 
 
  CLASS-METHODS delete_data 
    IMPORTING VALUE(iv_order) TYPE zcds_crud-order_number. 
 
ENDCLASS.

5.2 AMDP Method Implementations (SQL Script)

CLASS zcrud_procedure IMPLEMENTATION. 
 
METHOD read_data BY DATABASE PROCEDURE 
  FOR HDB 
  LANGUAGE SQLSCRIPT 
  USING zcds_crud. 
 
  it_data = SELECT * FROM zcds_crud WHERE order_number = :iv_order; 
 
ENDMETHOD. 
 
METHOD read_all_data BY DATABASE PROCEDURE 
  FOR HDB 
  LANGUAGE SQLSCRIPT 
  USING zcds_crud. 
 
  it_data = SELECT * FROM zcds_crud; 
 
ENDMETHOD. 
 
METHOD insert_data BY DATABASE PROCEDURE 
  FOR HDB 
  LANGUAGE SQLSCRIPT 
  USING zcds_crud. 
 
  INSERT INTO zcds_crud (order_number, item_number, uom, quantity) 
  VALUES (:iv_order, :iv_item, :iv_uom, :iv_qty); 
 
ENDMETHOD. 
 
METHOD update_data BY DATABASE PROCEDURE 
  FOR HDB 
  LANGUAGE SQLSCRIPT 
  USING zcds_crud. 
 
  UPDATE zcds_crud 
  SET item_number = :iv_item, 
      uom         = :iv_uom, 
      quantity    = :iv_qty 
  WHERE order_number = :iv_order; 
 
ENDMETHOD. 
 
METHOD delete_data BY DATABASE PROCEDURE 
  FOR HDB 
  LANGUAGE SQLSCRIPT 
  USING zcds_crud. 
 
  DELETE FROM zcds_crud WHERE order_number = :iv_order; 
 
ENDMETHOD. 
 
ENDCLASS.

5.3 ABAP Report: Selection Screen

REPORT zcrud_report_amdp. 
 
PARAMETERS: p_ord TYPE zcds_crud-order_number OBLIGATORY, 
            p_read  AS CHECKBOX DEFAULT abap_true, 
            p_crea  AS CHECKBOX, 
            p_upd   AS CHECKBOX, 
            p_del   AS CHECKBOX. 
 
PARAMETERS: p_item TYPE zcds_crud-item_number, 
            p_uom  TYPE zcds_crud-uom, 
            p_qty  TYPE zcds_crud-quantity. 
 
DATA: lt_data TYPE zcrud_procedure=>tt_type, 
      ls_data TYPE zcds_crud.

5.4 ABAP Report: Execution and CRUD Operations

START-OF-SELECTION.

  CASE 'X'.
    WHEN rb_read.
      PERFORM read_data.
    WHEN rb_crt.
      PERFORM create_screen.
    WHEN rb_upd.
      PERFORM update_screen.
    WHEN rb_dlt.
      PERFORM delete_data.
  ENDCASE.


*-------------------------------------------------------------*
* READ MODE – SHOW DATA IN ALV (Display Only)
*-------------------------------------------------------------*
FORM read_data.

  zcrud_procedure=>read_data(
    EXPORTING iv_order = p_ord
    IMPORTING it_data  = lt_data ).

  IF lt_data IS INITIAL.
    WRITE: / 'No record found'.
    RETURN.
  ENDIF.

  CALL SCREEN 100.

ENDFORM.


*-------------------------------------------------------------*
* CREATE MODE – EMPTY ALV WITH HEADERS (Editable)
*-------------------------------------------------------------*
FORM create_screen.

  CLEAR lt_data.
  ls_data-order_number = p_ord.
  ls_data-item_number  = p_item.
  ls_data-uom          = p_uom.
  ls_data-quantity     = p_qty.

  TRY.
      zcrud_procedure=>insert_data(
        EXPORTING
          iv_order = ls_data-order_number
          iv_item  = ls_data-item_number
          iv_uom   = ls_data-uom
          iv_qty   = ls_data-quantity
      ).
*      WRITE: / 'Record created successfully.'.
      MESSAGE 'Record created successfully' TYPE 'S'.
    CATCH cx_amdp_error INTO DATA(lx).
      WRITE: / 'Error creating record:', lx->get_text( ).
  ENDTRY.
  "Add empty row
*  APPEND INITIAL LINE TO lt_data.
  append ls_data to lt_data.

  CALL SCREEN 200.

ENDFORM.


*-------------------------------------------------------------*
* UPDATE MODE – ORDER DISPLAY ONLY, OTHERS EDITABLE
*-------------------------------------------------------------*
FORM update_screen.

  IF rb_upd = abap_true.
  zcrud_procedure=>read_data(
    EXPORTING iv_order = p_ord
    IMPORTING it_data = lt_data
  ).

  IF lt_data IS INITIAL.
     MESSAGE: 'No record found for update' type 'S'.
  ELSE.
    ls_data = lt_data[ 1 ].
    " Editable mode: overwrite with screen input if provided
    IF p_item IS NOT INITIAL.
      ls_data-item_number = p_item.
    ENDIF.
    IF p_uom IS NOT INITIAL.
      ls_data-uom = p_uom.
    ENDIF.
    IF p_qty IS NOT INITIAL.
      ls_data-quantity = p_qty.
    ENDIF.

    TRY.
        zcrud_procedure=>update_data(
          EXPORTING
            iv_order = ls_data-order_number
            iv_item  = ls_data-item_number
            iv_uom   = ls_data-uom
            iv_qty   = ls_data-quantity
        ).
        MESSAGE 'Record updated successfully' TYPE 'S'.
      CATCH cx_amdp_error INTO DATA(lxupd).
        MESSAGE 'Error updating record:' TYPE 'S'.
    ENDTRY.
  ENDIF.
ENDIF.

  CALL SCREEN 300.

ENDFORM.


*-------------------------------------------------------------*
* DELETE MODE
*-------------------------------------------------------------*
FORM delete_data.

  zcrud_procedure=>delete_data(
    EXPORTING iv_order = p_ord ).

  MESSAGE 'Record Deleted successfully' TYPE 'S'.

ENDFORM.


*--------------------------------------------------------------------*
* SCREEN 100 – READ MODE (DISPLAY ALV)
*--------------------------------------------------------------------*
MODULE status_0100 OUTPUT.
  SET PF-STATUS 'SCREEN100'.

  CREATE OBJECT gr_cust
    EXPORTING container_name = 'CC_ALV'.

  CREATE OBJECT gr_alv
    EXPORTING i_parent = gr_cust.

  CALL METHOD gr_alv->set_table_for_first_display
    EXPORTING i_structure_name = 'ZCDS_CRUD'
    CHANGING  it_outtab        = lt_data.

ENDMODULE.




*--------------------------------------------------------------------*
* SCREEN 200 – CREATE MODE (Editable)
*--------------------------------------------------------------------*
MODULE status_0200 OUTPUT.
  SET PF-STATUS 'SCREEN200'.

  CREATE OBJECT gr_cust
    EXPORTING container_name = 'CC_ALV'.

  CREATE OBJECT gr_alv
    EXPORTING i_parent = gr_cust.

  CALL METHOD gr_alv->set_table_for_first_display
    EXPORTING i_structure_name = 'ZCDS_CRUD'
              i_default   = 'X'
    CHANGING  it_outtab        = lt_data.

ENDMODULE.

MODULE user_command_0200 INPUT.

  case sy-ucomm.
    when 'BACK'.
      LEAVE TO SCREEN 0.

    ENDCASE.

  READ TABLE lt_data INTO ls_data INDEX 1.

  TRY.
      zcrud_procedure=>insert_data(
        EXPORTING
          iv_order = ls_data-order_number
          iv_item  = ls_data-item_number
          iv_uom   = ls_data-uom
          iv_qty   = ls_data-quantity ).
      MESSAGE 'Record Created Successfully' TYPE 'S'.
    CATCH cx_amdp_error INTO DATA(lx).
      MESSAGE lx->get_text( ) TYPE 'E'.
  ENDTRY.

  LEAVE TO SCREEN 0.
ENDMODULE.


*--------------------------------------------------------------------*
* SCREEN 300 – UPDATE MODE (Order display only)
*--------------------------------------------------------------------*
MODULE status_0300 OUTPUT.
  SET PF-STATUS 'SCREEN300'.

  DATA lt_fieldcat TYPE lvc_t_fcat.
  DATA ls_fcat     TYPE lvc_s_fcat.

  "ITEM/UOM/QTY editable
  LOOP AT lt_data INTO ls_data.
  ENDLOOP.

  "Build field catalog
  ls_fcat-fieldname = 'ORDER_NUMBER'.
  ls_fcat-scrtext_l = 'Order'.
  ls_fcat-edit      = ''.
  APPEND ls_fcat TO lt_fieldcat.

  CLEAR ls_fcat.
  ls_fcat-fieldname = 'ITEM_NUMBER'.
  ls_fcat-scrtext_l = 'Item'.
  ls_fcat-edit      = 'X'.
  APPEND ls_fcat TO lt_fieldcat.

  CLEAR ls_fcat.
  ls_fcat-fieldname = 'UOM'.
  ls_fcat-scrtext_l = 'UOM'.
  ls_fcat-edit      = 'X'.
  APPEND ls_fcat TO lt_fieldcat.

  CLEAR ls_fcat.
  ls_fcat-fieldname = 'QUANTITY'.
  ls_fcat-scrtext_l = 'Qty'.
  ls_fcat-edit      = 'X'.
  APPEND ls_fcat TO lt_fieldcat.

  CREATE OBJECT gr_cust
    EXPORTING container_name = 'CC_ALV'.

  CREATE OBJECT gr_alv
    EXPORTING i_parent = gr_cust.

  CALL METHOD gr_alv->set_table_for_first_display
    EXPORTING
      is_layout       = VALUE lvc_s_layo( )
    CHANGING
      it_outtab       = lt_data
      it_fieldcatalog = lt_fieldcat.

ENDMODULE.

MODULE user_command_0300 INPUT.

  case sy-ucomm.
    when 'BACK'.
      LEAVE TO SCREEN 0.

    ENDCASE.

  READ TABLE lt_data INTO ls_data INDEX 1.

  TRY.
      zcrud_procedure=>update_data(
        EXPORTING
          iv_order = ls_data-order_number
          iv_item  = ls_data-item_number
          iv_uom   = ls_data-uom
          iv_qty   = ls_data-quantity ).
      MESSAGE 'Record Updated Successfully' TYPE 'S'.
    CATCH cx_amdp_error INTO DATA(lxupd).
      MESSAGE lxupd->get_text( ) TYPE 'E'.
  ENDTRY.

  LEAVE TO SCREEN 0.
ENDMODULE.
*&---------------------------------------------------------------------*
*&      Module  USER_COMMAND_0100  INPUT
*&---------------------------------------------------------------------*
*       text
*----------------------------------------------------------------------*
MODULE user_command_0100 INPUT.

  case sy-ucomm.
    when 'BACK'.
      LEAVE TO SCREEN 0.

    ENDCASE.

ENDMODULE.

7. CRUD Operation Outputs (Screenshots Section)

7.1 READ Operation Output

7.2 CREATE Operation Output

7.3 UPDATE Operation Output

7.4 DELETE Operation Output

6. Conclusion

This implementation demonstrates how to:

Use AMDP classes to handle CRUD operations directly on HANA
Separate data logic (AMDP) from presentation logic (ABAP report)
Handle different CRUD modes efficiently
Provide clear user messages for all operations

This approach ensures performance, maintainability, and user-friendliness while working with SAP HANA and ABAP together, and it can be extended to other database-intensive operations following the same pattern.

RAP BASED ADOBEFORM WITH CUSTOM ACTION and Annotations

2025-12-10T07:53:48.802000+01:00

Introduction:
In this blog, we explore how RAP and Adobe Forms can be integrated to deliver a fully digital, end-to-end document generation experience directly from Fiori. By leveraging custom actions, virtual elements, and media-stream handling, we can trigger Adobe Form generation from the UI, manage the file output within RAP, and enable users to download the PDF instantly—ensuring a clean, cloud-ready and future-proof architecture.

Solution Overview:

In modern SAP applications, combining RAP (RESTful ABAP Programming Model) with Adobe Forms unlocks a clean, scalable way to generate and manage documents directly from Fiori. By extending the Fiori Elements UI with a custom action through the Integrative Extension Controller, we can trigger Adobe form generation seamlessly from the frontend. Using RAP virtual elements and media-stream properties, the generated PDF can be stored, retrieved, and downloaded. This approach delivers a fully end-to-end, cloud-ready solution for document creation, storage, and user-triggered actions—all built natively within RAP.

Root Entity:

@AccessControl.authorizationCheck: #NOT_REQUIRED         // No authorization checks required for read access
@EndUserText.label: 'ROOT ENTITY FOR ADOBE FORM'         // Description for display in tools
@Metadata.ignorePropagatedAnnotations: true              // Avoid unwanted propagated annotations

define root view entity ZRV_AFORM 
  as select from vbap                                    // Based on VBAP (Sales Order Item Data)
{

  /*-----------------------------------------------------------
    Key Fields for RAP Root Entity
  -----------------------------------------------------------*/
  key vbeln,          // Sales Document Number
  posnr,              // Item Number
  matnr,              // Material Number

  /*-----------------------------------------------------------
    Display text: Shown in UI for SEGW/Fiori preview
    Not used for actual functionality, only for readability.
  -----------------------------------------------------------*/
  'Preview(SEGW)' as ShowPDF,

  /*-----------------------------------------------------------
    Dynamic URL to download the Adobe Form PDF
    Format:
      /sap/opu/odata/SAP/ZRAP_ADOBE_FORM_SRV/adobeSet('<VBELN>')/$value
    This URL triggers GET_STREAM in the OData service.
  -----------------------------------------------------------*/
  concat(
    '/sap/opu/odata/SAP/ZRAP_ADOBE_FORM_SRV/adobeSet(''',
    concat( vbeln, ''')') /$value'
  ) as LinkToPDF

}

OData Service:

Include vbeln as a property in your entity type, and when the user provides a sales document number, the service should return the corresponding Adobe Form data in the response, implement GET_STREAM Method .

Implementation:

  METHOD /IWBEP/IF_MGW_APPL_SRV_RUNTIME~GET_STREAM.

    "---------------------------------------------------------------
    " Data Declarations
    "---------------------------------------------------------------
    DATA: lv_funcname   TYPE funcname,         " Generated FM name for Adobe Form
          ls_o_p        TYPE sfpoutputparams,  " Output parameters for Adobe Forms
          ls_formoutput TYPE fpformoutput,     " Adobe form output structure
          ls_stream     TYPE ty_s_media_resource,  " Stream returned to OData
          gv_bin_file   TYPE xstring.          " PDF binary data (unused variable)

    "---------------------------------------------------------------
    " Read Input Key from OData Request
    " Example: /sap/opu/odata/SRV/FormSet(vbeln='12345')/$value
    "---------------------------------------------------------------
    DATA(lv_vbeln) = VALUE vbeln_vl(
                        it_key_tab[ name = 'vbeln' ]-value OPTIONAL ).

    "---------------------------------------------------------------
    " STEP 1: Retrieve Adobe Form Generated Function Module
    "---------------------------------------------------------------
    TRY.
        CALL FUNCTION 'FP_FUNCTION_MODULE_NAME'
          EXPORTING
            i_name     = 'ZSALES_FORM_ITEMS'   " Adobe Form interface name
          IMPORTING
            e_funcname = lv_funcname.          " Generated FM name

        IF sy-subrc <> 0.
          RETURN.  " Stop processing if FM not found
        ENDIF.

        "-----------------------------------------------------------
        " STEP 2: Adobe Form Output Setup (Request PDF Only)
        "-----------------------------------------------------------
        ls_o_p-nodialog  = abap_true.   " No dialog popups
        ls_o_p-getpdf    = abap_true.   " Request PDF output
        ls_o_p-nopreview = abap_true.   " Skip preview

        " Open Adobe spool job
        CALL FUNCTION 'FP_JOB_OPEN'
          CHANGING
            ie_outputparams = ls_o_p
          EXCEPTIONS
            cancel          = 1
            usage_error     = 2
            system_error    = 3
            internal_error  = 4
            OTHERS          = 5.

      CATCH cx_root.
        " Ideally log or raise error
        RETURN.
    ENDTRY.

    "---------------------------------------------------------------
    " STEP 3: Call Adobe Form Generated Function Module
    "---------------------------------------------------------------
    CALL FUNCTION lv_funcname
      EXPORTING
        p_vbeln            = lv_vbeln         " Sales document number
      IMPORTING
        /1bcdwb/formoutput = ls_formoutput    " PDF Output (XSTRING)
      EXCEPTIONS
        usage_error        = 1
        system_error       = 2
        internal_error     = 3
        OTHERS             = 4.

    IF sy-subrc <> 0.
      RETURN.    " Handle form rendering errors
    ENDIF.

    "---------------------------------------------------------------
    " STEP 4: Close Adobe Print Job
    "---------------------------------------------------------------
    CALL FUNCTION 'FP_JOB_CLOSE'
      EXCEPTIONS
        usage_error    = 1
        system_error   = 2
        internal_error = 3
        OTHERS         = 4.

    IF sy-subrc <> 0.
      RETURN.
    ENDIF.

    "---------------------------------------------------------------
    " STEP 5: Populate OData Media Stream
    "---------------------------------------------------------------
    ls_stream-mime_type = 'application/pdf'.   " MIME type for PDF
    ls_stream-value     = ls_formoutput-pdf.   " XSTRING PDF data

    "---------------------------------------------------------------
    " STEP 6: Set Filename in Response Header
    "---------------------------------------------------------------
    DATA: ls_header   TYPE ihttpnvp,
          lv_filename TYPE string.

    " Dynamic file name e.g. SalesDoc_80001234.pdf
    lv_filename = |SalesDoc_{ lv_vbeln }.pdf|.

    ls_header-name  = 'Content-Disposition'.
    ls_header-value = |attachment; filename="{ lv_filename }"|.

    " Add header to OData HTTP response
    me->set_header( is_header = ls_header ).

    "---------------------------------------------------------------
    " STEP 7: Return Stream to OData Framework
    "---------------------------------------------------------------
    CALL METHOD me->copy_data_to_ref
      EXPORTING
        is_data = ls_stream
      CHANGING
        cr_data = er_stream.

  ENDMETHOD.

Projection View:

To expose the Adobe Form download link in the Fiori UI, I used a projection view with ui.lineItem and type: WITH_URL so the PDF URL becomes directly clickable in the list and object page. The actual PDF content BASE64 is not stored in the CDS view; instead, I used a RAP virtual element attach calculated by an ABAP class for Custom Action. This virtual element lets me fetch and return the generated Adobe Form dynamically at runtime without persisting the binary in the database.

@AccessControl.authorizationCheck: #NOT_REQUIRED          // No auth checks for read access
@EndUserText.label: 'PV FOR ADOBE FORM'                   // Description of the view
@Metadata.ignorePropagatedAnnotations: true               // Prevent annotation inheritance from base view

define root view entity ZPV_AFORM 
  as projection on ZRV_AFORM                               // Projection on RAP consumption view
{

  /*-----------------------------------------------------------
    Key Field: Sales Document (VBELN)
    Displayed in UI (List + Object Page)
  -----------------------------------------------------------*/
  @ui.facet: [{ type: #IDENTIFICATION_REFERENCE }]
  @ui.lineItem: [{ position: 10 }]
  @ui.identification: [{ position: 10 }]
  key vbeln,

  /*-----------------------------------------------------------
    Item Number
  -----------------------------------------------------------*/
  @ui.lineItem: [{ position: 20 }]
  @ui.identification: [{ position: 20 }]
  posnr,

  /*-----------------------------------------------------------
    Material
  -----------------------------------------------------------*/
  @ui.lineItem: [{ position: 30 }]
  @ui.identification: [{ position: 30 }]
  matnr,

  /*-----------------------------------------------------------
    PDF Link Column (UI: Display as clickable URL)
    This displays a clickable link "Show PDF" in the List Report.
  -----------------------------------------------------------*/
  @ui.lineItem: [{
     position: 10,
     type: #WITH_URL,      // URL-enabled column
     url: 'LinkToPDF'      // Field used as hyperlink
  }]
  @ui.identification: [{
     position: 61,
     type: #WITH_URL,
     url: 'LinkToPDF'
  }]
  ShowPDF,                // UI label for the clickable link

  /*-----------------------------------------------------------
    URL Field - Populated in Behavior Implementation
    Used by Fiori to download/open the PDF.
  -----------------------------------------------------------*/
  LinkToPDF,

  /*-----------------------------------------------------------
    Virtual Field for Base64 PDF content
    RAP calculates this via ZCL_ADOBEFORMM class.
  -----------------------------------------------------------*/
  @ObjectModel.virtualElement: true
  @ObjectModel.virtualElementCalculatedBy: 'ABAP:ZCL_ADOBEFORMM'
  virtual attach : abap.string(0)     // Base64 PDF to be fetched on-demand

}

Virtual Elements Implementation:

CLASS zcl_adobeformm IMPLEMENTATION.

  METHOD if_sadl_exit_calc_element_read~calculate.

    " Internal table for virtual elements defined in projection view
    DATA: lt_virtual TYPE TABLE OF zpv_aform,
          lv_base64 TYPE string.

    " Move original RAP data into a working virtual table
    lt_virtual = CORRESPONDING #( it_original_data ).

    " Loop over each row to calculate the virtual element (Base64 PDF)
    LOOP AT lt_virtual INTO DATA(ls_virtual).

      " Get Sales Order number from the current row
      DATA(lv_vbeln) = ls_virtual-vbeln.

      " Create instance of Adobe Form handler class
      DATA(lo_inst) = NEW zcl_adobeform( ).

      " Call Adobe Form generator to get raw PDF (XSTRING)
      DATA(rv_pdf) = lo_inst->get_data(
                        EXPORTING
                          p_vbeln = lv_vbeln     " Sales Order
                     ).

      " Convert PDF (XSTRING) → Base64 string, required for RAP media download
      CALL FUNCTION 'SCMS_BASE64_ENCODE_STR'
        EXPORTING
          input  = rv_pdf
        IMPORTING
          output = lv_base64.

      " Assign Base64 string to virtual element field
      ls_virtual-attach = lv_base64.

    ENDLOOP.

    " Move calculated data back to RAP consumption structure
    ct_calculated_data = CORRESPONDING #( lt_virtual ).

  ENDMETHOD.

ENDCLASS.

To retrieve the Adobe Form as an XSTRING, I implemented a dedicated ABAP class responsible for generating and returning the PDF content. The implementation code is as follows:

  method GET_DATA.

    " Adobe Form name
    DATA(lv_form_name) = CONV tdsfname( 'ZSALES_FORM_ITEMS' ).

    " Name of the generated function module for the form
    DATA(lv_form_fm_name) = VALUE rs38l_fnam( ).

    " Structures for Adobe Form parameters
    DATA(ls_docparams)    = VALUE sfpdocparams( ).
    DATA(ls_outputparams) = VALUE sfpoutputparams( ).
    DATA(ls_formoutput)   = VALUE fpformoutput( ).

*--------------------------------------------------------------------*
*   STEP 1: Get the Generated Function Module of the Adobe Form
*--------------------------------------------------------------------*
    TRY.
        CALL FUNCTION 'FP_FUNCTION_MODULE_NAME'
          EXPORTING
            i_name     = lv_form_name          " Form name
          IMPORTING
            e_funcname = lv_form_fm_name.      " Generated FM name

      CATCH cx_fp_api INTO DATA(lx_fp_api).
        " Handle form API errors
        MESSAGE ID lx_fp_api->msgid TYPE lx_fp_api->msgty
                NUMBER lx_fp_api->msgno
                WITH lx_fp_api->msgv1 lx_fp_api->msgv2
                     lx_fp_api->msgv3 lx_fp_api->msgv4.
        RETURN.
    ENDTRY.


*--------------------------------------------------------------------*
*   STEP 2: Prepare Output Parameters for PDF Generation
*--------------------------------------------------------------------*
    ls_outputparams-nodialog = 'X'.   " Avoid popup / preview dialog
    ls_outputparams-getpdf   = 'X'.   " Request PDF output only


*--------------------------------------------------------------------*
*   STEP 3: Open Adobe Form Spool Job
*--------------------------------------------------------------------*
    CALL FUNCTION 'FP_JOB_OPEN'
      CHANGING
        ie_outputparams = ls_outputparams
      EXCEPTIONS
        cancel          = 1
        usage_error     = 2
        system_error    = 3
        internal_error  = 4
        OTHERS          = 5.

    IF sy-subrc <> 0.
      " Display error message and exit
      MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
              WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
      RETURN.
    ENDIF.


*--------------------------------------------------------------------*
*   STEP 4: Call the Generated Adobe Form Function Module
*--------------------------------------------------------------------*
    CALL FUNCTION lv_form_fm_name
      EXPORTING
        /1BCDWB/DOCPARAMS  = ls_docparams    " Document parameters
        p_vbeln            = p_vbeln          " Sales document input
      IMPORTING
        /1BCDWB/FORMOUTPUT = ls_formoutput    " Output structure
      EXCEPTIONS
        USAGE_ERROR        = 1
        SYSTEM_ERROR       = 2
        INTERNAL_ERROR     = 3
        OTHERS             = 4.

    IF sy-subrc <> 0.
      " Errors during form rendering
      MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
              WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
      RETURN.
    ENDIF.


*--------------------------------------------------------------------*
*   STEP 5: Close Adobe Form Spool Job
*--------------------------------------------------------------------*
    CALL FUNCTION 'FP_JOB_CLOSE'
      EXCEPTIONS
        usage_error    = 1
        system_error   = 2
        internal_error = 3
        OTHERS         = 4.

    IF sy-subrc <> 0.
      " Handle spool closing issues
      MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
              WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
      RETURN.
    ENDIF.


*--------------------------------------------------------------------*
*   STEP 6: Return Base64 PDF string to RAP Virtual Element
*--------------------------------------------------------------------*
    rv_string = ls_formoutput-pdf.    " Base64 encoded PDF

  endmethod.

generate service definition and binding.
bind our service to list report.
The link is highlighted in the UI, and when the user clicks it, the corresponding Adobe Form for that specific sales document is downloaded instantly.
Right click on web app and click on open guided development.
We need custom action to be implemented.
Click on add a custom action.
Add necessary details and click on insert code snippet it will be added to manifest.json, it will add one more controller, where we can add our custom logic.

To handle multi-PDF downloads from the List Report, I implemented a custom action in the controller extension. When the user selects one or more rows, a confirmation popup is shown using MessageBox.confirm. After the user confirms, the extension reads each selected entity via the OData model and retrieves the attach virtual element, which contains the Adobe Form as a Base64 string. The code then converts the Base64 into a PDF Blob and automatically triggers a download for each sales document, generating individual files such as Sales_Document_<VBELN>.pdf. This approach provides a smooth, scalable way to download multiple Adobe Forms directly from the Fiori UI without additional backend endpoints.

sap.ui.define([
    "sap/m/MessageToast",
    "sap/m/MessageBox"
], function (MessageToast, MessageBox) {
    "use strict";

    return {
        adf: function (oEvent) {

            // Get the SmartTable from the view
            var oSmartTable = this.getView().byId("listReport");
            if (!oSmartTable) {
                MessageToast.show("SmartTable not found");
                return;
            }

            // Get the inner table (GridTable/ResponsiveTable)
            var oTable = oSmartTable.getTable();
            if (!oTable || typeof oTable.getSelectedContexts !== "function") {
                // If table is not ready or does not support selection
                MessageToast.show("Table not ready or selection not supported");
                return;
            }

            // Get selected row contexts
            var aSelectedContexts = oTable.getSelectedContexts();
            if (aSelectedContexts.length === 0) {
                // User must select at least one row
                MessageToast.show("Please select at least one row.");
                return;
            }

            // Ask user for confirmation before downloading PDFs
            MessageBox.confirm("Do you want to download the selected PDF(s)?", {
                title: "Confirm Download",
                actions: [MessageBox.Action.OK, MessageBox.Action.CANCEL],

                onClose: function (oAction) {
                    if (oAction === MessageBox.Action.OK) {

                        // Get OData model
                        var oModel = this.getOwnerComponent().getModel();

                        // Loop through all selected rows
                        aSelectedContexts.forEach(function (oContext, index) {
                            var sPath = oContext.getPath();  // Entity path of the row

                            // Read entity to fetch Base64 PDF (virtual element)
                            oModel.read(sPath, {
                                success: function (odata) {

                                    // Extract Base64 string from response
                                    var base64String = odata.attach;

                                    try {
                                        // Convert Base64 → binary
                                        var binaryString = atob(base64String);
                                        var len = binaryString.length;
                                        var bytes = new Uint8Array(len);

                                        for (var i = 0; i < len; i++) {
                                            bytes[i] = binaryString.charCodeAt(i);
                                        }

                                        // Create Blob for PDF download
                                        var blob = new Blob([bytes], { type: "application/pdf" });

                                        // Create a temporary download link
                                        var link = document.createElement("a");
                                        link.href = URL.createObjectURL(blob);

                                        // File name: Sales_Document_<VBELN>.pdf
                                        link.download = "Sales_Document_" + odata.vbeln + ".pdf";

                                        // Trigger download
                                        document.body.appendChild(link);
                                        link.click();
                                        document.body.removeChild(link);

                                    } catch (e) {
                                        // Invalid Base64 or conversion failure
                                        MessageToast.show("Invalid base64 for: " + odata.vbeln);
                                    }
                                },

                                // Error while calling OData service
                                error: function () {
                                    MessageToast.show("Error fetching PDF for: " + sPath);
                                }
                            });
                        });
                    }
                }.bind(this)
            });
        }
    };
});

Conclusion:
This end-to-end setup demonstrates how RAP, Adobe Forms, and Fiori Elements can work together seamlessly to deliver a modern document-generation experience. By leveraging virtual elements for XSTRING handling, URL-based PDF links, and a custom UI action for multi-file downloads, we can generate, expose, and retrieve Adobe Forms without any custom Gateway coding. The solution is clean, extensible, and fully aligned with SAP’s cloud-ready RAP architecture making it a practical template for building similar document-driven features in enterprise applications.

Thanks For Reading, Good Wishes
ABAP Connectivity
ABAP Development
SAP BTP ABAP environment

SAP RAP Data Modeling: Handling Virtual Fields with AMDP and Table Functions

2025-12-10T08:30:29.592000+01:00

Hi all,

In SAP RAP development, it is common to work with fields that should not be physically stored in database tables but must still appear in the service output. Such fields are often required for real-time calculations, business validations, or UI-level display logic.

This blog demonstrates two powerful techniques to handle these derived fields:

Table Functions (AMDP) for database-side calculations
Virtual Elements for ABAP-based runtime logic

To make the concept relatable, we use a simple Student Marks Management scenario where:

Total Marks is calculated using a Table Function (AMDP)
Pass/Fail Status is determined using Virtual Elements

This article will walk you through all necessary components—including CDS view entities, AMDP class implementation, RAP behavior definition, and the virtual element class.

I am implementing this requirement using two approaches:

Table Function for calculating Total Marks
Virtual Field for determining Status

Both methods will be covered in this blog.

Step 1: Create a new database table to store student information.

Code:

@EndUserText.label : 'Student Information'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table zstudent_info {
  key client : abap.clnt not null;
  key id     : zstudentid_de not null;
  name       : abap.char(50);
  class      : abap.int4;
  telugu     : abap.int4;
  hindi      : abap.int4;
  english    : abap.int4;
  maths      : abap.int4;
  science    : abap.int4;
  social     : abap.int4;
}

Step 2: Create a Table Function

Real-time Use Case for Table Function

In a Student Marks Management System, Total Marks are calculated dynamically across subjects without storing the result physically. A Table Function, implemented with AMDP and SQLScript, performs this calculation efficiently in the database, improving performance and keeping the data model clean by avoiding redundant storage.

For now, I am adding only the Total Marks field to implement the AMDP approach.

@EndUserText.label: 'Student Info with Total Marks'
define table function ZTABLE_FUNCTION_STUDENT
  with parameters
    @Environment.systemField: #CLIENT
    p_client : abap.clnt
  returns {
    client     : abap.clnt;
    id         : zstudentid_de;
    name       : abap.char(50);
    class      : abap.int4;
    telugu     : abap.int4;
    hindi      : abap.int4;
    english    : abap.int4;
    maths      : abap.int4;
    science    : abap.int4;
    social     : abap.int4;
    totalmarks : abap.int4;     // 🆕 Calculated field
  }
  implemented by method ZCL_TABLE_FUNC_STUDENT=>get_total_data;

Step 3: Now create a class ZCL_TABLE_FUNC_STATUS to implement the logic for calculating Total Marks.

Example Code:

CLASS zcl_table_func_student DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC.
  PUBLIC SECTION.
    INTERFACES if_amdp_marker_hdb.
    " Table function method declaration
    CLASS-METHODS get_total_data
      FOR TABLE FUNCTION ztable_function_student.
ENDCLASS.
CLASS zcl_table_func_student IMPLEMENTATION.
  METHOD get_total_data
    BY DATABASE FUNCTION
    FOR HDB
    LANGUAGE SQLSCRIPT
    OPTIONS READ-ONLY
    USING zstudent_info.
    RETURN
      SELECT
        client,
        id,
        name,
        class,
        telugu,
        hindi,
        english,
        maths,
        science,
        social,
        telugu + hindi + english + maths + science + social AS totalmarks
      FROM zstudent_info
      WHERE client = :p_client;
  ENDMETHOD.
ENDCLASS.

Step 4: Execute and test the code by pressing F8 On Table Function.

Output:

Now I am going with Virtual Elements.

Virtual elements are defined using annotations such as:

@ObjectModel.virtualElement: true
@ObjectModel.virtualElementCalculatedBy: 'ABAP:className'

The logic for the virtual element is implemented in the specified ABAP class.

Now I am creating the Root View

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Student Info with Status'
@Metadata.ignorePropagatedAnnotations: true
@ObjectModel.usageType: {
    serviceQuality: #X,
    sizeCategory: #S,
    dataClass: #MIXED
}
define root view entity zstudent_info_view
  as select from ZTABLE_FUNCTION_STUDENT( p_client : $session.client )
{
  key id         as Id,
      name       as Name,
      class      as Class,
      telugu     as Telugu,
      hindi      as Hindi,
      english    as English,
      maths      as Maths,
      science    as Science,
      social     as Social,
      totalmarks as TotalMarks,
      @ObjectModel.virtualElement: true
      @ObjectModel.virtualElementCalculatedBy: 'ABAP:ZCL_VIRTUAL_ELEMENT_CALCC'
      @EndUserText.label: 'Pass/Fail Status'
      cast( '' as abap.char(10) ) as Status
}

Root View Code :

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Root View'
@Metadata.ignorePropagatedAnnotations: true
define root view entity zstudent_info_view_root as select from zstudent_info_view
{

 key Id as Id,
 Name as Name,
 Class as Class,
 Telugu as Telugu,
 Hindi as Hindi,
 English as English,
 Maths as Maths,
 Science as Science,
 Social as Social,
 TotalMarks as TotalMarks,
      @ObjectModel.virtualElement: true
      @ObjectModel.virtualElementCalculatedBy: 'ABAP:ZCL_VIRTUAL_ELEMENT_CALCC'
      @EndUserText.label: 'Pass/Fail Status'
      cast( '' as abap.char(10) ) as Status
}

Projection View Code :

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Projection View'
@Metadata.ignorePropagatedAnnotations: true
@Metadata.allowExtensions: true
define root view entity ZSTUDENT_INFO_VIEW_ROOT_Pro as projection on zstudent_info_view_root
{


//@Consumption.valueHelpDefinition: [
//   { entity: {
//               name: 'ZSTUDENT_INFO_VIEW_ROOT',
//               element: 'ID'
//       } }
//   ]

   key Id,
//  @Consumption.valueHelpDefinition: [
//   { entity: {
//               name: 'ZSTUDENT_INFO_VIEW_ROOT',
//               element: 'Name'
//       } }
//   ]

    Name,

    Class,


    Telugu,

 
    Hindi,

   
    English,

   
    Maths,


    Science,

    Social,
    
    TotalMarks,       // Virtual field
    @ObjectModel.virtualElement: true
      @ObjectModel.virtualElementCalculatedBy: 'ABAP:ZCL_VIRTUAL_ELEMENT_CALCC'
      @EndUserText.label: 'Pass/Fail Status'
    Status            // Virtual field (Pass/Fail)
}

Definition of behavior for the root view

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

define behavior for zstudent_info_view_root alias student
  persistent table zstudent_informa
  lock master
  authorization master ( instance )
// etag master <field_name> " Uncomment if using ETag for concurrency control
{
  create;
  update;
  delete;
  field ( readonly ) TotalMarks, Status;

  mapping for zstudent_informa
  {
    Id      = id;
    Name    = name;
    Class   = class;
    Telugu  = telugu;
    Hindi   = hindi;
    English = english;
    Maths   = maths;
    Science = science;
    Social  = social;
  }
}

Create classes for the root view and projection view.

Create a class and logic for the virtual element.

CLASS zcl_virtual_element_calcc DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC.
  PUBLIC SECTION.
    INTERFACES if_sadl_exit_calc_element_read.
  PROTECTED SECTION.
  PRIVATE SECTION.
ENDCLASS.

CLASS zcl_virtual_element_calcc IMPLEMENTATION.

  METHOD if_sadl_exit_calc_element_read~calculate.

    CHECK NOT it_original_data IS INITIAL.

    DATA lt_calculated_data TYPE STANDARD TABLE OF zstudent_info_view WITH DEFAULT KEY.

    MOVE-CORRESPONDING it_original_data TO lt_calculated_data.

    LOOP AT lt_calculated_data ASSIGNING FIELD-SYMBOL(<student>).

      " Calculate TotalMarks by summing all subject marks
*      <student>-totalmarks = <student>-telugu
*                           + <student>-hindi
*                           + <student>-english
*                           + <student>-maths
*                           + <student>-science
*                           + <student>-social.

      " Check if any subject marks are less than 25
*      IF <student>-telugu < 25 OR
*         <student>-hindi  < 25 OR
*         <student>-english < 25 OR
*         <student>-maths < 25 OR
*         <student>-science < 25 OR
*         <student>-social < 25.
*        <student>-status = 'Failed'.
*      ELSE.
*          <student>-status = 'Passed'.
**        ENDIF.
*      ENDIF.
      IF <student>-totalmarks > 250 .
       <student>-status = 'Passed'.
       ELSE.
       <student>-status = 'Failed'.
ENDIF.


    ENDLOOP.

    MOVE-CORRESPONDING lt_calculated_data TO ct_calculated_data.

  ENDMETHOD.

  METHOD if_sadl_exit_calc_element_read~get_calculation_info.

    " Tell framework which fields you need from original data
    et_requested_orig_elements = VALUE #( BASE et_requested_orig_elements
                                          ( CONV #( 'TELUGU' ) )
                                          ( CONV #( 'HINDI' ) )
                                          ( CONV #( 'ENGLISH' ) )
                                          ( CONV #( 'MATHS' ) )
                                          ( CONV #( 'SCIENCE' ) )
                                          ( CONV #( 'SOCIAL' ) )
                                          ( CONV #( 'TOTALMARKS' ) )
                                        ).

  ENDMETHOD.

ENDCLASS.

Now, create a service definition for the projection view and bind the service.

Now, we are able to see the virtual element output field in the web application.

Conclusion

This blog demonstrated how to enrich a RAP data model using both Table Functions and Virtual Elements, allowing you to compute fields dynamically without storing redundant values in the database.

Table Functions (AMDP) perform high-performance calculations on the HANA database, such as Total Marks.
Virtual Elements allow ABAP-based runtime logic for UI-visible derived fields like Pass/Fail Status.

By combining these methods, you achieve a clean, efficient, and scalable RAP model that supports real-time business calculations while keeping the underlying data model simple and maintainable.

This approach can be extended for validations, analytical measures, financial calculations, or any scenario where derived fields should remain virtual yet visible in the application layer.

ABAP Development
ABAP Connectivity
SAP BTP ABAP environment

Advanced ABAP programming syntax

2025-12-10T12:12:09.269000+01:00

This blog is to provide new ABAP programming syntax along with some use case to ease and save development time of beginners and experienced professional who is looking for Advanced ABAP programming.

Many times, we come across a scenario where we have to bring data from different internal tables. As per traditional ABAP we use to loop the main internal table and then use READ TABLE statement for processing each field value.

Scenario: An internal table contains data passed from an API, we need to validate the data like check if Material, plant & storage location is valid or invalid from different value tables like T001W, T001L MARA etc

Old syntax:

New Syntax:

FOR keyword is used for main LOOP--ENDLOOP and LET---VALUE keyword allows you to declare work area for different Internal table like READ STATEMENTS and COND.. WHEN..THEN keyword will allow you to set the conditions.

Scenario: Many times, we need to append values to the internal table already holding some records then we have to use the BASE keyword.

Scenario: To create Range table from entries of different internal table

Scenario: To pass entries from one internal table to another based on filtering using FILTER keyword. Note: Internal table should be of SORTED or HASHED table type with KEY.

To calculate sum in internal table we use REDUCE statement

Output: Total Salary: 39000

Scenario: GROUP BY statement is used to group the data like for example Order containing multiple item details and we want to pass each order detail to some BAPI for data update.

Hope it helps the members looking for quick info on Advanced ABAP programming.

Next time will try to cover the CDS entities and RAP ABAP blogs. Till then happy coding 🙂

Convert XML File to Internal Table And Download Into CSV Format In ABAP

2025-12-12T07:59:31.023000+01:00

Introduction:
In most SAP ABAP projects, file uploads are a very common requirement—particularly in formats like TXT, CSV, or Excel. These formats are straightforward to parse using standard approaches such as GUI_UPLOAD, CL_GUI_FRONTEND_SERVICES, or transformations.

However, during a recent requirement, I encountered a different scenario:
the business team wanted to upload an XML file, extract specific fields from the XML structure, convert the values into an ABAP internal table, and finally allow users to download the processed data in CSV format.
While XML is widely used for integrations, parsing XML inside ABAP is not as common in day-to-day development—especially when the XML structure is nested and needs to be converted into a flattened internal table.
This made the requirement both interesting and challenging:
How do we read an XML file from the presentation server?
How do we parse the XML structure into an easily consumable internal table?
How do we convert the extracted data into a CSV file dynamically?
How do we present the parsed data to the user (ALV) before export?
SAP fortunately provides powerful XML-handling tools such as CL_XML_DOCUMENT and SMUM_XML_PARSE, which help convert XML into a tree-like format that can be processed easily. Using these, we can extract required data nodes (like EmpID, EmpName, Salary) and map them into a custom structure.

This blog explains the complete end-to-end solution:

Reading XML from local file
Parsing XML using SMUM_XML_PARSE
Populating an internal table
Displaying the result in ALV
Exporting the final output to CSV
This approach can be reused for any XML To ABAP conversion scenario, not just employee data. Whether you are processing orders, invoices, or custom data feeds, the same logic applies with minor adjustments.

" Data declarations
DATA: gcl_xml       TYPE REF TO cl_xml_document,
      gv_xml_string TYPE xstring,
      gv_size       TYPE sytabix,
      gt_xml_data   TYPE TABLE OF smum_xmltb,
      gwa_xml_data  TYPE smum_xmltb,
      gt_return     TYPE TABLE OF bapiret2.

" Employee structure
TYPES: BEGIN OF ty_employee,
         empid   TYPE char10,
         empname TYPE char50,
         salary  TYPE char15,
       END OF ty_employee.

DATA: gt_employees TYPE TABLE OF ty_employee,
      gwa_employee TYPE ty_employee.

" File parameter
PARAMETERS: p_file TYPE ibipparms-path.

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

START-OF-SELECTION.

  " Create XML document object
  CREATE OBJECT gcl_xml.

  " Import XML from file
  gcl_xml->import_from_file( filename = p_file ).

  IF sy-subrc = 0.
    " Render XML to xstring
    gcl_xml->render_2_xstring( IMPORTING
                               stream = gv_xml_string
                               size = gv_size ).

    IF sy-subrc = 0.
      " Parse XML
      CALL FUNCTION 'SMUM_XML_PARSE'
        EXPORTING
          xml_input = gv_xml_string
        TABLES
          xml_table = gt_xml_data
          return    = gt_return.

      IF sy-subrc = 0.
        " Process XML data to extract employee information
        LOOP AT gt_xml_data INTO gwa_xml_data.
          CASE gwa_xml_data-cname.
            WHEN 'EmpID'.
              gwa_employee-empid = gwa_xml_data-cvalue.
            WHEN 'EmpName'.
              gwa_employee-empname = gwa_xml_data-cvalue.
            WHEN 'Salary'.
              gwa_employee-salary = gwa_xml_data-cvalue.
              " Append when all fields are collected
              APPEND gwa_employee TO gt_employees.
              CLEAR gwa_employee.
          ENDCASE.
        ENDLOOP.

        " Display data using ALV
        IF gt_employees IS NOT INITIAL.
          TRY.

              CALL METHOD cl_salv_table=>factory
                IMPORTING
                  r_salv_table = data(lo_alv)
                CHANGING
                  t_table      = gt_employees.

              " Get columns object
              DATA(lo_columns) = lo_alv->get_columns( ).
              lo_columns->set_optimize( abap_true ).

              " Set column headers
              TRY.
                  DATA(lo_column) = lo_columns->get_column( columnname = 'EMPID' ).
                  lo_column->set_long_text( 'Employee ID' ).
                  lo_column->set_medium_text( 'Emp ID' ).
                  lo_column->set_short_text( 'EmpID' ).
                CATCH cx_salv_not_found.
              ENDTRY.

              TRY.
                  lo_column = lo_columns->get_column( columnname = 'EMPNAME' ).
                  lo_column->set_long_text( 'Employee Name' ).
                  lo_column->set_medium_text( 'Emp Name' ).
                  lo_column->set_short_text( 'EmpName' ).
                CATCH cx_salv_not_found.
              ENDTRY.

              TRY.
                  lo_column = lo_columns->get_column( columnname = 'SALARY' ).
                  lo_column->set_long_text( 'Employee Salary' ).
                  lo_column->set_medium_text( 'Salary' ).
                  lo_column->set_short_text( 'Salary' ).
                CATCH cx_salv_not_found.
              ENDTRY.

              " Display ALV
              lo_alv->display( ).

            CATCH cx_salv_msg.
          ENDTRY.
        ENDIF.
      ENDIF.
    ENDIF.

  ENDIF.
Data : IOUT          TYPE TABLE OF STRING,
      XOUT TYPE STRING.
      FIELD-SYMBOLS: <FS>.


  LOOP AT GT_EMPLOYEES INTO GWA_EMPLOYEE.

    CLEAR XOUT.
    DO.
      ASSIGN COMPONENT SY-INDEX OF STRUCTURE GWA_EMPLOYEE TO <FS>.
      IF SY-SUBRC <> 0.
        EXIT.
      ENDIF.
      IF SY-INDEX = 1.
        XOUT = <FS>.
      ELSE.
        CONCATENATE XOUT <FS> INTO XOUT SEPARATED BY ','.
      ENDIF.
    ENDDO.

    APPEND XOUT TO IOUT.

  ENDLOOP.

  CALL FUNCTION 'GUI_DOWNLOAD'
    EXPORTING
      FILENAME = 'C:- Tech_csv.csv'
    TABLES
      DATA_TAB = IOUT.

Conclusion:

This blog demonstrated a clear and practical approach to reading XML files in ABAP and transforming their contents into structured data using the Factory Method pattern. By separating file parsing, object creation, and data handling, the solution becomes more scalable, maintainable, and easy to extend for future XML formats. This design not only improves code readability but also ensures that enhancements or format changes can be accommodated with minimal impact on existing logic.

ABAP Development
ABAP Connectivity

Dynamic ALV Grid Output Using SALV and Docking Container in ABAP

2025-12-12T08:04:03.442000+01:00

Hi Everyone,

Recently, I worked on a requirement where the ALV output needed to appear dynamically on the same screen using a docking container instead of a separate list output. This makes the UI much more user-friendly, especially when running programs multiple times during testing.

While SALV handles the ALV part, the interesting part is embedding it inside a docking container placed at the bottom of the screen.
Below is a simple example using the SFLIGHT table. I drafted this article with support from a generative AI tool, but the explanation and experiences shared here are based on my own learning and practical testing.

REPORT ZALV_SALV_DOCK_DEMO.


CLASS LCL_REPORT DEFINITION.
  PUBLIC SECTION.
    DATA: LT_DATA   TYPE STANDARD TABLE OF SFLIGHT,     "Output data
          LR_CARRID TYPE RANGE OF SFLIGHT-CARRID.      "Select Options

    METHODS:
      GET_DATA,
      GENERATE_OUTPUT.
ENDCLASS.

DATA: LR_REPORT TYPE REF TO LCL_REPORT,
      G_CARRID  TYPE SFLIGHT-CARRID.


SELECTION-SCREEN BEGIN OF BLOCK BLK1 WITH FRAME TITLE G_TITLE.
SELECT-OPTIONS: S_CARRID FOR G_CARRID.
SELECTION-SCREEN END OF BLOCK BLK1.

INITIALIZATION.
  G_TITLE = 'Selection Criteria'.
  CREATE OBJECT LR_REPORT.
  LR_REPORT->GENERATE_OUTPUT( ).

START-OF-SELECTION.
  LR_REPORT->LR_CARRID = S_CARRID[].
  LR_REPORT->GET_DATA( ).

*---------------------------------------------------------------------*
* Class Implementation
*---------------------------------------------------------------------*
CLASS LCL_REPORT IMPLEMENTATION.

  METHOD GET_DATA.
    "Fetch data
    SELECT *
      FROM SFLIGHT
      INTO TABLE ME->LT_DATA
      WHERE CARRID IN LR_CARRID.

    IF SY-DBCNT IS INITIAL.
      MESSAGE S398(00) WITH 'No data selected'.
    ENDIF.

    "Export to memory
    EXPORT DATA = ME->LT_DATA TO MEMORY ID SY-CPROG.
  ENDMETHOD.


  METHOD GENERATE_OUTPUT.
    DATA: LR_DOCK      TYPE REF TO CL_GUI_DOCKING_CONTAINER,
          LR_CONTAINER TYPE REF TO CL_GUI_CONTAINER,
          LR_ALV       TYPE REF TO CL_SALV_TABLE.

    "Import internal table
    IMPORT DATA = ME->LT_DATA FROM MEMORY ID SY-CPROG.
    FREE MEMORY ID SY-CPROG.

    CHECK ME->LT_DATA IS NOT INITIAL.

    "Create docking container at bottom
    CREATE OBJECT LR_DOCK
      EXPORTING
        REPID = SY-CPROG
        DYNNR = SY-DYNNR
        RATIO = 80
        SIDE  = CL_GUI_DOCKING_CONTAINER=>DOCK_AT_BOTTOM
        NAME  = 'DOCK_CONT'.

    "Container assignment
    LR_CONTAINER ?= LR_DOCK.

    TRY.
        "Create SALV inside the docking container
        CL_SALV_TABLE=>FACTORY(
          EXPORTING
            LIST_DISPLAY   = IF_SALV_C_BOOL_SAP=>FALSE
            R_CONTAINER    = LR_CONTAINER
            CONTAINER_NAME = 'DOCK_CONT'
          IMPORTING
            R_SALV_TABLE   = LR_ALV
          CHANGING
            T_TABLE        = ME->LT_DATA ).
      CATCH CX_SALV_MSG.
    ENDTRY.

    "Enable standard functions
    DATA(LR_FUNCTIONS) = LR_ALV->GET_FUNCTIONS( ).
    LR_FUNCTIONS->SET_DEFAULT( ABAP_TRUE ).

    "Display ALV
    LR_ALV->DISPLAY( ).
  ENDMETHOD.

ENDCLASS.

The ALV appears at the bottom of the same screen
All SALV functions like sorting, filtering, and export are enabled
Code is modular and reusable
This example is useful when building interactive ABAP reports where the user should not leave the main selection screen. Using a docking container provides a clean and modern presentation for your ALV list.
If you want to display multiple ALVs, add toolbars, or enhance SALV—for example with custom columns—I’d be happy to share extended examples as well.

Selection Screen :

After Executing :
✅ Conclusion (Detailed & Explanatory)
By embedding the ALV Grid inside a docking container, we avoid the traditional list output and deliver a more user-friendly experience directly on the selection screen. SALV handles the formatting and functions, while the docking container ensures a flexible and consistent UI layout. This technique is highly useful for interactive reports, dashboards, and test-driven programs. While AI helped in organizing and refining the content, the logic, experimentation, and lessons shared are based on my own practical ABAP development work.

ABAP Development
SAP BTP ABAP environment

Editable ALV Report with Row-Based Field Editing and Custom F4 Help Using OOP in ABAP

2025-12-12T08:08:44.264000+01:00

Introduction:

This blog shows how to create an editable ALV grid in ABAP using CL_GUI_ALV_GRID, where only selected rows can be changed. It also explains how to add a custom F4 help to guide users with valid input. Together, these features make data editing easier, safer, and more user-friendly.

Solution Overview:

This ABAP report features an editable ALV grid built using Object-Oriented programming with CL_GUI_ALV_GRID. It allows users to edit a specific field only for the rows they explicitly select, ensuring controlled and precise data modification.

Additionally, a custom F4 help is implemented for one of the fields, providing tailored input assistance beyond the standard SAP search help. This approach improves data accuracy, enhances user experience, and supports business processes that require selective, validated updates to records within an ALV grid.

Selection-Screen:

Screen 100 - OUTPUT Module:

*------------------------------------------------------------------------------*
* MODULE: PBO
*------------------------------------------------------------------------------*
module status_0100 output.
  set pf-status 'ZSTATUS'.

  if gr_cont is initial.

    create object gr_cont
      exporting
        container_name = 'CNTNR'.

    create object gr_grid
      exporting
        i_parent = gr_cont.

    call method gr_grid->set_table_for_first_display
      exporting
        i_structure_name = 'TY_STATUS'
        is_layout        = gs_layout
      changing
        it_fieldcatalog  = gt_fcat
        it_outtab        = gt_data.

    create object gr_event_receiver.
    set handler gr_event_receiver->on_f4 for gr_grid.
  endif.
endmodule.

Screen 100 - INPUT Module:

*------------------------------------------------------------------------------*
* MODULE: PAI
*------------------------------------------------------------------------------*
module user_command_0100 input.
  gv_okcode = sy-ucomm.

  case gv_okcode.

    when 'BACK'.
      leave to screen 0.

    when 'EDIT'.
      gr_grid->check_changed_data( ).
      perform set_cell_styles using abap_true .
      perform refresh_grid.

    when 'SAVE'.
      perform save_to_db.
      perform set_cell_styles using  abap_false.
      perform refresh_grid.

    when 'REFRESH'.
      perform get_data.
      perform set_cell_styles using  abap_false.
      perform refresh_grid.

    when 'SELECT'.
      perform selectall.
      perform refresh_grid.

    when 'DESELECT'.
      perform deselect.
      perform set_cell_styles using  abap_false.
      perform refresh_grid.
  endcase.
endmodule.

Custom F4 Help Event Handler :

A handler class registers for the STATUS field's F4 event to display allowed flags ('X', 'P', blank) via F4IF_INT_TABLE_VALUE_REQUEST.

class cl_event_receiver definition. 
   public section. 
     methods: on_f4 for event onf4 of cl_gui_alv_grid 
       importing er_event_data e_fieldname es_row_no . 
     methods: constructor. 
  
 endclass.        

class cl_event_receiver implementation. 
  
  method constructor. 
     set handler on_f4 for gr_grid. 
     gr_grid->register_f4_for_fields( 
         it_f4 = value #( ( fieldname = 'STATUS' register = 'X' chngeafter = 'X' ) ) ). 
  
  endmethod. 
  
  method on_f4. 
   DATA: lt_return TYPE TABLE OF DDSHRETVAL. 
   
   if e_fieldname = 'STATUS'. 
  
       select distinct status from zdel_status into table (lt_flag) WHERE status NE ''. 
        APPEND INITIAL LINE TO lt_flag. 
  
       call function 'F4IF_INT_TABLE_VALUE_REQUEST' 
           exporting 
             retfield        = 'STATUS' 
             value_org       = 'S' 
           tables 
             value_tab       = lt_flag 
             return_tab      = lt_return 
           exceptions 
             parameter_error = 1 
             no_values_found = 2 
           others            = 3. 
  
      if sy-subrc = 0 and lt_return is not initial. 
  
        field-symbols <table_modi> type lvc_t_modi. 
         assign er_event_data->m_data->* to <table_modi>. 
         <table_modi> = value #( 
                     base <table_modi> 
                     ( row_id    = es_row_no-row_id 
                       fieldname = e_fieldname 
                       value     = lt_return[ 1 ]-fieldval ) ). 
         er_event_data->m_event_handled = 'X'. 
       endif. 
  
    endif. 
   endmethod.

Enable Editing on Selected Rows

When users click Edit, the STATUS column for selected rows becomes editable.

form set_cell_styles using   iv_enable type abap_bool . 
  
  loop at gt_data assigning field-symbol(<ls_data>). 
     clear <ls_data>-celltab. 
     if iv_enable = abap_true and <ls_data>-sel = abap_true. 
       data(ls_style) = value lvc_s_styl( 
                                         fieldname = 'STATUS' 
                                          style     = cl_gui_alv_grid=>mc_style_enabled ). 
       append ls_style to <ls_data>-celltab. 
     endif. 
   endloop. 
  
endform. 

form refresh_grid. 
   if gr_grid is bound. 
     gr_grid->refresh_table_display( 
       exporting is_stable = value lvc_s_stbl( row = 'X' col = 'X' ) ). 
   endif. 
 endform.

Save Changes Back to Database:

Only records marked with sel = abap_true are updated, with feedback on how many records were changed.

form save_to_db. 
   gr_grid->check_changed_data( ). 
  
  data count type i. 
   loop at gt_data assigning field-symbol(<ls_data>) where sel = abap_true. 
     update zdel_status 
       set   status     = <ls_data>-status 
       where plant      = <ls_data>-plant 
       and deliveryno = <ls_data>-deliveryno. 
     count = count + 1. 
     if sy-subrc = 0. 
       <ls_data>-sel = abap_false. 
     endif. 
   endloop. 
   message count && ' Records Updated Successfully.' type 'S'. 
   commit work. 
 endform.

Changes are updated in database table:

When clicking on ‘Refresh’ button it will display the old value of the field.

In edit mode of the field :

The values are changed:

Before saving click on refresh :

When click on ‘Select’, it will select all records through checkboxes :

form selectall . 
  
  loop at gt_data assigning field-symbol(<ls_data>). 
     <ls_data>-sel = abap_true. 
   endloop. 
 endform.

All select and edit:

Clicking ‘Deselect’ will uncheck all currently selected records.

form deselect . 
   loop at gt_data assigning field-symbol(<ls_data>). 
     <ls_data>-sel = abap_false. 
   endloop. 
  
endform.

Tables: zdel_status. 
 *-----------------------------------------------------------------------------* 
 * Types Declaration 
 *-----------------------------------------------------------------------------* 
 types: begin of ty_status, 
          sel        type abap_bool, 
          plant      type zdel_status-plant, "Plant 
          deliveryno type zdel_status-deliveryno, "Delivery  Number 
          statustime type zdel_status-statustime, "Status Time 
          location   type zdel_status-location, "Location 
          status     type zdel_status-status, "Status 
          celltab    type lvc_t_styl, 
        end   of ty_status. 
 *-----------------------------------------------------------------------------* 
 * Data Declaration 
 *-----------------------------------------------------------------------------* 
 data: gt_data   type standard table of ty_status, 
       gr_grid   type ref to cl_gui_alv_grid, 
       gr_cont   type ref to cl_gui_custom_container, 
       gt_fcat   type lvc_t_fcat, 
       gs_layout type lvc_s_layo, 
       gv_okcode type sy-ucomm. 
 *------------------------------------------------------------------------------* 
 * Select Options and Parameters 
 *------------------------------------------------------------------------------* 
  
selection-screen begin of block bk1 with frame title text-t01. 
 select-options: s_plant  for zdel_status-plant, 
                 s_delv   for zdel_status-deliveryno. 
 selection-screen end of block bk1. 
  
*-------------------------------------------------------------------------------* 
 * F4 Help Event Handler Class 
 *-------------------------------------------------------------------------------* 
 class cl_event_receiver definition. 
   public section. 
     methods: on_f4 for event onf4 of cl_gui_alv_grid 
       importing er_event_data e_fieldname es_row_no . 
     methods: constructor. 
 endclass. 
  
class cl_event_receiver implementation. 
  method constructor. 
     set handler on_f4 for gr_grid. 
     gr_grid->register_f4_for_fields( 
             it_f4 = value #( ( fieldname = 'STATUS' register = 'X'    chngeafter = 'X' ) ) ). 
  endmethod. 
method on_f4. 
   DATA: lt_return TYPE TABLE OF DDSHRETVAL. 
  if e_fieldname = 'STATUS'. 
          select distinct status from zdel_status into table (lt_flag)   WHERE status NE ''. 
        APPEND INITIAL LINE TO lt_flag. 
  
       call function 'F4IF_INT_TABLE_VALUE_REQUEST' 
           exporting 
             retfield        = 'STATUS' 
             value_org       = 'S' 
           tables 
             value_tab       = lt_flag 
             return_tab      = lt_return 
           exceptions 
             parameter_error = 1 
             no_values_found = 2 
           others            = 3. 
  
      if sy-subrc = 0 and lt_return is not initial. 
  
        field-symbols <table_modi> type lvc_t_modi. 
         assign er_event_data->m_data->* to <table_modi>. 
         <table_modi> = value #( 
                     base <table_modi> 
                     ( row_id    = es_row_no-row_id 
                       fieldname = e_fieldname 
                       value     = lt_return[ 1 ]-fieldval ) ). 
         er_event_data->m_event_handled = 'X'. 
       endif. 
    endif. 
   endmethod. 
 endclass. 
 *------------------------------------------------------------------------------* 
 * Start Of Selection 
 *------------------------------------------------------------------------------* 
 start-of-selection. 
   perform get_data.
   perform build_fcat.
   perform build_layout.
   call screen 100.               // using call screen
   data: gr_event_receiver type ref to cl_event_receiver. 
 *------------------------------------------------------------------------------* 
 * FORM: get data 
 *------------------------------------------------------------------------------* 
 form get_data. 
   clear gt_data. 
  select plant, deliveryno, statustime, location, status 
     from zdel_status 
     into table (lt_status) 
     where plant in @s_plant. 
  
  loop at lt_status into data(ls_status). 
     append value ty_status( 
       sel        = abap_false 
       plant      = ls_status-plant 
       deliveryno = ls_status-deliveryno 
       statustime = ls_status-statustime 
       location   = ls_status-location 
       status     = ls_status-status ) to gt_data. 
   endloop. 
 endform. 
 *------------------------------------------------------------------------------* 
 * MODULE: PBO 
 *------------------------------------------------------------------------------* 
 module status_0100 output. 
   set pf-status 'ZSTATUS'.   //using custom set pf-status

  if gr_cont is initial. 

    create object gr_cont 
       exporting 
         container_name = 'CNTNR'. 
  
    create object gr_grid 
       exporting 
         i_parent = gr_cont. 
  
    perform build_fcat. 
  
    gs_layout-stylefname = 'CELLTAB'.   //container layout
     gs_layout-no_rowmark = 'X'. 
     gs_layout-no_toolbar = 'X'. 
  
    call method gr_grid->set_table_for_first_display 
       exporting 
         i_structure_name = 'TY_STATUS' 
         is_layout        = gs_layout 
       changing 
         it_fieldcatalog  = gt_fcat 
         it_outtab        = gt_data. 
  
    create object gr_event_receiver. 
     set handler gr_event_receiver->on_f4 for gr_grid.  
   endif. 
 endmodule. 
 *------------------------------------------------------------------------------* 
 * FORM: Bulid Field Catalog 
 *------------------------------------------------------------------------------* 
 form build_fcat. 
   clear gt_fcat. 
  gt_fcat = value lvc_t_fcat( ( fieldname = 'SEL'        col_pos = 1   coltext = 'Sel'               edit = abap_true  checkbox = abap_true ) 
                               ( fieldname = 'PLANT'      col_pos = 2 coltext = 'Plant'             edit = abap_false ) 
                               ( fieldname = 'DELIVERYNO' col_pos = 3 coltext = 'Delivery No'       edit = abap_false ) 
                               ( fieldname = 'STATUSTIME' col_pos = 4 coltext = 'Status Time'       edit = abap_false ) 
                               ( fieldname = 'LOCATION'   col_pos = 5 coltext = 'Location'          edit = abap_false ) 
                               ( fieldname = 'STATUS'     col_pos = 6 coltext = 'Status'            edit = abap_false f4availabl = 'X' ) ). 
 endform. 
*&---------------------------------------------------------------------*
*&      Form  BUILD_LAYOUT
*&---------------------------------------------------------------------*
form build_layout .
    gs_layout-stylefname = 'CELLTAB'.
    gs_layout-no_rowmark = 'X'.
    gs_layout-no_toolbar = 'X'.
endform.
 *------------------------------------------------------------------------------* 
 * MODULE: PAI 
 *------------------------------------------------------------------------------* 
 module user_command_0100 input. 
   gv_okcode = sy-ucomm. 
  
  case gv_okcode. 
  
    when 'BACK'. 
       leave to screen 0. 
  
    when 'EDIT'. 
       gr_grid->check_changed_data( ). 
       perform set_cell_styles using abap_true . 
       perform refresh_grid. 
  
    when 'SAVE'. 
       perform save_to_db. 
       perform set_cell_styles using  abap_false . 
       perform refresh_grid. 
  
    when 'REFRESH'. 
       perform get_data. 
       perform set_cell_styles using  abap_false . 
       perform refresh_grid. 
  
    when 'SELECT'. 
       perform selectall. 
       perform refresh_grid. 
  
    when 'DESELECT'. 
       perform deselect. 
       perform set_cell_styles using  abap_false.
       perform refresh_grid. 
   endcase. 
 endmodule. 
 *------------------------------------------------------------------------------* 
 * FORM: Set Cell Style Based On Checkbox 
 *------------------------------------------------------------------------------* 
 form set_cell_styles using   iv_enable type abap_bool . 
  
  loop at gt_data assigning field-symbol(<ls_data>). 
     clear <ls_data>-celltab. 
     if iv_enable = abap_true and <ls_data>-sel = abap_true. 
       data(ls_style) = value lvc_s_styl( 
                                         fieldname = 'STATUS' 
                                          style     = cl_gui_alv_grid=>mc_style_enabled ). 
       append ls_style to <ls_data>-celltab. 
     endif. 
   endloop. 
  
endform. 
 *------------------------------------------------------------------------------* 
 * FORM: Refresh Alv 
 *------------------------------------------------------------------------------* 
 form refresh_grid. 
   if gr_grid is bound. 
     gr_grid->refresh_table_display( 
       exporting is_stable = value lvc_s_stbl( row = 'X' col = 'X' ) ). 
   endif. 
 endform. 
 *------------------------------------------------------------------------------* 
 * FORM: Save Changes to ZDEL_STATUS 
 *------------------------------------------------------------------------------* 
 form save_to_db. 
   gr_grid->check_changed_data( ). 
  
  data count type i. 
   loop at gt_data assigning field-symbol(<ls_data>) where sel = abap_true. 
     update zdel_status 
       set   status     = <ls_data>-status 
       where plant      = <ls_data>-plant 
       and deliveryno = <ls_data>-deliveryno. 
     count = count + 1. 
     if sy-subrc = 0. 
       <ls_data>-sel = abap_false. 
     endif. 
   endloop. 
   message count && ' Records Updated Successfully.' type 'S'. 
   commit work. 
 endform. 
 *&---------------------------------------------------------------------* 
 *&      Form  SELECTALL 
 *&---------------------------------------------------------------------* 
 *       text 
 *----------------------------------------------------------------------* 
 *  -->  p1        text 
 *  <--  p2        text 
 *----------------------------------------------------------------------* 
 form selectall . 
  
  loop at gt_data assigning field-symbol(<ls_data>). 
     <ls_data>-sel = abap_true. 
   endloop. 
 endform. 
 *&---------------------------------------------------------------------* 
 *&      Form  DESELECT 
 *&---------------------------------------------------------------------* 
 *       text 
 *----------------------------------------------------------------------* 
 *  -->  p1        text 
 *  <--  p2        text 
 *----------------------------------------------------------------------* 
 form deselect . 
   loop at gt_data assigning field-symbol(<ls_data>). 
     <ls_data>-sel = abap_false. 
   endloop. 
  
endform.

Conclusion:

Implementing an editable ALV grid with selective row editing and a custom F4 help provides a powerful yet user-friendly way to manage data within SAP. By allowing updates only for chosen rows, you maintain control and reduce the risk of unintended changes. The addition of a tailored F4 help further enhances data quality by guiding users toward valid, business-specific input.

ABAP Development

ABAP Connectivity

ABAP Extensibility

Send an Email for an selected record Using a SAP RAP(RESTful ABAP Programming Model)

2025-12-12T08:44:04.273000+01:00

Hi Everyone,

Scenario : Sending an Email for a Selected Record Using the RAP Model

Introduction:

In an SAP S/4HANA system, there is a need to send an email notification when a user selects or processes a specific record in a RAP (RESTful ABAP Programming)–based application. For example, when a sales order, request, or approval record is selected in the Fiori Elements app, an email should automatically be triggered to the responsible user or approver.

1. Creation of Table :

@EndUserText.label : 'Service Header Table'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #ALLOWED
define table zva_hdr_service {
  key client    : abap.clnt not null;
  key serviceno : zva_serviceno not null;
  servicename   : zva_servicename;
  startdate     : abap.dats;
  enddate       : abap.dats;
  @Semantics.amount.currencyCode : 'zva_hdr_service.currency'
  amount        : abap.curr(8,2);
  currency      : abap.cuky;
  createdby     : uname;
  createdon     : datum;

}

2. Creation of Root View Entity :

In the SAP RESTful ABAP Programming Model (RAP), the Root View Entity is the main CDS view entity that defines the data model and structure of the root business object.
It serves as the entry point for the RAP business object and forms the foundation for its behavior and service exposure.

A Root View Entity is defined using the CDS keyword define root view entity. It typically represents the main database table or a combination of tables that store the business data.

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Root View'
@Metadata.ignorePropagatedAnnotations: true
define root view entity zva_header_serv_root as select from zva_hdr_service as Service
{
key Service.serviceno as Serviceno,
Service.servicename as Servicename,
Service.startdate as Startdate,
Service.enddate as Enddate,
@Semantics.amount.currencyCode: 'currency'
Service.amount as Amount,
Service.currency as Currency
}

3. Creation of Projection View for Root View Entity:

In SAP RAP, a Projection View is a Core Data Services (CDS) view that defines which parts of a Business Object (BO) — specifically its data and associations — are exposed to the outside world (for example, through an OData service or Fiori app).

It acts as a public interface of your business object.
While the Root View Entity defines the complete internal data model, the Projection View determines the external view that users or external systems can access.

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Projection View'
@Metadata.ignorePropagatedAnnotations: true
@Metadata.allowExtensions: true
define root view entity ZVA_HEADER_SERV_ROOT_pro as projection on zva_header_serv_root as Service
{
    key Service.Serviceno,
    Service.Servicename,
    Service.Startdate,
    Service.Enddate,
    @Semantics.amount.currencyCode: 'Currency'
    Service.Amount,
    Service.Currency
}

4. Creation of Metadata Extensions for Projection View:

Metadata extensions are used to define UI-specific annotations for CDS views. They allow the separation of concerns by keeping the data model independent of UI-related semantics. These extensions are particularly useful for defining Fiori UI layouts and behaviors without modifying the underlying CDS view.

@Metadata.layer: #CORE
annotate entity ZVA_HEADER_SERV_ROOT_pro
    with 
{
   
    :{ lineItem:[{ type: #FOR_ACTION , dataAction: 'SendEmail',label: 'Email' } ] }
    :{ lineItem:[{  position:1  }],
          selectionField: [{ position: 1 ,element: 'Serviceno'  }] }
    Serviceno;
    :{ lineItem: [{ label: 'Service Name' , position:2  }],
          selectionField: [{ position: 2 ,element: 'Servicename'  }] }
    Servicename;
    : { lineItem: [{ label: 'Start Date' , position:3  }],
            selectionField: [{ position: 3,element: 'Startdate'  }]       }
    Startdate;
     : { lineItem: [{ label: 'End Date' , position:4 }],
            selectionField: [{  position: 4 ,element: 'Enddate'}] }
    Enddate;
    .lineItem: [{ label: 'Amount' , position:5  }]
    Amount;
    .lineItem: [{ label: 'Currency' , position:6 }]
    Currency;  
}

5. Creation of Root Abstract Entity :

A Root Abstract Entity is a CDS construct designed for modeling complex input parameters or non-standard operations in RAP. Unlike root view entities, abstract entities are not tied to database tables.

@EndUserText.label: 'Email'
define root abstract entity zva_email_send
{
//    Email : char200; 
    Email : zva_email;  
}

6. Creation of Behavior Definition for Root View or Consumption View and implement the classes:

Behavior Definition (BDEF) is a key component that defines the transactional behavior of a RAP Business Object (BO). It specifies how the BO can be accessed and manipulated by consumers, such as creating, updating, or deleting records. The BDEF is always tied to a Core Data Services (CDS) data model, which includes at least one root entity.

A BDEF consists of two main parts: a header and one or more entity behavior definitions. The header defines the overall behavior, while the entity behavior definitions specify the characteristics and operations for each entity. These operations include standard actions like create, update, and delete, as well as custom actions, determinations, and validations.

managed implementation in class zbp_va_header_serv_root unique;
strict ( 2 );
define behavior for zva_header_serv_root alias Service
persistent table ZVA_HDR_SERVICE
lock master
authorization master ( instance )
//etag master <field_name>
{
  action SendEmail parameter zva_email_send;
}

Place the cursor on the class name, press ( Ctrl + 1 ), choose Implement the Class, and then activate the class.

CLASS lhc_Service DEFINITION INHERITING FROM cl_abap_behavior_handler.
  PRIVATE SECTION.
    METHODS get_instance_authorizations FOR INSTANCE AUTHORIZATION
      IMPORTING keys REQUEST requested_authorizations FOR Service RESULT result.
    METHODS SendEmail FOR MODIFY
      IMPORTING keys FOR ACTION Service~SendEmail.
ENDCLASS.
CLASS lhc_Service IMPLEMENTATION.
  METHOD get_instance_authorizations.
  ENDMETHOD.
  METHOD SendEmail.
  ENDMETHOD.
ENDCLASS.

Implementation of SendEmail Method:

  " Implementation of the custom action SendEmail
  METHOD SendEmail.
    " Get the first selected record from the action context
    DATA(ls_keys) = VALUE #( keys[ 1 ] OPTIONAL ).
    DATA(p_email) = ls_keys-%param-Email.
    "-------------------------
    " Step 1: Validate email
    "-------------------------
    IF p_email IS INITIAL.
      " No email provided -> return error message
      APPEND VALUE #( %tky = ls_keys-%tky
                      %msg = new_message( id = 'ZVA_MSG'
                                          number = '000'
                                          severity = if_abap_behv_message=>severity-error ) )
             TO reported-Service.
      RETURN.
    ENDIF.

    IF NOT p_email CP '*@*.*'.
      " Invalid email format -> return error message
      APPEND VALUE #( %tky = ls_keys-%tky
                      %msg = new_message( id = 'ZVA_MSG'
                                          number = '001'
                                          severity = if_abap_behv_message=>severity-error ) )
             TO reported-Service.
      RETURN.
    ENDIF.

    "-------------------------
    " Step 2: Read service data
    "-------------------------
    READ ENTITIES OF zva_header_serv_root
      ENTITY Service
      ALL FIELDS
      WITH VALUE #( ( Serviceno = ls_keys-Serviceno ) )
      RESULT DATA(lt_serv).

    DATA(ls_serv) = lt_serv[ 1 ].

    "-------------------------
    " Step 3: Prepare and send email
    "-------------------------
    TRY.
        " Create persistent send request (BCS)
        DATA(lo_send_request) = cl_bcs=>create_persistent( ).

        " Prepare HTML email body
        DATA: lt_body TYPE soli_tab,
              lv_html TYPE string,
              lv_text TYPE string.

        lv_text = 'Hi Good Morning..'.

        " Add HTML table header
        CONCATENATE
          '<html><body>'
          '<p>' lv_text '</p>'
          '<h3>Service Details</h3>'
          '<table border="1" cellpadding="8" cellspacing="0" style="border-collapse:collapse;">'
          '<tr>'
          '<th>Service Number</th>'
          '<th>Service Name</th>'
          '<th>StartDate</th>'
          '<th>EndDate</th>'
          '<th>Amount</th>'
          '</tr>'
          INTO lv_html SEPARATED BY space.

        APPEND lv_html TO lt_body.
        CLEAR lv_html.

        " Add dynamic service data rows
        LOOP AT lt_serv INTO ls_serv.
          DATA(lv_amount) = ls_serv-Amount.
          CONCATENATE
            '<tr>'
            '<td>' ls_serv-Serviceno '</td>'
            '<td>' ls_serv-Servicename '</td>'
            '<td>' ls_serv-Startdate '</td>'
            '<td>' ls_serv-Enddate '</td>'
            '<td>' lv_amount '</td>'
            '</tr>'
            INTO lv_html SEPARATED BY space.
          APPEND lv_html TO lt_body.
          CLEAR lv_html.
        ENDLOOP.

        " Set up document object for the email
        DATA(lo_document) = cl_document_bcs=>create_document(
                              i_type    = 'HTM'
                              i_text    = lt_body
                              i_subject = 'Service Details' ).

        " Add document to send request
        lo_send_request->set_document( lo_document ).

        " Set sender as current SAP user
        lo_send_request->set_sender( cl_sapuser_bcs=>create( sy-uname ) ).

        " Add recipient email
        lo_send_request->add_recipient(
          i_recipient = cl_cam_address_bcs=>create_internet_address( p_email ),
          i_express   = abap_true ).

        " Send the email
        DATA(lv_sent_to_all) = lo_send_request->send( ).

    ENDTRY.

    "-------------------------
    " Step 4: Show success or error messages
    "-------------------------
    IF lv_sent_to_all = abap_true.
      " Email sent successfully
      APPEND VALUE #( %tky = ls_keys-%tky
                      %msg = new_message( id = 'ZVA_MSG'
                                          number = '002'
                                          severity = if_abap_behv_message=>severity-success ) )
             TO reported-Service.
    ELSE.
      " Email sending failed
      APPEND VALUE #( %tky = ls_keys-%tky
                      %msg = new_message( id = 'ZVA_MSG'
                                          number = '003'
                                          severity = if_abap_behv_message=>severity-error ) )
             TO reported-Service.
    ENDIF.
  ENDMETHOD.

7. Creation of Behavior Definition for Projection View and Implement the classes :

A Behavior Projection maps the transactional capabilities of the base behavior definition to a projection view. This allows for further customization of the behavior for specific use cases. For example:

projection implementation in class zbp_va_header_serv_root_pro unique;
strict ( 2 );
define behavior for ZVA_HEADER_SERV_ROOT_pro //alias <alias_name>
{
 use action SendEmail ;
}

Place the cursor on the class name, press ( Ctrl + 1 ), choose Implement the Class, and then activate the class.

8. Creation of Service Definition for Consumption View :

@EndUserText.label: 'Service Definition'
define service ZVA_HEADER_SERV_ROOT_PRO_SD {
  expose ZVA_HEADER_SERV_ROOT_pro;
}

9. Creation of Service Binding for Service Definition:

Click on public button and activate

Click on preview button then navigate the fiori .

Click on a Email button then open a popup then provide the email id.

if email id is not provided it's shows the error and incorrect email provided also shows a error message.

Email sent successful then shows the success message.

Go to SOST t-code we will check the the record.

Select the record and click on display button

Summary:

In this implementation, a custom action SendEmail is added to a RAP BO to allow users to send an email containing service details directly from the application.

1. Email Validation

The action first retrieves the email ID passed through the action parameters.
It performs two validations:

Checks if the email field is empty
Checks if the email format is valid using a simple pattern *@*.*
If the validation fails, an error message is returned using RAP messaging.

2. Reading Service Data

The code reads the selected service record from the root entity (zva_header_serv_root) using READ ENTITIES.
The retrieved fields are later used to dynamically build the email content.

3. Building and Sending the Email

The email is sent using SAP Business Communication Services (BCS):

A persistent send request (cl_bcs) is created
An HTML email body is built, including:
- Greeting text
- A formatted HTML table
- Dynamically added service details
The document is attached to the send request as an HTML email (HTM)
Sender is set as the logged-in SAP user
Recipient is the email address entered by the user
The email is finally sent using send( )

4. Success & Error Handling

After sending, the system returns:

A success message if the email was sent
An error message if the sending process failed

These messages are reported back through RAP’s reported- structure.

ABAP Development ,

SAP Fiori for SAP S/4HANA ,

ABAP Platform in SAP S/4HANA Cloud Private Edition and SAP S/4HANA 2025

2025-12-14T23:10:11.122000+01:00

SAP S/4HANA Cloud Private Edition and SAP S/4HANA 2025 were released to the SAP customer base on October 8, 2025.

ABAP Platform 2025 is the technology platform underlying the release 2025 of SAP S/4HANA Cloud Private Edition and SAP S/4HANA and is shipped as part of these products, supporting only SAP HANA database with full exploitation of its advanced capabilities. In addition, ABAP Platform 2025 is part of SAP S/4HANA Foundation 2025 for SAP HANA-only Add-Ons.

ABAP Platform 2025 is not shipped as a standalone product. ABAP Platform 2025 consists of the AS ABAP, the ABAP development tools for Eclipse, and several additional technology components which are required to run SAP S/4HANA Cloud Private Edition and SAP S/4HANA.

Previous versions of SAP S/4HANA Private Edition and SAP S/4HANA such as 1610, 1709, 1809, 1909, 2020, 2021, 2022 and 2023 can be upgraded directly to the 2025 release, which is based on ABAP Platform 2025 (corresponding to SAP_BASIS 816).

Product Highlights

Presentation

This presentation provides the SAP official external slide deck, just click on it to view:

Overview

ABAP Platform 2025 delivers innovations for the ABAP stack in different areas.

Clean core development

In August 2025, SAP enhanced its extensibility guidelines by introducing the new Clean core extensibility white paper. The sustainable and upgrade-safe ABAP extensibility model in SAP S/4HANA Cloud Private Edition and SAP S/4HANA fully relies on SAP clean core guiding principles, aiming to decouple custom extensions from SAP standard whenever possible. The refined SAP guidance for extensibility replaces binary clean core decisions with a more nuanced evaluation of classic ABAP extensions based on the clean core level concept. Evolving from the previous 3-tier model, the new extensibility model categorizes extensions into four levels (A, B, C, and D) and provides rules for ABAP classic extensions to meet the clean core level qualifications. Following this new clean core extensibility guidance the ABAP extensibility guide was updated with technical guidelines to support the clean core level concept. The ABAP extensibility model was changed from 3-tier model to ABAP Cloud development (level A) and classic ABAP development (levels B, C and D).

The overall clean core guidance remained unchanged: always striving for the highest possible level of extensibility. ABAP Cloud is the SAP’s recommended development model for all new custom extensions in SAP S/4HANA private cloud and on-premise systems, whereby the classic ABAP extensibility can still be used to reach clean core, with a focus on upgrade-stability and code quality. This enables SAP customers and partners to transition to a clean core incrementally and at their own speed. SAP provides guidance for ABAP clean core development by offering a recommended list of APIs (so-called “classic APIs”) to be used in classic ABAP development. For governance of ABAP clean core development, the ABAP test cockpit (ATC) now supports the clean core level concept with new ATC checks (see the blog post ABAP test cockpit (ATC) recommendations for governance of clean core ABAP development). For governance of ABAP development for clean core in SAP S/4HANA private cloud or on-premise systems the remote ATC in SAP BTP ABAP environment is the SAP recommended approach.

SAP Joule for Developers, ABAP AI capabilities

SAP Joule for Developers, ABAP AI capabilities are now key components and an integral part of AI-assisted ABAP Cloud development, also facilitating custom code transformation from ECC to SAP S/4HANA. The capabilities supporting developer tasks include Joule copilot in ABAP development tools for Eclipse, predictive code completion, code explanation and unit test generation for ABAP and ABAP CDS, app and service generation (including RAP BO generation), predictive business logic for RAP BOs, and OData consumption. The provided ABAP AI SDK, powered by Intelligent Scenario Lifecycle Management (ISLM), can be utilized for the implementation of AI capabilities in custom applications.

The custom code migration capabilities include docs chat for questions around custom code migration and S/4HANA simplifications, explanation of business purpose and processing logic of legacy code (ABAP reports), explanation of S/4HANA-related ATC findings in custom code, along with resolution recommendations based on S/4HANA simplification items and cookbooks (see the blog post SAP Joule for Developers Expands to Private Cloud: Accelerating ABAP Innovation and Transformation).

ABAP RESTful Application Programming Model (RAP)

Another major investment area in the 2025 release is the ABAP RESTful Application Programming Model, which powers modern development in both ABAP Cloud and classic ABAP, enabling the creation of delightful transactional SAP Fiori apps as well as local and web APIs. This release delivers new features to accelerate and enhance the development with RAP, including new generators to boost efficiency, support of CDS table entities as persistence layer, various capabilities for SAP Fiori elements-based UIs, such as collaborative draft, cross-BO scenarios, tree views, and event-driven side effects, as well as end-to-end extensibility options.

New ABAP Cloud generators for creating OData UI services with RAP BOs (with one or more entities) from scratch, with or without AI assistance, or for generating custom UI service based on RAP BO interface are provided. ABAP CDS table entities can be used as active persistence layer for managed RAP BOs without draft, replacing classic dictionary database tables.

Enhancements for building of SAP Fiori elements-based apps with RAP include the collaborative draft handling, which allows multiple users to work simultaneously and collaboratively on the same draft instance of an entity without blocking one another. You can now also build SAP Fiori UIs that use multiple RAP BOs interacting with each other. These cross-BO scenarios rely on cross-BO transactional enablement, where the entities of the participating RAP BOs are linked through so-called cross-BO associations. Read-only and editable tree view supports displaying and manipulating hierarchical data in SAP Fiori UIs, with options for drag and drop, cut and paste, reordering, and cascading delete. Event-driven RAP side effects enable asynchronous updates in SAP Fiori UIs. When such a specific RAP business event is raised, the associated side effect is triggered, and the defined targets are reloaded in the UI.

The privileged context can now be propagated in subsequent Entity Manipulation Language (EML) requests in reading and modifying operation. Further enhancement for the behavior definitions and the behavior pools are provided with this release.

ABAP development tools for Eclipse (ADT)

Various enhancements are provided in ABAP development tools for Eclipse for ABAP development, RAP and ABAP CDS related development aspects, testing and troubleshooting, as well as overall IDE and productivity improvements.

Refactoring support for ABAP classes and interfaces was improved by activation of renaming changes by default, validation of new names and displaying long texts of exceptions. The new where-used dialog enables prefiltering of search results to focus on usages relevant for the concrete use case. There is a new property abaplv to filter object searches with the ABAP language version. There are new editors like for example for working with software component relations, Adobe Forms or maintaining intelligent scenarios and intelligent scenarios models which are required to run a solution based on generative AI. It is possible to create and edit CDS table entities and create for them behavior definitions.

In the area of ABAP unit tests, method calls in test classes can now be highlighted in different colors to distinguish their method contexts. Quick actions allow tests to be launched or templates for test classes to be inserted with a single mouse click. The failed assertions and status of test methods can be displayed directly in the source code editor. The unit tests can be rerun with coverage and coverage results can be cleared in the ABAP Coverage view. Additionally, there is a new AMDP Test Double Framework, and the CDS Test Double Framework now supports CDS hierarchy views.

In the ABAP debugger, it is now possible to display the memory consumption of a debugged ABAP program in the new ABAP Memory (Debugger) view. The ABAP Memory Snapshot view lists all memory snapshots, which can be opened in the editor to show memory objects ranked by size. These views make it easier to analyze the memory usage of an ABAP application. Internal tables can now be easily compared using the table comparison tool within the ABAP debugger. Beyond this, the ABAP debugger can now consider variables with hidden values (for sensitive data), display variables of type JSON, and show component groups for nested structures in the Variables view. Collaborative error analysis is supported by export/import of ABAP Cross Trace results to/from JSON file or export of short dumps as ZIP file in the ABAP Runtime Error Viewer.

Beyond this there are also enhancements in transport management for adding an object to a transport or searching and grouping transport requests.

ABAP Language

The modern, declarative, and expression-oriented ABAP language allows writing simple and concise ABAP code through features such as inline declarations and constructor expressions. Advanced operations for internal tables include grouping, filtering, and the CORRESPONDING( ) operator. The cloud-optimized version “ABAP for Cloud Development” is used for ABAP Cloud development.

There are further enhancements for internal tables, including support for arbitrary logical expressions and equality conditions, as well as harmonization of table expressions and READ TABLE statement. New ABAP system classes for probability distributions are provided, enabling the generation of random number and the calculation of quantile, probabilities, and other aspects. These classes support various discrete and continuous distributions. This release also delivers enhancements for expressions and functions, as well as for transformations, such as the new domain XSDGEO for serializing and deserializing spatial data between the Extended Well-Known Binary (EWKB) representation and the GeoJSON format.

SAP HANA-centric optimizations & Data Integration scenarios

Modern ABAP development on SAP HANA has been enhanced with several advanced, database-centric features also enriching data integration scenarios. Recent innovations in data integration focus on data exposure, including ABAP-managed database procedures for advanced read scenarios. With CDS updatable view entities it is now possible to wrap existing DDIC database tables (or CDS table entities) and expose a native CDS signature, which can be used with ABAP SQL in combination with DCL-based access control.

On the consumption side, new write scenarios, the use of static CDS external entities, and the possibility to create ABAP CDS models based on imported CDS models make it easier than ever to integrate external data seamlessly into an ABAP CDS view stack.

Additional enhancements, such as CDS table entities to define and manage SAP HANA database tables as native CDS repository objects, a CDS generation wizard to simplify and automate the creation of hierarchically structured data in ABAP CDS, and AI-powered CDS Explain to get semantical context information about CDS entities further brighten the ABAP development landscape.

Embedded analytics

For embedded analytics scenarios it is now possible to expedite development workflow using ABAP Cloud generator wizards for creation of multidimensional analysis apps, Review Booklet apps, or native CDS hierarchy definitions. With the introduction of reusable measures and filters, the key figures, measures, filters and many more features can now be defined centrally, based on user needs to better manage and align analytical reporting. They can also be utilized in CDS view entities to ensure homogenous definition of complex calculations and unification of coherences of the running business.

Event Enablement & Business Events

The event-driven architecture of SAP S/4HANA Cloud Private Edition and SAP S/4HANA is strengthened, and the interoperability across enterprise solutions is improved through seamless integration with SAP Event Mesh Advanced Plan and support of SAP Cloud Application Event Hub to consume events published by SAP Order Management Foundation on SAP BTP.

The event-driven processing and monitoring was enhanced with new outbound event filtering, enabling selective publishing based on configurable criteria, and dynamic topics in SAP Event Mesh Advanced Plan for more efficient routing. Operational transparency was improved through comprehensive event logging, including local capture and logging of successfully processed events. Events of the same type and object within a session can now be grouped as activities, improving traceability and reducing monitoring noise. Together, these features provide a scalable and well-governed foundation for event-driven architecture.

Process integration & Connectivity

Key highlights of process integration include a robust OData service consumption model with Swagger UI preview and advanced OData V4 capabilities, such as bulk processing and asynchronous communication integrated with AIF. The API governance and communication management was enhanced by introducing Communication Targets within Communication Arrangements, enabling more granular control over connectivity endpoints. API lifecycle management is improved through API-to-package assignment and the ability to create API packages for better organization across API types. Additionally, OData-based access to Communication Management data increases automation, transparency, and integration with external tools.

Additional connectivity improvements include outbound communication enablement via HTTP and RFC, support for setting the AIR key as a custom HTTP header in SOAP requests for more secure message handling, direct push-based data exchange between ABAP systems via RFC, and SSE support in the ABAP HTTP client and server for efficient real-time event delivery in distributed scenarios.

Key user extensibility

Further improvements are provided for key user extensibility. It is now possible to generate a Fiori elements application for a custom business object with just one click and maintain behavior extensions for SAP-provided RAP business objects using key user extensibility. Moreover, using developer extensibility it is now possible to implement feature control for custom fields that were created via the Custom Fields app. The new extension field wizard provides a better development efficiency by boosting the creation of custom fields via developer extensibility.

Security

Key updates include support for OAuth Authorization Code with PKCE (RFC 7636) and JWT-based client authentication (RFC 7523), as well as SAP-managed client certificates for secure integration in S/4HANA Private Cloud (2025 FPS01). TLS 1.3 is now supported across HTTP, WebSocket RFC, and SMTP, with OAuth Client Credential Grant enabled for SMTP outbound scenarios such as Exchange Online.

Additional enhancements include new OpenID Connect features, improved troubleshooting guidance (SAP Note 3111813), and a new OAuth Client Configuration UI (SOAUTH_CLIENT) with built-in testing and token metadata display.

Useful Blog Posts, Community pages and Learnings

ABAP Community Topic Pages:

ABAP Development Community
ABAP Testing and Analysis Community
ABAP Extensibility Community
ABAP Connectivity Community
SAP BTP ABAP Environment Community
SAP S/4HANA Cloud ABAP Environment Community

ABAP at SAP Events:

ABAP Cloud at SAP TechEd in 2025
ABAP Cloud at Devtoberfest in 2025

Clean Core

Clean core extensibility white paper
ABAP Extensibility Guide – Clean Core for SAP S/4HANA Cloud - August 2025 Update
ABAP test cockpit (ATC) recommendations for governance of clean core ABAP development
ATC on SAP BTP: blog | overview presentation
Certification of Partner Solutions following Clean Core

SAP Joule for Developers, ABAP AI capabilities

SAP Joule for Developers Expands to Private Cloud: Accelerating ABAP Innovation and Transformation
ABAP AI Revolution Accelerates: The ABAP Developer Who Built Enterprise Apps in Minutes
From Legacy to AI-Powered: RISE Transformation Revolution with Joule for developers
ABAP AI - Chapter 2

ABAP Cloud:

ABAP Exensibility Guide
Become SAP Certified Associate – Back-End Developer - ABAP Cloud
ABAP Cloud FAQ
SAP Build and ABAP Cloud Basic Trial Offering
Developer Guide: From Classic ABAP to ABAP Cloud on SAP Help Portal

Further blog posts and topic pages:

State-of-the-Art ABAP Development with ABAP RESTful Application Programming Model (RAP)
ABAP Tools for Clean ABAP

Useful Links

Release Notes for ABAP Platform 2025
Documentation on SAP Help Portal
Product Availability Matrix (PAM)
The ABAP Platform Strategy
ABAP Platform Releases and Consumers
SAP Note 3612209 – ABAP Platform 2025 – General information

Previous landing pages

ABAP Platform for SAP S/4HANA 2023
ABAP Platform for SAP S/4HANA 2022
ABAP Platform for SAP S/4HANA 2021
ABAP Platform for SAP S/4HANA 2020
ABAP Platform for SAP S/4HANA 1909
ABAP Platform for SAP S/4HANA 1809
SAP NetWeaver AS for ABAP 7.52
SAP NetWeaver AS ABAP 7.50

Hide/Show Field In UI Dynamically Through Virtual Elements In RAP

2025-12-15T06:39:16.774000+01:00

Hi RAP Developers, Good Day

Introduction:
In the SAP RAP (RESTful ABAP Programming Model), enhancing UI behavior dynamically is a common requirement, especially when business rules demand that certain fields be shown or hidden based on the underlying data. While RAP provides powerful mechanisms for extending behavior, one of the most flexible techniques for achieving dynamic UI control is through virtual elements.

Solution Overview:

Virtual elements allow developers to calculate values at runtime without physically storing them in the database. Beyond computed fields, they can also serve as UI control flags, for example, determining whether a field should be visible, editable, or hidden in the Fiori Elements UI. In this blog, we explore how to leverage virtual elements to dynamically show or hide UI fields based on data conditions. Using a simple ABAP class implementation, we demonstrate how a virtual field can drive UI visibility logic efficiently within RAP.

Projection View:

@ObjectModel.virtualElementCalculatedBy: 'ABAP:ZCL_HIDE_VIRT'
  
    virtual ishide : abap_boolean

Metadata Extension:

  " Hide field from Identification section based on virtual element 'ishide'
  .identification: [{ position: 40, hidden: #( ishide ) }]

  " Display field in Line Item section
  .lineItem: [{ position: 30 }]

  " Make field available as a Selection Field
  .selectionField: [{ position: 30 }]

  " Business field – Total Price
  TotalPrice;

Implement Virtual Elements:

CLASS zcl_hide_virt DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC .

  PUBLIC SECTION.

    " SADL Exit Interface
    INTERFACES if_sadl_exit .

    " Interface for Virtual Element Calculation (Read)
    INTERFACES if_sadl_exit_calc_element_read .

  PROTECTED SECTION.
  PRIVATE SECTION.
ENDCLASS.



CLASS zcl_hide_virt IMPLEMENTATION.

  METHOD if_sadl_exit_calc_element_read~calculate.
    "------------------------------------------------------------------
    " Purpose: Populate virtual element 'ishide' based on TotalPrice
    "          to control field visibility in the UI.
    "------------------------------------------------------------------

    DATA : lt_virtual TYPE TABLE OF zc_tbjrn.

    " Copy original data to local internal table
    lt_virtual = CORRESPONDING #( it_original_data ).

    " Loop through internal table and set virtual element value
    LOOP AT lt_virtual ASSIGNING FIELD-SYMBOL(<fs_travel>).

      " Set ishide = abap_true when TotalPrice <= 142, else false
      <fs_travel>-ishide = COND abap_boolean(
                              WHEN <fs_travel>-totalprice LE 142
                                THEN abap_true
                                ELSE abap_false ).

    ENDLOOP.

    " Return updated table with calculated virtual element
    ct_calculated_data = CORRESPONDING #( lt_virtual ).

  ENDMETHOD.


  METHOD if_sadl_exit_calc_element_read~get_calculation_info.
    " No additional calculation info required
  ENDMETHOD.

ENDCLASS.

Preview:

Conclusion:

By leveraging virtual elements together with the SADL exit class, we can dynamically control field visibility in RAP applications without modifying the actual database layer. This approach provides a clean separation between data and UI logic, improves performance, and keeps the design fully extensible. With a simple calculation exit, fields like Hide Indicator can be determined at runtime based on business rules, allowing the UI to react instantly and display only what is relevant to the user. This method ensures a smarter, more flexible, and more maintainable RAP application.

Thanks For Reading My Blog..

ABAP Connectivity
SAP BTP ABAP environment

Timestamp Conversion for Different User Time Zones in ABAP

2025-12-15T06:48:28.394000+01:00

Hello Everyone!

Recently, I worked on a timestamp conversion issue related to user-specific time zones in SAP. The data stored in the SAP level was correct, but when displayed through an ABAP report, the timestamp appeared incorrect for some users.

After analyzing the issue, I found that the root cause was the conversion routine defined in the domain. This routine automatically converts timestamps based on the user's logon time zone, which caused mismatches during display.

In this blog, I will show how to resolve this issue by converting all timestamps to UTC before displaying them, ensuring consistent results for every user—regardless of their time zone or domain settings.

Problem Summary

The timestamp stored in the database table (ZDEL_INFO) was correct.
But when displaying the data in a report, the timestamp appeared incorrect for some users.
This happened because the domain of the timestamp field had a conversion routine (e.g., TZNTSTMPS).
As a result, SAP automatically converted timestamps based on each user's time zone.

Example:

Domain with Conversion Routine:

Table:

Report:

Solution Approach

Read timestamp values from the database.
Convert local timestamp → UTC timestamp using:

cl_kf_helper=>timestamp_local_zone_2_utc

3.Populate the final internal table with the corrected timestamp.

4.Display the data using CL_SALV_TABLE.

By converting timestamps to UTC, the displayed values remain consistent for all users.

*&---------------------------------------------------------------------*
*& Report ZTIMESTAMPS_USERS
*&---------------------------------------------------------------------*
*& Purpose:
*&   This report reads delivery data from table ZDEL_INFO,
*&   converts local timestamps into UTC based on the user’s time zone,
*&   and displays the results using CL_SALV_TABLE.
*&---------------------------------------------------------------------*
REPORT ztimestamps_users.

TABLES: zdel_info.

TYPES: BEGIN OF ty_del,
       deliveryno TYPE zdel_info-deliveryno,
       material   TYPE zdel_info-material,
       deldate    TYPE zdel_info-deldate,
END OF ty_del.

DATA: lt_final TYPE TABLE OF ty_del,
      ls_final TYPE ty_del.


*START-OF-SELECTION.

START-OF-SELECTION.

SELECT * FROM zdel_info
        INTO TABLE (lt_del).

LOOP AT lt_del INTO DATA(ls_del).

ls_final-deliveryno = ls_del-deliveryno.
ls_final-material   = ls_del-material.
IF ls_del-deldate IS  NOT INITIAL.

CALL METHOD cl_kf_helper=>timestamp_local_zone_2_utc
          EXPORTING
            i_timestamp_local = ls_del-deldate          " Timestamp in user's local time
            i_time_zone       = sy-zonlo                " Current user's time zone
          RECEIVING
            r_timestamp_utc   = DATA(lv_tmstamputc).    " Converted UTC timestamp

ls_final-deldate = lv_tmstamputc.
        CLEAR lv_tmstamputc.

ENDIF.
APPEND ls_final TO lt_final.
ENDLOOP.

DATA: o_alv TYPE REF TO cl_salv_table.

  cl_salv_table=>factory(
      IMPORTING
        r_salv_table = o_alv
      CHANGING
        t_table      = lt_final ).

* Display the ALV
o_alv->display( ).

Output:

Explanation of Key Logic

1. `timestamp_local_zone_2_utc`

This method converts a timestamp from the user’s local time zone (based on SY-ZONLO) to UTC.

2. Why Convert to UTC?

UTC is a universal reference.
Once converted to UTC, the timestamp remains consistent, regardless of:

User logon time zone
System time zone
Conversion routines in the domain

3. Output Using SALV

CL_SALV_TABLE is used for a simple and clean ALV output without advanced configuration.

Conclusion

Handling timestamps in SAP can be challenging, especially when conversion routines and user time zones come into play.
By converting timestamps to UTC before displaying them, we avoid incorrect values and ensure reliable reporting across all users.
It will have been Very Helpful for Real Time users in Project works
this has a process of just like small solution thank you...

ABAP Development
ABAP Connectivity
ABAP Extensibility

Hierarchical ALV Using Factory Method in SAP ABAP

2025-12-15T06:50:35.551000+01:00

In this blog post, we’ll explore how to implement a Hierarchical ALV using the Factory Method of the CL_SALV_HIERSEQ_TABLE class.

Introduction

In many SAP ERP scenarios, business users frequently work with data that follows a natural master–detail relationship, such as customers and their contacts, vendors and their company-code assignments, or materials and their storage locations. Presenting such related datasets in a clean and intuitive format is critical for efficient decision-making.

While traditional ALV is highly effective for displaying single-level tables, it becomes less practical when dealing with multi-level or dependent datasets. For these situations, SAP provides Hierarchical ALV through the class CL_SALV_HIERSEQ_TABLE, allowing developers to present complex data relationships in an expandable, easy-to-navigate layout within SAP GUI.

This blog demonstrates how to create a hierarchical ALV using a vendor master table and its corresponding item details. The objective is to show how straightforward it is to bind two related datasets, define the hierarchy mapping, and display the result using SAP’s SALV framework—all with clean, maintainable ABAP code.

Scenario Overview

We will work with two custom tables:

ZVA_VENDOR_TA – Stores vendor master information (header level).
ZVA_VENDOR_ITEM – Stores vendor-specific or company-code-specific details (item level).

The goal is to display these tables in a hierarchical ALV, where each vendor (header) can be expanded to reveal its associated item entries (detail).

CODE:

REPORT ZVA_FACTORY_HIERACY_ALV.

" Declaration of internal tables and work areas for hierarchical ALV binding
DATA: LT_HIERSEQ TYPE SALV_T_HIERSEQ_BINDING,
      LS_HIERSEQ TYPE SALV_S_HIERSEQ_BINDING.

" Select vendor master data from custom table ZVA_VENDOR_TA
SELECT VENDERNO, NAME, CITY, POSTALCODE, EMAIL, ACCOUNTGROUP, PROCESSORGROUP, POSTINGBLOCK
  FROM ZVA_VENDOR_TA INTO TABLE (LT_VENDOR).

" Check if data is available in the LT_VENDOR table
IF sy-subrc = 0.

  " If vendor data exists, select corresponding vendor item details from ZVA_VENDOR_ITEM
  SELECT VENDERNO, COMPANYCODE, PERSONNELNUMBER, AUTHORGROUP, NTGEW, GEWEI, EKORG, STATUS
    FROM ZVA_VENDOR_ITEM INTO  TABLE (LT_VENDOR_ITEM).

ENDIF.

" Define the hierarchy relationship between the master and detail tables
LS_HIERSEQ-MASTER = 'VENDERNO'.  " Master key field (header level)
LS_HIERSEQ-SLAVE  = 'VENDERNO'.  " Corresponding key field in detail (item level)
APPEND LS_HIERSEQ TO LT_HIERSEQ. " Add the mapping to the hierarchy sequence table

" Create and display the hierarchical ALV using CL_SALV_HIERSEQ_TABLE
CALL METHOD CL_SALV_HIERSEQ_TABLE=>FACTORY
  EXPORTING
    T_BINDING_LEVEL1_LEVEL2 = LT_HIERSEQ       " Define the binding between header and item tables
  IMPORTING
    R_HIERSEQ               = DATA(LO_SALV_HIERSEQ) " Get reference to the hierarchical ALV object
  CHANGING
    T_TABLE_LEVEL1          = LT_VENDOR         " Pass header (vendor) data
    T_TABLE_LEVEL2          = LT_VENDOR_ITEM.   " Pass item (vendor details) data

" Display the hierarchical ALV
LO_SALV_HIERSEQ->DISPLAY( ).

Output :

Conclusion

Hierarchical ALV is a powerful tool for presenting master–detail datasets in an organized and interactive format. The class CL_SALV_HIERSEQ_TABLE significantly simplifies the development process by handling the hierarchy logic internally, allowing developers to focus on data retrieval and business requirements rather than UI complexity.

By implementing this approach, organizations can deliver reports that are not only visually clear but also easier for end users to navigate—especially when dealing with multi-level relational data. This technique remains highly relevant for SAP GUI-based reporting and continues to be an important part of the ABAP developer’s toolkit.

If needed, this solution can be extended to support additional hierarchy levels, custom toolbar functions, or integration with business logic, making it flexible enough for advanced reporting scenarios.

ABAP Development

Building a Real RAP Application Step by Step — Vlog Series Introduction

2025-12-15T21:13:47.721000+01:00

Introduction

This vlog series aims to demonstrate how to build a real-life ABAP RAP application, following a practical, incremental, and production-oriented approach.

Disclaimer:
This series focuses on showcasing how a RAP application can be built incrementally from real functional requirements. The app is intentionally kept practical and educational, rather than exhaustive or fully hardened for production. Some edge cases or potential enhancements are intentionally not covered.
The purpose of the vlog is to share knowledge, demonstrate real development workflows, and contribute to the SAP community, not to deliver a fully polished commercial-grade application.
To allow anyone to follow the vlog series, I will be using an SAP BTP Trial. This environment carries several limitations compared to a customer system, but it is perfectly sufficient for demonstrating the concepts and end-to-end implementation

Instead of showing a pre-built demo or isolated RAP examples, the series walks through the development process from scratch, implementing the application one requirement at a time, exactly as it would be done in an actual ABAP Cloud project.

Each episode focuses on a small, well-defined set of user stories, keeping the learning process smooth and allowing you to see how the application grows after every step. The structure ensures the app is testable from the very beginning, and every enhancement is immediately visible in the UI preview.

If you want to understand RAP not just in theory but in practice, including determinations, validations, feature control, actions, side effects, completeness checks, semantic keys, and UI configuration, this series is for you.

What are we going to build?

We’ll be developing an internal equipment request application for a consulting firm.

Employees can request items kept in internal stock (laptops, monitors, headsets, etc.).

Each request follows a simple lifecycle:

Not Prepared / In Preparation / Delivered / (later also Cancelled)

Each request includes header data (requester, deadline, priority, status) and one or more items referencing products from a customizing table of available materials.

The scenario is intentionally simple but rich enough to cover the most important RAP concepts: CDS data modeling, RAP behavior definitions in managed scenarios, Semantic keys, Determinations & validations, UI annotations, Feature control, Prechecks, Popup actions, Value helps, Inline editing, Integration with customizing tables, ABAP Cloud–compliant development practices.

How the Vlog is structured

The application is built based on a list of functional requirements expressed as user stories. These stories are implemented in the same order they would typically be addressed in a real project. The format of each episode is:

Short and focused (usually covering 1-3 user stories)
Incremental (the app evolves visibly every episode)
Practical (every change is immediately testable)
Aligned with ABAP Cloud guidelines
Designed for long-term learning and reference

Whether you're starting with RAP or expanding your expertise, this series aims to provide a clear, realistic, and reusable learning path.

Full requirement backlog (User Stories)

Below is the collection of user stories implemented throughout the series, listed in almost the exact order used for development:

US-01: Basic request object: As an employee, I want to create internal equipment requests so that I can receive the products I need.

US-02: Search and Filter capabilities: As a user, I want to search requests using structured filters so that I can quickly locate relevant orders. I need to be able to search through the following criteria:

free search field,
by Requester (with search help),
by Priority (drop-down )
by Status (drop-down with multiple selections).

US-03: Sequential External ID and semantic key: As the system, I want to assign each request a sequential external number so that users can reference meaningful IDs.

US-04: Mandatory fields: As a user, I want the system to require Requester Name and Deadline Date so that requests are always complete.

US-05: Deadline validation: As the system, I want to validate that the deadline date is at least one day in the future so that operations can prepare on time.

US-06: Automatic priority determination: As the system, I want priority to be set based on deadline so that urgent requests receive proper attention (High: < 3 days, Medium: <7 days, otherwise, Low).

US-07: Status icons: As a user, I want statuses displayed with colored icons so that I can understand them at a glance.

US-08: Cancel status restrictions: As a user, I want to search for cancelled requests but not manually set status as “Cancelled” so that lifecycle rules are respected.

US-09: Default status: As the system, I want new requests to default to “In Preparation” so that the lifecycle begins correctly.

US-10: Status editability rules: As a user, I want status to be editable only after creation so that inconsistencies are avoided.

US-11: Cancel action: As a user, I want to cancel one or more requests from the list so that I can invalidate unnecessary requests.

US-12: Cancellation popup: As a user, I want to cancel and justify cancellations through a popup so that the system enforces to have reasons registered.

US-13: Cancel reason rules: As a user, I want “Cancellation Reason” to be editable only when status is “Cancelled” so that it appears available only when relevant.

US-13b: changing dynamic field hiding approach from CDS into virtual element.

US-14: No editing after cancellation: As the system, I want cancelled requests to become read-only so that historical data is kept intact.

US-15: Product catalog restriction: As a user, I want to select products only from internal stock so that I request only available items. Internal stock is customized through a customizing table.

US-16: Product value help: As a user, I want a value help showing only available products so that selection is efficient.

US-17: Unique product per request: As a system, I want to prevent duplicate products within a request so that items remain consistent.

US-18: Item creation via popup: As a user, I want to create items in a popup and edit them inline so that maintenance is fast and intuitive.

US-19: Make popup fields mandatory: As a system, I want to ensure that the data entered through the Product popup is complete.

US-20: Make item fields mandatory: As a system, I want to ensure that the data entered through the Product object page is complete.

Episode Roadmap

Each episode implements a specific subset of user stories. Episodes are planned to be released on a weekly basis (approx.). Episode 1 will be released shortly, before end of year!

01	Project introduction + Data model basics	US-01
02	Service exposure + First UI (read-only) preview	US-01
03	Basic behavior + Search fields (Part 1): Free text + Requester	US-02 (Requester + Free text)
04	Search fields (Part 2): Status & Priority	US-02 (Status + Priority)
05	Semantic key & Sequential numbering	US-03
06	Mandatory fields + Deadline validation	US-04 + US-05
07	Automatic Priority determination + Status icons & visual enhancements	US-06 + US-07
08	Status behavior rules	US-08 + US-09 + US-10
09	Cancel feature (Part 1)	US-11 + US-12
10	Cancel feature (Part 2)	US-13 + US-13b + US-14
11	Item popup creation & inline editing	US-18 + US-19
12	Product customizing + availability	US-15 + US-16
13	Item consistency: prevent duplicates	US-17

If this introduction was helpful, a like or follow would be appreciated as it helps others in the community find the series.

ABAP to Export Internal Table Data and Send as Email Attachments (TXT, CSV, XLSX)

2025-12-16T06:01:11.458000+01:00

Introduction:

Hello Everyone!!

When working on real projects, I often had to export ALV data manually every time someone needed it for an email. It was time-consuming and repetitive. So I created a small ABAP utility that automatically converts the ALV output into a TXT, CSV, or XLSX file and sends it directly by email. This makes the whole process much faster and easier for both users and developers.

Manually exporting the report every time is both repetitive and error-prone.
So I created a simple yet powerful ABAP program that automates this entire process.

With one execution, the program:
✔ Fetches Sales Order data from VBAK
✔ Displays the results in a Factory Method (CL_SALV_TABLE)
✔ Converts the data into TXT, CSV, or XLSX
✔ Attaches the file
✔ Emails it automatically using CL_BCS

How the Program Works

Data Retrieval – Sales order header data (VBAK) is read based on the input range.
ALV Display – The results are shown using CL_SALV_TABLE.
File Preparation
- TXT: Fixed-width formatting
- CSV: Comma-separated lines
- XLSX: Using SALV → XML export
Binary Conversion – Converts string or XML to SOLIX_TAB for email attachment.
Email Construction – Creates a BCS email object with subject, body, and attachment.
Sending – Dispatches the email instantly.

This approach is modular, clean, and easily extendable to other tables, formats, or business requirements.

PROGRAM FLOW

+------------------------------------------------------+
|                START OF SELECTION                    |
+-----------------------------+------------------------+
                              |
                              v
                 +------------------------+
                 |  Fetch Data (VBAK)    |
                 +------------------------+
                              |
                              v
                 +------------------------+
                 |   Display ALV Output   |
                 |  (CL_SALV_TABLE)       |
                 +------------------------+
                              |
                              v
         +------------------------------------------------+
         |   User selects output format (TXT/CSV/XLSX)    |
         +------------------------------------------------+
                              |
                              v
     +-------------------------------------------------------------+
     |   Generate content:                                         |
     |   - TXT  → String formatting                                |
     |   - CSV  → CSV concatenation                                |
     |   - XLSX → ALV->TO_XML (SALV XML Export)                    |
     +-------------------------------------------------------------+
                              |
                              v
     +-------------------------------------------------------------+
     | Convert content to binary attachment:                       |
     | - SCMS_STRING_TO_XSTRING (if TXT/CSV)                      |
     | - SCMS_XSTRING_TO_BINARY (all formats)                      |
     +-------------------------------------------------------------+
                              |
                              v
     +-------------------------------------------------------------+
     |   Build Email (BCS Framework):                              |
     |   - CREATE_PERSISTENT                                        |
     |   - CREATE_DOCUMENT                                          |
     |   - ADD_ATTACHMENT                                           |
     |   - SET_DOCUMENT                                             |
     |   - CREATE_SENDER / CREATE_INTERNET_ADDRESS                 |
     |   - ADD_RECIPIENT                                            |
     +-------------------------------------------------------------+
                              |
                              v
                 +----------------------------+
                 |       SEND EMAIL           |
                 |     (LO_SEND->SEND)        |
                 +----------------------------+
                              |
                              v
                 +----------------------------+
                 |   Email Sent Successfully  |
                 +----------------------------+

Function Modules & Classes Used in the Program

Function Module	Purpose / Usage
SCMS_STRING_TO_XSTRING	Converts plain text (string) into XSTRING format. Used for TXT and CSV attachments.
SCMS_XSTRING_TO_BINARY	Converts XSTRING into SOLIX_TAB (binary table). Required for sending attachments (TXT, CSV, XLSX).

Class / Method	Purpose / Usage
CL_SALV_TABLE=>FACTORY	Creates ALV object instance for display.
LO_ALV->DISPLAY	Displays the ALV grid on the screen.
LO_ALV->TO_XML	Converts ALV data into XML. Used for generating XLSX output.

Class / Method	Purpose / Usage
CL_BCS=>CREATE_PERSISTENT	Initializes an email send request.
CL_DOCUMENT_BCS=>CREATE_DOCUMENT	Creates email body and subject.
LO_DOCUMENT->ADD_ATTACHMENT	Adds attachment (TXT/CSV/XLSX) to email.
LO_SEND_REQUEST->SET_DOCUMENT	Attaches the document to the send request.
CL_SAPUSER_BCS=>CREATE	Defines email sender (current SAP user).
CL_CAM_ADDRESS_BCS=>CREATE_INTERNET_ADDRESS	Creates external email recipient.
LO_SEND_REQUEST->ADD_RECIPIENT	Adds a recipient to the email request.
LO_SEND_REQUEST->SEND	Sends the final email.

SOURCE CODE FOR REFERENCE :

*&---------------------------------------------------------------------*
*& Report ZEMAIL_ATTACH
*&---------------------------------------------------------------------*
*&
*&---------------------------------------------------------------------*
REPORT zemail_attach.

TABLES:vbak.

*------------Selection screen parameters-------------------------------*
SELECT-OPTIONS: s_vbeln FOR vbak-vbeln.

PARAMETERS: p_txt  RADIOBUTTON GROUP rg1 DEFAULT 'X',
            p_csv  RADIOBUTTON GROUP rg1,
            p_xlsx RADIOBUTTON GROUP rg1.

PARAMETERS: p_email TYPE adr6-smtp_addr.

*-------------Start-of-selection---------------------------------------*

START-OF-SELECTION.

*Fetch sales order header data from VBAK
SELECT vbeln,
       erdat,
       vbtyp,
       auart,
       vkorg,
       kunnr FROM vbak
       INTO TABLE (lt_vbak)
       WHERE vbeln IN @s_vbeln.

SORT  lt_vbak BY vbeln.

*-------------Display ALV----------------------------------------------*
DATA: lo_alv TYPE REF TO cl_salv_table.

TRY.
    cl_salv_table=>factory(
      IMPORTING
        r_salv_table = lo_alv
      CHANGING
        t_table      = lt_vbak ).

lo_alv->display( ).

  CATCH cx_salv_msg INTO DATA(lx_msg).
    MESSAGE lx_msg->get_text( ) TYPE 'E'.
ENDTRY.

*-------------TXT Format----------------------------------------------*
IF p_txt ='X'.
DATA(lv_txt) = |{ 'VBELN' WIDTH = 12 }| &&
               |{ 'ERDAT' WIDTH = 10 }| &&
               |{ 'VBTYP' WIDTH = 6 } | &&
               |{ 'AUART' WIDTH = 6 } | &&
               |{ 'VKORG' WIDTH = 6 } | &&
               |{ 'KUNNR' WIDTH = 12 }| &&
               cl_abap_char_utilities=>cr_lf.

LOOP AT lt_vbak ASSIGNING FIELD-SYMBOL(<fs_row>).
 lv_txt = lv_txt &&
           |{ <fs_row>-vbeln WIDTH = 12 } | &&
           |{ <fs_row>-erdat WIDTH = 10 } | &&
           |{ <fs_row>-vbtyp WIDTH = 6 }  | &&
           |{ <fs_row>-auart WIDTH = 6 }  | &&
           |{ <fs_row>-vkorg WIDTH = 6 }  | &&
           |{ <fs_row>-kunnr WIDTH = 12 } | &&
           cl_abap_char_utilities=>cr_lf.
ENDLOOP.

*-------------CSV Format------------------------------------------------*
ENDIF.

IF p_csv = 'X'.
DATA(lv_csv) = |VBELN,ERDAT,VBTYP,AUART,VKORG,KUNNR| &&
                 cl_abap_char_utilities=>cr_lf.

 LOOP AT lt_vbak ASSIGNING <fs_row>.
    lv_csv = lv_csv &&
             |{ <fs_row>-vbeln },{ <fs_row>-erdat },{ <fs_row>-vbtyp },| &&
             |{ <fs_row>-auart },{ <fs_row>-vkorg },{ <fs_row>-kunnr } | &&
             cl_abap_char_utilities=>cr_lf.
ENDLOOP.
ENDIF.

*-------------XLSX Format------------------------------------------------*

IF p_xlsx = 'X'.

DATA(lv_xml) = lo_alv->to_xml( xml_type = if_salv_bs_xml=>c_type_xlsx ).

ENDIF.

*-------------Convert content to binary for attachment-------------------*
DATA: lv_xstring  TYPE xstring,
      lt_bin      TYPE solix_tab,
      lv_size     TYPE i,
      lv_filename TYPE so_obj_des.

IF p_txt = 'X'.
  lv_filename = 'report.txt'.
 CALL FUNCTION 'SCMS_STRING_TO_XSTRING'
    EXPORTING
      text   = lv_txt
    IMPORTING
      buffer = lv_xstring.
 CALL FUNCTION 'SCMS_XSTRING_TO_BINARY'
  EXPORTING
    buffer                = lv_xstring
  TABLES
    binary_tab            = lt_bin.

ELSEIF p_csv = 'X'.
  lv_filename = 'report.csv'.
  CALL FUNCTION 'SCMS_STRING_TO_XSTRING'
    EXPORTING text   = lv_csv
    IMPORTING buffer = lv_xstring.
  CALL FUNCTION 'SCMS_XSTRING_TO_BINARY'
    EXPORTING buffer     = lv_xstring
    TABLES   binary_tab  = lt_bin.

ELSEIF p_xlsx = 'X'.
  lv_filename = 'report.xlsx'.
  CALL FUNCTION 'SCMS_XSTRING_TO_BINARY'
    EXPORTING
      buffer        = lv_xml
    IMPORTING
      output_length = lv_size
    TABLES
      binary_tab    = lt_bin.
ENDIF.

*--------------- Create and send email------------------------------------*
DATA: lo_send_request TYPE REF TO cl_bcs,
      lo_document     TYPE REF TO cl_document_bcs,
      lo_sender       TYPE REF TO cl_sapuser_bcs,
      lo_recipient    TYPE REF TO if_recipient_bcs,
      lv_subject      TYPE so_obj_des.
*Create send request
lo_send_request = cl_bcs=>create_persistent( ).

*Subject line
lv_subject = 'Sales Order Report'.

*Create email body text
DATA(lt_body) = VALUE soli_tab( ( line = 'Sales Order Report Attached.' ) ).

* Create document with attachment
lo_document = cl_document_bcs=>create_document(
                i_type    = 'RAW'
                i_text    = lt_body
                i_subject = lv_subject ).

lo_document->add_attachment(
  i_attachment_type    = 'BIN'
  i_attachment_subject = lv_filename
  i_attachment_language = sy-langu
  i_att_content_hex    = lt_bin ).

*Add document to send request
lo_send_request->set_document( lo_document ).

*Set sender
lo_sender = cl_sapuser_bcs=>create( sy-uname ).
lo_send_request->set_sender( lo_sender ).

*Add recipient
lo_recipient = cl_cam_address_bcs=>create_internet_address( p_email ).
lo_send_request->add_recipient(
  i_recipient = lo_recipient
  i_express   = 'X' ).

* Send email
TRY.
    lo_send_request->send( i_with_error_screen = 'X' ).
    COMMIT WORK.
    MESSAGE 'Email sent successfully' TYPE 'S'.
  CATCH cx_bcs INTO DATA(lx_bcs).
    MESSAGE lx_bcs->get_text( ) TYPE 'E'.
ENDTRY.

These images will help you better understand how the program behaves during execution.

You can check the mail delivery status in transaction SOST.

Conclusion:

Automating ALV export and email delivery may seem like a small enhancement, but it brings significant value to daily business operations. Instead of manually downloading and sending files each time a user requests data, this ABAP utility streamlines the entire workflow—fetching data, generating TXT/CSV/XLSX files, and sending them by email in one seamless execution.

ABAP Development
ABAP Connectivity
ABAP Extensibility

Building a Custom Stock/Requirements Report in SAP ABAP

2025-12-16T06:16:16.031000+01:00

Introduction

In SAP Materials Management, the Stock or Requirements List MD04 is one of the most frequently used transactions for planners and production teams. It provides a real-time view of current stock, incoming receipts, and outgoing requirements for a material at plant level. However, in real project scenarios, users often need a simplified, customized, or report-based version of MD04 that can be enhanced further or adapted to specific business needs.

During one such requirement, I worked on building a custom ABAP report that replicates the core functionality of MD04 while keeping the logic transparent and flexible. This blog explains how a custom Stock/Requirements Report can be built using standard SAP tables and function modules, without modifying standard SAP transactions.

Solution Review :

The custom report ZSTCOK_912 is designed to display stock and MRP elements for a given Material and Plant, closely mirroring the MD04 output.

1. Selection Screen

The report starts with a simple and user friendly selection screen:
Material Number MATNR
Plant WERKS
Both parameters are mandatory to ensure accurate stock evaluation.

2. Material Number Conversion

Since SAP stores material numbers with leading zeros, the report uses:

CONVERSION_EXIT_ALPHA_INPUT

This ensures the material number is in the correct internal format before database access.

3. Current Stock Determination

To calculate the opening balance:

Table MARD is read
All unrestricted stock LABST across storage locations is summed
This provides the current physical stock, which becomes the starting available quantity.

4. Fetching Stock or Requirements Data

The core of the solution uses the standard SAP function module:

MD_STOCK_REQUIREMENTS_LIST_API

This is the same API used by MD04 and returns:
MRP elements receipts and requirements
Quantities
Planning and control data
The data is stored in internal tables such as MDPSX, MDEZX, and MDSUX.

5. Display Logic and Running Stock Calculation

Each MRP element is processed sequentially:
Receipts increase available stock
Requirements reduce available stock
A running available quantity is calculated and displayed line by line, giving users a projected stock position over time.

6. Output Format

The report displays:

Date
MRP element type Receipt, Requirement, Dependent Requirement, etc.
Document number
Receipt quantity
Projected available stock
Additionally, summary information such as total records processed and current stock is displayed at the end.

The Complete Solution Code

*&---------------------------------------------------------------------*
*& Report ZSTCOK_912
*&---------------------------------------------------------------------*
*& Custom Stock/Requirements  Report
*& Purpose: Display stock and requirements similar to MD04 transaction
*&---------------------------------------------------------------------*
REPORT ZSTCOK_912.

*&---------------------------------------------------------------------*
*& DATA DECLARATIONS
*&---------------------------------------------------------------------*

" Reference to standard SAP tables for material master data
TABLES: mara, " General Material Data
marc. " Plant Data for Material

*&---------------------------------------------------------------------*
*& SELECTION SCREEN
*&---------------------------------------------------------------------*
" Input parameters for the report - both are mandatory
SELECTION-SCREEN BEGIN OF BLOCK b1 WITH FRAME TITLE TEXT-001.
PARAMETERS: p_matnr TYPE matnr OBLIGATORY, " Material Number
p_werks TYPE werks_d OBLIGATORY. " Plant
SELECTION-SCREEN END OF BLOCK b1.

*&---------------------------------------------------------------------*
*& INTERNAL TABLES AND WORK AREAS
*&---------------------------------------------------------------------*

" Internal tables to store data returned by the function module
DATA: gt_mdpsx TYPE TABLE OF mdps, " MRP element data (dates, doc numbers)
gs_mdpsx TYPE mdps, " Work area for MDPSX
gt_mdezx TYPE TABLE OF mdez, " MRP element quantities
gs_mdezx TYPE mdez, " Work area for MDEZX
gt_mdsux TYPE TABLE OF mdsu, " Summary data
gs_mdsux TYPE mdsu. " Work area for MDSUX

" Structures for exporting parameters from function module
DATA: gs_mt61d TYPE mt61d, " Material requirements planning data
gs_mdkp TYPE mdkp, " MRP controller and configuration
gs_cm61m TYPE cm61m, " MRP list control data
gs_mdsta TYPE mdsta, " MRP statistics
gv_ergbz TYPE ergbz. " Result indicator

" Variables for processing and display
DATA: gv_labst TYPE labst, " Unrestricted stock quantity
gv_available TYPE labst, " Available quantity (opening stock)
lv_running_stock TYPE mng01, " Running available stock
lv_matnr TYPE matnr, " Material number with leading zeros
lv_txt TYPE char30, " Text for MRP element description
lv_count TYPE i. " Counter for total records

*&---------------------------------------------------------------------*
*& START-OF-SELECTION
*&---------------------------------------------------------------------*
START-OF-SELECTION.

"*------------------------------------------------------------------*
"* Step 1: Convert Material Number with Leading Zeros
"*------------------------------------------------------------------*
" SAP stores material numbers with leading zeros in database
" This conversion ensures proper format for database queries
CALL FUNCTION 'CONVERSION_EXIT_ALPHA_INPUT'
EXPORTING
input = p_matnr
IMPORTING
output = lv_matnr.

"*------------------------------------------------------------------*
"* Step 2: Get Current Stock from MARD Table
"*------------------------------------------------------------------*
" MARD contains storage location data for materials
" We sum all unrestricted stock (LABST) across storage locations
SELECT SINGLE SUM( labst )
INTO gv_labst
FROM mard
WHERE matnr = lv_matnr
AND werks = p_werks.

" Initialize available quantity based on query result
IF sy-subrc = 0.
gv_available = gv_labst. " Stock found
ELSE.
gv_available = 0. " No stock found
ENDIF.

"*------------------------------------------------------------------*
"* Step 3: Call Function Module to Get Stock Requirements List
"*------------------------------------------------------------------*
" MD_STOCK_REQUIREMENTS_LIST_API is SAP standard FM used by MD04
" It returns all MRP elements (receipts and requirements)
CALL FUNCTION 'MD_STOCK_REQUIREMENTS_LIST_API'
EXPORTING
matnr = lv_matnr " Material number
werks = p_werks " Plant
IMPORTING
e_mt61d = gs_mt61d " Planning data
e_mdkp = gs_mdkp " MRP configuration
e_cm61m = gs_cm61m " Control data
e_mdsta = gs_mdsta " Statistics
e_ergbz = gv_ergbz " Result indicator
TABLES
mdpsx = gt_mdpsx " MRP element master data
mdezx = gt_mdezx " MRP element quantities
mdsux = gt_mdsux " Summary data
EXCEPTIONS
material_plant_not_found = 1 " Material doesn't exist
plant_not_found = 2 " Plant doesn't exist
OTHERS = 3. " Other errors

" Error handling for function module call
IF sy-subrc <> 0.
WRITE: / 'Error getting stock requirements data'.
WRITE: / 'Return Code:', sy-subrc.
EXIT.
ENDIF.

" Check if any data was returned
IF gt_mdpsx IS INITIAL AND gt_mdezx IS INITIAL.
WRITE: / 'No stock requirements data found for Material:', p_matnr,
'Plant:', p_werks.
EXIT.
ENDIF.

"*------------------------------------------------------------------*
"* Step 4: Display Report Header Information
"*------------------------------------------------------------------*
WRITE: / 'Stock/Requirements List as of', sy-datum, sy-uzeit.
WRITE: / sy-uline(155).
WRITE: / 'Material:', p_matnr, ' Plant:', p_werks.
WRITE: / sy-uline(155).
SKIP 1.

" Display MRP configuration details if available
IF gs_mdkp IS NOT INITIAL.
WRITE: / 'MRP Controller:', gs_mdkp-dispo. " Person responsible
WRITE: / 'MRP Type:', gs_mdkp-dismm. " Planning strategy
WRITE: / 'Lot Size:', gs_mdkp-disls. " Lot sizing procedure
SKIP 1.
ENDIF.

"*------------------------------------------------------------------*
"* Step 5: Display Column Headers
"*------------------------------------------------------------------*
" Column positions are carefully aligned for readability
WRITE: / 'Date', " Date of MRP element
15 'MRP Element data', " Type of element (receipt/requirement)
45 'Doc Number', " Document number reference
70 'Receipt Qty', " Quantity of receipt
90 'Available Qty'. " Running available stock
WRITE: / sy-uline(155).

" Initialize running stock with opening balance
lv_running_stock = gv_available.

"*------------------------------------------------------------------*
"* Step 6: Display Opening Stock
"*------------------------------------------------------------------*
" Show current available stock as starting point
WRITE: / sy-datum USING EDIT MASK '__/______', " Today's date formatted
90 gv_available. " Opening stock quantity
WRITE: / sy-uline(155).

"*------------------------------------------------------------------*
"* Step 7: Process and Display MRP Elements
"*------------------------------------------------------------------*
" Loop through all MRP elements (receipts and requirements)
LOOP AT gt_mdpsx INTO gs_mdpsx.

" Get corresponding quantity data for this MRP element
" Match by date (dat00) and planning number (plumi)
READ TABLE gt_mdezx INTO gs_mdezx
WITH KEY dat00 = gs_mdpsx-dat00
plumi = gs_mdpsx-plumi.

IF sy-subrc = 0.

"*----------------------------------------------------------------*
"* Determine MRP Element Type Description
"*----------------------------------------------------------------*
" DELKZ field indicates whether element is receipt or requirement
CASE gs_mdpsx-delkz.
WHEN 'V'.
lv_txt = 'Receipt'. " Incoming material
WHEN 'B'.
lv_txt = 'Requirement'. " Outgoing material demand
WHEN 'L'.
lv_txt = 'Delivery Schedule'. " Scheduled delivery
WHEN 'A'.
lv_txt = 'Dependent Reqmt'. " From BOM explosion
WHEN 'U'.
lv_txt = 'Stock Transfer'. " Between storage locations
WHEN OTHERS.
lv_txt = gs_mdpsx-delkz. " Display code if unknown
ENDCASE.

"*----------------------------------------------------------------*
"* Calculate Running Available Stock
"*----------------------------------------------------------------*
" Receipts (+) increase stock, Requirements (-) decrease stock
IF gs_mdpsx-delkz = 'V'.
" Receipt: Add to available stock
lv_running_stock = lv_running_stock + gs_mdezx-mng03.
ELSE.
" Requirement: Subtract from available stock
lv_running_stock = lv_running_stock - gs_mdezx-mng02.
ENDIF.

"*----------------------------------------------------------------*
"* Display MRP Element Line
"*----------------------------------------------------------------*
" Show each element with aligned columns
WRITE: / gs_mdpsx-dat00 USING EDIT MASK '__/______', " Date formatted
15 lv_txt, " Element type description
45 gs_mdpsx-delnr, " Document number
70 gs_mdezx-mng03, " Receipt quantity
90 lv_running_stock. " Projected available stock

" Increment record counter
lv_count = lv_count + 1.

ENDIF.

ENDLOOP.

"*------------------------------------------------------------------*
"* Step 8: Display Summary Information
"*------------------------------------------------------------------*
WRITE: / sy-uline(155).
SKIP 1.

" Show total number of MRP elements processed
WRITE: / 'Total Records:', lv_count.
" Show current physical stock
WRITE: / 'Current Stock:', gv_labst.

" Display summary data count if available
IF gt_mdsux IS NOT INITIAL.
SKIP 2.
WRITE: / 'Summary Data Available - Total Entries:', lines( gt_mdsux ).
ENDIF.

*&---------------------------------------------------------------------*
*& END OF REPORT
*&---------------------------------------------------------------------*

Output for standard MD04 real stock view:

Output for custom Report output:

Conclusion :

This custom ABAP report demonstrates how standard SAP functionality like MD04 can be replicated and customized using clean ABAP logic and standard APIs. By leveraging MD_STOCK_REQUIREMENTS_LIST_API and combining it with stock data from MARD, the report provides a clear and reliable view of stock movements and future requirements.

From my experience, building such custom reports not only helps meet specific business requirements but also improves understanding of SAP’s internal MRP data flow. This approach offers flexibility for further enhancements such as ALV output, additional filters, or integration with planning dashboards, making it a practical alternative to standard transactions when customization is required.

Thanks for Reading My Blog..

ABAP Connectivity

SAP BTP ABAP environment .

A journey from Netweaver 7.50 to S/4HANA - Part 4: Custom Code Conversion Conundrums

2025-12-16T14:50:29.981000+01:00

After the preliminary steps for our custom code conversion described in part 1, part 2 and part 3 of this blog series, we finally started the actual coding activity over the summer.

To begin with, about 120 objects needed to be tackled which had been classified as high priority by the functional and business teams, many of which would most likely be needed for process testing in the first of eventual four sandbox systems. Once done with those, a big list with about 2,500 objects needed to be processed by our development team. For this blog post I picked three issues we encountered and briefly describe how we tackled them.

What to do with customer master creation or updates via XD01 and XD02?

We have several programs which create new customers or update existing customers via batch input (or call transaction) logic based on transaction XD01/02 and targeting the "old" tables KNA1, KNB1, KNVV, etc. While the tables still exist in S/4HANA, the transactions are no longer functional because customers now have to be created and maintained as business partners via transaction BP and the business partner tables are in the "lead". The old tables are then filled from the BP, so are still available but only for read access.

Some of our logic creates customers in bulk based on file uploads and we needed an alternative route for that because many users are relying on that logic. Other programs call XD02 in order to update some fields in the customer master. Searching for alternatives, we happened upon class CL_MD_BP_MAINTAIN and method MAINTAIN, which - based on OSS Note 2484299 - BAPI list for BP - is the recommended "tool" in S/4HANA for these kind of tasks (the BAPIs (FMs) listed in the note are intended for an ECC-system).

At first glance, using this class and method looked straight-forward enough, given that it only requires one import parameter:

cl_md_bp_maintain=>maintain(
  EXPORTING
    i_data   = l_data
  IMPORTING
    e_return = l_return ).

The "fun" really started once we realised what this parameter "i_data" really is ... very deeply nested structure CVIS_EI_EXTERN! The "complex" in the description doesn't really do it justice - at the very least, I would have added an "extremely" before "complex"!

High level definition of deeply nested structure CVIS_EI_EXTERN

To get a better handle on what I was looking at, I extended all the structures and all of their sub-structures until reaching the lowest nesting level for each of them. I then downloaded everything into a spreadsheet which ended up having 18(!) nested levels in columns A to R and over 32,000(!!!) rows. Here is a small snippet taken from the spreadsheet:

Green rows are for fields, blue lines indicate a (sub)structure and yellow rows tabletypes.

Based on a code example found in a helpful blog post here in SAP Community, we started to piece together the code needed to fill this gigantic structure in order to create a new customer in our system. By now, we do have some working code but are still working out some details for specific cases where only some fields need to be updated instead a new customer created.

Syntax error while testing logic for Australia but due to a vanished table related to Taiwan

As most of you will already know, SAP calls the OSS-notes related to a conversion to S/4HANA "Simplification Items" because SAP simplified the underlying database by eliminating tables and table fields and - to state the obvious - this makes the switch to S/4HANA anything but simple, at least if you have a large custom code base like we do!

While our development team has been working through the custom code conversion, other teams are already testing processes in sandbox systems. These were created based on productive systems which - even though the code is sourced from the same development system - differ in the data they contain. One is for example a small system for only one company code, while another one is used in Asian-Pacific countries, so is much larger than the first sandbox to be converted and also covers many more test cases. Testing processes related to webshop orders for Australia came to a stop when the logic ran into a syntax error because a table and its structure needed for e-documents in Taiwan was found missing.

Dump due to a syntax error

The table KNA1_TW_EXT contains just a handful of fields but they are legal requirements in Taiwan for invoices. A simplification item exists for the table but it's only the rather generic one mentioning objects no longer available in S/4HANA and it doesn't go into anything specific: 2296016 - SAP S/4HANA custom code adaptation - removal of orphaned objects. So, we were wondering what happens to the data stored in the productive system in ECC during system conversion?

Digging around a bit more, I found OSS-Note 3166424 - eDocument Taiwan: Migrate Extension Fields for Electronic Documents for Taiwan directly related to table KNA1_TW_EXT. In it, the conversion steps are explained and - guess what? - they involve manually downloading the data from table KNA1_TW_EXT while still on ECC and then - again manually - running SAP-provided program EDOC_TW_CUST_MIGRATE to add the fields' content to their "new" location which is funnily enough table KNA1! Unfortunately, we didn't have the upload program in our system and the OSS-Note wasn't applicable to our version of the S/4HANA-system anyway.

So, the next step was to create an SAP incident to ask about the note's applicability in our system and to get some confirmation that these manual steps are actually necessary. We got both quickly and could then run through these motions in the sandbox system. And these steps will need to be added to the big check list for needed manual activities when the actual productive system gets converted sometime next year.

The need for and fun with Retrofit

Given the long-running nature of our custom code conversion and process testing in sandbox systems, we obviously couldn't impose a freeze on the productive landscape still on Netweaver 750 EHP8 (ECC). We therefore needed a means to keep our new S/4HANA landscape up to date with new developments and applied changes in the corresponding ECC-system. With help from SAP, a Retrofit system based on Solution Manager was established and can now be used to "merge" changes applied in the ECC-system with the code in S/4HANA.

Simplified system landscape

Once transports hit our ECC productive systems, they become relevant for Retrofit in S/4HANA. The transports are automatically checked and the ones without conflicts - new objects, changed objects for which no S/4HANA code conversion has happened and which don't have S/4HANA Readiness findings - are directly imported into the S/4HANA development system. Other transports are held back for manual inspections.

While the Retrofit framework handles report programs and includes just fine by displaying differences in the two code versions side by side, it has its limitations when it comes to Adobe forms and enhancements. For these objects the side by side comparison doesn't work and it would need to be done manually via version compare which can not just be tedious but also rather error prone. Because of that, we are now asking our colleagues who applied changes in these objects in ECC to re-apply the same changes - adapted to the S/4HANA needs - in the S/4HANA development system.

Generally and speaking from a Retrofit perspective, any change not applied in the ECC system is a good change. Even with the tools available in Retrofit, the effort increases with frequent changes in ECC to objects already converted to S/4. And with each new change, the complexity and chances for errors increases.

This concludes part 4 of our journey from SAP Netweaver to S/4HANA - I'm sure that 2026 will throw some more curve balls our way!

Cartoon generated with Gemini

SAP Community - ABAP Development

CALL BAPI IN CUSTOM ENTITY THROUGH RAP

Date Hierarchy Using Tree ALV(FM & OOPS )

Introduction:

Collective Value Helps in RAP: V2 and V4 Implementation Guide - Part 2

The Problem - Flat List Display

You Are Standing in an Open Field... Inside SAP GUI

Building a VM in One Day (The "How")

99% Vibe coded

Why This Matters

HANA-Powered AMDP CRUD Framework: A Complete Workflow from ADT Development to ABAP Execution

RAP BASED ADOBEFORM WITH CUSTOM ACTION and Annotations

SAP RAP Data Modeling: Handling Virtual Fields with AMDP and Table Functions

Conclusion

Advanced ABAP programming syntax

Convert XML File to Internal Table And Download Into CSV Format In ABAP

Dynamic ALV Grid Output Using SALV and Docking Container in ABAP

✅ Conclusion (Detailed & Explanatory)

Editable ALV Report with Row-Based Field Editing and Custom F4 Help Using OOP in ABAP

Send an Email for an selected record Using a SAP RAP(RESTful ABAP Programming Model)

Summary:

1. Email Validation

2. Reading Service Data

3. Building and Sending the Email

4. Success & Error Handling

ABAP Platform in SAP S/4HANA Cloud Private Edition and SAP S/4HANA 2025

Product Highlights

Presentation

Overview

Clean core development

SAP Joule for Developers, ABAP AI capabilities

ABAP RESTful Application Programming Model (RAP)

ABAP development tools for Eclipse (ADT)

ABAP Language

SAP HANA-centric optimizations & Data Integration scenarios

Embedded analytics

Event Enablement & Business Events

Process integration & Connectivity

Key user extensibility

Security

Useful Blog Posts, Community pages and Learnings

Useful Links

Previous landing pages

Hide/Show Field In UI Dynamically Through Virtual Elements In RAP

Timestamp Conversion for Different User Time Zones in ABAP

Problem Summary

Solution Approach

Explanation of Key Logic

1. timestamp_local_zone_2_utc

2. Why Convert to UTC?

3. Output Using SALV

Conclusion

Hierarchical ALV Using Factory Method in SAP ABAP

Introduction

Scenario Overview

Conclusion

Building a Real RAP Application Step by Step — Vlog Series Introduction

Introduction

What are we going to build?

How the Vlog is structured

Full requirement backlog (User Stories)

Episode Roadmap

ABAP to Export Internal Table Data and Send as Email Attachments (TXT, CSV, XLSX)

How the Program Works

Conclusion:

Building a Custom Stock/Requirements Report in SAP ABAP

A journey from Netweaver 7.50 to S/4HANA - Part 4: Custom Code Conversion Conundrums

What to do with customer master creation or updates via XD01 and XD02?

Syntax error while testing logic for Australia but due to a vanished table related to Taiwan

The need for and fun with Retrofit

1. `timestamp_local_zone_2_utc`