SAP Community - SAP S/4HANA Cloud ABAP Environment

Using Custom Logic in SAP S/4HANA Cloud to restrict multiple parkings of supplier invoices

2025-11-20T04:38:24.793000+01:00

Problem Background:

A customer has requested a requirement to restrict the repeated parking of goods receipt reference documents and reference document items corresponding to purchase orders that have already been parked and posted. If a purchase order has already completed goods receipt, reference document, and invoice posting, it should no longer be possible to park an invoice for this purchase order.

Solution:

Attempt to meet the requirement through custom logic using a BAdI.

Analysis Steps:

1. We have previously assisted customers with invoicing requirements, and the business enhancement points we need to use are the same. You can refer to these two blogs: Using Custom Logic in SAP S/4HANA Cloud to check if the payment terms of pre made invoices are consistent with those in supplier master data | SAP Blogs and Using Custom Logic in SAP S/4HANA Cloud to restrict invoicing of purchase orders with incomplete receipts | SAP Blogs .

First, we need to add an enhancement implementation in the application - Custom Logic of SAP S/4HANA Cloud system. According to the business scenario, select the business context Procurement: Supplier Invoice and business add-in description Check Invoice Data, and fill in the implementation description and implementation identifier.

2. After adding the enhancement implementation in Custom Logic, we need to find the CDS Views that can provide the business requirement fields. After testing, for the same PO + ITEM + goods receipt, if it has already been posted, the same goods receipt document cannot be selected again for repeated parking. Therefore, the fields I use as validation conditions here are PO and ITEM numbers. At the same time, since we need to check whether this PO and ITEM have already been posted, we need to use SUPPLIERINVOICESTATUS = '5' in I_SupplierInvoiceAPI01. However, this CDS View does not have the PO and ITEM fields, so we need to use I_SuplrInvcItemPurOrdRefAPI01. In the sample code below, I used a custom CDS View. You can create a custom CDS View YY1_I_SUPPLIERINVOICEAPI01 in your own system based on I_SupplierInvoiceAPI01, select the corresponding fields, and make adjustments.

At the same time, as I mentioned in my previous articles, in the sample code provided by the BAdI, we can find statements that can restrict the behavior that triggers the BAdI. According to our needs, we need to add the following statement to restrict the BAdI to only trigger during invoice parking, without affecting other processes:

Park: if_ex_mrm_check_invoice_cloud=>c_Action_Park

3. Based on the above analysis, implement the BAdI. The specific code is as follows.

loop at ITEMSWITHPOREFERENCE REFERENCE INTO DATA(Supinvoice_item).
if action = if_ex_mrm_check_invoice_cloud=>c_Action_Hold.
    select single 
    from YY1_I_SUPPLIERINVOICEAPI01 with privileged access
    where PURCHASEORDER = @Supinvoice_item->PURCHASEORDER and PURCHASEORDERITEM = @Supinvoice_item->PURCHASEORDERITEM
    and SUPPLIERINVOICESTATUS = '5'
    into (Is_Supinvoice_status) .
    if Is_Supinvoice_status = abap_true.
      append value #( messagetype = 'E' messageid = 'MRM_BADI_CLOUD' messagenumber = '001' messagevariable1 = '暂存的发票有重复项目。' ) to messages.
    endif.
endif.
endloop.

Conclusion:

By reading this article and several previous blogs on similar scenarios, I hope you now understand how to use custom logic to apply certain restrictions when creating preliminary invoices for purchase orders.
You can find more information about SAP S/4HANA Cloud procurement-related issues at the following link: SAP S/4HANA Cloud Public Edition Sourcing and Procurement - SAP Community

You can also read more blogs about SAP S/4HANA Cloud procurement at the following link: SAP S/4HANA Cloud Public Edition Sourcing and Procurement - SAP Community

If you have any suggestions or thoughts about this article, please feel free to share them in the comments section. I look forward to communicating with you. You are also welcome to follow my personal account, and I look forward to seeing you in the next blog post!

Tracing Smart Forms and Driver Programs from Output Types in SAP – Debugging Made Easy.

2025-11-20T06:40:31.588000+01:00

Introduction: --

Smart Forms are widely used in SAP to generate business outputs like Order Confirmations, Billing Documents, etc. However, identifying which Smart Form and driver program are linked to a particular output type, and how to debug them, is not always straightforward.

This blog provides a clear and separate step-by-step guide for: --

Sales Orders (VA03) – Application V1
Billing Documents (VF03) – Application V3

We'll cover how to: -

Identify the driver program and Smart Form
Trigger and debug the output
Trace the data flow using breakpoints

Section 1: Sales Orders (VA03 – Application V1)

Step 1: Identify Output Type Configuration

Go to T-code NACE

Choose Application: V1 (Sales)

Click on Output Types.

Select output type and click "Processing Routines".

Here You’ll see: --

Driver Program
Form Routine
Smart Form name

Then we will go to the driver program and put the debugger point.

Debug via VA03: --

Go to VA03, enter a valid sales order.
Navigate to Extras → Output → Header → Print Preview.
The system triggers the output program, and if you've placed breakpoints in the identified driver program, it enters debugging mode.

Section 2: Billing Documents (VF03 – Application V3)

Step 1: Identify Output Type Configuration

Go to T-code NACE.
Choose Application: V3 (Billing).

Click on Output Types.
Select output type and click "Processing Routines".

Here You’ll see: --

Driver Program
Form Routine
Smart Form information

Then we will go to the driver program and put the debugger point.

Trigger and Debug Output from VF03: --

Access VF03, input the billing document.
Navigate to Goto → Header → Output, select the output type and choose Repeat Output.
Use the Further Data option to configure the output's request for reprocessing.
To manually trigger debugging: --
Use Program RSNAST00
Provide relevant document and output type details
Execute to simulate output processing and hit breakpoints

Remember: --

Debugging Smart Forms is not just about fixing errors. it's about understanding the full flow from document to output and ensuring quality deliverables to your business users.

Conclusion: --

Understanding how to trace and debug Smart Forms and their associated driver programs is essential for any SAP ABAP developer or functional consultant involved in output management.

By following the structured steps for Sales (VA03 - V1) and Billing (VF03 - V3) provided in this blog, you can:

Quickly locate the output type configuration using NACE.
Identify the correct driver program and Smart Form.
Set effective breakpoints and debug output logic.
Use tools like RSNAST00, and SOST for monitoring and troubleshooting.
Ensure correct data is passed from application documents to the Smart Form output

Thank You__

Simple understanding of Hierarchies in SAP S/4HANA Embedded Analytics– Part 1 (Basics)

2025-11-21T12:47:55.322000+01:00

Accurate CDS hierarchy modeling and understanding is critical for financial reporting and operational analytics. Without well-defined hierarchies, drill-down analysis and aggregated insights become challenging. This blog demystifies hierarchy concepts in SAP S/4HANA Embedded Analytics and shows how they power SAC,Multidimensiona Reports , AFO and Datasphere scenarios.This blog will give you the basic understanding of Hierarchies in CDS Views (S4 Hana)

What This Blog Covers

Common hierarchy terminologies
Types of hierarchies in CDS Views
Standard hierarchies in S/4HANA
Why custom hierarchies matter

1. Key Terminologies-

Before diving into implementation, let’s clarify the basics:

Root Node : Top-most node in the hierarchy. Has No parent. Signifies the Hierarchy Structure and contains the Hierarchy metadata. A hierarchy can have several root nodes.
Hierarchy Node : Represents a group or element in the hierarchy.
Parent Node : A node that has child nodes beneath it.
Child Node : Belongs to a parent node.
Leaf Node : Lowest node in the hierarchy (end point).
Hierarchy Directory : Stores hierarchy definitions.
Siblings : Nodes sharing the same parent.
Hierarchy Level : Indicates depth of a node in the hierarchy. Levels can be defined as 0,1,2,3 . In S/4 EA change level based hierarchies to Parent child hierarchies .
Recursive Hierarchy: Nodes can reference themselves (e.g., Org Structure). Implemented using self-association in CDS.
Hierarchy Node Texts: These contain the descriptive names or labels associated with the hierarchy nodes, typically derived from the related master data (for example, the name or description of a General Ledger account or Product Hierarchy Description).
Orphan nodes, These are the nodes missing a link to a root. You can choose to ignore them, raise an error, or promote them as alternative roots using annotations like ORPHANS = ROOT

2. Example of a Hierarchy-

Company → Product Category → Product → Variant Shoe Model 1

Example:

Company (ABC Corp) → Root Node -> The top most node in hierarchy (Defined via Hierarchy Directory and Root node has no parent defined)---- To be discussed in details in another Part 2.
Product Category (Footwear) → Child of Company->A Parent Node for Product but this is not the Root node(Since it has Company as a Parent Node).
Product (Shoes) → Child of Product Category->Parent Node for Variant
Variant (Shoe Model 1) → Leaf Node->Lowest Node in the hierarchy

In SAP: For Cost Center or Profit Center hierarchy, Controlling Area could be the root node.

3. Types of Hierarchies in CDS Views-

In S/4HANA Embedded Analytics, hierarchies are modeled using CDS annotations. Most common type:

Parent-Child Hierarchy 🔗 Always recursive. Each node references its parent, forming a tree structure. Example: Cost Center hierarchy where each cost center belongs to a higher-level.

Level-Based Hierarchy 🔗Not supported in S4 Hana Embedded analytics as Analytical engine supports only Parent Child Hierarchy for drill downs and aggregations.

CDS Annotation Example:

@Hierarchy.parentChild:
{ recurse:          {   parent: 'ParentNode',   child:  'HierarchyNode'   },
  siblingsOrder:    {   by: 'SequenceNumber',    direction: 'ASC'   },
  directory:        '_Hierarchy' }

4. Standard Hierarchies in S/4HANA-

SAP delivers several predefined hierarchies:

Cost Center Hierarchy – For controlling and cost reporting
Profit Center Hierarchy – For profitability analysis
GL Account Hierarchy – For financial statements
Product Hierarchy – For material classification
EHS Location Hierarchies – For Environment, Health & Safety compliance

5. Custom Hierarchies-

Business requirements often demand custom hierarchies:

Example: A sales region hierarchy combining geography and product lines.
Implemented using CDS Views by developing a relation between Dimension Views and Hierarchy View.

6. Why Hierarchies Matter?

Enable drill-down reporting in SAC or Fiori Multidimensional Reports/AFO.
Support aggregations at multiple levels
Provide flexibility for planning and analytics

7. Technical Details: Where Hierarchies Are Stored-

HRRP_NODE_N Table: Stores Parent Node info, hierarchy node level details, and relationships between nodes(Example where GL Account/Profit Center/Cost Center Hierarchy details are stored).
HRRP_DIR_N Table: Stores Hierarchy Directory info (name, version, metadata).

👉When you activate or create a hierarchy (standard or custom), these tables are updated.

HRRP_NODE_N = Node-level details (Parent-Child relationships)
HRRP_DIR_N = Directory-level details (Hierarchy header info)

8. Hierarchy Components & Annotations-

A well-defined hierarchy in CDS has multiple views:

Source(Master Data) View: Provides key fields and relationships (Eg GL Account/Cost Center/Product related details).
Hierarchy View: Contains the relationships and parent–child links. Eg - Hierarchy(Child) Node, Parent Node, Node levels etc.
Directory View: Provides metadata about hierarchy variants -- Optional.
Text Views for labeling nodes and directory entries . Eg: GL account and it's text/ Cost center and it's text etc.

Proper annotations (@Hierarchy.parentChild, @ObjectModel.dataCategory: #HIERARCHY) control recursion, sibling order, orphan handling, and directory association

Notes:

Parent–Child Hierarchy: Supported in CDS for analytics; recursive structure.
Level-Based Hierarchy: Not supported in CDS for analytical consumption (only parent–child works for drill-down).
Orphan nodes = Nodes without a parent.
A Parent Node can have multiple Hierarchy Nodes/Child nodes but a hierarchy node cannot have multiple parents
A node can appear under different parents in different hierarchy versions, not in the same hierarchy( It usually refers to alternate hierarchy versions or variants, not simultaneous parents in the same hierarchy. For example:

Hierarchy Variant/Version 1: Region → Country → City

Hierarchy Variant/Version 2: Sales Channel → Country → City.This is managed via Hierarchy Directory.

A CDS hierarchy cannot serve as the underlying source for building another CDS hierarchy.

Next Article (Part 2)

How to activate Standard hierarchies and develop Custom Hierarchies in CDS Views (S4 Hana EA).
How to consume hierarchies in SAC

An End-to-End Hands-On Tutorial for Clean Core RAP Development

2025-11-28T12:18:20.855000+01:00

Introduction

In this workshop, we will build a simple Item business object using the ABAP RESTful Application Programming Model (RAP) on an SAP BTP trial system.

RAP is SAP’s strategic programming model for developing cloud-ready, Fiori-enabled business applications in ABAP. It provides a clean, end-to-end programming model where you can define business objects, behaviors, services, and UI-ready projections in a structured way.

In this blog, we will:

Create a database table for items.
Define CDS root and projection views.
Implement behavior definitions with CRUD, and enhance it with actions, validations and determinations.
Expose the business object as an OData service.
Preview it in Fiori.
Model relationships using associations and compositions between entities.
Implement value helps to improve user input and Fiori UX.

By the end, you will understand how RAP objects are structured, connected, and how Clean Core principles are applied in a real example.

Why RAP?

Cloud-ready: SAP’s standard for S/4HANA cloud extensions and custom apps.
Clean Core compliant: No modifications to standard objects; all extensibility is via APIs.
End-to-end model: Business logic, UI, draft handling, and authorizations all in one place.
Consistency: Automatic CRUD, locking, and draft handling.
Fiori-ready: Generates OData services consumable by Fiori Elements.
Productivity: Faster development than classical ABAP or BOPF.

Environment Setup

For this demo, we use ABAP Development Tools (ADT) in Eclipse connected to an ABAP on Cloud project on an SAP BTP trial system. This setup gives us access to all RAP development tools and lets us preview Fiori apps directly from Eclipse.

If you’re setting this up for the first time, SAP provides a step-by-step tutorial to install Eclipse IDE, add the ABAP Development Tools (ADT) plugin and connect to your SAP system. Download the Eclipse IDE and add the ABAP Development Tools (ADT) Plugin | SAP Tutorials

Useful ADT Shortcuts

Here are some useful ADT keyboard shortcuts for the ABAP development in Eclipse.

Info: You can display the full list of available shortcuts in the Show Key Assit in ADT by pressing Ctrl+Shift+L.

Part 1: Simple BO

Step 1: Create a Package

Before creating RAP objects, we need a package to organize them. Packages are like folders in Eclipse—they help manage all the development objects together.

1. In Eclipse, right-click your ABAP on Cloud project → New → ABAP Package.

2. Enter package details

Why this matters:

All RAP objects (tables, CDS views, behavior definitions, service definitions) should be in the same package.
It ensures clean core compliance, meaning your custom objects don’t modify standard SAP objects directly.

Step 2: Create Database Table

The database table is the foundation of your RAP business object. For this example, we’ll create a table called ZITEM02 for our Item BO.

1. Right-click your package → New → Other Repository Object → search for "Database Table".

2. Add the fields and mark item_id as the primary key.

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

  key client            : abap.clnt not null;
  key item_id           : sysuuid_x16 not null;
  name                  : abap.char(50) not null;
  description           : abap.char(100);
  price                 : abap.dec(10,2);
  status_code           : abap.char(5) not null;
  local_created_by      : abp_creation_user;
  local_created_at      : abp_creation_tstmpl;
  local_last_changed_by : abp_locinst_lastchange_user;
  local_last_changed_at : abp_locinst_lastchange_tstmpl;
  last_changed_at       : abp_lastchange_tstmpl;

}

3. Activate the table.

The table ZITEM_02 serves as the persistent layer for your RAP business object. All data is stored here.

Administrative Fields:

local_created_by/ local_created_at → track who created the record and when.

local_last_changed_by / local_last_changed_at → track local changes before activation (important for draft-enabled objects).

last_changed_at → tracks the last committed change; used as the ETag for locking and consistency.

Why Admin Fields Matter:

RAP automatically uses them for draft management, locking, and optimistic concurrency control. Even if your app is simple, including them makes your BO ready for enhancements such as validations, actions, and side effects.

Step 3: Create CDS

1. Root View

The root view sits on top of the database table and defines the entity structure for your business object. It is the source for the behavior definition.

1. Right-click the database table → New Data Definition

2. Select the Root View Entity template.

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Root View Entity for Item'
@Metadata.allowExtensions: true
define root view entity ZR_ITEM_02
  as select from zitem_02
{
  key item_id               as ItemId,
      name                  as Name,
      description           as Description,
      price                 as Price,
      status_code           as StatusCode,

      local_created_by      as LocalCreatedBy,
      local_created_at      as LocalCreatedAt,
      local_last_changed_by as LocalLastChangedBy,
      local_last_changed_at as LocalLastChangedAt,
      last_changed_at       as LastChangedAt
}

Table = raw persistence.

Root view = business-level representation, enriched with semantics, annotations, and ready for behavior logic.

The root view defines the primary key item_id to match the table.

2. Projection View

The projection view is built on top of the root view and serves as the entry point for service exposure. Here, we select which fields are exposed in the transactional OData service. We can also include UI annotations to guide Fiori Elements in rendering the app automatically.

1. Right-click the Root View CDS → New Data Definition

2. Select the Projection View template.

The root view contains the core business data and logic, while the projection only exposes what the frontend needs. This way, we don’t modify or clutter the core data model with UI-specific details, keeping the core stable and extensible.

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Projection View for Item'
@Metadata.allowExtensions: true
define root view entity ZC_ITEM_02
  provider contract transactional_query
  as projection on ZR_ITEM_02
{
  key ItemId,
      Name,
      Description,
      Price,
      StatusCode
}

For today, I’ll keep the UI annotations minimal here and show how to add them cleanly in a metadata extension later, which keeps our projection view tidy and focused on data exposure.

Step 4: Create Behavior Definition

The behavior definition specifies how this entity behaves at runtime: which operations are allowed, It maps fields from the root view to the database table, and how draft actions are handled.

1. Right-click the Root View CDS → New Behavior Definition

Since the purpose of this first example is to display the list report, we only need to map fields from the root view to the database table.

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

define behavior for ZR_ITEM_02 alias Item
persistent table zitem_02
lock master
authorization master ( instance )
etag master LastChangedAt
{
  create ( authorization : global );
  update;
  delete;
  field ( readonly, numbering : managed ) ItemId;

  mapping for zitem_02
    {
      ItemId      = item_id;
      Name        = name;
      Description = description;
      Price       = price;
      StatusCode  = status_code;
      LastChangedAt = last_changed_at;
      LocalCreatedAt = local_created_at;
      LocalCreatedBy = local_created_by;
      LocalLastChangedAt = local_last_changed_at;
      LocalLastChangedBy = local_last_changed_by;
    }
}

readonly → The field cannot be changed by the user. RAP ensures it is protected in the frontend and backend.
numbering : managed → RAP automatically generates unique values for this field when a new entity is created. You don’t need to write your own logic for primary keys like UUIDs or sequences.

The behavior projection allows us to expose only a subset of behavior from the main entity for a specific service. This is useful if we want different services to expose different parts of the behavior without modifying the core behavior definition.

projection;
strict ( 2 );

define behavior for ZC_ITEM_02 alias Item
{
  use create;
  use update;
  use delete;
}

Step 5: Create Service Definition

The service definition declares which projection views are exposed as OData services. Here, we expose our projection view, making our User BO available for Fiori or API consumption. Service definitions are protocol-agnostic and can later be consumed via different bindings.

@EndUserText.label: 'Service Definition for Item'
define service ZSD_ITEM {
  expose ZC_ITEM_02 as Item;
}

Step 6: Create Service Binding

Right-click the Service Definition → New Service Binding

Finally, the service binding connects the service definition to a specific protocol, such as OData V2 or V4. After activation, Publish the service and it can be accessed directly from Fiori elements or any OData client.

At this stage, our Business Object is not draft-enabled and does not support create/update/delete yet.
This means the Fiori Elements application shows a read-only list report, and because the table is empty, the preview will be blank.

This step is intentional — it confirms that:

the CDS views are correct
the projection is exposed
the service binding is active
the app renders successfully with no errors

Even with no data, seeing the list report appear is an important milestone. In the next sections, we will add draft support and enable full CRUD operations.

Part 2: Enabling Draft, CRUD Operations, and Transactional Behavior in the RAP Business Object

In Part 1 of this series, we created the foundation of our RAP application:

A clean core–compliant database table
The CDS root view entity
The projection view
A minimal behavior definition
A service binding that exposes our object to Fiori

At that stage, the generated application was intentionally read-only, serving as a good starting point to verify that the service and CDS structure work correctly.

Now, in Part 2, we take the next major step: turning our read-only object into a full transactional Business Object using the managed RAP BO approach. This includes:

Activating Create, Update, and Delete support
Enabling Draft handling for safe data entry
Allowing the Fiori Elements app to automatically render UI flows such as Edit, Save, Delete, and Discard Draft
Preparing the BO for further business logic enhancements (which we will add in Part 3)

Why We Enable Draft in RAP?

Draft is one of the key features of Fiori Elements applications.

Before enabling it, it’s important to explain why draft is needed.

Users expect modern UI behavior

In modern SAP Fiori apps, users do not commit their changes immediately. Instead:

They can start editing an object.
Leave the page.
Navigate back later.
Recover their unsaved changes.

This improves the UX significantly and eliminates accidental data loss.

Draft prevents incomplete database commits

Draft ensures that:

Partial or inconsistent data is never saved.
Users can enter complex data in multiple steps.
Locks on active instances are minimized.

This is especially important in enterprise systems with many concurrent users.

RAP provides draft automatically

Thanks to RAP’s managed BO runtime, draft functionality requires no custom code — only a few declarations in the behavior definition.

Step 1: Updating the Behavior Definition of the Root Entity

1. Add with draft;

2. Add draft table zitem_02_d;

This associates the BO with a draft table.

If the draft table does not exist yet, ADT will offer to create it automatically.

3. Click on "Quick assist" ( CTRL + 1 )

@EndUserText.label : 'Draft table for entity ZR_ITEM_02'
@AbapCatalog.enhancement.category : #EXTENSIBLE_ANY
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table zitem_02_d {

  key mandt          : mandt not null;
  key itemid         : sysuuid_x16 not null;
  name               : abap.char(50);
  description        : abap.char(100);
  price              : abap.dec(10,2);
  statuscode         : abap.char(5);
  localcreatedby     : abp_creation_user;
  localcreatedat     : abp_creation_tstmpl;
  locallastchangedby : abp_locinst_lastchange_user;
  locallastchangedat : abp_locinst_lastchange_tstmpl;
  lastchangedat      : abp_lastchange_tstmpl;
  "%admin"           : include sych_bdl_draft_admin_inc;

}

Draft tables contain:

Table fields
Administrator fields
Temporary user changes

This table supports parallel editing and safe drafts.

4. Additional Draft Actions and What They Do

In RAP, the draft handling pattern can be extended beyond the basic actions .
For more advanced scenarios — especially when working with optimized draft flows, background checks, or multi-step editing — we can include the following actions:

  draft action Activate optimized;
  draft action Edit;
  draft action Discard;
  draft action Resume;
  draft determine action Prepare { }

Beyond the basic Edit / Activate / Discard pattern, RAP provides additional draft actions to improve performance and user experience.

Resume – restores an existing draft so users can continue where they left off.
Prepare – pre-fills data before the user sees the draft instance.

These actions require no manual coding unless you want to enhance them, and together they deliver a modern, safe, Fiori-compliant editing workflow.

5. Add total etag LastChangedAt;

This ETag is used by RAP to guarantee concurrency and data consistency.
It prevents situations where one user accidentally overwrites changes made by another user.
It is also required for draft handling and for the Fiori Elements UI, which relies on this timestamp to detect outdated edits.
RAP automatically manages this field, updating it whenever the record is changed.

6. Update the Behavior Projection

The projection behavior definition exposes the business behavior to the Fiori UI and the OData service. Even if the root BO supports create, update, delete, and draft actions, they must be explicitly enabled in the behavior projection. Without this step, Fiori Elements will not show the Create/Edit/Delete or draft buttons. The projection layer ensures clean core separation by keeping internal logic in the root BO while exposing only the required operations to the UI.

projection;
strict ( 2 );
use draft;

define behavior for ZC_ITEM_02 alias Item
{
  use create;
  use update;
  use delete;

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

7. Create Behavior Implementation Class

Eclipse generates a global ABAP class with the naming convention.

Understanding What “Managed Implementation” Means

Standard CRUD is generated automatically

You do not need to write: create/ update/ delete logic, draft save/ load logic, locking logic, ETag management

RAP provides all of this out of the box.

The class is only for custom behavior

This is where we will later implement validations (check input before save), determinations (auto-fill fields), actions (mark item as completed), unmanaged logic, feature control, authorization checks, if needed.

But for Part 2 (Draft + CRUD), the class stays empty.

8. Creating the Metadata Extension (UI Annotations)

After creating the projection view and exposing the BO behavior, we need to define how this data should be displayed in Fiori Elements apps.

This is where metadata extensions come into play. They allow you to add UI annotations without touching the core CDS view, keeping your implementation clean and following Clean Core principles.

Right-click on the Consumption View → New → Metadata Extension

@Metadata.layer: #CORE
annotate entity ZC_ITEM_02 with
{
  @UI.facet: [
         {
             purpose: #STANDARD,
             type: #IDENTIFICATION_REFERENCE,
             label: 'Items',
             position: 10
         } ]
  ItemId;
  @UI.lineItem: [{ position: 10, label: 'Name' }]
  @UI.identification: [{ position: 10, label: 'Name' }]
  Name;
  @UI.lineItem: [{ position: 20, label: 'Description' }]
  @UI.identification: [{ position: 20, label: 'Description' }]
  Description;
  @UI.lineItem: [{ position: 30, label: 'Price' }]
  @UI.identification: [{ position: 30, label: 'Price' }]
  Price;
  @UI.lineItem: [{ position: 40, label: 'Status Code' }]
  @UI.identification: [{ position: 40, label: 'Status Code' }]
  StatusCode;

}

The metadata extension defines how the Item BO is displayed in Fiori Elements. Using annotations like @ui.lineItem and @ui.Identification, we specify which fields appear in the list report and object header. The @ui.facet groups the fields into a standard identification card. Placing these annotations in a metadata extension layer ensures Clean Core compliance, separating UI concerns from business logic, while enabling a ready-to-use Fiori preview.

After adding draft-enabled behavior and the metadata extension, let’s see the results in the Fiori preview:

Create Button appears automatically at the top of the list report and clicking it opens a draft object, ready for entry.

Delete Button appears at the top of the list report.

List Report displays all annotated fields without manually selecting columns, shows all items.

Object Page: clicking a list entry opens the object page.

Edit Button is visible on the object page, clicking it opens the draft for editing, supporting safe modifications before activation.

This confirms that draft-enabled RAP objects, combined with metadata annotations, automatically generate a full-featured Fiori UI: list report, object page, and CRUD actions—all without writing UI code manually.

Part 3: Enhancing the Item BO with Actions, Determinations, Validations

In Part 1 and Part 2, we created the basic structure of a RAP Business Object, enabled draft handling, activated CRUD operations, and prepared a clean UI using metadata extensions.

Now, in Part 3, we introduce the most important part of RAP:
Business logic — implemented through:

Validations (check before save)
Determinations (auto-fill fields)
Actions (custom operations triggered by the user)
Side Effects (UI refresh logic after actions)

To demonstrate these features in a realistic scenario, we switch to a second simple Business Object: Leave Requests

This BO includes fields such as employee name, requested days, and status.
With it, we implement:

A validation to ensure the requested days are > 0
A determination that sets the default status
A custom action Approve Leave Request
Metadata annotations to show an action button in the UI
Side effects to refresh the UI automatically after approval

Leave Request BO — Behavior Definition

Here is the behavior definition, which we will explain piece by piece:

managed implementation in class zbp_r_leavereq unique;
strict ( 2 );
with draft;

define behavior for ZR_LEAVEREQ
persistent table zleavereq
draft table zleavereq_d
lock master
total etag LastChangedAt
authorization master ( instance )
etag master LastChangedAt
{
  create ( authorization : global );
  update;
  delete;
  field ( readonly, numbering : managed ) Leaveguid;

  draft action Activate optimized;
  draft action Edit;
  draft action Discard;
  draft action Resume;
  draft determine action Prepare { }

  validation checkDays on save { create; update; field DaysReq; }
  determination setDefaultStatus on modify { create; }
  action approveLeaveRequest;


  mapping for zleavereq
    {
      Leaveguid          = leaveguid;
      EmployeeName       = employee_name;
      DaysReq            = days_req;
      Status             = status;
      LocalCreatedAt     = local_created_at;
      LocalCreatedBy     = local_created_by;
      LocalLastChangedAt = local_last_changed_at;
      LocalLastChangedBy = local_last_changed_by;
      LastChangedAt      = last_changed_at;
    }
}

Validation: checkDays

A validation allows you to stop a save operation if business rules are violated.

In this example, we ensure that requested days > 0.

Validation Logic in the Behavior Implementation Class

METHOD checkDays.
  READ ENTITIES OF zr_leavereq IN LOCAL MODE
  ENTITY zr_leavereq
  ALL FIELDS
  WITH CORRESPONDING #( keys )
  RESULT DATA(lt_leave_req).

  LOOP AT lt_leave_req ASSIGNING FIELD-SYMBOL(<fs_lr>).
    IF <fs_lr>-DaysReq < 1.
      APPEND VALUE #( %tky = <fs_lr>-%tky ) TO failed-zr_leavereq.
      APPEND VALUE #(
          %tky =  <fs_lr>-%tky
          %msg = new_message_with_text(
          text = 'Number of days should be > 0.'
          severity = if_abap_behv_message=>severity-error )
      ) TO reported-zr_leavereq.
    ENDIF.
  ENDLOOP.
ENDMETHOD.

What This Does

Prevents invalid leave requests
Displays an error in the Fiori UI
Ensures data consistency

The validation is triggered on save, both for create and update.

Determination: setDefaultStatus

A determination is used to auto-fill or derive values without UI involvement.

Here, whenever a leave request is created, we automatically set its initial status:

METHOD setDefaultStatus.
  DATA(key) = VALUE #( keys[ 1 ] OPTIONAL ).

  MODIFY ENTITIES OF zr_leavereq IN LOCAL MODE
  ENTITY zr_leavereq
  UPDATE FIELDS ( Status )
  WITH VALUE #( ( %tky = key-%tky
                  Status = 'Pending' ) ).

ENDMETHOD.

Action: approveLeaveRequest

Actions implement custom operations that the user triggers manually from the UI.

Here, we add an Approve action.

METHOD approveLeaveRequest.
  DATA(key) = VALUE #( keys[ 1 ] OPTIONAL ).

  MODIFY ENTITIES OF zr_leavereq IN LOCAL MODE
  ENTITY zr_leavereq
  UPDATE FIELDS ( Status )
  WITH VALUE #( ( %tky = key-%tky
                  Status = 'Approved' ) ).

ENDMETHOD.

When is an Action Appropriate?

Use an action when:

you require manual user intent (approve, reject, submit)
the change differs from standard CRUD
you want a button in the UI

Adding the Action to the Behavior Projection

Without adding it to the projection, the UI cannot call the action.

projection;
strict ( 2 );
use draft;

define behavior for ZC_LEAVEREQ
{
  use create;
  use update;
  use delete;

  use action approveLeaveRequest;

  side effects
  {
    action approveLeaveRequest affects $self, field Status;
  }

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

Side Effects — Keeping Fiori UI Updated

Side effects tell RAP which fields or entities might change when an action runs.

This ensures the UI refreshes automatically after the action is executed.

This informs Fiori Elements:

After pressing “Approve”, refresh the Status field
Update list report and object page automatically

Without side effects, the UI does not update until a manual refresh.

Adding an Inline Action Button to the Fiori List Report

In the Metadata Extension, you expose the action as a button:

@UI.lineItem: [{
  position: 40,
  type: #FOR_ACTION,
  dataAction: 'approveLeaveRequest',
  label: 'Approve',
  inline: true
}]

Meaning of inline: true

✔ The approve button appears directly in the table row
✔ User can approve without navigating to the object page
✔ Great for workflow-like processes

Part 4: CDS Relationships: Associations and Composition

In this part, we move to a more realistic RAP scenario, where our business object is no longer a single table.
Instead, we have Projects and Tasks, and these objects need to be connected.

RAP uses CDS associations and compositions to model these relationships.

CDS Associations — Linking Entities Together

An association is basically a link between two view entities — similar to a JOIN — but it is not executed until we actually navigate to it.

Association Between Task and User

In our app, each Task is assigned to a User.
We represent this using an association:

define view entity ZI_TASK
  as select from ztask_01
  association [0..1] to ZR_USER         as _User    on _User.UserCode = $projection.Assignee
{

What this means (simple explanation)

association → create a link between Task and User
ZR_USER → the target entity (the User root)
_User → the name we will use to navigate to it
on ... → join condition ( Assignee equals the UserCode )

Cardinality — What [0..1] Means

Cardinality describes how many related records the association can return.

This means:

0 → the task might not have an assigned user (Assignee is empty)
1 → if a user is assigned, there can be only one matching UserCode

This is a typical “optional 1-to-1” relationship.

If Assignee = 'USR01', we get that one user.
If Assignee is empty, we get nothing.

Using the Association in the Projection

Inside the projection view ZC_TASK, we read the user’s name through the _User association:

_User.UserName as AssigneeName,

This is only read, not stored anywhere in the Task table.

To make SAP Fiori show the text automatically, we add:

@ObjectModel.text.element: ['AssigneeName']
Assignee,

Result in the Fiori UI:

The UI displays UserCode + UserName

Why Associations Are Great

They avoid duplicate data
They allow “on-demand” navigation
They plug naturally into Fiori Elements
(value helps, display texts, navigation links)

Composition — Building a Parent/Child Relationship (Project → Tasks)

Now that we’ve seen simple associations, let’s move to something more powerful in RAP:
composition.

A composition is not just a link — it models a parent/child relationship where the child’s lifecycle depends entirely on the parent.

In our example:

Project is the parent
Tasks are the children

This is a very common RAP pattern used in real applications.

Defining the Composition in the Root Entity

In the Project root view (ZR_PROJECT), we define:

composition [0..*] of ZI_TASK as _Tasks

What this means (simple explanation):

composition → strong parent–child relationship
[0..*] → a project can have zero, one, or many tasks
of ZI_TASK → tasks are the child entity
_Tasks → the navigation property we will use in the UI

This tells RAP that:

Tasks belong to a project
Tasks cannot exist without the project
If the project is deleted, all its tasks must be deleted too
Tasks must always reference a ProjectId (its parent)

This is different from a normal association — it defines ownership.

Exposing the Composition in the Projection

In the Project projection (ZC_PROJECT), we expose the composition:

_Tasks : redirected to composition child ZC_TASK

This allows the UI to show the list of Tasks inside the Project object page, including:

Create Task
Edit Task
Delete Task

All directly in the Project UI.

Without this redirection, the Tasks table wouldn't appear in the Fiori Elements app.

Behavior Definition: Root and Child Must Work Together

Since compositions define hierarchy, the behavior must reflect that hierarchy.

define behavior for ZR_PROJECT alias Project
{
  create;
  update;
  delete;

  association _Tasks { create; with draft; }
}

Meaning:

The Project behavior controls the entire object
It is allowed to create children (_Tasks { create; })
Children are created in the context of the parent

In Fiori:

When you open a Project → Task table appears
“Create” inside the Tasks table creates a child of this project

define behavior for ZI_TASK alias Task
{
  update;
  delete;

  field (readonly) ParentId;

  association _Project { with draft; }
}

Meaning:

Tasks cannot create their own parent
Tasks inherit locking and authorization from the Project
Tasks cannot change the ParentId (because it is read-only)

The lifecycle looks like this:

You create a Project
Inside the project, you add Tasks
Tasks cannot exist outside the Project

Why Composition Is Important

It gives RAP a clear structure of your data model
It enables nested object pages (Projects → Tasks)
It simplifies locking, authorization, and lifecycle management
Fiori Elements automatically understands parent/child UI patterns
Child objects cannot “float” or become inconsistent

Part 5: Value Helps

So far, we built our entities, associations, and composition.
But in a real Fiori Elements app, users shouldn’t manually type in IDs.

Instead, they should select values from a value help (similar to a search help in classical ABAP).

In RAP, value helps are implemented using CDS view entities and the annotation:

@Consumption.valueHelpDefinition

Creating a Value Help View

Let’s look at the value help for selecting a User.

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Value Help for User'
@Metadata.ignorePropagatedAnnotations: true
define view entity ZI_USER_VH
  as select from ZR_USER
{
    @UI.hidden: true
  key UserId,
      UserCode,
      UserName
}

It selects from ZR_USER, our user root entity.
The value help will show UserCode and UserName in the popup search dialog.
This view is not a projection — it's a standalone VH definition recommended for RAP apps.

This view is now ready to be used by any field that needs a value help for Users.

Plugging the Value Help into the Task Projection

In the Task projection, we attach the value help to the Assignee field:

@Consumption.valueHelpDefinition: [{
    entity: { name: 'ZI_USER_VH', element: 'UserCode' },
    useForValidation: true
}]
Assignee,

What this does:

Opens a value help popup
Shows columns from ZI_USER_VH (UserCode, UserName)
Ensures the selected UserCode is valid (useForValidation: true)
Prevents users from entering invalid users

How to write Table function in stranded way like SAP

2025-12-09T12:36:55.534000+01:00

How to Write CDS Table Functions the Standard SAP Way

In SAP S/4HANA, we cannot always express complex business logic using pure CDS syntax. To manage scenarios like long text processing, procedural calculations, or important joins, SAP uses CDS Table Functions implemented through AMDP.

While many developers create table functions on the fly, SAP sticks to a strict and consistent design pattern across its standard content. This approach ensures good performance, readability, upgrade safety, and transportability.

A useful way to grasp this standard is to look at how SAP builds transactional CDS views, especially those that use CDS Table Functions. By examining SAP-delivered objects like I_SalesOrderTP, we can clearly see the structure, naming conventions, annotations, and implementation method that SAP expects developers to follow.

This guide explains how SAP writes table functions, how they implement them using AMDP, and how they use them in CDS views. This will help you design your own extensions in the same way SAP does.

Start with a Standard View: I_SALESORDERTP.

SAP provides many standard CDS views in S/4HANA.
To understand how SAP writes table functions, the easiest example is the view: I_SALESORDERTP
This is a Transactional Processing View, delivered by SAP.

2. Locate the Table Function Used Inside the View.

Inside the view, you will notice SAP has used: with parameters (...).

This indicates that the view is consuming a CDS Table Function.

3. You will find the CDS Table Function that SAP has written.

4. Open the AMDP Class to See SAP’s Logic.

Once you find the Table Function name, open the AMDP class: cl_sd_S4h_stxl_utils=>get_header_text
Inside this class, SAP has written the entire logic.

When crafting Table Functions ", in the manner SAP does " consistently adhere to this structure:

Create a CDS Table Function with parameters.

Implement it via an AMDP class/method using native SQLScript.

Consume it in your final CDS view using with parameters.

Follow the exact naming, annotation, and structure shown in standard objects such as I_SalesOrderTP, I_PurchaseOrderTP, I_BillingDocumentTP, etc.

Following this pattern guarantees:

Best performance (native HANA execution)

Transportability and upgrade-safety

Consistency with thousands of standard SAP-delivered objects

Conclusion

It is a tried-and-true architectural best practice to use SAP's standard pattern for CDS Table Functions. You can align your custom developments with the same design principles used in core SAP objects like *I_SalesOrderTP*, *I_PurchaseOrderTP*, and *I_BillingDocumentTP* by defining a CDS Table Function with parameters, implementing its logic in an AMDP method using native SQLScript, and consuming it through a final CDS view.

This method guarantees that sophisticated logic runs directly on SAP HANA for maximum efficiency, stays neatly isolated from the consumption layer, and is resilient to upgrades and transports. More significantly, because it adheres to a well-known and extensively used standard, it makes your solution instantly comprehensible to other SAP developers.

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.

How to create a BTP Account and add in the ADT

2025-12-12T08:59:14.528000+01:00

If you are new to SAP Business Technology Platform (BTP) or planning to explore ABAP Cloud development, creating an SAP BTP Trial account is the perfect place to start. The SAP BTP Trial allows you to experiment with SAP services, build applications, and practice ABAP Cloud development free of cost and without any commercial commitment. In this blog, I will walk you through step-by-step instructions to create an SAP BTP Trial account and connect it to ABAP Development Tools (ADT) in Eclipse.

Step 1: Visit SAP’s Website

Go to www.sap.com.
Find the “Free Trial” and click on it .
Start your free trial will be there click on it.

Step 2: Sign Up or Log In

New? Click “Register”:

Enter your email and login.

Step 3: Create Your Trial

On the “Welcome” page, click “Go to Your Trial Account”.
Pick a region which is close to you.

Click “Create Account” .

Step 4: Explore Your Playground

Click the “trial” box to start.

Check out “Service Marketplace” for fun tools like app-building.

Step 5: Enter Your Playground

You’re in the SAP BTP Cockpit Now.

Step 6: Start Your ABAP Trial

click “Boosters”
“Prepare an Account for ABAP Trial” --> “Start”.

A pop-up says, “Successful Booster Executed” And click “Go to Service Key”.

Find the Service Key row, click the 3 dots, and select “View”.

Copy the JSON code.

Step 7: Set Up Eclipse

Open Eclipse In your system.

Click “File” --> “New” --> “Project”--> “ABAP Cloud Project”.
Paste the JSON code.

Step 8: Create Your Coding Project

See “Successfully Logged On” On the Browser

In Eclipse, your project appears on the left.

Setting up an SAP BTP Trial account and connecting it to ABAP Development Tools is the first step toward learning modern SAP development.

With this trial environment, you can:

Practice ABAP Cloud & RAP
Explore SAP BTP services
Build and test applications safely in a non-production system

Setting up an SAP BTP Trial account and connecting it to ABAP Development Tools in Eclipse is a very straightforward, yet powerful, first step into the world of modern SAP development. Within a few steps, you have hands-on access to an ABAP Cloud environment where you can learn, experiment, and build with no cost and risk.

This trial setup lets you understand the latest development paradigm of SAP, practice ABAP Cloud and RAP concepts, and experience the broader capabilities of SAP Business Technology Platform on an actual system. Whether you are a novice or experienced ABAP developer moving to cloud-based development, SAP Business Technology Platform Trial is your ideal playground where you can upskill yourself for all future SAP projects.

In short, investing in setting up and using the SAP BTP Trial today lays a great foundation for becoming proficient with next-generation SAP development tomorrow.

How to Use SAP Extensibility Wizard in SAP S/4HANA Clean Core

2025-12-23T07:13:48.565000+01:00

A Comprehensive Guide to Extending SAP S/4HANA with the SAP Extensibility Wizard — Without Compromising Your Clean Core

Introduction

Extensibility is a critical aspect of SAP S/4HANA, enabling organizations to tailor the system to their unique business needs while maintaining stability and upgrade readiness. In this guide, we will explore the SAP Extensibility Wizard, a powerful tool designed to help developers extend SAP S/4HANA in a clean and controlled way.

What Is the SAP Extensibility Wizard?

The SAP Extensibility Wizard is a guided tool provided by SAP that simplifies the process of creating extensions. It ensures that developers can add custom functionality without modifying the core system, thereby preserving the clean core principle. This approach guarantees that upgrades remain smooth and that the system stays resilient over time.

Availability: Public Cloud vs. Private Cloud

A common question arises: Is the SAP Extensibility Wizard available only in the Public Cloud, or also in the Private Cloud?

Public Cloud (SAP S/4HANA Cloud – Public Edition):
The wizard is primarily available here. It supports clean-core extensibility and helps organizations build safe, upgrade‑friendly extensions.
Private Cloud / On‑Premise:
Extensibility is possible through other approaches such as in‑app extensibility, ABAP Cloud, and side‑by‑side extensions on SAP BTP. However, the wizard itself is not provided in the same way as in the Public Cloud.

In summary:

Public Cloud → Wizard available.
Private Cloud / On‑Premise → Extensibility options exist, but without the wizard.

Focus of This Blog

This blog will focus on the SAP Extensibility Wizard for SAP S/4HANA Cloud – Public Edition.

How to Use the Extensibility Wizard

With the SAP S/4HANA Cloud Public Edition extensibility wizard, developers can:

Create on‑stack extensions such as custom fields and custom logic.
Build side‑by‑side extensions like custom processes using SAP Build Process Automation.

This guided approach ensures that extensions are implemented efficiently, securely, and in alignment with SAP’s clean‑core strategy.

Conclusion

The SAP Extensibility Wizard is a key enabler for organizations running SAP S/4HANA Cloud Public Edition. By leveraging this tool, businesses can extend their systems with confidence, ensuring that customizations remain upgrade‑safe and future‑proof.

Detailed Steps:

Use Case : We will create a sales order approval process .

1. Navigate to SAP S4/HANA Fiori Launchpad.

1.1 Select Business Application Manage Sales Orders.

1.2 Navigate to Create Extension

1.3 In this case , we will select custom process.

The process can start based on various triggers

1.4 Select Business Event from SAP S4/HANA, that Triggers the process

1.5 Select Event Object

1.6 Select the SalesOrder create event.

1.7 Click Preview to see all the options you selected on previous screens, and make any necessary corrections.

1.8 Click Create , to create the process in SAP Build.

1.9 The extension is now available and can also be opened in SAP Build.

1.10 When you select Open Extension, the system launches another tab that opens the process.

1.11 The Process Automation project overview page is now displayed. Select SalesOrder Approval.

1.12 Extension is now openEd in SAP Build , Start design of the process.

The Business context is carried over from SAP S4/HANA to SAP Build .

1.13 You can add an action, form , or approval . To get further details on the sales order, you need to call an action .

1.14 In this use case , we will call sales order read API , to fetch the sales order details.

1.15 Browse the library to search for the relevant APIs .

1.16 Select read sales order API to get details of the sales order, The business context and system ID were automatically pulled in from SAP S4/HANA .

1.17 The action to read the sales order has now been added . Now users can design the process according to their needs. The user now wants to initiate a workflow that sends an email to the approver for sales order approval .

1.18 The email will include the sales order details , allowing approver to review and approve it . we're utilizing AI to generate the process , Enter the prompt to add an approval step and send the sales order details to the approver via email.

1.19 AI has now added the process step to read the sales order and email, The sales order details to the approver .

Conclusion

The SAP Extensibility Wizard empowers organizations running SAP S/4HANA Cloud Public Edition to extend their systems safely and efficiently, without compromising the clean core. By leveraging guided tools for custom fields, logic, and side‑by‑side processes, businesses can innovate while staying upgrade‑ready.

Extensibility in SAP is not just about adding features—it’s about doing so in a way that keeps your system future‑proof. With the wizard, you can confidently build the extensions your business needs today, while ensuring smooth upgrades tomorrow.

Custom Entity With Actions

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

What is a Custom Entity in RAP?

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

You need to expose calculated or external data.

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

You require custom operations beyond standard CRUD.

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

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

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

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

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

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

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

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

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

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

Output:

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

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

Conclusion

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

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

Research: Unmanaged Transactional Buffer For RESTful Application Programming Model

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

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

Ilya Prusakou
ABAP Developer & Researcher

Abstract.

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

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

Examples.

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

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

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

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

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

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

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

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

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

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

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

Buffer class.

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

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

Entity buffer tables.

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

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

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

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

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

Buffer preparation.

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

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

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

Root preparation

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

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

Root preparation logic is the following:

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

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

Child preparation

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

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

Let's explore logic.

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

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

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

parent1
- child1
- child2
- child3
- child4

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

Full Buffer key vs Partial Buffer key.

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

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

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

Impact of key field data type on buffer handling:

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

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

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

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

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

Schematically it can be expressed in the following way:

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

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

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

Complex Data source.

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

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

Buffer Components

Buffer flags

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

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

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

Buffer additional components

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

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

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

Generic pattern of usage.

Buffer handled in the following way:

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

Buffer access.

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

Buffer access in Transactional phase.

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

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

Buffer access in Save phase

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

Types of access in save phase:

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

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

Transactional buffer vs Draft buffer.

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

Operation aggregation.

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

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

Delete vs Discard vs Remove entry from buffer.

So let's define couple moments:

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

Unmanaged Transactional Buffer Blueprint

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

CLASS zpru_cl_example_buffer DEFINITION
  PUBLIC FINAL
  CREATE PUBLIC.

  PUBLIC SECTION.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    CLASS-METHODS prep_first_node_buffer
      IMPORTING !keys TYPE tt_first_node_keys.

    CLASS-METHODS prep_second_node_buffer
      IMPORTING !keys TYPE tt_second_node_keys.

    CLASS-METHODS prep_third_node_buffer
      IMPORTING !keys TYPE tt_third_node_keys.

    CLASS-METHODS prep_fourth_node_buffer
      IMPORTING !keys TYPE tt_fourth_node_keys.

ENDCLASS.


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

New Events for Outbound Nota Fiscal

2026-01-20T14:48:41.847000+01:00

Hi everyone!

Today, I would like to share with you some impactful insights directly from an SAP Note, which outlines a streamlined approach for sending the events listed in the NF-e Technical Note 2025.002 v1.30, published October 2025.

You can implement these changes in the outbound invoicing option for Brazil by following the instructions on SAP Note 3692197 and SAP Note 3689265.

Check out the latest updates and features in our What's New session on the SAP Help Portal:

SAP S/4HANA: New Events for Outbound Nota Fiscal

SAP ERP: New Events for Outbound Nota Fiscal

The Process

To send these events, you need to create a specific structure, as described in the "Manual da SEFAZ". You should create the new structure through the SEND_GENERIC_EVENT method from the CL_NFE_CLOUD_NFE_PROCESSOR class. This effectively sends the events using the IS_GENERIC_EVENT parameter, which is essential for declaring the structure.

You have to name this structure as ZNFE_MAP_EVENT_XXXXXX. You replace the XXXXXX for the number of supported events from the NF-e Technical Note 2025.002 v1.30. For example: ZNFE_MAP_EVENT_112110.

In this structure, you'll find control fields and event-specific fields that are mapped directly to the XML event. You have to build the DET_EVENTO structure, which can vary depending on the type of event. The field names differ between the backend system and their appearance in the cloud solution. Check the following example:

The structure of the event 112110 (Informação de efetivo pagamento integral para liberar crédito presumido do adquirente) is denoted as ZNFE_MAP_EVENT_112110. This structure has the following string fields and their equivalent in the cloud solution, following the rules of name conversion:

ATTR_VERSAO -> converted to a__versao to create the XML (you can check the rule to create XML attributes instead of elements in SAP Note 3692197)

DESC_EVENTO -> descEvento

C_ORGAO_AUTOR -> cOrgaoAutor

TP_AUTOR -> tpAutor

VER_APLIC -> verAplic

Check the XML file obtained after the name conversion. To download the XML file, follow the steps mentioned in SAP Note 3692197.

<detEvento versao="1"> 
   <descEvento>Informação de efetivo pagamento integral para liberar crédito presumido do adquirente</descEvento> 
   <cOrgaoAutor>35</cOrgaoAutor> 
   <tpAutor>1</tpAutor> 
   <verAplic>1</verAplic> 
   <indQuitacao>1</indQuitacao> 
</detEvento>

DET_EVENTO Structure Declaration

Create the structure  ZNFE_MAP_EVENT_112110. Ensure the structure matches the following definition:

TYPES: 
  BEGIN OF ZNFE_MAP_EVENT_112110, 
    a__versao        TYPE string, " XML Attribute 
    desc_evento      TYPE string, 
    c_orgao_autor    TYPE string, 
    tp_autor         TYPE string, 
    ver_aplic        TYPE string, 
    ind_quitacao     TYPE string, 
  END OF ZNFE_MAP_EVENT_112110.

Populating DET_EVENTO

You populate the DET_EVENTO  using assignment based on input parameters of the program. Check the following example:

DATA : ls_event_112110 TYPE ZNFE_MAP_EVENT_112110. 
ls_event_112110-a__versao = p_ver.         " Version - XML attribute 
ls_event_112110-desc_evento = p_desc.     " Event description 
ls_event_112110-c_orgao_autor = p_orgaut. " Author organization code 
ls_event_112110-tp_autor = p_tpaut.       " Type of authority 
ls_event_112110-ver_aplic = p_verapp.     " Application version 
ls_event_112110-ind_quitacao = p_indqui.  " Settlement indicator

Steps to Send a Generic Event

Step 1: Declare and Populate IS_GENERIC_EVENT

The IS_GENERIC_EVENT structure contains high-level control fields required for all types of events, including details such as issuing state, issuer's CNPJ, and access key (P_ACCKEY). Use the following template to populate the structure:

DATA : ls_generic_event        TYPE nfe_cloud_nfe_map_gnrc_evt. 
ls_generic_event-uuid                = lo_uuid_generator->generate_uuid( ). " Unique identifier 
ls_generic_event-authorize_uuid      = p_authid.                           " Reference UUID 
ls_generic_event-issuing_state       = p_state.                           " State code 
ls_generic_event-environment_type    = 'HOMOLOGATION'.                    " Environment 
ls_generic_event-issuing_type        = 'NORMAL'.                          " Issuing type 
ls_generic_event-issuer_identifier   = p_issuer.                          " Issuer CNPJ 
ls_generic_event-receiver_identifier = '74544297000192'.                " Receiver CNPJ

Step 2: Declare and Populate Specific DET_EVENTO

Based on the event type (P_TYPE), decide the specific structure for DET_EVENTO. For example:

If P_TYPE = '112110', use the predefined structure ZNFE_MAP_EVENT_112110: 

DATA : ls_event_112110 TYPE ZNFE_MAP_EVENT_112110. 
ls_event_112110-a__versao = p_ver.         " Attributes mapped as XML attributes 
ls_event_112110-desc_evento = p_desc. 
ls_event_112110-c_orgao_autor = p_orgaut. 
ls_event_112110-tp_autor = p_tpaut. 
ls_event_112110-ver_aplic = p_verapp. 
ls_event_112110-ind_quitacao = p_indqui. 
ls_generic_event-event_info-det_evento->* = ls_event_112110.  " Assigning DET_EVENTO structure

Step 3: Send the Event

Invoke the SEND_GENERIC_EVENT method:

TRY. 
  ls_result = lo_processor->send_generic_event( 
      is_generic_event       = ls_generic_event 
      is_company_definition  = ls_company_defition ). 
CATCH cx_nfe_cloud_invalid_value INTO lx_invalid_value. 
  lx_invalid_value->raise_message( ). 
  RETURN. 
ENDTRY.

Checking Event Status

To verify the status of sent events, follow these steps:

Service Locator: Use CREATE_SERVICE_LOCATOR_OBJECT from the CL_J_1BNFE_CF_MONITOR class.

Service Type Parameter: Reference C_SERVICE_EVENT_STATUS from CL_J_1BNFE_CF_CONSTANT.

Map Events and Generate JSON: Utilize the STRUCTURE_SERIALIZATION method from CL_J_1BNFE_CF_EVENT_UPDATE.

Client and OA2C Creation: Use SET_REQUEST_JSON and SEND_REQUEST_TO_CLOUD methods from CL_J_1BNFE_CF_SERVICE_COMM.

Transform JSON Response: Apply GET_RESPONSE_FROM_CLOUD to convert the response into an NF-e format.

Develop Response Structure: EVENT_TABLE_DESERIALIZATION method helps integrate this into an NF-e structure.

Building Your Application

Beyond these steps, you'll need to develop or extend your applications to:

Fill in necessary event data.

Trigger creation and submission based on business processes.

Implement error handling, logging, and monitoring according to your compliance standards.

That's a wrap for today! I hope this guide serves as a handy reference for anyone navigating the intricacies of sending events in SAP. Stay tuned for more insights and happy coding!

Until next time,

Natália

SAP e-Invoicing Application Engineer

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

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

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

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

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

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

The Three Paths for ABAP AI Evolution:

1. The Standard Path: Joule for Developers in ADT

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

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

Best for: Building your own AI-powered business applications (e.g., automated invoice processing).
The ABAP AI SDK is our reuse library that enables you to integrate Large Language Models (LLMs) and generative AI features directly into your SAP business applications with ABAP. So it is the "AI toolbox," allowing you to build intelligent applications with business context in the ABAP stack. The ABAP AI SDK is available in:
- SAP BTP ABAP Environment
- SAP S/4HANA Cloud Public Edition
- SAP S/4HANA Cloud Private Edition and OnPrem as of release 2025 via standard delivery.
- S/4 HANA private cloud version and on-premise 2021 onwards are supported via Transport-based Correction Instructions (TCI), see details in SAP Note 3513374.
Here you find more details on the AI SDK:
- https://help.sap.com/docs/abap-ai/generative-ai-in-abap-cloud/availability
- https://community.sap.com/t5/artificial-intelligence-blogs-posts/abap-meets-ai-my-hands-on-experience-with-sap-s-abap-sdk-for-llm/ba-p/14285453
Action: Use the SAP BTP Free Tier to access the Generative AI Hub and the ABAP AI SDK to connect your custom ABAP code to external foundation models.

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

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

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

Here you can learn more:

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

Creating an Interactive Editable ALV in ABAP with Header-Item CRUD Functionality

2026-01-24T04:59:44.641000+01:00

In this blog post, we will explore a powerful ABAP implementation of an editable ALV using CL_GUI_ALV_GRID. This solution provides:

Interactive two-screen design (Header & Item)
Double-click to drill down from header to item
Row-based editing using LVC_ROWMARK
Field-level edit control via CELLTAB
Full CRUD operations (Create, Read, Update, Delete) for both header and item data

🏠 Scenario

We use two custom database tables:

Custom Table → Delivery Header Data (VBELN, ERNAM, ERDAT, VSTEL, VKORG)
Custom Table → Delivery Item Data (VBELN, POSNR, MATNR, WERKS)

The goal is to allow users to edit only selected rows, protect primary key fields, and manage entries interactively.

1. Table Declarations

TABLES?

Custom transparent table containing delivery header data.
Custom transparent table for delivery item data.
These tables are used to fetch and store ALV grid data.

🔷 2. Class Forward Declaration

CLASS DELIVERY DEFINITION DEFERRED.

Forward declares a class named DELIVERY used later to handle double-click events.
This is necessary to register event handlers before the class is fully implemented.

🔷 3. Type Declarations

TYPES: BEGIN OF T_ZDB_EDIT_ALV, VBELN TYPE ZDB_EDIT_ALV-VBELN, ERNAM TYPE ZDB_EDIT_ALV-ERNAM, ERDAT TYPE ZDB_EDIT_ALV-ERDAT, VSTEL TYPE ZDB_EDIT_ALV-VSTEL, VKORG TYPE ZDB_EDIT_ALV-VKORG, CELLTAB TYPE LVC_T_STYL, END OF T_ZDB_EDIT_ALV.

Defines a structure T_ZDB_EDIT_ALV to hold header data and editable styles.
CELLTAB: Stores editable style info for ALV cell-level control.

Similarly, for item data:

TYPES: BEGIN OF T_ZDB_EDIT_ALV1, VBELN TYPE ZDB_EDIT_ALV1-VBELN, POSNR TYPE ZDB_EDIT_ALV1-POSNR, MATNR TYPE ZDB_EDIT_ALV1-MATNR, WERKS TYPE ZDB_EDIT_ALV1-WERKS, CELLTAB TYPE LVC_T_STYL, END OF T_ZDB_EDIT_ALV1.

🔷 4. Data Definitions

DATA: LT_LIKP TYPE TABLE OF T_ZDB_EDIT_ALV, LS_LIKP TYPE T_ZDB_EDIT_ALV, LT_LIPS TYPE TABLE OF T_ZDB_EDIT_ALV1, LS_LIPS TYPE T_ZDB_EDIT_ALV1,

Internal tables and work areas for header (LT_LIKP, LS_LIKP) and item (LT_LIPS, LS_LIPS) records.

LT_FCAT TYPE LVC_T_FCAT, LS_FCAT TYPE LVC_S_FCAT, LT_FCAT1 TYPE LVC_T_FCAT, LS_FCAT1 TYPE LVC_S_FCAT,

Field catalog tables for header (LT_FCAT) and item (LT_FCAT1) ALVs.

LS_LAYO TYPE LVC_S_LAYO, LS_LAYO1 TYPE LVC_S_LAYO,

Layout configurations for header and item grids.

O_CONTAINER1 TYPE REF TO CL_GUI_CUSTOM_CONTAINER, O_GRID1 TYPE REF TO CL_GUI_ALV_GRID, O_CONTAINER2 TYPE REF TO CL_GUI_CUSTOM_CONTAINER, O_GRID2 TYPE REF TO CL_GUI_ALV_GRID,

Containers and ALV grid objects for screen 200 (header) and screen 100 (item).

5. Selection Screen Definition

Purpose: Creates a selection screen block with delivery number as the input filter.
S_VBELN: Allows users to input multiple values or ranges for VBELN.
TEXT-000: Refers to a text element (defined in SE32 or SE38) for the frame title.

🔷 6. Field Catalog for Item ALV

Uses VALUE #( ) constructor to populate the field catalog for the item-level ALV (LT_LIPS).
COL_POS: Column order in the ALV.
FIELDNAME: Field to display.
COLTEXT: Header text.
TABNAME: Reference table used for dynamic assignment (not required in OO ALV, but used for clarity here).

🔷 7. Layout Configuration for Item ALV

GRID_TITLE: Title of the ALV.
SEL_MODE = 'A': Allows multiple row selection.
NO_TOOLBAR = 'X': Hides the standard ALV toolbar.
STYLEFNAME = 'CELLTAB': Tells ALV to use the CELLTAB column to control editable styles per cell.

🔷 8. Start-of-Selection

START-OF-SELECTION. CALL SCREEN 200.

Trigger point of the report after user input.
It navigates to screen 200, which displays the header-level ALV.

9. Event Handler Class Definition

Defines a local class DELIVERY with method GET_DATA.
The method is registered as an event handler for the double-click event of the ALV.

🔷 10. Class Implementation

GET_DATA is triggered when the user double-clicks on a row in header ALV.
It reads the delivery number (VBELN) of the clicked row.
Then fetches all matching item-level records from ZDB_EDIT_ALV1 into LT_LIPS.
Opens Screen 100, which shows the item ALV.

🔷 11. Screen 100 (Item ALV) - OUTPUT Module

SET PF-STATUS 'ZITEMS': Sets the GUI status (button functions) for item screen.
PERFORM CREATE_OBJECT_LIPS: Initializes the ALV Grid for item records.

🔷 12. Screen 100 - INPUT Module

Handles user actions on screen 100:
- BACK: Return to header ALV.
- CREATE: Add a new item row.
- EDIT: Enable selected row for editing.
- UPDATE: Update modified item data.
- DELETE: Remove selected rows.
- SAVE: Insert/update item data into DB.

FORM CREATE_OBJECT_LIPS – Initializes ALV on Screen 100 (Item).
MODULE STATUS_0200 OUTPUT – Prepares header ALV on Screen 200.
MODULE USER_COMMAND_0200 INPUT – Handles toolbar actions for header ALV.
Then we’ll go deeper into the CRUD FORMs (CREATE/EDIT/UPDATE/DELETE/SAVE) for both header and item ALVs.
FORM CREATE_OBJECT_LIPS – Create ALV Grid for Items

🔹

Explanation:

CLEAR O_CONTAINER2: Reset reference before ALV creation (safety check).
CREATE OBJECT O_CONTAINER2: Creates a custom container placed on the screen (SCREEN 100) using element CONTAINER2.
CREATE OBJECT O_GRID2: Binds an ALV Grid (CL_GUI_ALV_GRID) to the container.
SET_TABLE_FOR_FIRST_DISPLAY:
- IS_LAYOUT = LS_LAYO1: Applies previously configured layout for item ALV.
- IT_OUTTAB = LT_LIPS: Data source for the ALV.
- IT_FIELDCATALOG = LT_FCAT1: Column settings for the ALV.

🔷 13. MODULE STATUS_0200 OUTPUT – Setup Header Screen (Screen 200)

Explanation:

SET PF-STATUS 'ZHEADER': Sets GUI status for header toolbar (buttons: CREATE, EDIT, SAVE, etc.).
The SELECT pulls header records from ZDB_EDIT_ALV based on delivery numbers entered on the selection screen.

ALV Grid Initialization:

Creates the custom container and grid for header-level display.

Field Catalog (LT_FCAT):

Each field is appended individually to LT_FCAT with attributes:

Layout for Header ALV:

Final ALV Setup:

Initializes header ALV with all settings and data.

Event Handler Registration:

Double-click on any row in header ALV triggers GET_DATA, which fetches corresponding items.

🔷 14. MODULE USER_COMMAND_0200 INPUT – Header Screen Toolbar Actions

Executes the relevant FORM based on user action on toolbar buttons:
- CREATE: Adds a new editable row.
- EDIT: Enables selected row for editing.
- SAVE: Inserts or updates data in DB.
- DELETE: Removes selected rows from ALV and DB.
- UPDATE: Commits modified data to DB.

15. FORM CHANGE_MODE – Enable Edit Mode for Selected Header Row

Purpose: Only the selected row becomes editable. All others stay read-only.
LVC_T_ROID, LVC_S_STYL: Types for editable styles.
CELLTAB is used for cell-level control.
Gets the row(s) selected in the header ALV using LVC_ROWMARK.

Loop over each header entry to determine which row to enable.

Compares the current loop index with selected rows.
If it’s selected, enable its editable fields.

🔹 If Selected Row → Enable ditable Fields

IF SY-SUBRC = 0. LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED. LS_STYLEROW-FIELDNAME = 'VBELN'. INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

VBELN is a primary key → disabled.
Similarly disables ERNAM.

LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_ENABLED. LS_STYLEROW-FIELDNAME = 'ERDAT'. INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

Enables only non-primary key fields for editing: ERDAT, VSTEL, VKORG.

🔹 Assign Cell Styles to Entry

CLEAR: LS_LIKP-CELLTAB. INSERT LINES OF LT_STYLEROW INTO TABLE LS_LIKP-CELLTAB. MODIFY LT_LIKP FROM LS_LIKP TRANSPORTING CELLTAB. CLEAR: LT_STYLEROW.

Applies the style to the current line.

🔹 Else – Row not selected → Make it fully non-editable

ELSE. LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED. ... INSERT LS_STYLEROW INTO TABLE LT_STYLEROW. ... MODIFY LT_LIKP FROM LS_LIKP TRANSPORTING CELLTAB.

🔹 Toggle Grid Ready for Input

IF O_GRID1->IS_READY_FOR_INPUT( ) EQ 0. CALL METHOD O_GRID1->SET_READY_FOR_INPUT EXPORTING I_READY_FOR_INPUT = 1. ELSE. CALL METHOD O_GRID1->SET_READY_FOR_INPUT EXPORTING I_READY_FOR_INPUT = 0. ENDIF.

Activates input mode if not already.

O_GRID1->REFRESH_TABLE_DISPLAY( ).ENDFORM.

Refreshes the ALV to reflect the updated editable state.

🔷 16. FORM CREATE_HEADER_DATA – Add New Editable Header Row

FORM CREATE_HEADER_DATA . DATA: LS_NEW TYPE T_ZDB_EDIT_ALV, LT_STYLEROW TYPE STANDARD TABLE OF LVC_S_STYL WITH DEFAULT KEY, LS_STYLEROW TYPE LVC_S_STYL.

Prepares a new structure and editable field style list.

🔹 Set Editable Fields

LS_STYLEROW-FIELDNAME = 'VBELN'. LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_ENABLED. APPEND LS_STYLEROW TO LT_STYLEROW.

All fields are enabled since it’s a new row. Even primary keys like VBELN, ERNAM.
Repeats for: ERNAM, ERDAT, VSTEL, VKORG.

🔹 Assign Styles and Add New Entry

LS_NEW-CELLTAB = LT_STYLEROW. APPEND LS_NEW TO LT_LIKP.

Assigns the editable CELLTAB and appends the new row to the internal table.

CALL METHOD O_GRID1->SET_READY_FOR_INPUT EXPORTING I_READY_FOR_INPUT = 1. CALL METHOD O_GRID1->REFRESH_TABLE_DISPLAY.ENDFORM.

Turns on editable mode and refreshes ALV.

17. FORM DELETE_HEADER_DATA – Delete Selected Header Rows

FORM DELETE_HEADER_DATA . DATA: LT_ROWS TYPE LVC_T_ROW, LS_ROW TYPE LVC_S_ROW, LV_IDX TYPE SY-TABIX.

LT_ROWS: Holds the list of selected row indexes.
LS_ROW: Work area for current row index.
LV_IDX: Integer used to track which row index is being processed.

🔹 Get Selected Rows

CALL METHOD O_GRID1->GET_SELECTED_ROWS IMPORTING ET_INDEX_ROWS = LT_ROWS.

Fetches the selected row indexes in the header ALV grid.

🔹 Loop and Delete from DB & Internal Table

LOOP AT LT_ROWS INTO LS_ROW. LV_IDX = LS_ROW-INDEX. READ TABLE LT_LIKP INDEX LV_IDX INTO LS_LIKP. IF SY-SUBRC = 0. DELETE FROM ZDB_EDIT_ALV WHERE VBELN = LS_LIKP-VBELN. DELETE LT_LIKP INDEX LV_IDX. ENDIF. ENDLOOP.

For each selected row:
- Reads that entry from LT_LIKP.
- Deletes corresponding record from DB table ZDB_EDIT_ALV.
- Deletes it from internal table LT_LIKP.

🔹 Refresh ALV & Commit

CALL METHOD O_GRID1->REFRESH_TABLE_DISPLAY. COMMIT WORK. MESSAGE 'Selected header(s) deleted' TYPE 'S'.ENDFORM.

Refreshes the ALV display.
Saves DB changes using COMMIT WORK.
Displays success message.

🔷 18. FORM SAVE_HEADER_DATA – Insert or Update Header Records

FORM SAVE_HEADER_DATA .

🔹 Flat Structure Definition

TYPES: BEGIN OF TY_ZDB_EDIT_ALV_FLAT, VBELN TYPE ZDB_EDIT_ALV-VBELN, ERNAM TYPE ZDB_EDIT_ALV-ERNAM, ERDAT TYPE ZDB_EDIT_ALV-ERDAT, VSTEL TYPE ZDB_EDIT_ALV-VSTEL, VKORG TYPE ZDB_EDIT_ALV-VKORG, END OF TY_ZDB_EDIT_ALV_FLAT. DATA: LS_DB_ALV_FLAT TYPE TY_ZDB_EDIT_ALV_FLAT.

This structure excludes CELLTAB and is used to write data into the DB.

🔹 Ensure User Changes Are Captured

CALL METHOD O_GRID1->CHECK_CHANGED_DATA.

Updates the internal table (LT_LIKP) with user input from the ALV grid.

🔹 Loop Through Header Table and Save to DB

LOOP AT LT_LIKP INTO LS_LIKP. LS_DB_ALV_FLAT-VBELN = LS_LIKP-VBELN. LS_DB_ALV_FLAT-ERNAM = LS_LIKP-ERNAM. LS_DB_ALV_FLAT-ERDAT = LS_LIKP-ERDAT. LS_DB_ALV_FLAT-VSTEL = LS_LIKP-VSTEL. LS_DB_ALV_FLAT-VKORG = LS_LIKP-VKORG.

Copies the values to a flat version to avoid CELLTAB structure issues.

🔹 Insert or Update Logic

SELECT SINGLE VBELN INTO @DATA(LV_VBELN) FROM ZDB_EDIT_ALV WHERE VBELN = @LS_DB_ALV_FLAT-VBELN AND ERNAM = @LS_DB_ALV_FLAT-ERNAM. IF SY-SUBRC = 0. UPDATE ZDB_EDIT_ALV SET ERDAT = @LS_DB_ALV_FLAT-ERDAT, VSTEL = @LS_DB_ALV_FLAT-VSTEL, VKORG = @LS_DB_ALV_FLAT-VKORG WHERE VBELN = @LS_DB_ALV_FLAT-VBELN AND ERNAM = @LS_DB_ALV_FLAT-ERNAM. ELSE. INSERT ZDB_EDIT_ALV FROM LS_DB_ALV_FLAT. ENDIF. ENDLOOP.

If record exists (same VBELN & ERNAM) → UPDATE.
Else → INSERT as new record.

COMMIT WORK. MESSAGE 'Header data saved successfully' TYPE 'S'.ENDFORM.

Final commit and success message.

🔷 19. FORM UPDATE_HEADER_DATA – Update Header Records

FORM UPDATE_HEADER_DATA . CALL METHOD O_GRID1->CHECK_CHANGED_DATA.

Reads current ALV data into LT_LIKP.

🔹 Loop and Upsert to DB

Maps data into a flat structure.

Same insert/update logic as SAVE

COMMIT WORK. MESSAGE 'Header data Updated successfully' TYPE 'S'.ENDFORM.

✅ That completes the full documentation of header-level editable ALV with CRUD.

Next, I’ll begin the item-level ALV explanation starting with:

FORM CHANGE_ITEMS_MODE
FORM CREATE_ITEMS_DATA
FORM DELETE_ITEMS_DATA
FORM SAVE_ITEMS_DATA
FORM UPDATE_ITEMS_DATA

🔷 20. FORM CHANGE_ITEMS_MODE – Make Only Selected Item Row Editable

FORM CHANGE_ITEMS_MODE . DATA: LT_INDEX_ROWS TYPE LVC_T_ROW, LT_ROW_NO TYPE LVC_T_ROID, LS_ROW_NO TYPE LVC_S_ROID, LS_STYLEROW TYPE LVC_S_STYL, LT_STYLEROW TYPE TABLE OF LVC_S_STYL.

Similar to header edit logic.
Used to control which single row in the item ALV becomes editable.

CALL METHOD O_GRID2->GET_SELECTED_ROWS IMPORTING ET_ROW_NO = LT_ROW_NO.

Retrieves the selected item rows using LVC_ROWMARK.

🔹 Loop Over All Rows and Toggle Editable Mode

IF NOT LT_ROW_NO IS INITIAL. LOOP AT LT_LIPS INTO LS_LIPS. READ TABLE LT_ROW_NO INTO LS_ROW_NO WITH KEY ROW_ID = SY-TABIX.

For each item row in LT_LIPS, check if it’s selected.

🔹 If Selected: Enable Editable Fields

IF SY-SUBRC = 0. LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED. LS_STYLEROW-FIELDNAME = 'VBELN'. INSERT LS_STYLEROW INTO TABLE LT_STYLEROW. LS_STYLEROW-FIELDNAME = 'POSNR'. INSERT LS_STYLEROW INTO TABLE LT_STYLEROW. LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_ENABLED. LS_STYLEROW-FIELDNAME = 'MATNR'. INSERT LS_STYLEROW INTO TABLE LT_STYLEROW. LS_STYLEROW-FIELDNAME = 'WERKS'. INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

VBELN and POSNR are primary keys → disabled.
Only MATNR, WERKS are editable.

CLEAR: LS_LIPS-CELLTAB. INSERT LINES OF LT_STYLEROW INTO TABLE LS_LIPS-CELLTAB. MODIFY LT_LIPS FROM LS_LIPS TRANSPORTING CELLTAB. CLEAR: LT_STYLEROW.

Applies the cell-style configuration to the current row.

🔹 Else: Disable All Fields for Non-Selected Rows

ELSE. LOOP AT FIELDS: 'VBELN', 'POSNR', 'MATNR', 'WERKS'. LS_STYLEROW-FIELDNAME = FIELD. LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED. INSERT LS_STYLEROW INTO TABLE LT_STYLEROW. ENDLOOP. CLEAR: LS_LIPS-CELLTAB. INSERT LINES OF LT_STYLEROW INTO TABLE LS_LIPS-CELLTAB. MODIFY LT_LIPS FROM LS_LIPS TRANSPORTING CELLTAB. CLEAR: LT_STYLEROW.

🔹 Toggle Edit Mode and Refresh ALV

IF O_GRID2->IS_READY_FOR_INPUT( ) EQ 0. CALL METHOD O_GRID2->SET_READY_FOR_INPUT EXPORTING I_READY_FOR_INPUT = 1. ELSE. CALL METHOD O_GRID2->SET_READY_FOR_INPUT EXPORTING I_READY_FOR_INPUT = 0. ENDIF. O_GRID2->REFRESH_TABLE_DISPLAY( ).ENDFORM.

🔷 21. FORM CREATE_ITEMS_DATA – Add New Editable Row in Item ALV

FORM CREATE_ITEMS_DATA . DATA: LS_NEW TYPE T_ZDB_EDIT_ALV1, LT_STYLEROW TYPE STANDARD TABLE OF LVC_S_STYL WITH DEFAULT KEY, LS_STYLEROW TYPE LVC_S_STYL. CLEAR: LS_NEW, LT_STYLEROW.

Creates a blank work area and editable style table.

🔹 Enable All Fields (for Create)

LS_STYLEROW-FIELDNAME = 'VBELN'. LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_ENABLED. APPEND LS_STYLEROW TO LT_STYLEROW. ... (Repeat for POSNR, MATNR, WERKS)

All fields are enabled so user can create new record from scratch.

LS_NEW-CELLTAB = LT_STYLEROW. APPEND LS_NEW TO LT_LIPS. CALL METHOD O_GRID2->SET_READY_FOR_INPUT EXPORTING I_READY_FOR_INPUT = 1. CALL METHOD O_GRID2->REFRESH_TABLE_DISPLAY.ENDFORM.

Appends the new row to ALV and switches to input mode.

🔷 22. FORM DELETE_ITEMS_DATA – Delete Selected Item Rows

FORM DELETE_ITEMS_DATA . DATA: LT_ROWS TYPE LVC_T_ROW, LS_ROW TYPE LVC_S_ROW, LV_IDX TYPE SY-TABIX. CALL METHOD O_GRID2->GET_SELECTED_ROWS IMPORTING ET_INDEX_ROWS = LT_ROWS.

Gets the selected item row indexes from ALV.

LOOP AT LT_ROWS INTO LS_ROW. LV_IDX = LS_ROW-INDEX. READ TABLE LT_LIPS INDEX LV_IDX INTO LS_LIPS. IF SY-SUBRC = 0. DELETE FROM ZDB_EDIT_ALV1 WHERE VBELN = LS_LIPS-VBELN. DELETE LT_LIPS INDEX LV_IDX. ENDIF. ENDLOOP. CALL METHOD O_GRID2->REFRESH_TABLE_DISPLAY. COMMIT WORK. MESSAGE 'Selected header(s) deleted' TYPE 'S'.ENDFORM.

Deletes item records from both DB and internal table.

🔷 23. FORM SAVE_ITEMS_DATA – Insert or Update Item Rows

FORM SAVE_ITEMS_DATA . DATA: LS_DB_ALV1 TYPE TY_ZDB_EDIT_ALV1_FLAT, LS_DB_FULL TYPE ZDB_EDIT_ALV1, LV_VBELN TYPE ZDB_EDIT_ALV1-VBELN. CALL METHOD O_GRID2->CHECK_CHANGED_DATA.

Converts ALV changes to internal table.
Flat structure is used to exclude CELLTAB.

🔹 Loop Through Item Table

LOOP AT LT_LIPS INTO LS_LIPS. LS_DB_ALV1-VBELN = LS_LIPS-VBELN. LS_DB_ALV1-POSNR = LS_LIPS-POSNR. LS_DB_ALV1-MATNR = LS_LIPS-MATNR. LS_DB_ALV1-WERKS = LS_LIPS-WERKS.

Transfer values from ALV row to flat structure.

🔹 DB Insert/Update Logic

SELECT SINGLE VBELN INTO @LV_VBELN FROM ZDB_EDIT_ALV1 WHERE VBELN = @LS_DB_ALV1-VBELN AND POSNR = @LS_DB_ALV1-POSNR. IF SY-SUBRC = 0. UPDATE ZDB_EDIT_ALV1 SET MATNR = @LS_DB_ALV1-MATNR, WERKS = @LS_DB_ALV1-WERKS WHERE VBELN = @LS_DB_ALV1-VBELN AND POSNR = @LS_DB_ALV1-POSNR. ELSE. CLEAR LS_DB_FULL. MOVE-CORRESPONDING LS_DB_ALV1 TO LS_DB_FULL. INSERT ZDB_EDIT_ALV1 FROM LS_DB_FULL. ENDIF. ENDLOOP. COMMIT WORK. MESSAGE 'Item data saved successfully' TYPE 'S'.ENDFORM.

🔷 24. FORM UPDATE_ITEMS_DATA – Update Existing Item Records

FORM UPDATE_ITEMS_DATA . DATA: LS_DB_ALV1 TYPE TY_ZDB_EDIT_ALV1_FLAT, LS_DB_FULL TYPE ZDB_EDIT_ALV1, LV_VBELN TYPE ZDB_EDIT_ALV1-VBELN. CALL METHOD O_GRID2->CHECK_CHANGED_DATA.

Same structure and update logic as SAVE.

LOOP AT LT_LIPS INTO LS_LIPS. LS_DB_ALV1-VBELN = LS_LIPS-VBELN. LS_DB_ALV1-POSNR = LS_LIPS-POSNR. LS_DB_ALV1-MATNR = LS_LIPS-MATNR. LS_DB_ALV1-WERKS = LS_LIPS-WERKS. SELECT SINGLE VBELN INTO @DATA(S_VBELN) FROM ZDB_EDIT_ALV1 WHERE VBELN = @LS_DB_ALV1-VBELN AND POSNR = @LS_DB_ALV1-POSNR. IF SY-SUBRC = 0. UPDATE ZDB_EDIT_ALV1 SET MATNR = @LS_DB_ALV1-MATNR, WERKS = @LS_DB_ALV1-WERKS WHERE VBELN = @LS_DB_ALV1-VBELN AND POSNR = @LS_DB_ALV1-POSNR. ELSE. CLEAR LS_DB_FULL. MOVE-CORRESPONDING LS_DB_ALV1 TO LS_DB_FULL. INSERT ZDB_EDIT_ALV1 FROM LS_DB_FULL. ENDIF. ENDLOOP. COMMIT WORK. MESSAGE 'Item data Updated successfully' TYPE 'S'.ENDFORM.Output:

Header Output

When I was click on edit button

When I was click on create button

When I was create a new row delete button

When I was click on create buttom multiple append rows also created in both header and item also

If I was save on empty row Its shows as

If was double click on empty on no items was displayed and Header empty row it will not created on items details

Same actions performs in CURD operations in item level also:

Program :

REPORT ZEDITABLE_ALV_INT.

************************************************************************
* Program Name  : 
* Description   : Editable ALV using CL_GUI_ALV_GRID with row-based edit
*                 control using LVC_ROWMARK. Only selected row becomes
*                 editable, primary keys remain non-editable and to perfrom a crud operations.
* Created by    : <NRAJU>
*************************************************************************
*---------------------------------------------------------------------*
*                   Table Declarations
*---------------------------------------------------------------------*
TABLES:ZDB_EDIT_ALV,ZDB_EDIT_ALV1.
CLASS DELIVERY DEFINITION DEFERRED.
*---------------------------------------------------------------------*
*                   Type Declarations
*---------------------------------------------------------------------*
TYPES: BEGIN OF T_ZDB_EDIT_ALV,
             VBELN TYPE ZDB_EDIT_ALV-VBELN, "Delivery  Number
       ERNAM TYPE ZDB_EDIT_ALV-ERNAM, "Name of Person who Created the Object
             ERDAT TYPE ZDB_EDIT_ALV-ERDAT, "Date on Which Record Was Created
             VSTEL TYPE ZDB_EDIT_ALV-VSTEL, "Shipping Point/Receiving Point
             VKORG TYPE ZDB_EDIT_ALV-VKORG, "Sales Organization
             CELLTAB TYPE LVC_T_STYL,          "Editable style table
           END   OF T_ZDB_EDIT_ALV.
TYPES: BEGIN OF T_ZDB_EDIT_ALV1,
             VBELN TYPE ZDB_EDIT_ALV1-VBELN, "Delivery  Number
             POSNR TYPE ZDB_EDIT_ALV1-POSNR, "Sales Document Item
             ERNAM TYPE ZDB_EDIT_ALV1-ERNAM,
             MATNR TYPE ZDB_EDIT_ALV1-MATNR, "Material Number
             WERKS TYPE ZDB_EDIT_ALV1-WERKS, "Plant
             CELLTAB TYPE LVC_T_STYL,          "Editable style table
           END   OF T_ZDB_EDIT_ALV1.
 DATA:LT_LIKP TYPE TABLE OF T_ZDB_EDIT_ALV,     "Internal table for header
       LS_LIKP TYPE T_ZDB_EDIT_ALV,             "workarea for header
       LT_LIPS TYPE TABLE OF T_ZDB_EDIT_ALV1,   "Internal table for Item
       LS_LIPS TYPE T_ZDB_EDIT_ALV1,            "Workarea for item
       LT_FCAT TYPE LVC_T_FCAT,                 "Filedcat
       LS_FCAT TYPE LVC_S_FCAT,
       LT_FCAT1 TYPE LVC_T_FCAT,                "filedcatlog
       LS_FCAT1 TYPE LVC_S_FCAT,
       LS_LAYO TYPE LVC_S_LAYO,                 "Layout
       LS_LAYO1 TYPE LVC_S_LAYO,
   O_CONTAINER1 TYPE REF TO CL_GUI_CUSTOM_CONTAINER,    "Container for Header
       O_GRID1 TYPE REF TO CL_GUI_ALV_GRID,                 "Grid for Header
    O_CONTAINER2 TYPE REF TO CL_GUI_CUSTOM_CONTAINER,    "Container for item
       O_GRID2 TYPE REF TO CL_GUI_ALV_GRID.                 "Grid for It
*---------------------------------------------------------------------*
*                   Selection Screen
*---------------------------------------------------------------------*
   SELECTION-SCREEN BEGIN OF BLOCK B1 WITH FRAME TITLE TEXT-000.
       SELECT-OPTIONS:S_VBELN FOR ZDB_EDIT_ALV-VBELN.
    SELECTION-SCREEN END OF BLOCK B1.
*************fieldcatalog creation creation for item
    LT_FCAT1 = VALUE #(
    ( COL_POS = 1 FIELDNAME = 'VBELN'  COLTEXT = 'Delivery Number'  )
    ( COL_POS = 2 FIELDNAME = 'POSNR'  COLTEXT = 'Item Number'   )
    ( COL_POS = 3 FIELDNAME = 'ERNAM' COLTEXT = 'NAME' )
    ( COL_POS = 4 FIELDNAME = 'MATNR'  COLTEXT = 'Material Number'   )
    ( COL_POS = 5 FIELDNAME = 'WERKS'  COLTEXT = 'Plant'   )
  ).

*************Layout creation for item
     LS_LAYO1-GRID_TITLE = 'Custom Table for Items'.
    LS_LAYO1-SEL_MODE = 'A'.
    LS_LAYO1-NO_TOOLBAR = 'X'.
    LS_LAYO1-STYLEFNAME = 'CELLTAB'.

     "*************fieldcatalog creation creation
    LS_FCAT-ROW_POS = 1.
    LS_FCAT-COL_POS = 1.
    LS_FCAT-FIELDNAME = 'VBELN'.
    LS_FCAT-COLTEXT = 'Delivery  Number'.
    LS_FCAT-OUTPUTLEN = 20.
    APPEND LS_FCAT TO LT_FCAT.
    CLEAR LS_FCAT.

   LS_FCAT-ROW_POS = 1.
    LS_FCAT-COL_POS = 1.
    LS_FCAT-FIELDNAME = 'ERNAM'.
    LS_FCAT-COLTEXT = 'Name'.
    LS_FCAT-OUTPUTLEN = 20.
    APPEND LS_FCAT TO LT_FCAT.
    CLEAR LS_FCAT.

    LS_FCAT-ROW_POS = 1.
    LS_FCAT-COL_POS = 1.
    LS_FCAT-FIELDNAME = 'ERDAT'.
    LS_FCAT-COLTEXT = 'Date'.
    LS_FCAT-OUTPUTLEN = 20.
    APPEND LS_FCAT TO LT_FCAT.
    CLEAR LS_FCAT.

   LS_FCAT-ROW_POS = 1.
    LS_FCAT-COL_POS = 1.
    LS_FCAT-FIELDNAME = 'VSTEL'.
    LS_FCAT-COLTEXT = 'SALES'.
    LS_FCAT-OUTPUTLEN = 20.
    APPEND LS_FCAT TO LT_FCAT.
    CLEAR LS_FCAT.
    LS_FCAT-ROW_POS = 1.
    LS_FCAT-COL_POS = 1.
    LS_FCAT-FIELDNAME = 'VKORG'.
    LS_FCAT-COLTEXT = 'Delivery  Number'.
    LS_FCAT-OUTPUTLEN = 20.
    APPEND LS_FCAT TO LT_FCAT.
    CLEAR LS_FCAT.

***********layout of fieldcat
   LS_LAYO-GRID_TITLE = 'Custom Table for Header'.
    LS_LAYO-SEL_MODE = 'A'.
    LS_LAYO-NO_TOOLBAR = 'X'.
    LS_LAYO-STYLEFNAME = 'CELLTAB'.

    START-OF-SELECTION.                                  "start-of-selection
    CALL SCREEN 200.                                     "Screen for Header
    CLASS Delivery DEFINITION.
      PUBLIC SECTION.
      METHODS: GET_DATA FOR EVENT DOUBLE_CLICK OF CL_GUI_ALV_GRID
                                               IMPORTING E_ROW.
       ENDCLASS.
*&---------------------------------------------------------------------*
*&       Class (Implementation)  Delivery
*&---------------------------------------------------------------------*
*        Text
*----------------------------------------------------------------------*
CLASS DELIVERY IMPLEMENTATION.
  METHOD: GET_DATA.
    READ TABLE LT_LIKP INTO LS_LIKP INDEX E_ROW-INDEX.
    SELECT VBELN
           POSNR
           ERNAM
           MATNR
           WERKS
            FROM ZDB_EDIT_ALV1
      INTO CORRESPONDING FIELDS OF TABLE LT_LIPS
      WHERE VBELN = LS_LIKP-VBELN and ernam = ls_likp-ernam.

**        Check if items exist
*    IF lt_lips IS INITIAL.
*      MESSAGE 'No items exist for this header.' TYPE 'I'.
*      RETURN.
*    ENDIF.
      CALL SCREEN 100.
* " Refresh ALV to reflect changes
*  CALL METHOD O_GRID1->REFRESH_TABLE_DISPLAY.
  ENDMETHOD.
ENDCLASS.               "Delivery
*&---------------------------------------------------------------------*
*&      Module  STATUS_0100  OUTPUT
*&---------------------------------------------------------------------*
*       text
*----------------------------------------------------------------------*
MODULE STATUS_0100 OUTPUT.
  SET PF-STATUS 'ZITEMS'.               "Creating buttons for items
  PERFORM CREATE_OBJECT_LIPS.           "perform for create item
ENDMODULE.
*&---------------------------------------------------------------------*
*&      Module  USER_COMMAND_0100  INPUT
*&---------------------------------------------------------------------*
*       text
*----------------------------------------------------------------------*
MODULE USER_COMMAND_0100 INPUT.
  CASE SY-UCOMM.
    WHEN 'BACK'.
      LEAVE TO SCREEN 200.
    WHEN 'CREATE'.                    "Createing new record for items
       PERFORM CREATE_ITEMS_DATA.
    WHEN 'EDIT'.                      "Editable alv for items
       PERFORM CHANGE_ITEMS_MODE.
    WHEN 'UPDATE'.                    "Updateing the records for items
        PERFORM UPDATE_ITEMS_DATA.
    WHEN 'DELETE'.                    "Deleting the records for item tables
        PERFORM DELETE_ITEMS_DATA.
    WHEN 'SAVE'.                      "Saveing the recording from db table in item records
        PERFORM SAVE_ITEMS_DATA.
  ENDCASE.
ENDMODULE.
*&---------------------------------------------------------------------*
*&      Form  CREATE_OBJECT_LIPS
FORM CREATE_OBJECT_LIPS .
  CLEAR O_CONTAINER2.
  IF O_CONTAINER2 IS INITIAL AND O_GRID2 IS INITIAL.
    CREATE OBJECT O_CONTAINER2
      EXPORTING
        CONTAINER_NAME              = 'CONTAINER2'
      EXCEPTIONS
        CNTL_ERROR                  = 1
        CNTL_SYSTEM_ERROR           = 2
        CREATE_ERROR                = 3
        LIFETIME_ERROR              = 4
        LIFETIME_DYNPRO_DYNPRO_LINK = 5
        OTHERS                      = 6
        .
    CREATE OBJECT O_GRID2
      EXPORTING
        I_PARENT          = O_CONTAINER2
      EXCEPTIONS
        ERROR_CNTL_CREATE = 1
        ERROR_CNTL_INIT   = 2
        ERROR_CNTL_LINK   = 3
        ERROR_DP_CREATE   = 4
        OTHERS            = 5
        .
    ENDIF.
    CALL METHOD O_GRID2->SET_TABLE_FOR_FIRST_DISPLAY
      EXPORTING
        IS_LAYOUT                     = LS_LAYO1
      CHANGING
        IT_OUTTAB                     = LT_LIPS
        IT_FIELDCATALOG               = LT_FCAT1
      EXCEPTIONS
        INVALID_PARAMETER_COMBINATION = 1
        PROGRAM_ERROR                 = 2
        TOO_MANY_LINES                = 3
        OTHERS                        = 4
            .
    call method O_GRID2->REFRESH_TABLE_DISPLAY( ).
ENDFORM.
*&---------------------------------------------------------------------*
*&      Module  STATUS_0200  OUTPUT
*&---------------------------------------------------------------------*
MODULE STATUS_0200 OUTPUT.
  SET PF-STATUS 'ZHEADER'.
  " Only load header data from DB once
  IF lt_likp IS INITIAL.
    SELECT vbeln
           ernam
           erdat
           vstel
           vkorg
      FROM zdb_edit_alv
      INTO CORRESPONDING FIELDS OF TABLE lt_likp
      WHERE vbeln IN s_vbeln.
  ENDIF.
  " Only create container and grid once
  IF o_container1 IS INITIAL AND o_grid1 IS INITIAL.
    " Create custom container
    CREATE OBJECT o_container1
      EXPORTING
        container_name = 'CONTAINER1'.
    " Create ALV grid object
    CREATE OBJECT o_grid1
      EXPORTING
        i_parent = o_container1.
    " Set up field catalog and layout if needed (assuming lt_fcat and ls_layo are ready)
    CALL METHOD o_grid1->set_table_for_first_display
      EXPORTING
        i_structure_name              = 'ZDB_EDIT_ALV'
        is_layout                     = ls_layo
      CHANGING
        it_outtab                     = lt_likp
        it_fieldcatalog               = lt_fcat
      EXCEPTIONS
        invalid_parameter_combination = 1
        program_error                 = 2
        too_many_lines                = 3
        OTHERS                        = 4.
    " Set event handler for item-level data retrieval
    DATA(o_delivery) = NEW delivery( ).
    SET HANDLER o_delivery->get_data FOR o_grid1.
  ENDIF.
ENDMODULE.
*&---------------------------------------------------------------------*
*&      Module  USER_COMMAND_0200  INPUT
MODULE USER_COMMAND_0200 INPUT.
 CASE SY-UCOMM.
   WHEN 'BACK'.
      LEAVE PROGRAM.                    "Back to the program
    WHEN 'CREATE'.                      "Creating new record for header data
      PERFORM CREATE_HEADER_DATA.
    WHEN 'EDIT'.                        "Editable alv for header data
      PERFORM CHANGE_MODE.
    WHEN 'UPDATE'.                      "Updateing the record for header data
       PERFORM UPDATE_HEADER_DATA.
  WHEN 'DELETE'.                      "deleteing for a record for header data
       PERFORM DELETE_HEADER_DATA.
    WHEN 'SAVE'.                        "saveing the db table for header data
       PERFORM SAVE_HEADER_DATA.
  ENDCASE.
ENDMODULE.
*&---------------------------------------------------------------------*
*&      Form  CHANGE_MODE
*&---------------------------------------------------------------------*
FORM CHANGE_MODE .
   DATA : LT_INDEX_ROWS TYPE LVC_T_ROW,
         LT_ROW_NO     TYPE LVC_T_ROID,
         LS_ROW_NO     TYPE LVC_S_ROID,
         LS_STYLEROW   TYPE LVC_S_STYL,
         LT_STYLEROW   TYPE TABLE OF LVC_S_STYL.
  CALL METHOD O_GRID1->GET_SELECTED_ROWS
    IMPORTING
*     et_index_rows = lt_index_rows
      ET_ROW_NO = LT_ROW_NO.
  IF NOT LT_ROW_NO IS INITIAL.
    LOOP AT LT_LIKP INTO LS_LIKP.
      READ TABLE LT_ROW_NO INTO LS_ROW_NO WITH KEY ROW_ID = SY-TABIX.
      IF SY-SUBRC = 0.
        LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
        LS_STYLEROW-FIELDNAME = 'VBELN'.
        INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

        LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
        LS_STYLEROW-FIELDNAME = 'ERNAM'.
        INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

        LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_ENABLED.
        LS_STYLEROW-FIELDNAME = 'ERDAT'.
        INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

        LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_ENABLED.
        LS_STYLEROW-FIELDNAME = 'VSTEL'.
        INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

        LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_ENABLED.
        LS_STYLEROW-FIELDNAME = 'VKORG'.
        INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

        CLEAR: LS_LIKP-CELLTAB.
        INSERT LINES OF LT_STYLEROW INTO TABLE LS_LIKP-CELLTAB.
        MODIFY LT_LIKP FROM LS_LIKP TRANSPORTING CELLTAB.
        CLEAR: LT_STYLEROW.
      ELSE.
        LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
        LS_STYLEROW-FIELDNAME = 'VBELN'.
        INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

        LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
        LS_STYLEROW-FIELDNAME = 'ERNAM'.
        INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

        LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
        LS_STYLEROW-FIELDNAME = 'ERDAT'.
        INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

        LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
        LS_STYLEROW-FIELDNAME = 'VSTEL'.
        INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

        LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
        LS_STYLEROW-FIELDNAME = 'VKORG'.
        INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

        CLEAR: LS_LIKP-CELLTAB.
        INSERT LINES OF LT_STYLEROW INTO TABLE LS_LIKP-CELLTAB.
        MODIFY LT_LIKP FROM LS_LIKP TRANSPORTING CELLTAB.
        CLEAR: LT_STYLEROW.
      ENDIF.
    ENDLOOP.
  ENDIF.

  CLEAR LT_ROW_NO.
  CLEAR LS_ROW_NO.

  IF O_GRID1->IS_READY_FOR_INPUT( ) EQ 0.
    CALL METHOD O_GRID1->SET_READY_FOR_INPUT
      EXPORTING
        I_READY_FOR_INPUT = 1.

  ELSE.
    CALL METHOD O_GRID1->SET_READY_FOR_INPUT
      EXPORTING
        I_READY_FOR_INPUT = 0.
  ENDIF.
 CALL METHOD O_GRID1->REFRESH_TABLE_DISPLAY( ).

ENDFORM.
*&---------------------------------------------------------------------*
*&      Form  CREATE_HEADER_DATA
*&---------------------------------------------------------------------*
FORM CREATE_HEADER_DATA .
 DATA: LS_NEW        TYPE T_ZDB_EDIT_ALV,
        LT_STYLEROW   TYPE STANDARD TABLE OF LVC_S_STYL WITH DEFAULT KEY,
        LS_STYLEROW   TYPE LVC_S_STYL.

  CLEAR: LS_NEW, LT_STYLEROW.

  " Define editable fields

  LS_STYLEROW-FIELDNAME = 'VBELN'.
  LS_STYLEROW-STYLE     = CL_GUI_ALV_GRID=>MC_STYLE_ENABLED.
  APPEND LS_STYLEROW TO LT_STYLEROW.

  LS_STYLEROW-FIELDNAME = 'ERNAM'.
  LS_STYLEROW-STYLE     = CL_GUI_ALV_GRID=>MC_STYLE_ENABLED.
  APPEND LS_STYLEROW TO LT_STYLEROW.

  LS_STYLEROW-FIELDNAME = 'ERDAT'.
  LS_STYLEROW-STYLE     = CL_GUI_ALV_GRID=>MC_STYLE_ENABLED.
  APPEND LS_STYLEROW TO LT_STYLEROW.

  LS_STYLEROW-FIELDNAME = 'VSTEL'.
  LS_STYLEROW-STYLE     = CL_GUI_ALV_GRID=>MC_STYLE_ENABLED.
  APPEND LS_STYLEROW TO LT_STYLEROW.

  LS_STYLEROW-FIELDNAME = 'VKORG'.
  LS_STYLEROW-STYLE     = CL_GUI_ALV_GRID=>MC_STYLE_ENABLED.
  APPEND LS_STYLEROW TO LT_STYLEROW.

  " Assign celltab to new row
  LS_NEW-CELLTAB = LT_STYLEROW.

  " Insert new row at the beginning
  APPEND LS_NEW TO LT_LIKP.

  " Set grid to editable mode
  CALL METHOD O_GRID1->SET_READY_FOR_INPUT
    EXPORTING
      I_READY_FOR_INPUT = 1.

  " Refresh ALV to reflect changes
  CALL METHOD O_GRID1->REFRESH_TABLE_DISPLAY.

ENDFORM.
*&---------------------------------------------------------------------*
*&      Form  DELETE_HEADER_DATA
*&---------------------------------------------------------------------
FORM DELETE_HEADER_DATA .
  DATA: LT_ROWS TYPE LVC_T_ROW,
        LS_ROW  TYPE LVC_S_ROW,
        LV_IDX  TYPE SY-TABIX.
  CALL METHOD O_GRID1->GET_SELECTED_ROWS
    IMPORTING ET_INDEX_ROWS = LT_ROWS.
  LOOP AT LT_ROWS INTO LS_ROW.
    LV_IDX = LS_ROW-INDEX.
    READ TABLE LT_LIKP INDEX LV_IDX INTO LS_LIKP.
    IF SY-SUBRC = 0.
      DELETE FROM ZDB_EDIT_ALV WHERE VBELN = LS_LIKP-VBELN and ERNAM = LS_LIKP-ERNAM.
      DELETE LT_LIKP INDEX LV_IDX.
    ENDIF.
  ENDLOOP.
  CALL METHOD O_GRID1->REFRESH_TABLE_DISPLAY.
  COMMIT WORK.
  MESSAGE 'Selected header(s) deleted' TYPE 'S'.

ENDFORM.
*&---------------------------------------------------------------------*
*&      Form  SAVE_HEADER_DATA
*&---------------------------------------------------------------------*
TYPES: BEGIN OF TY_ZDB_EDIT_ALV_FLAT,
         VBELN TYPE ZDB_EDIT_ALV-VBELN,
         ERNAM TYPE ZDB_EDIT_ALV-ERNAM,
         ERDAT TYPE ZDB_EDIT_ALV-ERDAT,
         VSTEL TYPE ZDB_EDIT_ALV-VSTEL,
         VKORG TYPE ZDB_EDIT_ALV-VKORG,
       END OF TY_ZDB_EDIT_ALV_FLAT.

DATA: LS_DB_ALV_FLAT TYPE TY_ZDB_EDIT_ALV_FLAT.

FORM SAVE_HEADER_DATA .

DATA: LS_DB_ALV_FLAT TYPE TY_ZDB_EDIT_ALV_FLAT,
        LV_VBELN       TYPE ZDB_EDIT_ALV-VBELN,
        LV_SKIPPED     TYPE I VALUE 0,
        LT_LIKP_CLEAN  TYPE TABLE OF T_ZDB_EDIT_ALV,
        LS_LIKP_CLEAN  TYPE T_ZDB_EDIT_ALV,
        LV_SAVED_ROWS  TYPE I VALUE 0.

  " Capture ALV changes
  CALL METHOD O_GRID1->CHECK_CHANGED_DATA.

  LOOP AT LT_LIKP INTO LS_LIKP.

    " Skip empty header rows
    IF LS_LIKP-VBELN IS INITIAL
    AND LS_LIKP-ERNAM IS INITIAL
    AND LS_LIKP-ERDAT IS INITIAL
    AND LS_LIKP-VSTEL IS INITIAL
    AND LS_LIKP-VKORG IS INITIAL.

      LV_SKIPPED = LV_SKIPPED + 1.
      CONTINUE.
    ENDIF.

    " Keep non-empty row for redisplay
    LS_LIKP_CLEAN = LS_LIKP.
    APPEND LS_LIKP_CLEAN TO LT_LIKP_CLEAN.

    " Prepare structure for DB insert/update
    CLEAR LS_DB_ALV_FLAT.
    MOVE-CORRESPONDING LS_LIKP TO LS_DB_ALV_FLAT.

    " Check if record exists
    SELECT SINGLE VBELN
      INTO @LV_VBELN
      FROM ZDB_EDIT_ALV
      WHERE VBELN = @LS_DB_ALV_FLAT-VBELN.

    IF SY-SUBRC = 0.
      " Record exists -> UPDATE
      UPDATE ZDB_EDIT_ALV SET
        ERNAM = @LS_DB_ALV_FLAT-ERNAM,
        ERDAT = @LS_DB_ALV_FLAT-ERDAT,
        VSTEL = @LS_DB_ALV_FLAT-VSTEL,
        VKORG = @LS_DB_ALV_FLAT-VKORG
      WHERE VBELN = @LS_DB_ALV_FLAT-VBELN.
    ELSE.
      " Record does not exist -> INSERT
      INSERT ZDB_EDIT_ALV FROM LS_DB_ALV_FLAT.
    ENDIF.

    LV_SAVED_ROWS = LV_SAVED_ROWS + 1.

  ENDLOOP.
  " Replace the old internal table with the cleaned one (remove empty rows)
  LT_LIKP = LT_LIKP_CLEAN.
  COMMIT WORK.
*ENDIF.
 " Message after save
IF LV_SKIPPED > 0.
  MESSAGE |{ LV_SKIPPED } empty header record(s) were not saved and removed.| TYPE 'I'.
ELSEIF LV_SAVED_ROWS < 0.
  MESSAGE | { LV_SAVED_ROWS } without editing or creating anything were data not saved.| TYPE 'I'.
ELSE.
  MESSAGE 'Header data saved successfully' TYPE 'S'.
ENDIF.
  " Lock the grid after save
  PERFORM DISABLE_ALL_CELLS_IN_HEADER.

  CALL METHOD O_GRID1->SET_READY_FOR_INPUT
    EXPORTING I_READY_FOR_INPUT = 0.

  CALL METHOD O_GRID1->REFRESH_TABLE_DISPLAY.
ENDFORM.
*&---------------------------------------------------------------------*
*&      Form  UPDATE_HEADER_DATA
*&---------------------------------------------------------------------*
FORM UPDATE_HEADER_DATA .
  CALL METHOD O_GRID1->CHECK_CHANGED_DATA.
  LOOP AT LT_LIKP INTO LS_LIKP.
    " Map to flat structure (exclude CELLTAB)
    LS_DB_ALV_FLAT-VBELN = LS_LIKP-VBELN.
    LS_DB_ALV_FLAT-ERNAM = LS_LIKP-ERNAM.
    LS_DB_ALV_FLAT-ERDAT = LS_LIKP-ERDAT.
    LS_DB_ALV_FLAT-VSTEL = LS_LIKP-VSTEL.
    LS_DB_ALV_FLAT-VKORG = LS_LIKP-VKORG.
    " Check if record exists
    SELECT SINGLE VBELN
  INTO @DATA(LV_VBELN)
  FROM ZDB_EDIT_ALV
  WHERE VBELN = @LS_DB_ALV_FLAT-VBELN
    AND ERNAM = @LS_DB_ALV_FLAT-ERNAM.
    IF SY-SUBRC = 0.
      " Record exists -> UPDATE
      UPDATE ZDB_EDIT_ALV SET
        ERDAT = @LS_DB_ALV_FLAT-ERDAT,
        VSTEL = @LS_DB_ALV_FLAT-VSTEL,
        VKORG = @LS_DB_ALV_FLAT-VKORG
      WHERE VBELN = @LS_DB_ALV_FLAT-VBELN AND ERNAM = @LS_DB_ALV_FLAT-ERNAM.
    ELSE.
      " Record does not exist -> INSERT
      INSERT ZDB_EDIT_ALV FROM LS_DB_ALV_FLAT.
    ENDIF.
  ENDLOOP.
  COMMIT WORK.
  MESSAGE 'Header data Updated successfully' TYPE 'S'.

  " ➕ Make all fields non-editable after save
  PERFORM DISABLE_ALL_CELLS_IN_HEADER.

  " ➕ Set ALV to non-edit mode
  CALL METHOD O_GRID1->SET_READY_FOR_INPUT
    EXPORTING I_READY_FOR_INPUT = 0.

  " ➕ Refresh ALV display
  CALL METHOD O_GRID1->REFRESH_TABLE_DISPLAY.

ENDFORM.
*&---------------------------------------------------------------------*
*&      Form  CHANGE_ITEMS_MODE
*&---------------------------------------------------------------------*
FORM CHANGE_ITEMS_MODE .
   DATA : LT_INDEX_ROWS TYPE LVC_T_ROW,
         LT_ROW_NO     TYPE LVC_T_ROID,
         LS_ROW_NO     TYPE LVC_S_ROID,
         LS_STYLEROW   TYPE LVC_S_STYL,
         LT_STYLEROW   TYPE TABLE OF LVC_S_STYL.

  CALL METHOD O_GRID2->GET_SELECTED_ROWS
    IMPORTING
*     et_index_rows = lt_index_rows
      ET_ROW_NO = LT_ROW_NO.

  IF NOT LT_ROW_NO IS INITIAL.

    LOOP AT LT_LIPS INTO LS_LIPS.

      READ TABLE LT_ROW_NO INTO LS_ROW_NO WITH KEY ROW_ID = SY-TABIX.
      IF SY-SUBRC = 0.
        LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
        LS_STYLEROW-FIELDNAME = 'VBELN'.
        INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

        LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
        LS_STYLEROW-FIELDNAME = 'POSNR'.
        INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

        LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
        LS_STYLEROW-FIELDNAME = 'ERNAM'.
        INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

        LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_ENABLED.
        LS_STYLEROW-FIELDNAME = 'MATNR'.
        INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

        LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_ENABLED.
        LS_STYLEROW-FIELDNAME = 'WERKS'.
        INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

        CLEAR: LS_LIPS-CELLTAB.
        INSERT LINES OF LT_STYLEROW INTO TABLE LS_LIPS-CELLTAB.
        MODIFY LT_LIPS FROM LS_LIPS TRANSPORTING CELLTAB.
        CLEAR: LT_STYLEROW.
      ELSE.
        LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
        LS_STYLEROW-FIELDNAME = 'VBELN'.
        INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

        LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
        LS_STYLEROW-FIELDNAME = 'POSNR'.
        INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

        LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
        LS_STYLEROW-FIELDNAME = 'ERNAM'.
        INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

        LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
        LS_STYLEROW-FIELDNAME = 'MATNR'.
        INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

        LS_STYLEROW-STYLE = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
        LS_STYLEROW-FIELDNAME = 'WERKS'.
        INSERT LS_STYLEROW INTO TABLE LT_STYLEROW.

        CLEAR: LS_LIPS-CELLTAB.
        INSERT LINES OF LT_STYLEROW INTO TABLE LS_LIPS-CELLTAB.
        MODIFY LT_LIPS FROM LS_LIPS TRANSPORTING CELLTAB.
        CLEAR: LT_STYLEROW.
      ENDIF.
    ENDLOOP.

  ENDIF.

  CLEAR LT_ROW_NO.
  CLEAR LS_ROW_NO.

  IF O_GRID2->IS_READY_FOR_INPUT( ) EQ 0.
    CALL METHOD O_GRID2->SET_READY_FOR_INPUT
      EXPORTING
        I_READY_FOR_INPUT = 1.

  ELSE.
    CALL METHOD O_GRID2->SET_READY_FOR_INPUT
      EXPORTING
        I_READY_FOR_INPUT = 0.
  ENDIF.
  O_GRID2->REFRESH_TABLE_DISPLAY( ).

ENDFORM.
*&---------------------------------------------------------------------*
*&      Form  CREATE_ITEMS_DATA
*&---------------------------------------------------------------------
FORM CREATE_ITEMS_DATA .
   DATA: LS_NEW        TYPE T_ZDB_EDIT_ALV1,
        LT_STYLEROW   TYPE STANDARD TABLE OF LVC_S_STYL WITH DEFAULT KEY,
        LS_STYLEROW   TYPE LVC_S_STYL.

  CLEAR: LS_NEW, LT_STYLEROW.

  " Define editable fields

  LS_STYLEROW-FIELDNAME = 'VBELN'.
  LS_STYLEROW-STYLE     = CL_GUI_ALV_GRID=>MC_STYLE_ENABLED.
  APPEND LS_STYLEROW TO LT_STYLEROW.

  LS_STYLEROW-FIELDNAME = 'POSNR'.
  LS_STYLEROW-STYLE     = CL_GUI_ALV_GRID=>MC_STYLE_ENABLED.
  APPEND LS_STYLEROW TO LT_STYLEROW.

   LS_STYLEROW-FIELDNAME = 'ERNAM'.
  LS_STYLEROW-STYLE     = CL_GUI_ALV_GRID=>MC_STYLE_ENABLED.
  APPEND LS_STYLEROW TO LT_STYLEROW.

  LS_STYLEROW-FIELDNAME = 'MATNR'.
  LS_STYLEROW-STYLE     = CL_GUI_ALV_GRID=>MC_STYLE_ENABLED.
  APPEND LS_STYLEROW TO LT_STYLEROW.

  LS_STYLEROW-FIELDNAME = 'WERKS'.
  LS_STYLEROW-STYLE     = CL_GUI_ALV_GRID=>MC_STYLE_ENABLED.
  APPEND LS_STYLEROW TO LT_STYLEROW.

  " Assign celltab to new row
  LS_NEW-CELLTAB = LT_STYLEROW.

  " Insert new row at the beginning
  APPEND LS_NEW TO LT_LIPS.

  " Set grid to editable mode
  CALL METHOD O_GRID2->SET_READY_FOR_INPUT
    EXPORTING
      I_READY_FOR_INPUT = 1.

  " Refresh ALV to reflect changes
  CALL METHOD O_GRID2->REFRESH_TABLE_DISPLAY.

ENDFORM.

TYPES: BEGIN OF TY_ZDB_EDIT_ALV1_FLAT,
         VBELN TYPE ZDB_EDIT_ALV1-VBELN,
         POSNR TYPE ZDB_EDIT_ALV1-POSNR,
         ERNAM TYPE ZDB_EDIT_ALV1-ERNAM,
         MATNR TYPE ZDB_EDIT_ALV1-MATNR,
         WERKS TYPE ZDB_EDIT_ALV1-WERKS,
       END OF TY_ZDB_EDIT_ALV1_FLAT.

DATA: LS_DB_ALV1 TYPE TY_ZDB_EDIT_ALV1_FLAT.
*&---------------------------------------------------------------------*
*&      Form  SAVE_ITEMS_DATA
*&---------------------------------------------------------------------
FORM SAVE_ITEMS_DATA .
DATA: LS_DB_ALV1     TYPE TY_ZDB_EDIT_ALV1_FLAT,
      LS_DB_FULL     TYPE ZDB_EDIT_ALV1,
      LV_VBELN       TYPE ZDB_EDIT_ALV1-VBELN,
      LV_SKIPPED     TYPE I VALUE 0,
      LT_LIPS_CLEAN  TYPE TABLE OF T_ZDB_EDIT_ALV1,
      LS_LIPS_CLEAN  TYPE T_ZDB_EDIT_ALV1,
      LV_SAVED_ROWS  TYPE I VALUE 0,
      LV_HEADER_CHECK TYPE ZDB_EDIT_ALV-VBELN.

CALL METHOD O_GRID2->CHECK_CHANGED_DATA.

LOOP AT LT_LIPS INTO LS_LIPS.

  " Skip empty item rows
  IF LS_LIPS-VBELN IS INITIAL
  AND LS_LIPS-POSNR IS INITIAL
  AND LS_LIPS-ERNAM IS INITIAL
  AND LS_LIPS-MATNR IS INITIAL
  AND LS_LIPS-WERKS IS INITIAL.
    LV_SKIPPED = LV_SKIPPED + 1.
    CONTINUE.
  ENDIF.

  " # Check if header exists
  SELECT SINGLE VBELN
    INTO @LV_HEADER_CHECK
    FROM ZDB_EDIT_ALV
    WHERE VBELN = @LS_LIPS-VBELN AND ERNAM = @LS_LIPS-ERNAM.

  IF SY-SUBRC <> 0.
    LV_SKIPPED = LV_SKIPPED + 1.
    CONTINUE. " Don't allow saving item without header
  ENDIF.

  " Keep non-empty row
  LS_LIPS_CLEAN = LS_LIPS.
  APPEND LS_LIPS_CLEAN TO LT_LIPS_CLEAN.

  " Prepare flat structure
  CLEAR LS_DB_ALV1.
  MOVE-CORRESPONDING LS_LIPS TO LS_DB_ALV1.

  " Check if item record exists
  SELECT SINGLE VBELN
    INTO @LV_VBELN
    FROM ZDB_EDIT_ALV1
    WHERE VBELN = @LS_DB_ALV1-VBELN
      AND POSNR = @LS_DB_ALV1-POSNR
      AND ERNAM = @LS_DB_ALV1-ERNAM.

  IF SY-SUBRC = 0.
    " UPDATE
    UPDATE ZDB_EDIT_ALV1 SET
      MATNR = @LS_DB_ALV1-MATNR,
      WERKS = @LS_DB_ALV1-WERKS
    WHERE VBELN = @LS_DB_ALV1-VBELN
      AND POSNR = @LS_DB_ALV1-POSNR
      AND ERNAM = @LS_DB_ALV1-ERNAM.
  ELSE.
    " INSERT
    CLEAR LS_DB_FULL.
    MOVE-CORRESPONDING LS_DB_ALV1 TO LS_DB_FULL.
    INSERT ZDB_EDIT_ALV1 FROM LS_DB_FULL.
  ENDIF.

  LV_SAVED_ROWS = LV_SAVED_ROWS + 1.

ENDLOOP.

LT_LIPS = LT_LIPS_CLEAN.

COMMIT WORK.

" ✅ Final messaging
IF LV_SAVED_ROWS > 0.
  MESSAGE 'Item data saved successfully' TYPE 'S'.
ELSEIF LV_SKIPPED > 0.
  MESSAGE |{ LV_SKIPPED } item row(s) were skipped – empty or missing header.| TYPE 'I'.
ELSE.
  MESSAGE 'No item data saved.' TYPE 'I'.
ENDIF.



  " Make all fields non-editable after save
  PERFORM DISABLE_ALL_CELLS_IN_ITEMS.

  " Set ALV to non-edit mode
  CALL METHOD O_GRID2->SET_READY_FOR_INPUT
    EXPORTING I_READY_FOR_INPUT = 0.

  " Refresh ALV display
  CALL METHOD O_GRID2->REFRESH_TABLE_DISPLAY.

ENDFORM.

*&---------------------------------------------------------------------*
*&      Form  UPDATE_ITEMS_DATA
*&---------------------------------------------------------------------*
FORM UPDATE_ITEMS_DATA .

  DATA: LS_DB_ALV1  TYPE TY_ZDB_EDIT_ALV1_FLAT,
        LS_DB_FULL  TYPE ZDB_EDIT_ALV1,
        LV_VBELN    TYPE ZDB_EDIT_ALV1-VBELN.

" Ensure ALV changes are captured
  CALL METHOD O_GRID2->CHECK_CHANGED_DATA.

  LOOP AT LT_LIPS INTO LS_LIPS.

    " Map to flat structure (exclude CELLTAB)
    CLEAR LS_DB_ALV1.
    LS_DB_ALV1-VBELN = LS_LIPS-VBELN.
    LS_DB_ALV1-POSNR = LS_LIPS-POSNR.
    LS_DB_ALV1-ERNAM = LS_LIPS-ERNAM.
    LS_DB_ALV1-MATNR = LS_LIPS-MATNR.
    LS_DB_ALV1-WERKS = LS_LIPS-WERKS.

    " Check if record exists in DB
    SELECT SINGLE VBELN
      INTO @S_VBELN
      FROM ZDB_EDIT_ALV1
      WHERE VBELN = @LS_DB_ALV1-VBELN
        AND POSNR = @LS_DB_ALV1-POSNR AND ERNAM = @LS_DB_ALV1-ERNAM.

    IF SY-SUBRC = 0.
      " Record exists -> UPDATE
      UPDATE ZDB_EDIT_ALV1 SET
        MATNR = @LS_DB_ALV1-MATNR,
        WERKS = @LS_DB_ALV1-WERKS
        WHERE VBELN = @LS_DB_ALV1-VBELN
          AND POSNR = @LS_DB_ALV1-POSNR AND ERNAM = @LS_DB_ALV1-ERNAM.
    ELSE.
      " Record does not exist -> INSERT
      CLEAR LS_DB_FULL.
      MOVE-CORRESPONDING LS_DB_ALV1 TO LS_DB_FULL.
      INSERT ZDB_EDIT_ALV1 FROM LS_DB_FULL.
    ENDIF.

  ENDLOOP.

  COMMIT WORK.
  IF SY-SUBRC <> 0.
 MESSAGE 'Item data saved successfully' TYPE 'S'.
ELSE.
  MESSAGE 'Created new row but empty record not saved' type 'I'.
ENDIF.

  " ➕ Make all fields non-editable after save
  PERFORM DISABLE_ALL_CELLS_IN_ITEMS.

  " ➕ Set ALV to non-edit mode
  CALL METHOD O_GRID2->SET_READY_FOR_INPUT
    EXPORTING I_READY_FOR_INPUT = 0.

  " ➕ Refresh ALV display
  CALL METHOD O_GRID2->REFRESH_TABLE_DISPLAY.

ENDFORM.
*&---------------------------------------------------------------------*
*&      Form  DELETE_ITEMS_DATA
*&---------------------------------------------------------------------*
*       text
*----------------------------------------------------------------------*
*  -->  p1        text
*  <--  p2        text
*----------------------------------------------------------------------*
FORM DELETE_ITEMS_DATA .

  DATA: LT_ROWS TYPE LVC_T_ROW,
      LS_ROW  TYPE LVC_S_ROW,
      LV_IDX  TYPE SY-TABIX.

CALL METHOD O_GRID2->GET_SELECTED_ROWS
  IMPORTING ET_INDEX_ROWS = LT_ROWS.

LOOP AT LT_ROWS INTO LS_ROW.
  LV_IDX = LS_ROW-INDEX.
  READ TABLE LT_LIPS INDEX LV_IDX INTO LS_LIPS.
  IF SY-SUBRC = 0.
    " Corrected DELETE to use both VBELN and POSNR
    DELETE FROM ZDB_EDIT_ALV1 WHERE VBELN = LS_LIPS-VBELN AND POSNR = LS_LIPS-POSNR AND ERNAM = LS_LIPS-ERNAM.
    DELETE LT_LIPS INDEX LV_IDX.
  ENDIF.
ENDLOOP.

CALL METHOD O_GRID2->REFRESH_TABLE_DISPLAY.
COMMIT WORK.

MESSAGE 'Selected item(s) deleted' TYPE 'S'.

ENDFORM.
*&---------------------------------------------------------------------*
*&      Form  DISABLE_ALL_CELLS_IN_HEADER
*&---------------------------------------------------------------------*
FORM DISABLE_ALL_CELLS_IN_HEADER .

  DATA:  LT_STYLEROW   TYPE STANDARD TABLE OF LVC_S_STYL WITH DEFAULT KEY,
        LS_STYLEROW   TYPE LVC_S_STYL.

  LOOP AT LT_LIKP INTO LS_LIKP.

    CLEAR LT_STYLEROW.

    LS_STYLEROW-FIELDNAME = 'VBELN'.
  LS_STYLEROW-STYLE     = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
  APPEND LS_STYLEROW TO LT_STYLEROW.

  LS_STYLEROW-FIELDNAME = 'ERNAM'.
  LS_STYLEROW-STYLE     = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
  APPEND LS_STYLEROW TO LT_STYLEROW.

  LS_STYLEROW-FIELDNAME = 'ERDAT'.
  LS_STYLEROW-STYLE     = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
  APPEND LS_STYLEROW TO LT_STYLEROW.

  LS_STYLEROW-FIELDNAME = 'VSTEL'.
  LS_STYLEROW-STYLE     = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
  APPEND LS_STYLEROW TO LT_STYLEROW.

  LS_STYLEROW-FIELDNAME = 'VKORG'.
  LS_STYLEROW-STYLE     = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
  APPEND LS_STYLEROW TO LT_STYLEROW.

    " Apply to current row
    LS_LIKP-CELLTAB = LT_STYLEROW.
    MODIFY LT_LIKP FROM LS_LIKP TRANSPORTING CELLTAB.

    ENDLOOP.

ENDFORM.
*&---------------------------------------------------------------------*
*&      Form  DISABLE_ALL_CELLS_IN_ITEMS
*&---------------------------------------------------------------------*
FORM DISABLE_ALL_CELLS_IN_ITEMS .

  DATA:  LT_STYLEROW   TYPE STANDARD TABLE OF LVC_S_STYL WITH DEFAULT KEY,
        LS_STYLEROW   TYPE LVC_S_STYL.

  LOOP AT LT_LIPS INTO LS_LIPS.

    CLEAR LT_STYLEROW.

    LS_STYLEROW-FIELDNAME = 'VBELN'.
  LS_STYLEROW-STYLE     = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
  APPEND LS_STYLEROW TO LT_STYLEROW.

  LS_STYLEROW-FIELDNAME = 'POSNR'.
  LS_STYLEROW-STYLE     = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
  APPEND LS_STYLEROW TO LT_STYLEROW.


  LS_STYLEROW-FIELDNAME = 'ERNAM'.
  LS_STYLEROW-STYLE     = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
  APPEND LS_STYLEROW TO LT_STYLEROW.

  LS_STYLEROW-FIELDNAME = 'MATNR'.
  LS_STYLEROW-STYLE     = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
  APPEND LS_STYLEROW TO LT_STYLEROW.

  LS_STYLEROW-FIELDNAME = 'WERKS'.
  LS_STYLEROW-STYLE     = CL_GUI_ALV_GRID=>MC_STYLE_DISABLED.
  APPEND LS_STYLEROW TO LT_STYLEROW.


    " Apply to current row
    LS_LIKP-CELLTAB = LT_STYLEROW.
    MODIFY LT_LIPS FROM LS_LIPS TRANSPORTING CELLTAB.

    ENDLOOP.

ENDFORM.

Using Custom Logic in SAP S/4HANA Cloud to change field status of Purchase Requisition

2026-01-26T04:50:48.909000+01:00

Problem Background:

We received a customer request: when creating a purchase requisition, they want the Valuation Price field to be optional, but in the current system this field is mandatory.

Solution:

Attempt to meet the requirement through custom logic using a BAdI.

Analysis Steps:

1. After searching in SAP for Me, we found a KBA 3322867 - Valuation Price field is mandatory in Create Purchase Requisitions app - SAP for Me which provides a solution to this problem. So we can try to use BAdI MM_PUR_S4_PR_FLDCNTRL_SIMPLE to solve this problem.

2. We enter APP Custom Logic to create an implementation. The description of this BAdI is "Change of Field Control for Purchase Requisitions". In the documentation, we can get more information including supported fields. "PURCHASEREQUISITIONPRICE - Valuation Price" is included, that means our requirement can be fulfilled by this BAdI.

3. With this BAdI, we can set four status for supported fields of Purchase Requisition: Hidden, Read-only, Mandatory, Optional.

'-': To hide the field
'*': To make the field read-only
'+': To make the field mandatory
'.': To make the field optional

4. The sample code of this BAdI is quite readable and easy. Based on this problem, implement the BAdI. The specific code is as follows.

FIELD-SYMBOLS <fs> TYPE mmpur_s_pr_fldsel.

READ TABLE fieldselection_table ASSIGNING <fs> WITH KEY field = 'PURCHASEREQUISITIONPRICE'.
IF sy-subrc EQ 0.
    <fs>-fieldstatus = '.'.
ENDIF.

5. After testing, the BAdI works prefect. This BAdI not only supports GUI APP - Create Purchase Requisition - Advanced, but also supports Fiori APP - Manage Purchase Requisitions - Professional.

Conclusion:

You can also read more blogs about SAP S/4HANA Cloud procurement at the following link: SAP S/4HANA Cloud Public Edition Sourcing and Procurement - SAP Community

Dynamic RAP Actions Explained: Abstract Entities Powering Flexible Action Buttons

2026-02-04T08:58:36.978000+01:00

Introduction--

In the RESTful ABAP Programming Model (RAP), actions play a crucial role in triggering custom business logic on business objects — for example, approving, rejecting, or performing special updates on records.

Sometimes, these actions require user inputs, such as selecting a reason code, approval type, or custom parameter value before execution. To achieve this, RAP provides parameterized actions, and to enhance usability, we can use an abstract entity to define the parameter structure along with a dropdown (value help).

In this blog, we’ll explore how to build a parameterized RAP action that displays a dropdown list for user selection, powered by an abstract entity. This approach keeps the core logic clean, reusable, and consistent with RAP’s “clean core” principles.

Objective--

By the end of this blog, you’ll learn how to: -

Define an abstract entity to represent the action parameters

Provide a dropdown for the parameter field

Link the abstract entity to the RAP action definition

Implement the behavior logic to handle user input

Execute and test the action from the Fiori Elements UI

Business Scenario Overview--

You are designing a Purchase Order (PO) Management RAP application, consisting of a Header and Item structure.

The goal: -

To release purchase orders (POs) from Fiori using a parameterized action.

The action uses an abstract entity to capture runtime parameters (like release flag).

Database Tables--

Header Table: ZBRT_T_PO_HRD

This table stores high-level details of a purchase order.

@EndUserText.label : 'Purchase order header table' 
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE 
@AbapCatalog.tableCategory : #TRANSPARENT 
@AbapCatalog.deliveryClass : #A 
@AbapCatalog.dataMaintenance : #RESTRICTED 
define table zbrt_t_po_hrd { 

key mandt    : abap.clnt not null;
key ebeln    : ebeln not null;
bukrs        : abap.char(4);
supplier     : abap.char(10);
bsart        : abap.char(4);
lifnr        : abap.char(10);
land1        : abap.char(2);
country_desc : abap.char(40);
po_release   : abap.char(1); 
migo_status  : abap.char(40); 
email        : abap.char(60); 
lastdatetime : timestampl; 
}

Key points:--

EBELN is the primary key.

lastdatetime acts as the ETag for draft handling and concurrency control.

po_release indicates whether the PO has been released or not.

Item Table: ZBRT_T_PO_ITEM--

This stores item-level details linked to the header via a foreign key.

@EndUserText.label : 'Purchase order item table' 
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE 
@AbapCatalog.tableCategory : #TRANSPARENT 
@AbapCatalog.deliveryClass : #A 
@AbapCatalog.dataMaintenance : #RESTRICTED 
define table zbrt_t_po_item { 

key mandt       : abap.clnt not null; 
@AbapCatalog.foreignKey.screenCheck : false 
key ebeln       : ebeln not null 
with foreign key [1..*,1] zbrt_t_po_hrd 
where mandt = zbrt_t_po_item.mandt 
and ebeln = zbrt_t_po_item.ebeln; 
key ebelp       : abap.numc(5) not null; 
matnr           : abap.char(40); 
werks           : abap.char(4); 
lgort           : abap.char(4); 
@Semantics.quantity.unitOfMeasure : 'zbrt_t_po_item.meins' 
menge           : abap.quan(12,2); 
meins           : abap.unit(3); 
@Semantics.amount.currencyCode : 'zbrt_t_po_item.waers'
netpr           : abap.curr(15,2);
waers           : abap.cuky;
lastdatechanged : timestampl;
}

Key points:-

The association [1..*,1] means: Many items can belong to one header.

Semantic annotations help map units and currencies for UI display.

lastdatechanged helps track data changes per item.

Abstract Entity: ZBRT_POPUP-

Abstract entities are not physical tables; they are used for data transfer or parameter passing.

In this case, it’s used as a parameter popup entity during your action execution (e.g., PO release).

@EndUserText.label: 'PO RELEASE' 
@Metadata.allowExtensions: true 
define abstract entity zbrt_popup 
{ 
@UI.defaultValue: 'X' @EndUserText.label: 'po_release' 
po_release : abap.char( 1 );
}

Purpose:-

Used as a popup parameter for a RAP parameterized action.

When the user triggers the Release PO action in the Fiori UI, this abstract entity is displayed to capture additional inputs (like “Release Flag”).

It is decoupled from the database, acting only as a temporary input structure.

Interface View for Header: ZC_BRT_PO_HEAD--

This is the Root Entity of your RAP Business Object.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #NOT_REQUIRED 
@EndUserText.label: 'Projection view for header' 
@Metadata.ignorePropagatedAnnotations: true 
@ObjectModel.usageType:{
serviceQuality: #X, 
sizeCategory: #S,
dataClass: #MIXED 
} 
@Metadata.allowExtensions: true 
define root view entity zc_brt_po_head 
as select from zbrt_t_po_hrd 
composition [1..*] of zc_brt_po_item as _item 
{ 
key ebeln,
bukrs,
supplier, 
bsart,
lifnr,
land1,
country_desc,
po_release,
migo_status,
email, 
@Semantics.systemDateTime.localInstanceLastChangedAt: true 
lastdatetime,
cast('3' as abap.char(1)) as porelease,
cast('1' as abap.char(1)) as noporelease,  
_item
}

Key concepts:-

root view entity: Marks it as the root node of the RAP Business Object.

composition [1..*] of _item: Establishes a header–item relationship (1 header → many items).

@Semantics.systemDateTime.localInstanceLastChangedAt: Enables ETag-based draft and lock management.

cast('3' as abap.char(1)) as porelease: Defines a calculated field named porelease. This is a constant value ('3') cast to a character of length 1. It is typically used to represent a fixed feature control value (e.g., enabling a 'Release PO' button on the UI).

cast('1' as abap.char(1)) as noporelease: Defines another calculated field named noporelease with a constant value of '1'. Similar to above, this could be used for feature control (e.g., disabling a 'No Release' button).

Interface View for Item: ZC_BRT_PO_ITEM--

This is the child entity linked to the header.

@AbapCatalog.viewEnhancementCategory: [#NONE] 
@AccessControl.authorizationCheck: #NOT_REQUIRED 
@EndUserText.label: 'Projection view for item' 
@Metadata.ignorePropagatedAnnotations: true 
@ObjectModel.usageType:{ 
serviceQuality: #X, 
sizeCategory: #S,
dataClass: #MIXED 
} 
@Metadata.allowExtensions: true 
define view entity zc_brt_po_item
as select from zbrt_t_po_item
association to parent zc_brt_po_head as _head on $projection.ebeln = _head.ebeln
{
key ebeln,
key ebelp,
matnr,
werks,
lgort,
@Semantics.quantity.unitOfMeasure: 'Meins'
menge,
meins,
@Semantics.amount.currencyCode: 'Waers'
netpr,
waers, 
@Semantics.systemDateTime.localInstanceLastChangedAt: true
lastdatechanged,
_head
}

Explanation:-

This view represents the item-level node in your RAP BO.

_head is a public association to navigate back to the header.

The same ETag annotation (@Semantics.systemDateTime.localInstanceLastChangedAt) ensures concurrency management for items too.

Then design the behavior definition-

managed implementation in class zbp_c_brt_po_head unique; 
strict ( 2 ); 
with draft; 

define behavior for zc_brt_po_head //alias <alias_name> 
persistent table zbrt_t_po_hrd 
lock master 
total etag Lastdatetime 
draft table zbrt_t_h_dft 
authorization master ( instance ) 
etag master lastdatetime 
{
create ( precheck ) { default function GetDefaultsForCreate; } 
update ( precheck, features : instance ); 
delete ( precheck, features : instance ); 
field ( readonly ) bsart, Country_Desc; 
field ( mandatory ) bukrs; 
field ( readonly : create ) po_release;
 
association _item { create; with draft; }
 
mapping for zbrt_t_po_hrd 
{ 
bsart        = bsart; 
bukrs        = bukrs; 
country_desc = country_desc; 
ebeln        = ebeln; 
land1        = land1; 
lastdatetime = lastdatetime; 
lifnr        = lifnr; 
migo_status  = migo_status; 
porelease    = po_release; 
email        = email; 
} 
validation check_email on save { field Email; }
determination migo_status_update on modify { field porelease; } 
action ( features : instance ) POREL parameter zbrt_popup result [1] $self; 
action ( features : instance ) PONOREL result [1] $self;
static action Static_ALL result [1] $self;

draft action Activate optimized;
draft action Edit;
draft action Resume;
draft action Discard;
draft determine action Prepare; 
} 
define behavior for zc_brt_po_item //alias <alias_name>
persistent table zbrt_t_po_item
lock dependent by _head
draft table zbrt_t_i_ft
authorization dependent by _head
etag master Lastdatechanged
{
update;
delete;
field ( readonly ) ebeln, ebelp;
association _head; 
}

determination migo_status_update on modify { field porelease; }

Automatically updates MIGO status whenever the PO Release field changes.

action ( features : instance ) POREL parameter zbrt_popup result [1] $self; 
action ( features : instance ) PONOREL result [1] $self; 
static action Static_ALL result [1] $self;

POREL → Triggered to release a purchase order (with parameter popup).

PONOREL → Reverses release.

Static_ALL → Static action (not tied to any instance).

Metadata extension--

@Metadata.layer: #CORE 
@UI:{ 
    headerInfo:{ 
    title:{ value: 'Ebeln'}, 
    description:{value: 'Migo_Status' }, 
    typeName: 'Purchase Order Data', 
    typeNamePlural: 'Purchase Order Data' } 
} 
annotate view zc_brt_po_head with 
{ 
@UI.facet: 
[ 
{ position: 10, label: 'PO Header', type: #IDENTIFICATION_REFERENCE }, 
{ position: 20 , label: 'PO Item' , type: #LINEITEM_REFERENCE , targetElement: '_item' } 
] 
@UI.identification: [ { 
position: 10, label: 'PO Number' 
} , 
{ type: #FOR_ACTION_GROUP, label: 'PO Release Options', actionGroupId: '_ClickRelease' }, 
{ type: #FOR_ACTION, label: 'PO Release', dataAction: 'POREL', actionGroupId: '_ClickRelease' }, 
{ type: #FOR_ACTION, label: 'PO NotRelease', dataAction: 'PONOREL', actionGroupId: '_ClickRelease' } 
] 
@UI.lineItem: [ { 
position: 10, label: 'PO Number' 
} , 
{ type: #FOR_ACTION_GROUP, label: 'PO Release Options', actionGroupId: '_ClickRelease' }, 
{ type: #FOR_ACTION, label: 'PO Release', dataAction: 'POREL', actionGroupId: '_ClickRelease' }, 
{ type: #FOR_ACTION, label: 'PO NotRelease', dataAction: 'PONOREL', actionGroupId: '_ClickRelease' } , 

//This button we will use as static button 
{ type: #FOR_ACTION, label: 'Release All POs', dataAction: 'Static_ALL',actionGroupId: '_ClickRelease' } ] 
@UI.selectionField: [ { 
position: 10 
} ] 
@EndUserText.label: 'PO Number' 
ebeln; 
@UI.identification: [ { 
position: 20 , 
label: 'Company Code' 
} ] 
@UI.lineItem: [ { 
position: 20 , 
label: 'Company Code' 
} ] 
@UI.selectionField: [ { 
position: 20 
} ] 
@EndUserText.label: 'Company Code' 
bukrs; 
@EndUserText.label: 'Document Type' 
@UI.identification: [ {
position: 40 , 
label: 'Document Type' 
} ] 
@UI.lineItem: [ { 
position: 40 , 
label: 'Document Type' 
} ] 
@UI.selectionField: [ { 
position: 40 
} ]
bsart;
@EndUserText.label: 'Vendor' 
@UI.identification: [ { 
position: 50 , 
label: 'Vendor' 
} ] 
@UI.lineItem: [ { 
position: 50 , 
label: 'Vendor' 
} ] 
@UI.selectionField: [ { 
position: 50 
} ] 
lifnr; 
@EndUserText.label: 'Country' 
@UI.identification: [ { 
position: 60 , 
label: 'Country' 
} ] 
@UI.lineItem: [ { 
position: 60 , 
label: 'Country' 
} ] 
@UI.selectionField: [ { 
position: 60 
} ] 
land1; 
@EndUserText.label: 'Country Name' 
@UI.identification: [ { 
position: 70 , 
label: 'Country Name' 
} ] 
@UI.lineItem: [ { 
position: 70 , 
label: 'Country Name' 
} ] 
@UI.selectionField: [ { 
position: 70 
} ] 
country_desc; 
@EndUserText.label: 'PO Release' 
@UI.identification: [ { 
position: 80 , 
label: 'PO Release' 
} ] 
@UI.lineItem: [ { 
position: 80 , 
label: 'PO Release' 
} ] 
@UI.selectionField: [ { 
position: 80 
} ] 
po_release; 
@EndUserText.label: 'MIGO Status' 
@UI.identification: [ { 
position: 90 , 
label: 'MIGO Status' 
} ] 
@UI.lineItem: [ { 
position: 90 , 
label: 'MIGO Status' 
} ] 
@UI.selectionField: [ { 
position: 90 
} ] 
migo_status;
@EndUserText.label: 'Email ID' 
@UI.identification: [ { 
position: 100 , 
label: 'Email ID' 
} ] 
@UI.lineItem: [ { 
position: 100 , 
label: 'Email ID' 
} ] 
@UI.selectionField: [ { 
position: 100 
} ]
email; 
@UI.identification: [ { 
position: 110, label: 'Change Date Time' 
} ] 
@UI.lineItem: [ { 
position: 110, label: 'Change Date Time' 
} ] 
@UI.selectionField: [ { 
position: 110 
} ] 
@EndUserText.label: 'Change Date Time'
lastdatetime;
}

This is the Metadata Extension (UI annotations) for RAP Purchase Order application-- it defines how the fields and actions from our behavior definition (zc_brt_po_head) appear in the Fiori Elements app (List Report/Object Page).

.identification: [ { 

position: 10, label: 'PO Number' 
} , 
{ type: #FOR_ACTION_GROUP, label: 'PO Release Options', actionGroupId: '_ClickRelease' }, 
{ type: #FOR_ACTION, label: 'PO Release', dataAction: 'POREL', actionGroupId: '_ClickRelease' }, 
{ type: #FOR_ACTION, label: 'PO NotRelease', dataAction: 'PONOREL', actionGroupId: '_ClickRelease' } 
]

These create grouped action buttons and drop-down on both the List Report and Object Page:-

PO Release Options → Acts as a dropdown group.

Inside it:

PO Release → Triggers the POREL action (for releasing PO).

PO NotRelease → Triggers PONOREL action (for cancelling release).
Release All POs → Added later as a static action.

{ type: #FOR_ACTION, label: 'Release All POs', dataAction: 'Static_ALL', actionGroupId: '_ClickRelease' }

This button executes the Static Action (Static_ALL) — useful for mass operations like “Release All Purchase Orders” without selecting individual ones.

Then implement the logic in the behavior implementation class for validation, actions and determination--

CLASS lhc_zc_brt_po_head DEFINITION INHERITING FROM cl_abap_behavior_handler. 

PRIVATE SECTION. 

METHODS get_instance_features FOR INSTANCE FEATURES 
IMPORTING keys REQUEST requested_features FOR zc_brt_po_head RESULT result. 

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

METHODS precheck_create FOR PRECHECK 
IMPORTING entities FOR CREATE zc_brt_po_head. 

METHODS precheck_update FOR PRECHECK 
IMPORTING entities FOR UPDATE zc_brt_po_head. 

METHODS precheck_delete FOR PRECHECK 
IMPORTING keys FOR DELETE zc_brt_po_head. 

METHODS GetDefaultsForCreate FOR READ 
IMPORTING keys FOR FUNCTION zc_brt_po_head~GetDefaultsForCreate RESULT result. 

METHODS ponorel FOR MODIFY 
IMPORTING keys FOR ACTION zc_brt_po_head~ponorel RESULT result. 

METHODS porel FOR MODIFY 
IMPORTING keys FOR ACTION zc_brt_po_head~porel RESULT result.
 
METHODS Static_ALL FOR MODIFY 
IMPORTING keys FOR ACTION zc_brt_po_head~Static_ALL RESULT result. 

METHODS migo_status_update FOR DETERMINE ON MODIFY 
IMPORTING keys FOR zc_brt_po_head~migo_status_update. 

METHODS check_email FOR VALIDATE ON SAVE 
IMPORTING keys FOR zc_brt_po_head~check_email. 

ENDCLASS. 

CLASS lhc_zc_brt_po_head IMPLEMENTATION. 
 
METHOD get_instance_features. 
ENDMETHOD. 

METHOD get_instance_authorizations. 
ENDMETHOD. 

METHOD precheck_create. 

 LOOP AT entities INTO DATA(ls_enity). 

  IF ls_enity-bukrs EQ '6000'. 
    APPEND VALUE #( ebeln = ls_enity-ebeln ) TO failed-zc_brt_po_head. 
    APPEND VALUE #( 
                  ebeln = ls_enity-ebeln 
                  %msg = new_message_with_text(
                  severity = if_abap_behv_message=>severity-error
                  text = 'Please enter correct Company Code' && ls_enity- bukrs ) )
   TO reported-zc_brt_po_head. 

ENDIF. 
ENDLOOP. 

ENDMETHOD. 

METHOD precheck_update. 

LOOP AT entities INTO DATA(ls_enity). 

  IF ls_enity-bukrs EQ '6000'. 
   APPEND VALUE #( ebeln = ls_enity-ebeln ) TO failed-zc_brt_po_head. 
   APPEND VALUE #( 
                ebeln = ls_enity-ebeln 
                %msg = new_message_with_text( 
                severity = if_abap_behv_message=>severity-error 
                text = 'Please enter correct Company Code' && ls_enity-Bukrs )
) TO reported-zc_brt_po_head. 

ENDIF. 
ENDLOOP. 

ENDMETHOD. 

METHOD precheck_delete. 

   READ ENTITY IN LOCAL MODE zc_brt_po_head 
   ALL FIELDS WITH VALUE #( FOR ls_key IN keys 
                          ( ebeln = ls_key-ebeln ) ) 
RESULT DATA(lt_prechk_delete). 

LOOP AT lt_prechk_delete INTO DATA(ls_enity). 

  IF ls_enity-porelease EQ abap_true. 
    APPEND VALUE #( ebeln = ls_enity-ebeln ) TO failed-zc_brt_po_head. 
    APPEND VALUE #( 
               ebeln = ls_enity-ebeln 
               %msg = new_message_with_text( 
               severity = if_abap_behv_message=>severity-error 
               text = 'You can not delete this line Item as PO release is X'
) 
) TO reported-zc_brt_po_head. 

ENDIF. 
ENDLOOP. 

ENDMETHOD. 

METHOD GetDefaultsForCreate. 
  APPEND VALUE #( %cid = keys[ 1 ]-%cid %param-bsart = 'ZNB' ) TO result. 
ENDMETHOD. 

METHOD ponorel. 
 
   READ ENTITY IN LOCAL MODE zc_brt_po_head 
   ALL FIELDS WITH VALUE #( FOR ls_key IN keys 
                          ( ebeln = ls_key-ebeln ) ) 
   RESULT DATA(lt_po_action). 

LOOP AT lt_po_action ASSIGNING FIELD-SYMBOL(<fs_po_action>). 

   MODIFY ENTITY IN LOCAL MODE zc_brt_po_head 
   UPDATE FIELDS ( porelease ) 
   WITH VALUE #( ( ebeln = <fs_po_action>-ebeln 
                   porelease = abap_false ) )  
   REPORTED reported 
   FAILED failed. 

   READ ENTITY IN LOCAL MODE zc_brt_po_head 
   ALL FIELDS WITH VALUE #( ( ebeln = <fs_po_action>-ebeln ) ) 
   RESULT DATA(lt_result). 
   result = VALUE #( FOR ls_result IN lt_result 
                   ( ebeln           = ls_result-ebeln 
                    %param-ebeln     = ls_result-ebeln 
                    %param-porelease = ls_result-porelease ) ). 
ENDLOOP. 

ENDMETHOD. 

METHOD porel. 

LOOP AT keys ASSIGNING FIELD-SYMBOL(<fs_po_action>). 

   DATA(lv_popup_value) = <fs_po_action>-%param-po_release. 
   MODIFY ENTITY IN LOCAL MODE zc_brt_po_head 
   UPDATE FIELDS ( po_release ) 
   WITH VALUE #( ( Ebeln = <fs_po_action>-Ebeln 
                   po_release = lv_popup_value ) ) 
   REPORTED reported FAILED failed.

   READ ENTITY IN LOCAL MODE zc_brt_po_head 
   ALL FIELDS WITH VALUE #( ( Ebeln = <fs_po_action>-Ebeln ) ) 
   RESULT DATA(lt_result). 
   
   result = VALUE #( FOR ls_result IN lt_result 
                   ( ebeln = ls_result-Ebeln 
                     %param-ebeln = ls_result-ebeln 
                     %param-po_release = ls_result-po_release ) ). 

ENDLOOP. 

ENDMETHOD. 

METHOD Static_ALL. 

   SELECT FROM zbrt_t_po_hrd 
          FIELDS ebeln , po_release 
          WHERE po_release = _false 
   INTO TABLE(lt_static_act). 

LOOP AT lt_static_act INTO DATA(ls_static_action). 

   MODIFY ENTITY IN LOCAL MODE zc_brt_po_head 
   UPDATE FIELDS ( porelease ) 
   WITH VALUE #( ( ebeln = ls_static_action-ebeln 
                   porelease = abap_true ) ) .
 
   READ ENTITY IN LOCAL MODE zc_brt_po_head 
   ALL FIELDS WITH VALUE #( ( ebeln = ls_static_action-ebeln ) ) 
   RESULT DATA(lt_result). 
   result = VALUE #( FOR ls_result IN lt_result 
                   ( %param-ebeln = ls_result-ebeln 
                     %param-porelease = ls_result-porelease ) ).
ENDLOOP. 

   INSERT VALUE #( 
                 %msg = new_message_with_text( 
                  severity = if_abap_behv_message=>severity-success 
                  text = |{ lines( lt_static_act ) } Records has been  upadted | ) ) 
   INTO TABLE reported-zc_brt_po_head. 

ENDMETHOD. 

METHOD migo_status_update. 

   READ ENTITY IN LOCAL MODE zc_brt_po_head 
   ALL FIELDS WITH VALUE #( FOR ls_key IN keys 
                          ( ebeln = ls_key-ebeln ) ) 
   RESULT DATA(lt_migo_status). 

LOOP AT lt_migo_status ASSIGNING FIELD-SYMBOL(<fs_migo>). 

  IF <fs_migo>-porelease EQ abap_true. 
     MODIFY ENTITY IN LOCAL MODE zc_brt_po_head 
     UPDATE FIELDS ( migo_status )
     WITH VALUE #( ( ebeln = <fs_migo>-ebeln 
                     migo_status = 'GR has done' ) ). 

  ELSEIF <fs_migo>-porelease EQ abap_false. 
     MODIFY ENTITY IN LOCAL MODE zc_brt_po_head 
     UPDATE FIELDS ( migo_status ) 
     WITH VALUE #( ( ebeln = <fs_migo>-ebeln 
                     migo_status = 'Open' ) ). 
ENDIF. 
ENDLOOP. 
ENDMETHOD. 

METHOD check_email. 

DATA: lr_reg TYPE REF TO cl_abap_regex. 
DATA: lr_matcher TYPE REF TO cl_abap_matcher, 
      lv_email TYPE string. 

   CREATE OBJECT lr_reg
      EXPORTING 
        pattern = '\w+(\.\w+)*@(\w+\.)+(\w{2,4})' 
        ignore_case = abap_true.

   READ ENTITY IN LOCAL MODE zc_brt_po_head 
   ALL FIELDS WITH VALUE #( FOR ls_key IN keys 
                          ( Ebeln = ls_key-Ebeln ) ) 
   RESULT DATA(lt_validation). 

LOOP AT lt_validation INTO DATA(ls_validation). 
   DATA(lv_po_count) = strlen( ls_validation-Email ). 
   IF lv_po_count LT 10. 
     APPEND VALUE #( Ebeln = ls_validation-Ebeln ) TO failed-zc_brt_po_head. 
     APPEND VALUE #( Ebeln = ls_validation-Ebeln 
                     %msg = new_message_with_text( 
                     severity = if_abap_behv_message=>severity-error 
                     text = 'Pls enter correct length for Email' && ls_validation-Email ) ) 
     TO reported-zc_brt_po_head. 

ENDIF. 

   lr_matcher = lr_reg->create_matcher( text = ls_validation-Email ).
   IF lr_matcher->match( ) IS INITIAL.
     APPEND VALUE #( Ebeln = ls_validation-Ebeln ) TO failed-zc_brt_po_head. 
     APPEND VALUE #( Ebeln = ls_validation-Ebeln 
                     %msg = new_message_with_text( 
                     severity = if_abap_behv_message=>severity-error 
                     text = 'Pls enter correct format for Email Id' && ls_validation-Email ) ) 
     TO reported-zc_brt_po_head.
 
ENDIF. 
ENDLOOP. 
ENDMETHOD.

ENDCLASS.

METHOD ponorel. 
 
  READ ENTITY IN LOCAL MODE zc_brt_po_head 
  ALL FIELDS WITH VALUE #( FOR ls_key IN keys 
  ( ebeln = ls_key-ebeln ) ) RESULT DATA(lt_po_action). 

LOOP AT lt_po_action ASSIGNING FIELD-SYMBOL(<fs_po_action>). 

   MODIFY ENTITY IN LOCAL MODE zc_brt_po_head 
   UPDATE FIELDS ( porelease ) 
   WITH VALUE #( ( ebeln = <fs_po_action>-ebeln 
   porelease = abap_false 
   ) 
)  REPORTED reported 
   FAILED failed. 
   READ ENTITY IN LOCAL MODE zc_brt_po_head 
   ALL FIELDS WITH VALUE #( ( ebeln = <fs_po_action>-ebeln ) ) 
   RESULT DATA(lt_result). 
   result = VALUE #( FOR ls_result IN lt_result 
    ( 
    ebeln            = ls_result-ebeln 
    %param-ebeln     = ls_result-ebeln 
    %param-porelease = ls_result-porelease 
  )
).
ENDLOOP. 

ENDMETHOD.

Purpose of the Method--

ponorel is triggered when a user clicks the “PO Not Release” button in Fiori.
Its job is to:

Read the selected PO(s) from the frontend.
Update their porelease field to false.
Return the updated PO information back to the frontend so the UI reflects the change.

Step	Purpose
Read entity from local mode	Fetch selected POs from draft/local buffer
Loop through POs	Process each PO individually
Modify entity	Set porelease = false (Not Released)
Read back updated record	Get latest values for UI
Assign to result	Send updated record(s) back to Fiori

METHOD porel. 

LOOP AT keys ASSIGNING FIELD-SYMBOL(<fs_po_action>). 

   DATA(lv_popup_value) = <fs_po_action>-%param-po_release. 
   MODIFY ENTITY IN LOCAL MODE zc_brt_po_head UPDATE FIELDS ( po_release ) 
   WITH VALUE #( 
       ( Ebeln = <fs_po_action>-Ebeln po_release = lv_popup_value ) 
  ) 
         REPORTED reported FAILED failed.

   READ ENTITY IN LOCAL MODE zc_brt_po_head 
   ALL FIELDS WITH VALUE #( ( Ebeln = <fs_po_action>-Ebeln ) ) 
   RESULT DATA(lt_result). 

   result = VALUE #( FOR ls_result IN lt_result 
                   ( ebeln = ls_result-Ebeln 
                    %param-ebeln = ls_result-ebeln 
                    %param-po_release = ls_result-po_release ) ). 
ENDLOOP. 

ENDMETHOD.

Purpose of the Method--

porel is triggered when a user clicks the “PO Release” button in Fiori.
Its job is to:

Read the selected POs from the frontend.
Update their po_release field based on the value passed from the frontend (%param-po_release).
Return the updated PO(s) back to the frontend so the UI reflects the change.

Feature	ponorel	porel
po_release update	Always sets to false	Sets dynamically from frontend %param-po_release
Use case	“PO Not Release” button	“PO Release” button or popup
Logic	Hard-coded	Dynamic based on action parameter

METHOD Static_ALL. 

   SELECT FROM zbrt_t_po_hrd 
          FIELDS ebeln , po_release 
          WHERE po_release = _false 
   INTO TABLE (lt_static_act). 

LOOP AT lt_static_act INTO DATA(ls_static_action). 

   MODIFY ENTITY IN LOCAL MODE zc_brt_po_head 
   UPDATE FIELDS ( porelease ) 
   WITH VALUE #( 
                ( ebeln = ls_static_action-ebeln 
                  porelease = abap_true )
 ) . 
   READ ENTITY IN LOCAL MODE zc_brt_po_head 
   ALL FIELDS WITH VALUE #( ( ebeln = ls_static_action-ebeln ) ) 
   RESULT DATA(lt_result). 

   result = VALUE #( FOR ls_result IN lt_result 
                   ( 
                    %param-ebeln = ls_result-ebeln 
                    %param-porelease = ls_result-porelease 
                   )
).
ENDLOOP. 

   INSERT VALUE #( 
               %msg = new_message_with_text( 
               severity = if_abap_behv_message=>severity-success 
               text = |{ lines( lt_static_act ) } Records has been upadted | 
                ) 
) INTO TABLE reported-zc_brt_po_head. 

ENDMETHOD.

Purpose of Static_ALL--

This method is typically triggered by a “Release All POs” button in Fiori.

It automatically sets all POs with porelease = false to true.

Provides a success message for the user showing how many POs were updated.

Step	Action
1	Select all unreleased POs from DB
2	Loop through them
3	Set porelease = true in local/draft mode
4	Read the updated record
5	Return updated data to frontend
6	Insert a success message in reported-zc_brt_po_head

METHOD migo_status_update. 

   READ ENTITY IN LOCAL MODE zc_brt_po_head 
   ALL FIELDS WITH VALUE #
                    ( FOR ls_key IN keys 
                    ( ebeln = ls_key-ebeln ) ) 
                      RESULT DATA(lt_migo_status). 

LOOP AT lt_migo_status ASSIGNING FIELD-SYMBOL(<fs_migo>). 

   IF <fs_migo>-porelease EQ abap_true. 
      MODIFY ENTITY IN LOCAL MODE zc_brt_po_head 
      UPDATE FIELDS ( migo_status )
      WITH VALUE #( ( ebeln = <fs_migo>-ebeln 
      migo_status = 'GR has done') ).

   ELSEIF <fs_migo>-porelease EQ abap_false. 
      MODIFY ENTITY IN LOCAL MODE zc_brt_po_head 
      UPDATE FIELDS ( migo_status ) 
      WITH VALUE #( ( ebeln = <fs_migo>-ebeln 
      migo_status = 'Open' ) ). 

ENDIF. 
ENDLOOP. 
ENDMETHOD.

Purpose--

Whenever the field porelease is modified (via POREL, PONOREL, or Static_ALL), this determination triggers.

Updates migo_status dynamically:

'GR has done' → if the PO is released (porelease = abap_true).

'Open' → if the PO is not released (porelease = abap_false).

Concept	Explanation
Determination	Runs automatically when a field changes (porelease) in RAP.
Local Mode	Updates the draft version, ensuring changes are visible in the UI before committing.
Dynamic Update	migo_status is computed automatically based on porelease.
No result table	The UI will automatically get updated via RAP binding; no explicit result table needed.

Create the service definition and service binding--

Let's preview our application in Fiori--

Above can see the PO Release status and MIGO Status is done.

Let's create a record and see the pop-up.

Above can the action button with drop down.

Let’s check the actions button, how PO release and MIGO status are changing.

Select one record-->click on action drop-down-->click on PO Not Release.

Now can see automatically MIGO status changed based on PO Release.

Conclusion--

In this blog, we explored how to implement parameterized actions in RAP using abstract entities and a dropdown-based parameter selection, enabling flexible and user-driven behavior in Fiori applications.

We demonstrated how multiple actions -- such as POREL, PONOREL, and STATIC_ALL — can be designed to handle different business scenarios like Purchase Order release, mass update, and status refresh dynamically. Furthermore, with the MIGO_STATUS_UPDATE determination, we ensured real-time consistency between release and goods receipt statuses, illustrating the power of behavior-driven logic in the RAP framework.

Thanks-------

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

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

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

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

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

We will cover the below points:

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

1 Architecture Overview

Solution Architecture

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

2 Prerequisites

You must have:

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

3 Creating a Task Chain in SAP Datasphere

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

In the given example:

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

SAP Datasphere Task Chain with Replication Flow inside

Main takeaways:

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

4 Configuring OAuth Client in SAP Datasphere

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

Navigation Path

Datasphere → Administration → App Integration → OAuth Clients

OAuth Endpoints Provided

Amongst others, SAP Datasphere automatically exposes:

Authorization URL
Token URL

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

Configured OAuth Client (based on Technical User)

Menu Path Datasphere

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

OAuth Client Generation

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

OAuth Client Details

Important settings:

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

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

5 Creating Communication Artifacts in ABAP Cloud

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

First create an Outbound Service of type HTTP:

Create Outbound Service

Create a Communication Scenario with Authentication Methods = OAuth 2.0 only, bind it to your outbound service and publish it:

Communication Scenario Creation

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

ABAP Cloud Web Access

ABAP Cloud Communication Systems

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

ABAP Cloud Communication Systems Details

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

ABAP Cloud Communication Systems Users

Key fields:

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

6 Creating a Communication Arrangement in SAP ABAP Cloud

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

Navigation: Communication Management → Communication Arrangements

Arrangement Example: ZDSP_CS_REST

ABAP Cloud Communication Arrangements

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

ABAP Cloud Communication Arrangements Detailed Configuration

What this provides:

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

7 Calling the Datasphere Task Chain API from ABAP Cloud

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

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

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

ABAP Cloud Implementation Pattern

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

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

The code snippet performs the following parts in more detail:

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

triggers a new run
receives a JSON response containing a LogId

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

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

Print everything in the ABAP Console.

ABAP-Code Snippet:

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

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

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

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

  ENDMETHOD.

  METHOD call_dsp.

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

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

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

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

    DATA(arrangement) = arrangements[ 1 ].

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

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

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

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

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

    WAIT UP TO 10 SECONDS.

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

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

  ENDMETHOD.
ENDCLASS.

Once triggered:

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

Follow-up calls can fetch:

Execution status
Logs
Completion result

8 Execution Results

ABAP Cloud Console Log: Results

The Task Chain in Datasphere is in Running status:

SAP Datasphere Task Chain Running Status

9 Conclusion/Outlook & Further aspects:

Overview of the major building blocks:

Capability	Result
Secure Auth	OAuth 2.0 Client Credentials
No hardcoded secrets	via Communication Arrangements/System
Remote orchestration	Creating an end-to-end orchestrated chain of tasks
Cloud-native ABAP	Using appropriate ABAP Class APIs
Datasphere automation	Using Task Chain API

Use Cases that the implementation enables:

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

References

SAP Datasphere Task Chain API Documentation: https://api.sap.com/api/DatasphereTasks/overview
SAP Datasphere Task Chain Help Page: https://help.sap.com/docs/SAP_DATASPHERE/c8a54ee704e94e15926551293243fd1d/274f2736465c4c48a091c675880502a2.html?locale=en-US
ABAP Cloud - how to call external APIs: https://jacekw.dev/blog/2022/oauth-client-credentials-from-abap-cloud/

These are your main takeaways to further sharpen the solution:

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

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

Unlock S/4HANA Cloud Secrets: Hybrid Events+APIs Strategy for Seamless BTP Data Flows

2026-02-12T01:30:35.487000+01:00

Strategic Financial Data Extraction from SAP S/4HANA Cloud Public Edition to SAP BTP

Using Transfer Pricing as a Real-World Example

Transfer pricing represents a perfect use case to demonstrate generic financial data extraction strategies from SAP S/4HANA Cloud Public Edition. Multinational organisations need GL, Controlling, Material Ledger, and Asset Accounting postings to flow reliably to external engines hosted on SAP BTP—but Public Cloud’s “no direct database access” constraint demands architecturally sound patterns.

Why Transfer Pricing Perfectly Illustrates the Challenge

The business need: Calculate inter-company markups (cost-plus, resale-minus) using real-time ACDOCA postings across multiple currencies, profit centres, and cost elements.
The constraint: Pure cloud extensibility—no RFCs, no custom ABAP, no direct table extracts.
The solution: Three proven patterns that work for any financial data integration scenario.

Pattern 1: Event Notifications (Real-Time Push Model)

How transfer pricing uses it: GL postings trigger automatic business event notifications routed through SAP Event Mesh to BTP applications.

Event Notification

Generic applicability: Works for any posting-driven process—revenue recognition, inter-company reconciliation, compliance monitoring.

High-level activation:

Integration configuration apps → Activate accounting-related event notifications
Communication scenarios → Configure outbound event destinations
Event Mesh subscription → Point to BTP service endpoint
Payload contains: Company codes, ledger amounts (local/group), profit centres, material valuations

Pattern 2: Standard Query Services (Scheduled Pull Model)

How transfer pricing uses it: BTP service queries S/4HANA nightly for new/changed financial postings.

Query ServiceKey services (release-dependent availability):

Financial line item services → GL/CO/ML/AA postings
Profitability services → Margin analysis data
Material valuation services → Cost component details

Generic applicability: Perfect for scheduled reconciliation, historical backfills, or validation runs.

Pattern 3: Hybrid Extraction (Production Resilience)

Transfer pricing demands 99.9% coverage. Smart architects layer all three patterns:

Use Case	Primary Pattern	Transfer Pricing Example	Generic Use
Real-time GL postings	Event notifications	Invoice → immediate markup	Any posting trigger
Historical catch-up	Standard APIs	Month-end reconciliation	Data migration
Day 1 implementation	Bulk extraction	Full ACDOCA baseline	Initial loads
Custom calculations	BTP processing	Exception overrides	Business rules

Three-tier reference flow:

Hybrid ExtractionBTP Implementation Patterns (Transfer Pricing Example)

Cloud Application Programming Model (CAP)

service FinancialIntegration {
  entity Postings as projection on external financial services;
  entity PricingResults as projection on HANA staging;
}

Pattern: Event handlers + scheduled queries → unified HANA staging → business rules.

ABAP RESTful Application Programming (RAP)

define root view entity FinancialDataView
  as select from standard financial services

Pattern: Analytical CDS views over external data → transactional services.

Architect’s Production Checklist

✅ Tenant validation: Test events/APIs in your specific S/4HANA Cloud environment
✅ Quota management: Monitor Event Mesh throughput + API rate limits
✅ Fallback design: API polling validates event stream completeness
✅ Quarterly readiness: SAP evolves event coverage and API fields continuously
✅ Pure cloud: Zero custom code in production S/4HANA

The Universal Pattern

Transfer pricing proves the strategy works for complex financial scenarios. The same architecture applies to:

Inter-company reconciliation
Revenue recognition automation
Compliance reporting engines
Analytics data pipelines
Any standard data object/model driven process

Universal PatternKey takeaway: This isn’t “just for transfer pricing”—it’s your reusable blueprint for any S/4HANA Cloud → BTP data integration.

Recurring Entry Approval Workflow in SAP S/4HANA - FBD1/FBD2/FBD9 Transactions

2026-02-24T08:51:32.650000+01:00

Introduction:

In many organizations, finance teams handle repetitive postings such as rent, subscriptions, insurance, lease payments, and service charges. Manually posting these entries every period increases operational effort and the risk of errors.

SAP provides the Recurring Entry Program (Transaction FBD1) to automate such postings. However, in controlled environments, organizations often require approval workflows before recurring documents are posted.

This blog explains how to implement and control a Recurring Entry Workflow using FBD1, ensuring automation with proper financial governance.

Requirement:

In SAP Standard, through FBD1 users can create recurring document templates. But these templates cannot be posted automatically. The created recurring document templates must be posted via F.14 transaction. It happens periodically through Job Scheduling.

FBD1 does not include any approval mechanism by standard. This leads to

Unauthorized financial commitments.
Incorrect Recurring Postings.
Audit, Compliance & Seggregation of Duties (SoD) violations.

To mitigate these risks, business requires an approval mechanism, so that

Authorized user only creates Recurring Document Templates (FBD1).
Delegation of Authority (DoA) ensures proper screening before approval.
Approved entries alone will be considered for Posting Runs.

Solution Architecture:

The proposed solution will work on triggering an approval workflow when the user creates a Recurring Document Entry through FBD1 and when he modifies the rejected Recurring Document Entry through FBD2. Modifications of the Recurring Document Template when it is in Approval is prevented through Custom Control Error Mechanism.

Process Flow:

Development Process:

Step – 1: Create a Recurring Document Entry Template in FBD1 T-Code. The Entry must be blocked, so that only upon complete approval of workflow block shall be removed and would process for posting.

For this purpose, we must enhance the standard procedure through Business Transaction Events. To identify the suitable BTE’s that can be used for our purpose, we can use SE37 transaction with the FM “PC_FUNCTION_FIND”. Keep a Session Breakpoint in the FM and run the process. The Parameter “I_EVENT” will provide the BTE numbers from which we can choose the suitable one for our purpose.

NOTE: For Blocking the Document while creation, through the above-mentioned process we came to the BTE as “SAMPLE_INTERFACE_00001025”.

Step – 2: Take a copy of the FM “SAMPLE_INTERFACE_00001025” in SE37. I have kept the name as “ZFI_BKDF_DOC_BLOCK_FM”.

Copy and paste the below code inside the FM.

DATA:
     lv_memory_bkdf TYPE char30 VALUE '(SAPMF05A)BKDF',
     lv_memory_bkdf1 TYPE char30 VALUE '(SAPMF05L)BKDF',
     wa_bkpf TYPE bkpf.
FIELD-SYMBOLS: <lfs_bkdf> TYPE bkdf.
READ TABLE t_bkpf into wa_bkpf index 1.
    If sy-tcode = 'FBD1' or sy-tcode = 'FBD9'.
      ASSIGN (lv_memory_bkdf) TO <lfs_bkdf>.
    elseif sy-tcode = 'FBD2'.
      ASSIGN (lv_memory_bkdf1) TO <lfs_bkdf>.
    endif.
   IF <lfs_bkdf> IS ASSIGNED AND t_bkpf-bukrs EQ '9000'.
    <lfs_bkdf>-blocked_for_posting = abap_true.
    <lfs_bkdf>-XDELT = abap_true.
  ENDIF.

NOTE:

Here “BLOCKED_FOR_POSTING” & “XDELT (Deletion_Indicator) are the fields for which value has been to “X” for blocking the document.
The runtime values of these fields are fetched from previous procedures through Memory Assignment.

For FBD1 & FBD2, the standard procedural program varies (See Data Declaration).

Step – 3: Once the Recurring Entry Document is blocked and saved, our custom workflow must get triggered. Before proceeding to Workflow, we must create a custom class where the Event, Methods necessary for the workflow operation would reside.

Go to the T-code SE24 and create a custom class. I had created in the name “ZCL_FI_RECURRING_WF”. In the Interfaces tab, provide the interfaces as shown in the below image. These interfaces are necessary for Object instantiation & Workflow Operations.
In the Events Tab, I have given the event name as “CREATED” as shown below.
The event parameter is “ZST_WF_REC_JOUR”. It is a custom table type referring a custom structure " ZFI_ST_RECJOUR_ENTRY”.

Structure:
In the Attributes tab, Object Key is specified as “LV_OBJKEY” as shown below.
The standard methods corresponding to the added interfaces, would reflect in the Methods tab as shown below.
Now we can add our custom methods. The following are the methods that I created for my requirement as shown below.
M_FETCH_APPROVER – Fetching Approvers and Sending Approval Notifications.
M_UNBLOCK_POSTING – Unblocking the Recurring Entry Document after Complete Approval.
M_COMPLETE_MAIL – Notification Mail to Initiator after Complete Approval / Rejection in any level.
The individual method procedures and its parameters are below.
M_FETCH_APPROVER:
Parameters:

Here, “ZTT_FI_WF_AGENT” table type is a single field for storing the agents (Image represents structure of the Table Type).
“ZFI_RECUR_MAT_APP_TT” table type is for storing agent information (Image represents structure of the Table Type).

DATA:
  gc_subject     TYPE so_obj_des, " Email subject
  gc_email_to    TYPE adr6-smtp_addr, " Valid email
  gs_text        TYPE soli, " Text used into the email body
  gc_type_raw    TYPE so_obj_tp, " Email type
  gc_att_type    TYPE soodk-objtp, " Attachment type
  gc_att_subject TYPE sood-objdes. " Attachment title

  DATA:
  gt_text           TYPE soli_tab, " Table which contains email body text
  gt_attachment_hex TYPE solix_tab, " Table which contains the attached file
  gv_sent_to_all    TYPE os_boolean, " Receive the information if email was sent
  gv_error_message  TYPE string, " Used to get the error message
  go_send_request   TYPE REF TO cl_bcs, " Email object
  go_recipient      TYPE REF TO if_recipient_bcs, " Who will receive the email
  go_sender         TYPE REF TO cl_sapuser_bcs, " Who is sending the email
  go_document       TYPE REF TO cl_document_bcs, " Email body
  gx_bcs_exception  TYPE REF TO cx_bcs,
  wa_agents type ZST_FI_APPWF_AGENT.
  wa_rec_wf_sts type ZFI_REC_WF_ST_DT.

    lv_initiator = lv_initiator_us+2(12).
    lv_counter = lv_counter + 1.

     CALL METHOD zcl_amdp_fi_recurring_wf=>get_initial_approvers
      EXPORTING
        p_mandt      = sy-mandt
        p_compcode   = lv_comp_code
        p_init       = lv_initiator
      IMPORTING
        it_approvers = data(it_approvers).

    sort it_approvers by zlevel .
    delete ADJACENT DUPLICATES FROM it_approvers comparing zlevel.
    DESCRIBE TABLE it_approvers LINES lv_counter_max.
    read table it_approvers into data(wa_approver) index 1.
    if sy-subrc = 0.
      lv_init_name = wa_approver-name_text1.
      lv_init_mid = wa_approver-smtp_addr1.
    endif.
    read table it_approvers into wa_approver with key zlevel = lv_counter.
    if sy-subrc = 0.
      concatenate 'US' wa_approver-zuser into wa_agents-agent.
      lv_appr_mid = wa_approver-smtp_addr.
      lv_appr_name = wa_approver-name_text.
      append wa_agents to it_agents.
    endif.

   TRY.
    go_send_request = cl_bcs=>create_persistent( ).
    go_sender = cl_sapuser_bcs=>create( 'SAP_WFRT' ).
    go_send_request->set_sender( i_sender = go_sender ).

  DATA(lv_belnr1) = lv_belnr.
  SHIFT lv_belnr1 LEFT DELETING LEADING '0'.

  CONCATENATE 'Approve Jounral Entry' lv_comp_code '-' lv_belnr1 '-' lv_gjahr INTO gc_subject SEPARATED BY space.

  gs_text-line = '<HTML><BODY>'.
  APPEND gs_text to gt_text[].
  CLEAR: gs_text.

  concatenate 'Dear' lv_appr_name into gs_text-line SEPARATED BY SPACE.
  APPEND gs_text TO gt_text[].
  CLEAR : gs_text.

  gs_text-line = '<br></br>'.
  APPEND gs_text TO gt_text.
  CLEAR: gs_text.

  concatenate 'Recurring Journal Entry' lv_belnr1 '-'  lv_comp_code '-' lv_gjahr 'is waiting for your approval.' into gs_text-line separated by space .
  APPEND gs_text TO gt_text[].
  CLEAR : gs_text.

  gs_text-line = '<br></br>'.
  APPEND gs_text TO gt_text.
  CLEAR: gs_text.

  gs_text-line = 'Please review the details using the provided link.'.
  APPEND gs_text TO gt_text[].
  CLEAR : gs_text.

  gs_text-line = '<br></br>'.
  APPEND gs_text TO gt_text.
  CLEAR: gs_text.

  gs_text-line = 'This is a system generated mail. Please do not reply to this.'.
  APPEND gs_text TO gt_text[].
  CLEAR: gs_text.

  gs_text-line = '<br></br>'.
  APPEND gs_text TO gt_text.
  CLEAR: gs_text.

  gs_text-line = 'Thanks and Regards,'.
  APPEND gs_text TO gt_text[].
  CLEAR: gs_text.

  gs_text-line = '<br></br>'.
  APPEND gs_text TO gt_text.
  CLEAR: gs_text.

  gs_text-line = lv_init_name.
  APPEND gs_text TO gt_text[].
  CLEAR: gs_text.

  gs_text-line = '</HTML></BODY>'.
  APPEND gs_text to gt_text[].
  CLEAR: gs_text.

  go_document = cl_document_bcs=>create_document(
                    i_type    = 'HTM'
                    i_text    = gt_text
                    i_subject = gc_subject ).

  go_send_request->set_document( go_document ).

*  loop at it_approvers into wa_approver.
    go_recipient = cl_cam_address_bcs=>create_internet_address( lv_appr_mid ).
    go_send_request->add_recipient(
          EXPORTING
            i_recipient = go_recipient
            i_express   = abap_true
        ).
*  endloop.

  gv_sent_to_all = go_send_request->send( i_with_error_screen = abap_true ).
  COMMIT WORK.
  CATCH cx_bcs INTO gx_bcs_exception.
    gv_error_message = gx_bcs_exception->get_text( ).
    WRITE gv_error_message.

ENDTRY.

IF LV_COUNTER > LV_COUNTER_MAX.
  LV_EXIT = 'X'.
ELSE.
  LV_EXIT = 'Y'.
ENDIF.

wa_rec_wf_sts-doc_no = lv_belnr1.
wa_rec_wf_sts-comp_code = lv_comp_code.
wa_rec_wf_sts-fis_year = lv_gjahr.
wa_rec_wf_sts-status = 'In-process'.

MODIFY ZFI_REC_WF_ST_DT from wa_rec_wf_sts.
COMMIT WORK.

M_UNBLOCK_POSTING:

Parameters:

    DATA:
      lt_bkdf       TYPE TABLE OF bkdf,
      lt_bkpf       TYPE TABLE OF bkpf,
      lt_dummy_bseg TYPE TABLE OF bseg,
      lt_dummy_bsec TYPE TABLE OF bsec,
      lt_dummy_bsed TYPE TABLE OF bsed,
      lt_dummy_bset TYPE TABLE OF bset.

    SELECT SINGLE *
    FROM bkpf
    INTO (ls_bkpf)
    WHERE bukrs = _bkdf-bukrs
    AND   belnr = _bkdf-belnr
    AND   gjahr = _bkdf-gjahr.

    IF sy-subrc = 0.
      " Read blocked recurring entry data
      SELECT SINGLE *
        FROM bkdf
        INTO (ls_bkdf)
        WHERE bukrs = _bkdf-bukrs
        AND   belnr = _bkdf-belnr
        AND   gjahr = _bkdf-gjahr.

      IF sy-subrc = 0.
        " Remove Block
        ls_bkdf-blocked_for_posting = abap_false.
        ls_bkdf-xdelt = abap_false.
        " Add records
        APPEND ls_bkpf TO lt_bkpf.
        APPEND ls_bkdf TO lt_bkdf.
        " Update document
        CALL FUNCTION 'CHANGE_DOCUMENT'
          TABLES
            t_bkdf = lt_bkdf
            t_bkpf = lt_bkpf
            t_bsec = lt_dummy_bsec
            t_bsed = lt_dummy_bsed
            t_bseg = lt_dummy_bseg
            t_bset = lt_dummy_bset.
        IF sy-subrc = 0.
          COMMIT WORK.
        ENDIF.
      ENDIF.
    ENDIF.
  ENDMETHOD.

M_COMPLETE_MAIL:

Parameters:

        DATA: gc_subject     TYPE so_obj_des, " Email subject
          gc_email_to    TYPE adr6-smtp_addr, " Valid email
          gs_text        TYPE soli, " Text used into the email body
          gc_type_raw    TYPE so_obj_tp, " Email type
          gc_att_type    TYPE soodk-objtp, " Attachment type
          gc_att_subject TYPE sood-objdes. " Attachment title
    DATA:
          gt_text           TYPE soli_tab, " Table which contains email body text
          gt_attachment_hex TYPE solix_tab, " Table which contains the attached file
          gv_sent_to_all    TYPE os_boolean, " Receive the information if email was sent
          gv_error_message  TYPE string, " Used to get the error message
          go_send_request   TYPE REF TO cl_bcs, " Email object
          go_recipient      TYPE REF TO if_recipient_bcs, " Who will receive the email
          go_sender         TYPE REF TO cl_sapuser_bcs, " Who is sending the email
          go_document       TYPE REF TO cl_document_bcs, " Email body
          gx_bcs_exception  TYPE REF TO cx_bcs.

    DATA: e_reason                 TYPE swcont-value,
          reason_txt               TYPE swcont-value,
          l_lines                  TYPE i,
          object_content           TYPE TABLE OF solisti1,
          subcontainer_all_objects TYPE TABLE OF swr_cont,
          lv_wa_reason             LIKE LINE OF subcontainer_all_objects,
          lv_no_att                TYPE  sy-index,
          document_id              TYPE sofolenti1-doc_id,
          return_code              TYPE  sy-subrc,
          ifs_xml_container        TYPE  xstring,
          ifs_xml_container_schema TYPE  xstring,
          simple_container         TYPE TABLE OF swr_cont,
          message_lines            TYPE TABLE OF swr_messag,
          message_struct           TYPE TABLE OF swr_mstruc,
          subcontainer_bor_objects TYPE TABLE OF swr_cont.

    if lv_flag ne 'R'.
       TRY.

          go_send_request = cl_bcs=>create_persistent( ).
          go_sender = cl_sapuser_bcs=>create( 'SAP_WFRT' ).
          go_send_request->set_sender( i_sender = go_sender ).

CONCATENATE 'Recurring Entry Approved:' lv_comp_code lv_belnr lv_gjahr INTO gc_subject SEPARATED BY space.

          gs_text-line = '<HTML><BODY>'.
          APPEND gs_text TO gt_text[].
          CLEAR: gs_text.

          CONCATENATE 'Dear' lv_init_name ',' INTO gs_text-line SEPARATED BY space.
          APPEND gs_text TO gt_text.
          CLEAR: gs_text.

          gs_text-line = '<br></br>'.
          APPEND gs_text TO gt_text.
          CLEAR: gs_text.

          CONCATENATE 'Recurring Journal Entry' lv_belnr lv_comp_code lv_gjahr 'has been completely approved.' INTO gs_text-line SEPARATED BY space.
          APPEND gs_text TO gt_text[].
          CLEAR: gs_text.

          gs_text-line = '<br></br>'.
          APPEND gs_text TO gt_text.
          CLEAR: gs_text.

          CONCATENATE 'This is a system generated mail.' 'Please do not reply to this.' INTO gs_text-line SEPARATED BY space.
          APPEND gs_text TO gt_text[].
          CLEAR: gs_text.

          gs_text-line = '<br></br>'.
          APPEND gs_text TO gt_text.
          CLEAR: gs_text.

          gs_text-line = '</BODY></HTML>'.
          APPEND gs_text TO gt_text[].
          CLEAR: gs_text.

          go_document = cl_document_bcs=>create_document(
                            i_type    = 'HTM'
                            i_text    = gt_text
                            i_subject = gc_subject ).

          go_send_request->set_document( go_document ).


          go_recipient = cl_cam_address_bcs=>create_internet_address( lv_init_mid ).
          "Add recipient to send request
          go_send_request->add_recipient(
            EXPORTING
              i_recipient = go_recipient
              i_express   = abap_true
          ).

          "Send email and get the result
          gv_sent_to_all = go_send_request->send( i_with_error_screen = abap_true ).
          COMMIT WORK.
        CATCH cx_bcs INTO gx_bcs_exception.
          gv_error_message = gx_bcs_exception->get_text( ).
          WRITE gv_error_message.
      ENDTRY.

    else.
      DATA: lv_user TYPE bapibname-bapibname.
      DATA: ls_address TYPE bapiaddr3.
      DATA: lt_return TYPE TABLE OF bapiret2.

      lv_user = lv_actual_agent+2(12).

            CALL FUNCTION 'BAPI_USER_GET_DETAIL'
              EXPORTING
                username = lv_user
              IMPORTING
                address  = ls_address
              TABLES
                return   = lt_return[].

           CALL FUNCTION 'SAP_WAPI_READ_CONTAINER'
            EXPORTING
              workitem_id              = lv_workitem_id
              language                 = sy-langu
              user                     = sy-uname
            IMPORTING
              return_code              = return_code
              ifs_xml_container        = ifs_xml_container
              ifs_xml_container_schema = ifs_xml_container_schema
            TABLES
              simple_container         = simple_container
              message_lines            = message_lines
              message_struct           = message_struct
              subcontainer_bor_objects = subcontainer_bor_objects
              subcontainer_all_objects = subcontainer_all_objects.
*      &-----------------------------------------------------------------------------*
*       Initialize
*      &-----------------------------------------------------------------------------*
          lv_no_att = 0.
*      &-----------------------------------------------------------------------------*
*       Read the _ATTACH_OBJECTS element
*      &-----------------------------------------------------------------------------*
          LOOP AT subcontainer_all_objects INTO lv_wa_reason
                                           WHERE element = 'DECISION_NOTE'."'_ATTACH_OBJECTS'.
            lv_no_att = lv_no_att + 1.
            document_id = lv_wa_reason-value.
          ENDLOOP.
*      &-----------------------------------------------------------------------------*
*       Read the SOFM Document
*      &-----------------------------------------------------------------------------*
          IF document_id IS NOT INITIAL.
            REFRESH : object_content.
            CALL FUNCTION 'SO_DOCUMENT_READ_API1'
              EXPORTING
                document_id                = document_id
*               FILTER                     = 'X '
*       IMPORTING
*               DOCUMENT_DATA              =
              TABLES
*               OBJECT_HEADER              =
                object_content             = object_content
*               OBJECT_PARA                =
*               OBJECT_PARB                =
*               ATTACHMENT_LIST            =
*               RECEIVER_LIST              =
*               CONTENTS_HEX               =
              EXCEPTIONS
                document_id_not_exist      = 1
                operation_no_authorization = 2
                x_error                    = 3
                OTHERS                     = 4.
            IF sy-subrc EQ 0.
              CLEAR : l_lines.
              DESCRIBE TABLE object_content LINES l_lines.
              IF l_lines LT 5.
                READ TABLE object_content INTO reason_txt INDEX 1.
                IF sy-subrc EQ 0.
                  e_reason =  reason_txt.
                ENDIF.
              ENDIF.
            ENDIF.
          ENDIF.

            TRY.
                "Create send request
                go_send_request = cl_bcs=>create_persistent( ).
                "Email FROM...
                go_sender = cl_sapuser_bcs=>create( 'SAP_WFRT' ).
                "Add sender to send request
                go_send_request->set_sender( i_sender = go_sender ).

                CONCATENATE 'Recurring Entry Rejected:' lv_comp_code lv_belnr lv_gjahr INTO gc_subject SEPARATED BY space.

                gs_text-line = '<HTML><BODY>'.
                APPEND gs_text TO gt_text[].
                CLEAR: gs_text.

                CONCATENATE 'Dear' lv_init_name ',' INTO gs_text-ine SEPARATED BY space.
                APPEND gs_text TO gt_text.
                CLEAR: gs_text.

                gs_text-line = '<br></br>'.
                APPEND gs_text TO gt_text.
                CLEAR: gs_text.

                CONCATENATE 'Journal Entry' lv_belnr lv_comp_code lv_gjahr 'has been rejeted by.' ls_address-fullname INTO gs_text-line SEPARATED BY space.
                APPEND gs_text TO gt_text[].
                CLEAR: gs_text.

                gs_text-line = '<br></br>'.
                APPEND gs_text TO gt_text.
                CLEAR: gs_text.

                CONCATENATE 'Rejection Reason:' e_reason INTO gs_text-line SEPARATED BY space.
                APPEND gs_text TO gt_text[].
                CLEAR: gs_text.

                gs_text-line = '<br></br>'.
                APPEND gs_text TO gt_text.
                CLEAR: gs_text.

                CONCATENATE 'This is a system generated mail.' 'Please do not reply to this.' INTO gs_text-line SEPARATED BY space.
                APPEND gs_text TO gt_text[].
                CLEAR: gs_text.

                gs_text-line = '<br></br>'.
                APPEND gs_text TO gt_text.
                CLEAR: gs_text.

                gs_text-line = '</BODY></HTML>'.
                APPEND gs_text TO gt_text[].
                CLEAR: gs_text.

                go_document = cl_document_bcs=>create_document(
                                  i_type    = 'HTM'
                                  i_text    = gt_text
*                          i_length  = '12'
                                  i_subject = gc_subject ).

                go_send_request->set_document( go_document ).
                go_recipient = cl_cam_address_bcs=>create_internet_address( lv_init_mid ).
                "Add recipient to send request
                go_send_request->add_recipient(
                  EXPORTING
                    i_recipient = go_recipient
                    i_express   = abap_true
                ).
                "Send email and get the result
                gv_sent_to_all = go_send_request->send( i_with_error_screen = abap_true ).
                COMMIT WORK.
              CATCH cx_bcs INTO gx_bcs_exception.
                gv_error_message = gx_bcs_exception->get_text( ).
                WRITE gv_error_message.
            ENDTRY.
    endif.
  endmethod.

NOTE: Notification sent upon Complete Approval or upon Rejection in any one level is incorporated in the same method.

Thus, the class and methods required for the workflow operation has been completed successfully.

Step – 4: Now we need to trigger the Workflow once the Recurring Document is created in FBD1. For which we need to find the suitable BTE (For finding the BTE, refer the process mentioned in Step-2). The BTE for this requirement is “SAMPLE_INTERFACE_00001030”.
Copy this FM in SE37 to a custom one and write the below code.

IF sy-tcode = 'FBD1' OR sy-tcode = 'FBD9' .                 "Recurring Journal Entry Workflow Event Trigger

DATA: lv_objtype          TYPE sibftypeid,
      lv_event            TYPE sibfevent,
      lv_objkey           TYPE sibfinstid,
      lr_event_parameters TYPE REF TO if_swf_ifs_parameter_container,
      lv_param_name       TYPE swfdname,
      ls_recjour_input    TYPE zfi_st_recjour_entry.

CONSTANTS: lc_objtype    TYPE sibftypeid VALUE 'ZCL_FI_9000_RECURRING_WF',
           lc_event      TYPE sibfevent VALUE 'CREATED',
           lc_param_name TYPE swfdname VALUE 'ZST_WF_REC_JOUR'.

      lv_objtype = lc_objtype.
      lv_event   = lc_event.
      lv_param_name = lc_param_name.

      ls_recjour_input-wa_bkdf = i_bkdf.
      ls_recjour_input-wa_bkpf = t_bkpf.
      ls_recjour_input-wa_bsec = t_bsec.
      ls_recjour_input-wa_bsed = t_bsed.
      ls_recjour_input-wa_bseg = t_bseg.
      ls_recjour_input-wa_bset = t_bset.
      ls_recjour_input-tcode =  sy-tcode .

      concatenate ls_recjour_input-wa_bkpf-belnr ls_recjour_input-wa_bkpf-bukrs ls_recjour_input-wa_bkpf-gjahr into lv_objkey.

      CALL METHOD cl_swf_evt_event=>get_event_container
        EXPORTING
          im_objcateg  = cl_swf_evt_event=>mc_objcateg_cl
          im_objtype   = lv_objtype
          im_event     = lv_event
        RECEIVING
          re_reference = lr_event_parameters.

      TRY.
          CALL METHOD lr_event_parameters->set
            EXPORTING
              name  = lv_param_name
              value = ls_recjour_input.

        CATCH cx_swf_cnt_cont_access_denied .
        CATCH cx_swf_cnt_elem_access_denied .
        CATCH cx_swf_cnt_elem_not_found .
        CATCH cx_swf_cnt_elem_type_conflict .
        CATCH cx_swf_cnt_unit_type_conflict .
        CATCH cx_swf_cnt_elem_def_invalid .
        CATCH cx_swf_cnt_container .
     ENDTRY.

       TRY.
          CALL METHOD cl_swf_evt_event=>raise
            EXPORTING
              im_objcateg        = cl_swf_evt_event=>mc_objcateg_cl
              im_objtype         = lv_objtype
              im_event           = lv_event
              im_objkey          = lv_objkey
              im_event_container = lr_event_parameters.
          COMMIT WORK.
        CATCH cx_swf_evt_invalid_objtype .
        CATCH cx_swf_evt_invalid_event .
      ENDTRY.

      IF sy-subrc <> 0.
*        WRITE: 'Error occurred while triggering workflow event.' ##NO_TEXT.
      ENDIF.
   ENDIF.
   ENDIF.

STEP – 5: Now we need to create tasks in PFTC, for the methods that were created in STEP-3. This is a very normal procedure of creating the tasks that are to be consumed by the activity in the Workflow Template.

NOTE: For the User Decision Step, take a copy of the standard decision step (TS00008267) and do the necessary modifications and perform agent assignment. Once done, capture the Agent Assignment in a Customizing TR by running the report RHMOVE30 in SE38.

STEP – 6: I had created Flexible Workflow for this requirement. Open the transaction “SWDD_SCENARIO”. Create the Workflow containers with reference to all the event and the method parameters in the Custom Class created in STEP-3.

In the Process Data Tab, provide the class name and the associated event. Do the necessary event binding and activate the event as shown below.

NOTE: Caputre the Event Activation in the same customizing TR as mentioned in STEP - 5.
In the Activities Tab, create the activities for the tasks that were created in STEP-5. Include the User Decision Activity, in the list of activities.

NOTE: “DISPLAY_TCODE” is an activity which we have created for accessing the T-Code “FBD1”.
In the Conditions Tab, we have created one condition. This condition is for stopping the Workflow upon completion of all the agents.
When we create Flexible Workflow, we must create a customized Runtime Class. This Runtime Class helps us to utilize “Instance Methods” upon available events. We need to create a Subclass of the standard Runtime Class “CL_SWF_FLEX_IFS_RUN_APPL_BASE”. Then we can redefine the methods necessary for our purpose. There would be several standard methods which would be useful for several scenarios.
NOTE: For our process, we can redefine below methods, as shown below.

NOTE: First method would get triggered just before the Workflow is about to complete. Second method would trigger upon completion of each activity. Use TaskId as filter, such that procedure only for suitable tasks would run.
Inside the Result Callback method, utilize the mail notification methods created in STEP-3.
Activate the Workflow. Since we are implementing Flexible Workflow, we need to activate the scenario. Follow the path mentioned below.
SPRO -> ABAP Platform -> Application Server -> Business Management -> SAP Business Workflow -> Flexible Workflow -> Scenario Activation.
NOTE: Provide the Custom Workflow Number and activate the scenario. You can capture this in TR & transport to further landscape.
Now we need to Login to the FIORI launchpad. As Pre-requisites implement “Manage Workflows” & “Manage Workflow Scenarios” applications.
NOTE: In the “Manage Workflows” application create the Workflow, along with the sequence of the steps in which the workflow must be executed.
Manage Workflow Header:
Execution Steps:

Here the maximum level is 4. However, if we keep the maximum approver level less than 4 also, the Workflow will stop at the designated maximum level. This is based the Step-Condition indicated as Final Level in the above screenshot.
Once created, open the “Manage Workflow Scenarios” application and export the scenario. This will get downloaded as a XML file in the system.
Move the Customizing TR and import the downloaded XML file into the testing landscape and to further landscapes.
Upon Complete approval of the workflow, the “BLOCKED_FOR_POSTING” & “XDELT (Deletion_Indicator) fields would be reset. This makes the document eligible for further posting through Perioidic Job Scheduling in F.14 Transaction.
Incase if the approver rejects the document, he can provide the Reason for Rejection. This will be sent along with the Rejection Notification to the Initiator of the Workflow (i.e Recurring Entry Document Creator).
The Document Creator can modify according to the Rejection Comments and save the document. The Workflow would get triggered again for another approval cycle.
NOTE: I had designed the solution such that the document cannot be edited, unless it is fully approved / rejected. This is an optional solution to be incorporated.

Conclusion:
Recurring entries simplify financial operations, but without governance, they can introduce compliance risks. By integrating FBD1 with an approval workflow, organizations can achieve the right balance between automation and financial control, ensuring accuracy, transparency, and audit readiness.

“Dynamic Field Manipulation in RAP Action Popup – A Step-by-Step Guide”

2026-02-25T11:21:35.588000+01:00

Introduction-

In SAP RAP, actions play a crucial role in triggering business logic from the UI. One powerful feature is the ability to open a parameter dialog (popup) when an action is executed.
In this blog, we will explore how to dynamically control fields inside a RAP action popup, including implementing dropdown value help and runtime field manipulation. This step-by-step guide demonstrates how to design, implement, and test a parameterized RAP action that enhances user interaction in SAP Fiori Elements.

Let's create the tables-

Header table-

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

key client         : abap.clnt not null; 
key contact_id     : sysuuid_x16 not null; 
@EndUserText.label : 'First Name' 
first_name         : abap.char(30) not null; 
@EndUserText.label : 'Middle Name' 
middle_name        : abap.char(30); 
@EndUserText.label : 'Last Name' 
last_name          : abap.char(30); 
gender             : zbrt_de_gender; 
@EndUserText.label : 'Date of Birth' 
dob                : abap.dats; 
@EndUserText.label : 'Age' 
age                : abap.numc(3); 
@EndUserText.label : 'Telephone' 
telephone          : abap.numc(10); 
@EndUserText.label : 'Email' 
email              : abap.char(80); 
active             : abap_boolean; 
created_by         : abp_creation_user; 
created_at         : abp_creation_tstmpl; 
last_changed_by    : abp_lastchange_user; 
last_changed_at    : abp_lastchange_tstmpl; 
}

Item table with foreign key relationship-

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

key client      : abap.clnt not null; 
@AbapCatalog.foreignKey.screenCheck : false 
key contact_id  : sysuuid_x16 not null 
with foreign key [1..*,1] zbrt_t_contact 
where client = zbrt_t_contaddr.client 
and contact_id = zbrt_t_contaddr.contact_id; 
key address_id  : sysuuid_x16 not null; 
key address_sr  : abap.numc(2) not null; 
addr1           : abap.char(30); 
addr2           : abap.char(30); 
city            : abap.char(20); 
state           : abap.char(30); 
pincode         : abap.numc(6); 
created_by      : abp_creation_user; 
created_at      : abp_creation_tstmpl; 
last_changed_by : abp_lastchange_user; 
last_changed_at : abp_lastchange_tstmpl; 
}

Then create the interface view along with association and composition--

Header interface view--

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Contact View'
@Metadata.ignorePropagatedAnnotations: true
define root view entity Zi_Brt_Contact
as select from zbrt_t_contact
composition[0..*] of ZI_BRT_CONTADDR as _Address
association[1..*] to ZI_BRT_GENDER as _Gender
on $projection.Gender = _Gender.GenderCode
{
key contact_id as ContactId,
first_name as FirstName,
middle_name as MiddleName,
last_name as LastName,
gender as Gender,
dob as Dob,
age as Age,
telephone as Telephone,
email as Email,
active as Active,
created_by as CreatedBy,
created_at as CreatedAt, 
last_changed_by as LastChangedBy, 
last_changed_at as LastChangedAt, 
_Gender, 
_Address 
}

Item interface view--

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Address view'
@Metadata.ignorePropagatedAnnotations: true
define view entity ZI_BRT_CONTADDR
as select from zbrt_t_contaddr
association to parent Zi_Brt_Contact as _Contact
on $projection.ContactId = _Contact.ContactId
{
key contact_id as ContactId,
key address_id as AddressId,
key address_sr as AddressSr,
addr1 as Addr1,
addr2 as Addr2,
city as City,
state as State,
pincode as Pincode,
created_by as CreatedBy,
created_at as CreatedAt,
last_changed_by as LastChangedBy,
last_changed_at as LastChangedAt,
_Contact 
}

Then create the projection view for both header and item--

Header projection view--

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Projection view for contact'
@Metadata.ignorePropagatedAnnotations: true
@Metadata.allowExtensions: true
define root view entity zc_brt_contact
provider contract transactional_query
as projection on Zi_Brt_Contact
{
key ContactId,
FirstName,
MiddleName,
LastName,
// @ObjectModel.text.association: '_Gender'
Gender,
Dob,
Age,
Telephone,
Email,
Active,
CreatedBy,
CreatedAt,
LastChangedBy,
LastChangedAt,
/* Associations */
_Gender,
_Address : redirected to composition child zc_brt_contaddr
}

Item projection view--

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Address projection view'
@Metadata.ignorePropagatedAnnotations: true
@Metadata.allowExtensions: true
define view entity zc_brt_contaddr
as projection on ZI_BRT_CONTADDR
{
key ContactId,
key AddressId,
key AddressSr,
Addr1,
Addr2,
City,
State,
Pincode,
CreatedBy,
CreatedAt,
LastChangedBy,
LastChangedAt,
/* Associations */
_Contact : redirected to parent zc_brt_contact
}

Then create Behavior definition on interface view--

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

define behavior for Zi_Brt_Contact alias u_contact
implementation in class zbrt_cl_bp_contact_u unique
draft table zbrt_t_contact_d
late numbering
lock master total etag LastChangedAt
authorization master ( instance )
//etag master <field_name>
{
create;
update ( features : instance );
delete ( features : instance );
field ( readonly ) ContactId, Age;

association _Address { create (features : instance); with draft; }

determination calculate_age on modify { field Dob; }
action ( features : instance ) setstatus result[1] $self;
action change_field_value parameter ZI_BRT_STATUS_PARAM result[1] $self;

draft action Edit;
draft action Activate optimized;
draft action Resume;
draft action Discard;
draft determine action Prepare; 
mapping for zbrt_t_contact control zbrt_s_contact
{
    ContactId     = contact_id;
    FirstName     = first_name;
    MiddleName    = middle_name;
    LastName      = last_name;
    Gender        = gender;
    Dob           = dob;
    Age           = age;
    Telephone     = telephone;
    Email         = email;
    Active        = active;
    CreatedBy     = created_by;
    CreatedAt     = created_at;
    LastChangedBy = last_changed_by;
    LastChangedAt = last_changed_at;
  }
}
define behavior for ZI_BRT_CONTADDR alias u_contadd
implementation in class zbrt_cl_bp_contadd_u unique
draft table zbrt_t_contadd_d
late numbering
lock dependent by _Contact
authorization dependent by _Contact
{
update (features : instance);
delete (features : instance);
field ( readonly ) ContactId, AddressId, AddressSr;
association _Contact{with draft;}
mapping for zbrt_t_contaddr control zbrt_s_contaddr
{
    ContactId     = contact_id;
    AddressId     = address_id;
    AddressSr     = address_sr;
    Addr1         = addr1;
    Addr2         = addr2;
    City          = city;
    State         = state;
    Pincode       = pincode;
    CreatedBy     = created_by;
    CreatedAt     = created_at;
    LastChangedBy = last_changed_by;
    LastChangedAt = last_changed_at;
  }
}

Behavior definition on projection view--

projection;
strict ( 2 );
use draft;

define behavior for zc_brt_contact //alias u_contact
use etag
{
use create;
use update;
use delete;
use action setstatus;
use action change_field_value;

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

use association _Address { create; with draft; }
}
define behavior for zc_brt_contaddr //alias u_contaddr
{
use update;
use delete;
use association _Contact { with draft; }
}

Service definition--

Service binding--

Actions buttons in UI-

This is the action button declared in the behavior definition-->

This method setstatus is a RAP Action implementation.
It toggles the status (ACTIVE ↔ INACTIVE) of a Contact entity.

%tky-

Technical key
Required to update the same instance that was read
Mandatory in MODIFY ENTITIES

UPDATE FIELDS ( active )-->

Only updates the active field
Prevents accidental changes to other fields

After declaring action name in the behavior definition, we need to declare it in the metadata extension also--

In above we can see the action button name Change Status in the UI

Based on the Active status it is going to change.

Let's see--

Now the field abc -> Active status is Yes -> click on the Change Status button -> now it will become No.

IMP - Now here we have another action button which is a parameterized action button which is declared using abstract entity.

Change-Field-Value.

For that we have already created one Abstract entity --

@EndUserText.label: 'Status parameter'
@Metadata.allowExtensions: true
define abstract entity zi_brt_status_param
{
 .defaultValue  : 'X' 
 @EndUserText.label: 'Active'
 active            : abap_boolean;
 .defaultValue: #( 'ELEMENT_OF_REFERENCE_ENTITY : Telephone' )
 @EndUserText.label: 'Telephone'
 telephone         : abap.numc(10);
}

Then declared the same action name in the metadata also-

See the logic--

METHOD change_field_value.

DATA(ls_param) = VALUE #( keys[ 1 ]-%param ).

READ ENTITIES OF zi_brt_contact IN LOCAL MODE
ENTITY u_contact
ALL FIELDS WITH CORRESPONDING #( keys )
RESULT DATA(lt_contact).

MODIFY ENTITIES OF zi_brt_contact IN LOCAL MODE
ENTITY u_contact
UPDATE FIELDS ( active telephone )
WITH VALUE #(
   FOR lwa_contact IN lt_contact (
   %tky = lwa_contact-%tky
   %data-active = ls_param-active
   %data-telephone = ls_param-telephone
  ) ).

result = VALUE #( FOR lwa_contact IN lt_contact (
                  %key = lwa_contact-%key
                  %param = CORRESPONDING #( lwa_contact )
               ) ). 
ENDMETHOD.

This is an action implementation method inside the Behavior Implementation Class.

It updates:

active
telephone

based on the values entered in the RAP action popup parameter dialog.

Fetch Action Parameters from Popup

DATA(ls_param) = VALUE #( keys[ 1 ]-%param ).

keys → contains selected instances + action parameters

%param → holds popup field values entered by user

keys[ 1 ] → since action usually triggered on selected row(s)

Meaning:

We are extracting the parameter values entered in the popup into structure ls_param.

If popup had:

Active = ‘X’

Telephone = ‘9876543210’

Those values now sit in ls_param.

Read Current Entity Data--

READ ENTITIES OF zi_brt_contact IN LOCAL MODE
  ENTITY u_contact
  ALL FIELDS WITH CORRESPONDING #( keys )
  RESULT DATA(lt_contact).

Reading selected records from BO

IN LOCAL MODE → no DB commit, transactional buffer

WITH CORRESPONDING #( keys ) → read only selected instances

Result stored in lt_contact

Why required?

Because:

We need technical key %tky

We need current data before updating

EML update requires %tky

Update Fields Using MODIFY ENTITIES-

MODIFY ENTITIES OF zi_brt_contact IN LOCAL MODE
  ENTITY u_contact
  UPDATE FIELDS ( active telephone )
  WITH VALUE #(
    FOR lwa_contact IN lt_contact (
      %tky = lwa_contact-%tky
      %data-active = ls_param-active
      %data-telephone = ls_param-telephone
    ) 
  ).

We are updating:

active
telephone

for each selected instance.

Important Points:

✔ %tky → technical key required to identify instance
✔ %data-fieldname → actual field update
✔ UPDATE FIELDS → performance optimized (only those 2 fields updated)

Note - Even though popup opened per selected row, internally RAP still processes in mass-enabled mode.

That’s why:

FOR lwa_contact IN lt_contact

This allows:

Single selection
Multiple selection
Bulk update

Return Result to UI

result = VALUE #(
  FOR lwa_contact IN lt_contact (
    %key = lwa_contact-%key
    %param = CORRESPONDING #( lwa_contact )
  )
).

After update:

Returning updated instance(s)
%key → identifies updated instance

%param → sends data back to UI

User clicks Action
↓
Popup opens
↓
User enters Active + Telephone
↓
%param receives values
↓
READ ENTITIES → fetch selected records
↓
MODIFY ENTITIES → update selected instances
↓
Return result → UI refresh

Let's see how it works--

Now I have selected one record -> Bikash -> which telephone Num is there, and Active status is Yes -> click on Change-field-value ->

-> we can see the pop-up where we can change the Active status drop down and Telephone number as well -> let’s do the changes and see ->

In the above, we can see the changes.

Conclusion--

In this blog, we explored how to implement dynamic field manipulation inside a RAP action popup using a parameterized action. We walked through extracting popup parameters using %param, reading selected instances via READ ENTITIES, and performing controlled updates using MODIFY ENTITIES in local mode. Finally, we ensured proper UI synchronization by returning the updated result set back to the Fiori Elements application.

Thanks--

SAP Build Work Zone: Tile Opens(content federation) but App Fails with ‘IP Address Cannot Be Found

2026-03-02T10:49:06.511000+01:00

In my SAP Build Work Zone (Standard Edition) environment, I faced an issue where a dynamic tile loaded successfully through content federation, but clicking the tile caused the application to fail with a browser error:

ERR_NAME_NOT_RESOLVED – The IP address of the server could not be found

The failing URL always contained a very long auto‑generated hostname.

Interestingly, the dynamic tile itself worked correctly (e.g., OData count displayed), but navigating to the corresponding SAP Fiori app consistently failed. This clearly indicated that the issue was not with backend connectivity or destinations, but with the content runtime URL generated by Work Zone.

Please refer the screenshots.