SAP Community - ABAP RESTful Application Programming Model

Global Feature Contron in RAP, Feature control in RAP

2025-04-08T10:11:48.601000+02:00

Hello Everyone,

In this blog post we are going to Learn about Global Feature Control in RAP.

Global feature control in the RAP (RESTful Application Programming) model is used to enable or disable specific features for all users at once, regardless of individual data records or instances. It defines whether a particular operation (like create, update, or delete) is globally allowed or restricted. To do this, we extend the operation in the behavior definition as we did earlier for the instance feature.

Delete (features: global);

To implement a global feature, the "get_global_features" method must be implemented. As previously described, there is no transfer of the keys from the outside. The derivation of the various features must be based on other criteria.

Procedure:

Here we are defining a Custom table (ZKK_DT_TRAVEL).

The table zkk_dt_travel is a transparent table in SAP that stores travel-related information. It includes details such as travel ID, agency ID, customer ID, travel dates, booking fees, total price, currency, status and a description. It also tracks the creation and modification details like created by, created at, last changed by, and last changed at.

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

  key client      : abap.clnt not null;
  key travel_id   : /dmo/travel_id not null;
  agency_id       : /dmo/agency_id;
  customer_id     : /dmo/customer_id;
  begin_date      : /dmo/begin_date;
  end_date        : /dmo/end_date;
  @Semantics.amount.currencyCode : '/dmo/travel_m.currency_code'
  booking_fee     : abap.curr(16,2);
  @Semantics.amount.currencyCode : '/dmo/travel_m.currency_code'
  total_price     : /dmo/total_price;
  currency_code   : /dmo/currency_code;
  description     : /dmo/description;
  status          : abap_boolean;
  created_by      : abp_creation_user;
  created_at      : abp_creation_tstmpl;
  last_changed_by : abp_locinst_lastchange_user;
  last_changed_at : abp_locinst_lastchange_tstmpl;

}

The Above table holds the records which are given below

For this database table(ZKK_DT_TRAVEL) we are defining the Basic view/Interface view.

The ZKK_I_TRAVEL is a CDS view based on the zkk_dt_travel table. It provides a structured way to access travel data, including fields like travel ID, agency ID, customer ID, travel dates, booking fees, total price, currency, and timestamps. It uses annotations to enhance usability, such as semantic tags for amounts, currencies, and metadata for created/changed users and timestamps.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Interface view for Travelling'
@Metadata.ignorePropagatedAnnotations: true
@Metadata.allowExtensions: true
@ObjectModel.usageType:{
    serviceQuality: #X,
    sizeCategory: #S,
    dataClass: #MIXED
}
define root view entity ZKK_I_TRAVEL
  as select from zkk_dt_travel
{
  key travel_id       as TravelId,
      agency_id       as AgencyId,
      customer_id     as CustomerId,
      begin_date      as BeginDate,
      end_date        as EndDate,
      @Semantics.amount.currencyCode: 'CurrencyCode'
      booking_fee     as bookingfee,
      @Semantics.amount.currencyCode: 'CurrencyCode'
      total_price     as TotalPrice,
      currency_code   as CurrencyCode,
      description     as Description,
      status          as status,
      @Semantics.user.createdBy: true
      created_by      as CreatedBy,
      @Semantics.systemDateTime.createdAt: true
      created_at      as CreatedAt,
      @Semantics.user.localInstanceLastChangedBy: true
      last_changed_by as LastChangedBy,
      @Semantics.systemDateTime.lastChangedAt: true
      last_changed_at as LastChangedAt
}

Now I am defining the Projection view on top of interface view.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'projection view for Travel'
@Metadata.ignorePropagatedAnnotations: true
@Metadata.allowExtensions: true
@ObjectModel.usageType:{
    serviceQuality: #X,
    sizeCategory: #S,
    dataClass: #MIXED
}
define root view entity ZKK_C_TRAVEL  
  as projection on ZKK_I_TRAVEL as Travel
{
  key TravelId,
      AgencyId,
      CustomerId,
      BeginDate,
      EndDate,
      @Semantics.amount.currencyCode: 'CurrencyCode'
      bookingfee,
      @Semantics.amount.currencyCode: 'CurrencyCode'
      TotalPrice,
      CurrencyCode,
      Description,
      status,
      CreatedBy,
      CreatedAt,
      LastChangedBy,
      LastChangedAt
}

Now I am defining the Metadata Extension for projection View.

@Metadata.layer: #PARTNER
annotate entity ZKK_C_TRAVEL with
{
  @ui.facet: [{
     purpose: #STANDARD,
     position: 10,
     type : #IDENTIFICATION_REFERENCE,
     label: 'Travel Details'
   }]

  @ui.identification: [{ position: 10, label: 'Travel Id' }]
  @ui.lineItem: [{ label: 'Travel Id' }]
  TravelId;

  @ui.identification: [{ position: 20, label: 'Agency Id' }]
  @ui.lineItem: [{ label: 'Agency Id' }]
  AgencyId;

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

  @ui.identification: [{ position: 40, label: 'Begin Date' }]
  @ui.lineItem: [{ label: 'Begin Date' }]
  BeginDate;

  @ui.identification: [{ position: 50, label: 'End Date' }]
  @ui.lineItem: [{ label: 'End Date' }]
  EndDate;

  @ui.identification: [{ position: 60, label: 'Booking Fee' }]
  @ui.lineItem: [{ label: 'Booking Fee' }]
  bookingfee;

  @ui.identification: [{ position: 70, label: 'Total Price' }]
  @ui.lineItem: [{ label: 'Total Price' }]
  TotalPrice;

  @ui.identification: [{ position: 80, label: 'Status Confirm' },
  { type: #FOR_ACTION, dataAction: 'status', label: 'Status Confirm' } ]
  @ui.lineItem: [{ label: 'Status' },
  { type: #FOR_ACTION, dataAction: 'status', label: 'Confirm Status' }]
  status;


  @ui.identification: [{ position: 100, label: 'Currency' }]
  @ui.lineItem: [{ label: 'Currency' }]
  CurrencyCode;

  @ui.identification: [{ position: 90, label: 'Description' }]
  @ui.lineItem: [{ label: 'Description' }]
  Description;


  @ui.identification: [{ position: 110, label: 'Created By' }]
  @ui.lineItem: [{ label: 'Created By' }]
  CreatedBy;

  @ui.identification: [{ position: 120, label: 'Created At' }]
  @ui.lineItem: [{ label: 'Created At' }]
  CreatedAt;

  @ui.identification: [{ position: 130, label: 'Last Changed By' }]
  @ui.lineItem: [{ label: 'Last Changed By' }]
  LastChangedBy;

  @ui.identification: [{ position: 140, label: 'Last Changed At' }]
  @ui.lineItem: [{ label: 'Last Chnaged at' }]
  LastChangedAt;
}

Lets Define the Behaviour Definition.

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

define behavior for ZKK_I_TRAVEL alias Travel //alias <alias_name>
persistent table zkk_dt_travel
lock master
authorization master ( instance )
//etag master <field_name>
{
  create;
  update;
  delete ( features : global );
  field ( readonly : update ) TravelId;
  field ( readonly ) LastChangedAt, LastChangedBy, CreatedAt, CreatedBy;
  field ( mandatory : create ) AgencyId, CustomerId, BeginDate, EndDate, bookingfee, CurrencyCode;
  action ( features : instance ) status result [1] $self;

  mapping for ZKK_DT_TRAVEL {
  TravelId = travel_id;
  AgencyId = agency_id;
  CustomerId = customer_id;
  BeginDate = begin_date;
  EndDate = end_date;
  bookingfee = booking_fee;
  TotalPrice = total_price;
  CurrencyCode = currency_code;
  Description = description;
  status = status;
  CreatedBy = created_by;
  CreatedAt = created_at;
  LastChangedBy = last_changed_by;
  LastChangedAt = last_changed_at;
  }
}

Here in Behavior definition, we have to specify

delete (features: global);

as we are performing delete operation

After that we will get a warning as given below

When we double click on that warning GET_GLOBAL_FEATURE method will get automatically.

You can observe there is no KEYS parameter, that means we cannot read the details of selected record from here, we will get only the global data.

Now we have to implement our custom logic inside the above given method.

 METHOD get_global_features.

  if requested_features-%delete = if_abap_behv=>mk-on.
  Data(lv_result) = COND #( when cl_abap_context_info=>get_user_alias(  ) = 'xyz@gmail.com'
                           then if_abap_behv=>mk-on
                           else if_abap_behv=>mk-off
                            ).

  result-%delete = lv_result.

  ENDIF.

  ENDMETHOD.

Here we have to take the username or mail id which is registed on your SAP Universal ID, so for example i have taken 'xyz@gmail.com'.

Above logic is to make delete button enable or disable

When the user is xyz@gmail.com then the delete button will be enabled

(Requested features contains the actions which are specified with (features: global))

Preview the data

The user logged-in is xyz@gmail.com

The delete button is enabled

Rewriting the code

When the user is xyz@gmail.com then i want the delete button to be disabled

 METHOD get_global_features.

  if requested_features-%delete = if_abap_behv=>mk-on.
  Data(lv_result) = COND #( when cl_abap_context_info=>get_user_alias(  ) = 'xyz@gmail.com'
                           then if_abap_behv=>mk-off
                           else if_abap_behv=>mk-on
                            ).

  result-%delete = lv_result.

  ENDIF.

  ENDMETHOD.

When we RUN the application.

We dont get Delete option as enables, here it is disable for that particular user.

Conclusion:

Global feature control in RAP provides a centralized way to enable or disable specific operations across the entire application, regardless of individual records or user roles. It ensures consistent enforcement of business rules by globally restricting actions like create, update, or delete. This approach simplifies feature management, enhances data security, and ensures uniform behavior, making it an effective mechanism for controlling access and operations at the application level.

RAP: MANAGED VS UNMANAGED RAP

2025-04-08T10:33:54.672000+02:00

Managed RAP
• Greenfield Implementation
• CRUD operations are handled by the framework.
• Transactional buffer is managed by the framework.
• The framework takes care of the save sequence.

Unmanaged RAP
• Brownfield Implementation
• CRUD requires custom implementation.
• Transactional buffer is managed with a global singleton/static class.
• Custom save sequence logic must be written.

Managed with Unmanaged Save:
• The interactive phase remains the same, but the save sequence is handled by the developer.
• Transactional buffer is managed by RAP architecture.
• No persistence table in unmanaged save.

Additional Save (Enhancing Managed RAP)
• Allows developers to implement additional steps for the save logic of a managed RAP BO,
enhancing the standard save sequence.
• Can have a persistence table, as the RAP framework takes care of persisting to the database.

Restrictions:
You can’t use a BAPI with a commit statement, as the RAP LUW takes care of commit and
rollback. Additionally, there’s no persistence table in Unmanaged Save, as the developer writes their
own logic for persisting. Please refer to the attachment for complete restrictions.

When using a function module (on-premise), always create a wrapper around it and
release it with C1 to maintain cloud compatibility.

Best Practices & Recommendations:
• Managed RAP with Unmanaged Save is often the recommended option, combining the best
of both approaches.
• Unmanaged RAP should usually be a last resort.

Key Use Cases:
• No Custom Code: Go for Managed RAP.
• Need to Utilize Update Function Module: opt for Managed RAP with Unmanaged Save.
• Reusable Code/Loose Coupling with Pre-existing Functionality: Choose Unmanaged
RAP.
• Consume Custom APIs (on-premise) in BTP: Use Custom Entities + Unmanaged RAP.
• Unmanaged Queries: Combine Custom Entities + Unmanaged RAP.

Blog Series - Intitial Loads to SAP Advanced Event Mesh

2025-04-14T06:34:57.975000+02:00

In this blog series we focus on a Push Mechanism with the two Event Enabling Technologies

RAP (RESTful Application Programming Model): SAP Business Events: Initial Loads using RAP Events
AIFAEM: How to perform Initial Loads & Bulk Init Loads in AIFAEM triggered by an ABAP Program

as well as a Pull Mechanism by using Odata APIs from SAP BTP Integration Suite: How to Perform Initial Loads from S/4HANA to Advanced Event Mesh with Odata Poll

How to do background scheduling with clean core, including Fiori apps, replacing se38 reports

2025-04-14T12:39:46.843000+02:00

Running certain functionality in background is a common requirement for ERP systems and no news for SAP. But with the increased importance of Clean Core and ABAP Cloud, how do we do it now? If you know a little about clean core, then you know that an se38 ABAP report, that is then scheduled in background, is not clean core, so that's not the answer. But does that mean we can schedule Fiori apps in background? Well, not exactly, but sort of 😊. Let me explain.

Background and SAP Fiori

SAP Fiori is our design system at SAP, coming with guidelines, principals, buildings blocks and much, much, more. But in the end, the result of Fiori is visual; when you open a Fiori app, you see the web-based UI on your device that is based on Fiori. Thus, Fiori in itself, cannot "run in the background". But we can give background running capabilities to Fiori: either by adding it directly to a Fiori app, for example giving it a button a user can click, which then triggers certain functionality to run in the background. Or we can simply design a background job (now called Application Job Template) which we can run or schedule to run in the background via the SAP delivered Fiori app Application Jobs (F1240). So in that sense we can say yes, we can have background jobs combined with Fiori apps.

If you are still confused, and no worries if you are, I completely understand, let me illustrate this by making an example for both options:

Creating an Application Job Template that can be run/scheduled in the Application Jobs Fiori app, which allows us to run "any ABAP code" in background.
A RAP based Fiori app, in which a user can click a button to schedule a background job (using the Application Job Template as well)

1 RAP business object

First of, I need my RAP BO. Instead of using our beloved flight scenario, I opted to create a full custom example on my own. I may not go into full detail on every aspect of the RAP BO itself, as this blog focuses on the background running capability, so if you wonder anything, feel free to ask in the comments.

1.1 RAP BO data model

In total I have following RAP BOs for my complete example:

ZZ1_Author a Custom Business Object built in Custom Business Object Fiori app containing name, birthdate and other fields for an author.
ZR_Books containing simple fields such as the title of a book, number of pages, a price and more. And of course every book needs an author, so we associate ZZ1_Author (I didn't do parent-child composite relationship here for simpleness sake - if your scenario has parent-child relationship, everything will still work)
ZR_Bookstores for my imaginary bookstores that sells ZR_Books. Again, for simpleness sake we just have fields for the bookstore itself, such as its name and address.
ZR_BookstoreStockTP this now is my main BO combing bookstores and books. Please note, create/change/delete bookstores is only done with ZR_Bookstores and create/change/delete books with ZR_Books (I have behavior definitions with draft for both of them, projection views and finally OData V4 services, with simple Fiori Elements apps, one for each). The ZR_BookstoreStockTP BO as said combines these and also adds two stock values; one for how many of a certain book are available in the store currently, in shelves or on display, and how many of a certain book are in storage of that bookstore. To be perfectly transparent here, you could just use ZR_Bookstores as the main TP BO, having books as composite child and including the stock values that way. But these BOs have been used for other demo and use-cases by me, so I opted to reuse them as they are. So in conclusion, build your BO in the way it makes most sense. Back to ZR_BookstoreStockTP; we also have behavior definition, projections and finally an OData V4 service for my "Manage Bookstores" Fiori elements app.

Now if my stock gets low for some books in one of my stores, in my "Manage Bookstores" app I want to schedule a background job for creating new purchase orders for restocking (for demo purpose and because my books aren't real products in the system for which I can create a PO, I will simply increase the stock, but I hope you get the idea). Now before we get into how this is done on the BO behavior, we first need to prepare this application job template.

2 Setup custom Application Job Template

First of, we need to create a new ABAP Cloud class in ADT. Now we already have a slight difference depending on your current system. Since Public Cloud release 2502, there is interface IF_APJ_RT_RUN available. This will be made available with the next full release of 2025 for private cloud and on-premise. So if you are not on public cloud, for now use 2 interfaces instead: IF_APJ_DT_EXEC_OBJECT and IF_APJ_RT_EXEC_OBJECT. If your Tier 1 development package doesn't default ABAP for Cloud Development language version, be sure to switch it for your class to be clean core compliant. With the interface(s) added to your class, we have 2 methods to implement (my demo system is on-premise so you will continue to see that version, but everything should work the same/very similar should you be on 2502).

2.1 Define job parameters

First of we need to define the possible parameters that could be entered by the Fiori app, or when we schedule the job via the Application Jobs Fiori app. Think of it as the selection-screen you had for the se38 report. It also works in the same way as we need to define either select-options or parameters. Below is my code as an example for the bookstore restocking scenario.

  method if_apj_dt_exec_object~get_parameters.

    et_parameter_def = value #(
      ( selname = 'P_STORID' kind = if_apj_dt_exec_object=>parameter
        component_type = 'ZBOOKSTORE_ID'  length = 3
        changeable_ind = abap_true mandatory_ind = abap_true )
      ( selname = 'S_BOOKID' kind = if_apj_dt_exec_object=>select_option
        component_type = 'ZBOOK_ID'       length = 6
        changeable_ind = abap_true mandatory_ind = abap_true )
      ( selname = 'P_REORQT' kind = if_apj_dt_exec_object=>parameter
        datatype = 'I' length = 3 param_text = 'Reorder Qty'
        changeable_ind = abap_true mandatory_ind = abap_true )
      ( selname = 'P_SIMUL'  kind = if_apj_dt_exec_object=>parameter 
        datatype = 'C' length = 1 param_text = 'Simulate Only'
        changeable_ind = abap_true checkbox_ind  = abap_true )
    ).

    " Return default parameter values, if any
    et_parameter_val = value #(
      ( selname = 'P_REORQT' kind = if_apj_dt_exec_object=>parameter 
        sign = 'I' option = 'EQ' low = '10' )
    ).

  endmethod.

Few comments on above:

The names of the parameters can be max 8 letters, just like selection-screens.
When not using component_type, give datatype (max 4 letters), length and label text
The 2nd part, returning default values. is optional
In the older version as I'm using, if you want your job parameters to offer a search help in the final Fiori app for scheduling your job, it must be done via component_type field, which points to a DDIC data element, with a DDIC search help on it. I have done this data element and search-help assignment for my bookstore and my book. Now, in the newer version, we will be able to enter CDS value help views. But if you are not yet on 2502 as myself, my recommendation is this:
- Create a CDS value help as per usual practice (this you can then directly assign in the 2502 version as CDS value help view)
- Before 2502, next also create a DDIC value help, using the CDS value help as selection method: refer to the example below

2.2 Code the job logic

Just like in an se38 report, all the logic that the job needs to do is coded into the 2nd, the EXECUTE method. It is highly recommended to also work with application logs, so that potential troubleshooting gets easy. The application log, when existing, is displayed in the Application Jobs Fiori app.
Now let's get to the meat of things. Here is my bookstore restocking code, which uses of course my RAP BO to do the restocking (or, at this point you could create real purchase orders or requisitions or whatever your process may be. You can also do as many checks as you need etc. etc. - write your ABAP code, but clean and in ABAP Cloud). Now don't get scared, but this code is quite a big bigger. I'll explain 🙂

method if_apj_rt_exec_object~execute.
    data: lrt_book          type range of zbook_id,
          lrs_book          like line of lrt_book,
          lv_bookstore      type zbookstore_id,
          lv_reorder_qty    type zbooks_in_stock,
          lv_simulate       type c length 1,
          lt_update         type table for update zr_bookstorestocktp\\bookstorestock,
          lt_create         type table for create zr_bookstorestocktp\\bookstorestock,
          ls_update         type structure for update zr_bookstorestocktp\\bookstorestock,
          ls_create         type structure for create zr_bookstorestocktp\\bookstorestock,
          lt_reported       type response for reported early zr_bookstorestocktp,
          lt_failed         type response for failed early zr_bookstorestocktp,
          ls_bookstore_book type zi_bookstorestock,
          lv_create         type c length 1.

    try.
        " handle log
        if sy-batch = abap_true.
          " if we are running in background, we create application log
          go_log = cl_bali_log=>create_with_header(
            header = cl_bali_header_setter=>create( 
              object    = 'ZBOOKSTORE_01_LOG'
              subobject = 'ZBOOKSTORE_01_SUB' ) ).
          add_text_to_log( 'start job' ).
          final(lv_log_handle) = go_log->get_handle( ).
          add_text_to_log( |log handle: { lv_log_handle }| ).
        else.
          add_text_to_log( 'start job' ).
          add_text_to_log( |foreground run, no log created| ).
        endif.

        " Going through job parameter values
        loop at it_parameters into data(ls_parameter).
          case ls_parameter-selname.
            when 'S_BOOKID'.
              append value #( sign   = ls_parameter-sign
                              option = ls_parameter-option
                              low    = conv #( ls_parameter-low  )
                              high   = conv #( ls_parameter-high ) ) 
                to lrt_book.
            when 'P_STORID'.
              lv_bookstore = conv #( ls_parameter-low ).
            when 'P_REORQT'.
              lv_reorder_qty = conv #( ls_parameter-low ).
            when 'P_SIMUL'.
              lv_simulate = ls_parameter-low.
          endcase.
        endloop.

        " get bookstore for which reorder was requested
        select single * from zr_bookstores
          where bookstoreid = _bookstore
          into (ls_bookstore).
        if sy-subrc <> 0.
          add_text_to_log( |bookstore not found with id: { lv_bookstore }| ).
        else.
          " go through books...
          loop at lrt_book into lrs_book.
            clear: lv_create, ls_bookstore_book, ls_update, ls_create.
            " check if bookstore already has the current book
            if lrs_book-option = 'EQ'. " only handling EQ!
              add_text_to_log( |processing book with id: { lrs_book-low }| ).
              select single * from zi_bookstorestock
                where bookstoreid = _bookstore
                  and bookid      = _book-low
                into _bookstore_book.
              if sy-subrc <> 0.
                " book is not yet in bookstore, check if book exists...
                select single  from zi_books
                  where bookid = _book-low
                  into (lv_exists).
                if sy-subrc = 0.
                  " book needs to be added (created) to bookstore
                  lv_create = abap_true.
                  ls_bookstore_book = value #( bookstoreid = lv_bookstore
                    bookid = lrs_book-low booksinstore = 0 booksinstock = 0 ).
                else.
                  add_text_to_log( |book does not exit and is ignored: { lrs_book-low }| ).
                  continue.
                endif.
              endif.
              add_text_to_log( |stock qty. before: { ls_bookstore_book-booksinstock }| ).
              ls_bookstore_book-booksinstock += lv_reorder_qty.
              add_text_to_log( |stock qty. after: { ls_bookstore_book-booksinstock }| ).
              " set if we create or update the bookstore stock RAP BO
              if lv_create = abap_true.
                ls_create = corresponding #( ls_bookstore_book ).
                append ls_create to lt_create.
              else.
                ls_update = corresponding #( ls_bookstore_book ).
                append ls_update to lt_update.
              endif.
            endif.
          endloop.
          if sy-subrc <> 0.
            add_text_to_log( 'no books to reorder specified' ).
          endif.
        endif.

        " UPDATE or SIMULATION ----------------------------------------------
        if lv_simulate = abap_true.
          add_text_to_log( 'SIMULATION only, no changes saved' ).
        else.
          " change data -----------------------------------------------------
          if lt_update is not initial.
            modify entities of zr_bookstorestocktp
                 entity bookstorestock
                   update fields ( booksinstock ) with lt_update
                reported data(update_reported)
                failed data(update_failed).
            if update_failed is initial.
              " commit change
              commit entities response of zr_bookstorestocktp
                reported data(commit_reported1)
                failed data(commit_failed1).
              " set errors if commit failed
              lt_reported = corresponding #( deep commit_reported1 ).
              lt_failed = corresponding #( deep commit_failed1 ).
            else.
              " set error
              lt_reported = corresponding #( update_reported ).
              lt_failed = corresponding #( update_failed ).
            endif.
          endif.
          " create data -----------------------------------------------------
          if lt_create is not initial.
            modify entities of zr_bookstorestocktp
                 entity bookstorestock
                   create
                   fields ( bookstoreid bookid booksinstock booksinstore )
                auto fill cid with lt_create 
                reported data(create_reported)
                failed data(create_failed).
            if create_failed is initial.
              " commit created
              commit entities response of zr_bookstorestocktp
                reported data(commit_reported2)
                failed data(commit_failed2).
              " set errors if commit failed
              lt_reported = corresponding #( deep commit_reported2 ).
              lt_failed = corresponding #( deep commit_failed2 ).
            else.
              " set error
              lt_reported = corresponding #( create_reported ).
              lt_failed = corresponding #( create_failed ).
            endif.
          endif.
        endif.

        if lt_failed is initial.
          " SUCCESS -------------------------------
          add_text_to_log( |commit success, nothing in failed| ).

        else.
          " ERRORS --------------------------------
          loop at lt_failed-bookstorestock into data(ls_failed).
            add_text_to_log( |failed to modify bookstore { ls_failed-bookstoreid } with book { ls_failed-bookid }| ).
            add_text_to_log( |reason: { ls_failed-%fail-cause }| ).
          endloop.
        endif.

        add_text_to_log( |job finished| ).

      catch cx_bali_runtime into data(lx_bali_exception).

        data(lv_log_exception) = lx_bali_exception->get_text(  ).
        raise exception type cx_apj_rt_content
          exporting
            previous = lx_bali_exception.

    endtry.

  endmethod.

And here the comments for above, going top to bottom:

We start by handling the application log. Now because I wanted to test this class in foreground running, I added foreground support, but this is of course not needed. We have the instance attribute go_log which is a reference to if_bali_log. In order to create the object, we must enter an application log object and sub-object, so a prerequisite for this, is that these are already created in your system. This can simply be done in ADT, via New - Other - search for "Application Log Object". Here a screenshot of mine:
Next we loop over all parameters which were passed into the background job run, and filling internal tables for further checking/selecting data.
Now we start using the RAP BO for checks, such as reading the bookstore and also all books are checked if they already exist. This job cannot create new books, but it can add an existing book to an existing bookstore, even if that bookstore does not yet have that book. This is done during the lrt_books loop, when we read from the interface view zi_bookstorestock to check if the current looped book is already in the store. If not, we add everything into an EML create table, otherwise an EML update table.
Lastly, we check if the simulation checkbox is true (this is one of the job parameters - again not mandatory; you can create a job template without a simulation checkbox, but I added it), in which case we don't proceed with any change to our RAP BO. If this is not a simulation run, then we use EML to create and/or update ZR_BookstoreStockTP. All these EML are checked for fails and only if everything goes well, we commit our changes.
At the very end after all create/update has been completed, we check whether we had errors and add the errors into the application log. If we had no errors, we write a success message in the log.
Note that the full execution is basically in a try-catch-block. This is because the application job object may raise an exception, so we have to catch it.
You may noticed the method call add_text_to_log, which again is a simple method I built that allows me to handle both foreground and background log. Here the code for that:

  method add_text_to_log.
    " running in background for foreground...
    if sy-batch = abap_true.
      " background - create text object for log
      data(o_go_log_free_text) =
        cl_bali_free_text_setter=>create(
          severity = if_bali_constants=>c_severity_status
          text = i_text ).
      o_go_log_free_text->set_detail_level( detail_level = '1' ).
      " add text object to log
      go_log->add_item( item = o_go_log_free_text ).
      " save log
      cl_bali_log_db=>get_instance( )->save_log( 
        log = go_log
        assign_to_current_appl_job = abap_true ).
    else.
      " foreground - simply add text to instace attribute, which can be fetched by caller program
      gs_fglog-no += 1.
      gs_fglog-text = i_text.
      append gs_fglog to gt_fglog.
    endif.
  endmethod.

That's is! Logic and coding part completed. But how can we now trigger this code to run in the background? Now we get into what we call Application Job Template.

2.3 Application Job Catalog Entry and Template

Creating the APJ class is a must, before we can create the actual Application Job Template. And the job template requires a Job Catalog Entry. All is again done in ADT. Via File - New - Other - and then search for "application job":

We start with Application Job Catalog Entry. Here we must now enter the ABAP class, which has the EXECUTE method. Now depending on if your are in public cloud or on-premise/private, the next screen will look quite a bit different. I'll showcase a screenshot of both for reference:

On-premise/private cloud - what you see when you double click the job catalog entry in ADT:
On-premise/private cloud - what you see when you right-click the job catalog entry in ADT and choose Open With - SAP GUI:
Public cloud:

For this demo, this is all we do here: we create the job catalog entry and give our ABAP class and we are done. At this point you would assign CDS value helps on parameters as shown in the public cloud screenshot, but as mentioned, this is not yet available before 2502.

The 2nd step is the Application Job Template, which then can be used in Fiori app Application Jobs. As before, in ADT choose New - File - Other and this time choose "Application Job Template". Here now we give the Application Job Catalog Entry we just created, and that's it. If you like, you can default parameter values here. This is only taken into account if you create a new "job" via Application Jobs Fiori app, where these parameters are then suggested as default, but can be changed. If we schedule the background run programmatically, no parameters are set by default.

With this we are now ready. We can already schedule a background job in Application Jobs Fiori app and we can code an action for our RAP BO.

All we've discussed so far, you may also refer to SAP Help: Application Jobs | SAP Help Portal and Working with Application Job Objects | SAP Help Portal.

3 Scheduling/running in background

3.1 Using Application Jobs Fiori app (to run immediately or schedule)

Let's start with the simpler option; scheduling our bookstore restocking to run in the background, via Application Jobs Fiori app. Maybe a new book has just come out and we know for the next five weeks we want to reorder that book once a week. Go to your Fiori Launchpad and make sure you have a role with access to the app. Open Application Jobs app. From the start screen, select Create button. A wizard opens and it always defaults the alphabetically first Application Job Template. Clear the field and open the search help and find the Application Job Template we created in step 2. This is mine:

Optionally, you can rename the current Job we are creating, such as weekly restock or something. Click on Step 2 to continue the wizard.

Here you can enter the recurring pattern, just like you would for se38 reports. Be sure to setup bigger jobs with heavy processing logic to run outside of office hours, as per usual practice. For now I picked "start immediately" to showcase that my application job template is running:

Continue by clicking Step 3. Here finally we enter the parameters and if you defined value helps for your parameters, this should be user friendly to use.

Lastly when ready, click on Schedule.

Now because I told my job to start immediately, I can see the result of the first background run:

Note the green checkmark button under Log, meaning we do have an application log for this job. Let's click on it:

And lo and behold, our log exactly as we coded it, linked to our just scheduled application job.

3.2 Running background job from our own custom, RAP based, Fiori app

Now that the application job template is ready, we can also schedule a background job from a Fiori app. I will be using my RAP BO as explained in step 1. Now just as a little information, this is how my Fiori app looks like for ZR_BookstoreStockTP:

We can clearly see our stock values, now let's add a button to run the restocking in background.

3.2.1 Abstract CDS entity for action parameters

I create a super simple abstract entity, containing all parameters I need to run the background job:

@EndUserText.label: 'Abstract entity to reorder books'
define root abstract entity ZD_Reorder_Books
{
    .defaultValue : '10'
    @EndUserText.label: 'Quantity to order'
    ReorderQty : zbooks_in_stock;
}

Secondly, I have a behavior for the same abstract entity, to ensure mandatory parameters:

abstract;
define behavior for ZD_Reorder_Books //alias <alias_name>
{
  field ( mandatory ) ReorderQty;
}

3.2.2 Action in behavior definition

Next we add the action to our RAP BO behavior (I'm only copying the action line here, not the whole behavior):

action (lock:none) reorderBooks parameter ZD_Reorder_Books;

Few comments: the (lock:none) is needed as I will run this action for all selected instances at once, instead of per instance (I explain that further on the UI annotation part 3.2.3). Otherwise, quite straightforward action with input parameter.

3.2.3 UI annotation to display action button (and control how it calls the RAP framework)

Complicated title, small thing. First of, my action is an instance action (because I did not define it as a static action in the behavior definition) and it's also not a factory action, so it requires that in the result list in Fiori, at least 1 instance is selected through the checkboxes, for the action to run. Now to display the button in the table header, we need to annotate it at the first table field:

  @ui: { 
    lineItem: [ 
      { position: 10, importance: #HIGH },
      { type: #FOR_ACTION, dataAction: 'addBook', label: 'Add Book to Bookstore' },
      { type: #FOR_ACTION, dataAction: 'reorderBooks', label: 'Reorder Books', invocationGrouping: #CHANGE_SET },
      { type: #FOR_ACTION, dataAction: 'setInventory', label: 'Adjust Store Inventory', inline: true } 
    ]
 }
  BookstoreId;

The 2nd #FOR_ACTION is our reorderBooks action we just added to the behavior definition. With this, a button with label "Reorder Books" will now be displayed on the table.

Secondly, I defined invocationGrouping: #CHANGE_SET. This means that when more than 1 instance is selected when the action button is pressed, that instead of calling the action once per instance, the action groups all instances into one single call. That is why I had to define the (lock:none) in the behavior definition, because otherwise all instances would be locked by the time the action runs. Meaning I need to take care of any potential locking (which is not needed in this case, as we will schedule a background job).

3.2.4 Action behavior implementation

The 2nd to last step is the coding of our action, of course in the behavior implementation class. Here is mine:

  method reorderbooks.
    data:
      lv_bookstore         type zbookstore_id,
      lv_stop              type abap_bool,
      ls_job_parameter     type cl_apj_rt_api=>ty_job_parameter_value,
      ls_book_job_param    type cl_apj_rt_api=>ty_job_parameter_value,
      ls_value_range       type cl_apj_rt_api=>ty_value_range.

    check keys is not initial.
    " reset global static job parameter table
    zbp_r_bookstorestocktp=>gt_job_parameters = value #( ).

    " go through all selected books (and bookstore)
    loop at keys into data(ls_key).
      if lv_bookstore is initial.
        " set bookstore (ONCE) --------------------------------
        lv_bookstore = ls_key-bookstoreid.
        ls_job_parameter-name = zcl_apj_test=>gc_para_store.
        ls_value_range-sign = 'I'.
        ls_value_range-option = 'EQ'.
        ls_value_range-low = lv_bookstore.
        append ls_value_range to ls_job_parameter-t_value.
        " add to global static table, used in save modified
        append ls_job_parameter to zbp_r_bookstorestocktp=>gt_job_parameters. 
        clear: ls_job_parameter, ls_value_range.

        " set reorder quantity (ONCE) -------------------------
        if ls_key-%param-reorderqty <= 0.
          lv_stop = abap_true.
          append value #( %tky = ls_key-%tky ) to failed-bookstorestock.
          append value #( %msg     = new_message_with_text(
               severity = ms-error
               text     = |Please set reorder quantity to 1 or higher| ) )
            to reported-bookstorestock.
        else.
          ls_job_parameter-name = zcl_apj_test=>gc_para_qty.
          ls_value_range-sign = 'I'.
          ls_value_range-option = 'EQ'.
          ls_value_range-low = conv #( ls_key-%param-reorderqty ).
          append ls_value_range to ls_job_parameter-t_value.
          " add to global static table, used in save modified
          append ls_job_parameter to zbp_r_bookstorestocktp=>gt_job_parameters.
          clear: ls_job_parameter, ls_value_range.
        endif.

      elseif lv_bookstore <> ls_key-bookstoreid.
        " make sure we have only 1 bookstore selected
        lv_stop = abap_true.
        append value #( %tky = ls_key-%tky ) to failed-bookstorestock.
        append value #( %msg     = new_message_with_text(
             severity = ms-error
             text     = |Please select books for only 1 bookstore| ) )
          to reported-bookstorestock.
        exit.
      endif.

      " set selected book
      check lv_stop = abap_false.
      ls_value_range-sign = 'I'.
      ls_value_range-option = 'EQ'.
      ls_value_range-low = ls_key-bookid.
      append ls_value_range to ls_book_job_param-t_value.
      clear ls_value_range.
    endloop.
    check lv_stop = abap_false.

    " set all books parameter (range table filled in above loop)
    ls_book_job_param-name = zcl_apj_test=>gc_para_book.
    " add to global static table, used in save modified
    append ls_book_job_param to zbp_r_bookstorestocktp=>gt_job_parameters. 

  endmethod.

Now if you read above code, you will notice it doesn't do much yet; it performs some checks (only one bookstore selected) and eventually fills an application job parameters table which is a global class static variable, and that's it. The reason is that when we schedule the background job via cl_apj_rt_api, unfortunately as of right now, this class eventually calls a DB INSERT. For those more familiar with RAP know that it's not allowed to have any commits or hard DB changes during action processing. So we cannot actually schedule the background job from the the action itself, we can only prepare it because at this points we have all the instances that were selected on the Fiori UI. So to schedule the job, we need one final step...

3.2.5 Schedule background job programmatically from RAP additional save

We need "additional save". This can be included in a behavior definition. We simply add "with additional save" at the beginning of the behavior definition:

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

define behavior for ZR_BookstoreStockTP alias BookstoreStock
with additional save

Using ADT quick fix, you can add the corresponding method and class to your implementation class:

class lsc_zr_bookstorestocktp definition inheriting from cl_abap_behavior_saver.

  protected section.
    methods save_modified redefinition.

endclass.

We get a new local class that instead inherits from cl_abap_behavior_saver and has method save_modified.

Now finally in this method, we can call our application job template to run in the background:

  method save_modified.

    data:
      lv_job_template_name type cl_apj_rt_api=>ty_template_name 
        value 'ZBOOK_APJ_TEMPL',
      ls_job_parameter     type cl_apj_rt_api=>ty_job_parameter_value,
      ls_value_range       type cl_apj_rt_api=>ty_value_range,
      ls_job_start_info    type cl_apj_rt_api=>ty_start_info,
      lv_job_name          type cl_apj_rt_api=>ty_jobname,
      lv_job_count         type cl_apj_rt_api=>ty_jobcount.

    check zbp_r_bookstorestocktp=>gt_job_parameters is not initial.

    " get booktsore id from job parameters
    ls_job_parameter-name = zcl_apj_test=>gc_para_store.
    read table zbp_r_bookstorestocktp=>gt_job_parameters from ls_job_parameter using key name
      into ls_job_parameter.
    check sy-subrc = 0.
    read table ls_job_parameter-t_value index 1 into ls_value_range.
    check sy-subrc = 0.

    " reorder background job ------------------------------------------------
    try.
        ls_job_start_info-start_immediately = abap_true.
        " schedule job
        cl_apj_rt_api=>schedule_job(
          exporting
            iv_job_template_name   = lv_job_template_name
            iv_job_text            = |Restocking bookstore { ls_value_range-low }|
            is_start_info          = ls_job_start_info
            it_job_parameter_value = zbp_r_bookstorestocktp=>gt_job_parameters " built during action implemention
          importing
            ev_jobname             = lv_job_name
            ev_jobcount            = lv_job_count ).

        " success message
        append value #( %msg = new_message_with_text(
             severity = ms-success
             text = |Reorder job scheduled (job name: { lv_job_name })| ) )
          to reported-bookstorestock.

      catch cx_apj_rt into data(lx_job_scheduling_error).
        append value #( %msg = new_message(
                             id = 'ZBOOKSTORE'
                             number   = 000
                             severity = ms-error
                             v1 = lx_job_scheduling_error->get_longtext(  )
                             v2 = lx_job_scheduling_error->bapimsg-message
                        ) )
          to reported-bookstorestock.

      catch cx_root into data(lx_root_exception).
        append value #( %msg = new_message(
                            id = 'ZBOOKSTORE'
                            number   = 001
                            severity = if_abap_behv_message=>severity-error
                            v1 = lx_root_exception->get_longtext(  )
                        ) )
          to reported-bookstorestock.
    endtry.

  endmethod.

Very simple code really. We need of course to refer to an Application Job Template, the one we created. We define the job starting info and lastly the parameters, which we already prepared in he action implementation.

And that's all. Now in my Fiori app I can select some instances and click on the button for Reorder and eventually a new background job is run, which I can also monitor in the Application Jobs Fiori app, including of course the log.

Conclusion

Any kind of background capability can be provided clean core compliant via Fiori (even if no foreground application at all is needed - we can do the recurring background scheduling in Application Jobs Fiori app, as shown in step 3.1), so let's get away from our old-school se38 reports and instead work with RAP and Application Job Templates. We can also make use of SAP standard RAP, such as creating PO or other.

And do keep in mind the switch to the newer APJ version with 2025 release!

Hope this helps and let me know if there are any open questions regarding this topic.

ABAP Cloud Landing Page in ABAP Development Tools (ADT)

2025-04-19T08:05:51.235000+02:00

I am an ABAP developer How can I learn about ABAP Cloud?

"Learn About ABAP Cloud Landing Page" in ADT is one way of learning. The ABAP Cloud Landing Page serves as a comprehensive gateway that caters to developers across all proficiency levels - from newcomers to seasoned ABAP experts.

This centralized platform offers a meticulously organized collection of SAP-validated, trusted, repository, resources, making it effortless to navigate through essential information. The page features distinct sections including "Get Started," "ABAP Cloud wizards for each Development Scenarios," documentation links, Roadmaps, What's New Information, available tutorials, ensuring a smooth learning journey.

How to navigate to Learn About ABAP Cloud Landing Page in ADT?
ADT (ABAP in Eclipse )->Select Project -> Help -> Learn About About ABAP Cloud

This page features several sections:

Get Started
News
Transactional Apps
Analytical Apps
Integration Services
More about cloud development Concepts.

1. Get Started - Learn More Section

When you click on "Learn more" it navigate to SAP help documentation where you get the most important information about ABAP Cloud in one page.

1.1. Get Started - Resources

The resource overview includes documentation which provides detailed technical information about ABAP, tutorials that guide users through specific tasks or processes, blog posts that offer insights and tips from experienced users and developers, and videos that visually explain and demonstrate ABAP concepts and programming techniques.

You will also find "Resources" in every section where corresponding blogs, how to guides, tutorials, events sessions are linked accordingly.

2. News - Roadmap

News Roadmap section gives about the ABAP Cloud roadmap, planned and upcoming features across all solutions that offer ABAP Cloud.

3. Transactional Apps - Open Generators

Generators help you to develop transactional applications with low code. Through wizard in ADT you can develop a transaction applications.

Learn More Section

Learn More section navigates to help documentation for how to develop transactional, analytical and Integration services in ABAP Cloud.

4. Analytical Apps

In this section you will find help documentation and resources related to how develop analytical apps in ABAP Cloud.

5. Integration Services - Open Generators

Click Open Generators -> Choose a Project from Project Select -> Click OK

Generators help you to develop Integration services with low code.

6 More Section

Localization and Internalization

This sections given information about how apps and services can be translated and adapted to country/region-specific requirements.

Access Management

This section gives a overview of the important points about identity and access management considerations for SAP S/4HANA Cloud, public edition and SAP BTP, ABAP environment.

Extensibility:

This section give information about extensibility options in ABAP Cloud such as:

Key User Extensibility
Developer Extensibility
Side-by-Side Extensibility
Difference between these extensibility options when to which extensibility.
Extensibility Tools for Key users and developers.

More ABAP Cloud Development

Test: This section gives overview of requirements and considerations during the test phase of application development in ABAP cloud.

Extend: This section gives information about how to extend existing services and apps, background information about the release contract framework and the ABAP language.

Deploy: This section gives information about how to deploy and transport your app or service with ABAP lifecycle management.

Administrator, Configure and Monitor: This section gives information about the requirements and tools involved with, for example, monitoring an app or service that you've developed, Analyzing SQL statements, Identify and Access Management, Communication Management, security and Transport Management in ABAP Cloud.

This centralized landing page in ADT offers a meticulously organized collection of SAP-validated, trusted, repository, resources, making it effortless to navigate through essential information at single page which caters to developers across all proficiency levels - from newcomers to seasoned ABAP experts.

ABAP Cloud Landing Page will be updated with new content by SAP every BTP, S/4HANA release. Then tiles, links, generators shown in this blogs, page would be updated accordingly with new releases. Update you ADT to latest version when a new update comes up to see new changes to this page.

RAP: Numbering | Early numbering | Late numbering | Managed numbering

2025-04-21T09:38:17.384000+02:00

Numbering

Road Map for Learning Numbering in RAP

Early numbering:

The numbering type early numbering refers to an early value assignment for the primary key field. In this case, the final key value is available in the transactional buffer instantly after the MODIFY request for CREATE.

1. External Early Numbering:

consumer provides key
Key should be unique
key should be editable in create, and non-editable in modify. syntax:

2. Managed Internal Early Numbering:

Managed early numbering is only possible for key fields with ABAP type raw (16) (UUID) of BOs with

implementation type managed.

UUID is read-only. syntax:

3. Unmanaged Internal Early Numbering:

Unmanaged Early Numbering is available in Managed and Unmanaged Implementation Scenarios with Draft Capabilities
Key is read-only. Syntax:

Bdef:

Local handler class:

Late numbering:

The RAP runtime engine assigns values to the primary key fields.
In the ABAP behaviour pool, the RAP saver method adjust_numbers must be implemented to assign a final primary key value for each entity instance.
The key value for an instance is assigned just before the instance is saved on the database. Thus, a gapless assignment of unique keys is ensured.
Late numbering is available for managed and unmanaged implementation scenarios with and without draft.

Note:

late numbering can't be external, since a consumer can't influence the SAVE sequence after the point of no return.
If draft enabled, it is mandatory that the RAP draft table has an additional key field DRAFTUUID of data type raw (16).

Summary:

passed externally by the application user: External numbering
set internally by the framework: Managed internal
set internally by developer (implementation the FOR-NUMBERING method): Unmanaged Internal

Augmentation Operation in RAP

2025-04-21T10:41:27.204000+02:00

Ever wondered how to set default values for the object page fields during Create Operation in Fiori using RAP at the projection level?

With an augmentation implementation you can add data or modify incoming requests on the projection layer before data reaches the transactional buffer. You can add data to a modify request or issue additional requests by augmenting the operation before the request is passed to the base business object.

Use case

• Defaulting for incoming requests. For example: Populate default values for fields of object page on create operation in Fiori

• Behavior-enabling denormalized fields, for example enabling editing of language dependent fields.

Definition

Augmentation is defined in the projection behavior definition on the relevant operation with the following syntax:

define behavior for Entity [alias AliasedName]
  ..
{
  use create (augment);
  use update (augment); 

  use association AssocName { create (augment); }
  ...
}

Below steps will result you how to populate default values for the object page fields on create operation especially at project layer. That means this default values population is specific to projection not for entire BO.

In your projection behavior ZC_TRAVEL_PROCESSOR_M_XX definition, define augmentation for the create operation.

use create (augment);

2. Add behavior implementation class to the project behavior.

…
define behavior for ZC_TRAVEL_PROCESSOR_M_XX alias Travel
implementation in class zcl_bp_c_travelm_xx
….

3. Click the activation button or use the shortcut Ctrl + F3 to activate the behavior definition.

4. The ADT Quick Fix feature can be used to create implementation class for travel entity.

For this, set the cursor on the class name, and press Ctrl+1 to star the Quick Fix dialog.

Click on create behavior implementation to create the class.

Click Next and Finish to create the class. In Local Types of Class you will see a augmentation operation method created where you need to implement logic to populate default values.

5.In the method implementation paste the below code.

METHOD augment_create.
  
   DATA: travel_create TYPE TABLE FOR CREATE zi_travel_m_xx.

    travel_create = CORRESPONDING #( entities ).
    LOOP AT travel_create ASSIGNING FIELD-SYMBOL(<travel>).
      <travel>-agency_id = '070012'.
      <travel>-status  = 'O'.
      <travel>-%control-agency_id = if_abap_behv=>mk-on.
      <travel>-%control-status = if_abap_behv=>mk-on.
    ENDLOOP.

    MODIFY AUGMENTING ENTITIES OF zi_travel_m_xx ENTITY Travel CREATE FROM travel_create.
  ENDMETHOD.

"MODIFY AUGMENTING ENTITIES" is a EML statement with which you can modify entities of base business object. In the above example "ZI_TRAVEL_M_XX" is the base business object and "ZC_TRAVEL_PROCESSOR_M_XX" is the project business object.

6. Save and Activate the Class.

7.Test the app now using preview tool. On Click of Create Agency ID and Status fields are defaulted.

Same behavior can be achieved with determination with draft as well. But what is the difference ?

Note: Only when draft is enabled in BO above feature can be achieved.

Function module in rap

2025-04-22T10:50:11.208000+02:00

Introduction

This blog provides a step-by-step guide on creating a Product Management App using RAP in an unmanaged scenario. It explains how to create a function group and a function module using ABAP in Eclipse and integrate them into the RAP framework to perform CRUD (Create, Read, Update, Delete) operations on product data. The app will allow users to manage product details, including fields such as Product ID, Product Name, Quantity, and Unit Price.

Procedure:

Created one database table 'ZDP_DT_UTCL_PDT

@EndUserText.label : 'utcl products' 
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE 
@AbapCatalog.tableCategory : #TRANSPARENT 
@AbapCatalog.deliveryClass : #A 
@AbapCatalog.dataMaintenance : #RESTRICTED 
define table zdp_dt_utcl_pdt { 
key product_id : zdp_de_pdt_id not null; 
product_name : zdp_de_product_name; 
product_qty : zdp_de_pdt_quantity; 
product_unit_price : zdp_de_unit_price_pdt; 
}

Now we need to create interface view on top of DB table.

@AbapCatalog.viewEnhancementCategory:[#NONE] 
@AccessControl.authorizationCheck:#NOT_REQUIRED 
@EndUserText.label:'utcl prdt interface view' 
@Metadata.ignorePropagatedAnnotations:true 
@ObjectModel.usageType:{ 
serviceQuality:#X, 
sizeCategory:#S, 
dataClass:#MIXED 
} 
definerootviewentityzdp_I_cds_utcl_prdt 
asselectfromZDP_DT_UTCL_PDT 
{ 
keyproduct_idasProductId, 
product_nameasProductName, 
product_qtyasProductQty, 
product_unit_priceasProductUnitPrice 
}

Now we need to create a projection view on top of Interface view.

@AccessControl.authorizationCheck: #NOT_REQUIRED 
@EndUserText.label: 'projection view on utcl prdt' 
@Metadata.ignorePropagatedAnnotations: true 
@Metadata.allowExtensions: true 
define root view entity zdp_P_cds_utcl_prdt  
provider contract transactional_query 
as projection on zdp_I_cds_utcl_prdt 
{ 
key ProductId, 
ProductName, 
ProductQty, 
ProductUnitPrice 
}

Now we need to create the behavior definition on top of interface view.

I selected the unmanaged scenario in the behavior definition because, in my case, the CRUD operations are performed using a function module. If I had chosen the managed scenario, the RAP framework would have handled the CRUD operations automatically, but since my logic is custom and implemented through a function module,

ABAP in Eclipse Create Function Group and Function Module.

Type func in the search box and select ABAP Function Group from the suggestions. Click Next. Give the package name, function group name and description.

type function and select Abap function module. Click Next. Provide Name, description and function group name. We get an empty function module.

In this function module, we need to code the import, exporting, changing or exceptions parameters as required.

Code of Behavior Definition of Interface:

unmanaged implementation in class zbp_dp_i_cds_utcl_prdt unique; 
strict ( 2 ); 
define behavior for zdp_I_cds_utcl_prdt alias utcl_prdt 
//late numbering 
lock master 
authorization master ( instance ) 
//etag master <field_name> 
{ 
create; 
update; 
delete; 
field ( readonly ) ProductId; 
mapping for Zdp_dt_utcl_pdt control zdp_s_prdt_c 
{ 
ProductId = product_id; 
ProductName = product_name; 
ProductQty = product_qty; 
ProductUnitPrice = product_unit_price; 
} 
}

Now create a behavior definition on top of consumption view:

Code of Behavior Definition of Projection:

projection; 
strict ( 2 );  
define behavior for zdp_P_cds_utcl_prdt alias utcl_prdt 
{ 
use create; 
use update; 
use delete; 
}

Behavior implementation.

CLASS lhc_zdp_I_cds_utcl_prdt DEFINITION INHERITING FROM cl_abap_behavior_handler. 

PRIVATE SECTION. 
METHODS get_instance_authorizations FOR INSTANCE AUTHORIZATION 

IMPORTING keys REQUEST requested_authorizations FOR zdp_I_cds_utcl_prdt RESULT result. 

METHODS create FOR MODIFY 
IMPORTING entities FOR CREATE utcl_prdt. 

METHODS update FOR MODIFY 
IMPORTING entities FOR UPDATE zdp_I_cds_utcl_prdt. 

 

METHODS delete FOR MODIFY 
IMPORTING keys FOR DELETE zdp_I_cds_utcl_prdt. 

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

METHODS lock FOR LOCK 
IMPORTING keys FOR LOCK zdp_I_cds_utcl_prdt. 

TYPES: tt_failed TYPE TABLE FOR FAILED EARLY zdp_I_cds_utcl_prdt\\utcl_prdt, 

tt_reported TYPE TABLE FOR REPORTED EARLY zdp_I_cds_utcl_prdt\\utcl_prdt. 
TYPES tt_prdt_failed TYPE TABLE FOR FAILED zdp_I_cds_utcl_prdt. 
TYPES tt_prdt_reported TYPE TABLE FOR REPORTED zdp_I_cds_utcl_prdt. 
TYPES : tt_read TYPE TABLE FOR READ RESULT zdp_I_cds_utcl_prdt\\utcl_prdt. 
DATA : gs_prdt TYPE zdp_dt_utcl_pdt, 
gt_prdt TYPE TABLE OF zdp_dt_utcl_pdt. 
CLASS-DATA : gt_tab TYPE zdp_dt_utcl_pdt. 
METHODS map_messages 
IMPORTING 
cid TYPE abp_behv_cid OPTIONAL 
product_id TYPE zdp_de_pdt_id OPTIONAL 
messages TYPE char5 
EXPORTING 
failed_added TYPE abap_boolean 
CHANGING 
failed TYPE tt_failed 
reported TYPE tt_reported. 
ENDCLASS. 
CLASS lhc_zdp_I_cds_utcl_prdt IMPLEMENTATION. 
METHOD get_instance_authorizations. 
ENDMETHOD. 

METHOD create. 
DATA lv_msg TYPE char5. 
DATA : ls_tab1 TYPE zdp_dt_utcl_pdt. 
LOOP AT entities INTO DATA(ls_e). 
ls_tab1 = CORRESPONDING #( ls_e MAPPING FROM ENTITY USING CONTROL ). 
* LS_TAB1 = CORRESPONDING #( LT_PRODUCT[ 1 ] ). 
CALL FUNCTION 'ZDP_FM_PRDT_CREATE' 
EXPORTING 
ls_tab = ls_tab1 
IMPORTING 
msg = lv_msg. 
me->map_messages( 
EXPORTING 
cid = ls_e-%cid 
product_id = ls_tab1-product_id 
messages = lv_msg 
* IMPORTING 
* failed_added = 
CHANGING 
failed = failed-utcl_prdt 
reported = reported-utcl_prdt 
). 
ENDLOOP. 
ENDMETHOD. 

METHOD update. 
DATA : ls_update TYPE zdp_dt_utcl_pdt, 
ls_c TYPE zdp_s_prdt_c, 
lv_msg TYPE char20. 
LOOP AT entities ASSIGNING FIELD-SYMBOL(<fs_u>). 
ls_update = CORRESPONDING #( <fs_u> MAPPING FROM ENTITY ). 
ls_c = CORRESPONDING #( <fs_u> MAPPING FROM ENTITY ). 
CALL FUNCTION 'ZDP_FM_PRDT_UPDATE' 
EXPORTING 
ls_prd = ls_update 
ls_ctr = ls_c 
IMPORTING 
ls_prd_n = gs_prdt 
msg = lv_msg.  
* ENDLOOP. 
ENDMETHOD. 

METHOD delete. 
DATA(lv_id) = keys[ 1 ]-ProductId. 
CALL FUNCTION 'ZDP_FM_PRDT_DELETE' 
EXPORTING 
lv_prd_id = lv_id. 
ENDMETHOD. 
METHOD read. 
LOOP AT keys ASSIGNING FIELD-SYMBOL(<fs_e>) GROUP BY <fs_e>-%key. 
CALL FUNCTION 'ZDP_FM_PRDT_READ1' 
EXPORTING 
lv_pid = <fs_e>-ProductId 
IMPORTING 
lt_tab = gs_prdt. 
INSERT CORRESPONDING #( gs_prdt MAPPING TO ENTITY ) INTO TABLE result. 
ENDLOOP. 
ENDMETHOD. 
METHOD lock. 
ENDMETHOD. 
METHOD map_messages. 
IF messages IS NOT INITIAL. 
reported = VALUE #( ( %cid = cid 
ProductId = product_id 
%msg = new_message( 
id = 'Zdp_message_class' 
number = '001' 
severity = if_abap_behv_message=>severity-error 
v1 = product_id 
) ) ). 
ENDIF. 
ENDMETHOD. 
ENDCLASS. 
CLASS lsc_ZDP_I_CDS_UTCL_PRDT DEFINITION INHERITING FROM cl_abap_behavior_saver. 
PROTECTED SECTION. 
METHODS finalize REDEFINITION. 
METHODS check_before_save REDEFINITION. 
METHODS save REDEFINITION. 
METHODS cleanup REDEFINITION. 
METHODS cleanup_finalize REDEFINITION. 
ENDCLASS. 
CLASS lsc_ZDP_I_CDS_UTCL_PRDT IMPLEMENTATION. 
METHOD finalize. 
ENDMETHOD. 
METHOD check_before_save. 
ENDMETHOD. 
METHOD save. 
CALL FUNCTION 'ZDP_FM_SAVE_1'. 
ENDMETHOD. 
METHOD cleanup. 
ENDMETHOD. 
METHOD cleanup_finalize. 
ENDMETHOD. 
ENDCLASS.

create operation.

METHOD create. 

DATA lv_msg TYPE char5. 
DATA : ls_tab1 TYPE zdp_dt_utcl_pdt. 
LOOP AT entities INTO DATA(ls_e). 
ls_tab1 = CORRESPONDING #( ls_e MAPPING FROM ENTITY USING CONTROL ). 
* LS_TAB1 = CORRESPONDING #( LT_PRODUCT[ 1 ] ). 
CALL FUNCTION 'ZDP_FM_PRDT_CREATE' 
EXPORTING 
ls_tab = ls_tab1 
IMPORTING 
msg = lv_msg. 
me->map_messages( 
EXPORTING 
cid = ls_e-%cid 
product_id = ls_tab1-product_id 
messages = lv_msg 
CHANGING
failed = failed-utcl_prdt 
reported = reported-utcl_prdt ). 
ENDLOOP. 
ENDMETHOD.

Function module product create.

FUNCTION zdp_fm_prdt_create 
IMPORTING 
ls_tab TYPE zdp_dt_utcl_pdt 
EXPORTING 
msg TYPE char5. 

DATA(ls_tab1) = lS_tab. 
SELECT MAX( product_id ) FROM zdp_dt_utcl_pdt 
INTO (lv_pid). 

IF sy-subrc EQ 0. 
lv_pid += 1. 
zcl_dp_utcl_prdt_um_helper=>gt_tab = ls_tab1. 
ENDIF. 
ENDFUNCTION.

Here gt_tab is a global internal table which I have created in global class.

Update operation logic.

METHOD update.  
DATA : ls_update TYPE zdp_dt_utcl_pdt, 
ls_c TYPE zdp_s_prdt_c, 
lv_msg TYPE char20. 
LOOP AT entities ASSIGNING FIELD-SYMBOL(<fs_u>). 
  ls_update = CORRESPONDING #( <fs_u> MAPPING FROM ENTITY ). 
  ls_c = CORRESPONDING #( <fs_u> MAPPING FROM ENTITY ). 
CALL FUNCTION 'ZDP_FM_PRDT_UPDATE' 
EXPORTING 
   ls_prd = ls_update 
   ls_ctr = ls_c 
IMPORTING 
   ls_prd_n = gs_prdt 
   msg = lv_msg. 
ENDLOOP. 
ENDMETHOD.

Update function module logic.

FUNCTION zdp_fm_prdt_update 
IMPORTING 
ls_prd TYPE zdp_dt_utcl_pdt 
ls_ctr TYPE zdp_s_prdt_c 
EXPORTING 
ls_prd_n TYPE zdp_dt_utcl_pdt 
msg TYPE char20. 
SELECT SINGLE FROM zdp_dt_utcl_pdt 
FIELDS * WHERE product_id = _prd-product_id INTO (ls_p_old). 

ls_prd_n-product_id = ls_prd-product_id.
ls_prd_n-product_name = COND #( WHEN ls_ctr-product_name IS NOT INITIAL 
      THEN ls_prd-product_name 
      ELSE ls_p_old-product_name 
). 
ls_prd_n-product_qty = COND #( WHEN ls_ctr-product_qty IS NOT INITIAL 
     THEN ls_prd-product_qty 
     ELSE ls_p_old-product_qty 
). 
ls_prd_n-product_unit_price = COND #( WHEN ls_ctr-product_unit_price IS NOT INITIAL 
   THEN ls_prd-product_unit_price 
   ELSE ls_p_old-product_unit_price 
). 
IF ls_prd_n IS NOT INITIAL. 
zcl_dp_utcl_prdt_um_helper=>gs_tab_u = ls_prd_n. 
msg = 'Sucessfully Updated'. 
ENDIF. 
ENDFUNCTION.

Delete operation logic.

METHOD delete. 
DATA(lv_id) = keys[ 1 ]-ProductId.
CALL FUNCTION 'ZDP_FM_PRDT_DELETE' 
EXPORTING 
  lv_prd_id = lv_id. 
ENDMETHOD.

Delete function module logic.

FUNCTION zdp_fm_prdt_delete 
IMPORTING 
lv_prd_id TYPE zdp_de_pdt_id. 
   zcl_dp_utcl_prdt_um_helper=>prt_id = lv_prd_id. 
ENDFUNCTION.

Read operation logic.

METHOD read. 
LOOP AT keys ASSIGNING FIELD-SYMBOL(<fs_e>) GROUP BY <fs_e>-%key. 
CALL FUNCTION 'ZDP_FM_PRDT_READ1' 
EXPORTING 
lv_pid = <fs_e>-ProductId 
IMPORTING 
lt_tab = gs_prdt. 
INSERT CORRESPONDING #( gs_prdt MAPPING TO ENTITY ) INTO TABLE result. 
ENDLOOP. 
ENDMETHOD.

Read function module logic.

FUNCTION zdp_fm_prdt_read1 
IMPORTING 
  lv_pid TYPE zdp_de_product_id 
EXPORTING 
  lt_tab TYPE zdp_dt_utcl_pdt. 
SELECT SINGLE FROM zdp_dt_utcl_pdt FIELDS product_id, product_name,product_qty, product_unit_price 
WHERE product_id = _pid 
INTO _tab.
ENDFUNCTION.

save operation logic.

METHOD save. 
  CALL FUNCTION 'ZDP_FM_SAVE_1'. 
ENDMETHOD.

Save function module logic.

FUNCTION zdp_fm_save_1.
IF zcl_dp_utcl_prdt_um_helper=>gt_tab IS NOT INITIAL. 
  INSERT zdp_dt_utcl_pdt FROM @zcl_dp_utcl_prdt_um_helper=>gt_tab. 
ENDIF. 
if zcl_dp_utcl_prdt_um_helper=>gs_tab_u is NOT INITIAL. 
 UPDATE zdp_dt_utcl_pdt FROM @zcl_dp_utcl_prdt_um_helper=>gs_tab_u. 
ENDIF. 
if zcl_dp_utcl_prdt_um_helper=>prt_id is not initial. 
 DELETE FROM zdp_dt_utcl_pdt 
 WHERE product_id = @zcl_dp_utcl_prdt_um_helper=>prt_id. 
ENDIF. 
ENDFUNCTION.

Output:

Go to front-end

Here I will create one new record:

Delete product

Here we are delete super cement

Update gold cement product quantity.

Value Help with Additional Binding in RAP

2025-04-22T10:50:52.084000+02:00

Value Help with Additional Binding in RAP – Filtering Storage Locations by Plant in Material Stock Management

Introduction:

In this blog, I will demonstrate how to implement Value Help with Additional Binding in a RAP (RESTful ABAP Programming) application for the MM module. The scenario involves managing Material Stock Information by providing value help for Plant (WERKS) and Storage Location (LGORT). The key feature is filtering the storage location list dynamically based on the selected plant, enhancing the user experience.

When the user selects a Plant, the system automatically filters the Storage Location (LGORT) list to show only the storage locations related to the selected plant.

The requirement is to build a Fiori-based RAP application that enables users to:

Select a Plant from the dropdown.

Dynamically filter the Storage Locations based on the selected Plant.

Display and manage material stock details such as material number, plant, storage location, stock quantity, and unit of measure.

Procedure:

Key Tables Involved

1. I have created three custom tables, where Storage and plant table have records:

zvs_dt_storage_l → Storage Locations table with data

@EndUserText.label : 'Table for storage location'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table zvs_dt_storage_l {
  key client : abap.clnt not null;
  key lgort  : lgort_d not null;
  key lgobe  : abap.char(16) not null;
  werks      : werks_d;
}

Table Data:

zvs_dt_plant_dt → Plant Data

@EndUserText.label : 'Table for plant data'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table zvs_dt_plant_dt {
  key client : abap.clnt not null;
  key werks  : werks_d not null;
  name1      : abap.char(30);
}

Table Data:

zvs_dt_mat_stock → Material Stock Data

@EndUserText.label : 'table to store the material stock data.'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table zvs_dt_mat_stock {
  key client : abap.clnt not null;
  key matnr  : matnr not null;
  werks      : werks_d;
  lgort      : lgort_d;
  @Semantics.quantity.unitOfMeasure : 'zvs_dt_mat_stock.meins'
  labst      : abap.quan(13,3);
  meins      : meins;
}

2.1 Now create one interface view ‘ZVS_I_PLANT_DT’ on top of DB table 'ZVS_DT_PLANT_DT': -

This view provides the value help for Plant (WERKS).

I have used the annotation "@ObjectModel.resultSet.sizeCategory: #XS” which makes the value help appear as a dropdown.

@AbapCatalog.sqlViewName: 'ZVS_PLANT_DT'
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: true
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'interface view for plant data'
@Metadata.ignorePropagatedAnnotations: true
@ObjectModel.resultSet.sizeCategory: #XS
define view zvs_i_plant_dt as select from zvs_dt_plant_dt
{
    key werks as Werks,
    name1 as Name1
}

2.2 Now create interface view ‘ZVS_I_STORAGE_LC’ on top of DB table 'ZVS_DT_STORAGE_L': -

This view filters Storage Locations by Plant using additional binding.

This view selects Storage Location, Description, and Plant.

The Plant field acts as the filter when the user selects a Plant.

@AbapCatalog.sqlViewName: 'ZVS_STORAGE_LC'
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: true
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'interface view for storage location'
@Metadata.ignorePropagatedAnnotations: true
define view zvs_i_storage_lc as select from zvs_dt_storage_l
{
    key lgort as StorageLocation,
    lgobe as StorageLocDesc,
    werks as Plant
}

2.3 Now create interface view ‘ZVS_I_MAT_STOCK’ on top of DB table 'ZVS_DT_MAT_STOCK': -

An Interface View (zvs_i_mat_stock) for fetching material stock data with associations to plant and storage location details.

This view maps to the custom table zvs_dt_mat_stock.

It includes fields for Material Number, Plant, Storage Location, Stock Quantity, and Unit of Measure

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'interface view for material stock'
@Metadata.ignorePropagatedAnnotations: true

define root view entity zvs_i_mat_stock as select from zvs_dt_mat_stock
association[0..*] to zvs_i_plant_dt  as _plant on $projection.Werks = _plant.Werks
association[0..*] to zvs_i_storage_lc as _storage on $projection.Lgort = _storage.StorageLocation
{
    key matnr as Matnr,
    werks as Werks,
    lgort as Lgort,
    @Semantics.quantity.unitOfMeasure: 'meins'
    labst as Labst,
    meins as Meins,
    _plant,
    _storage.StorageLocDesc // Expose description from Storage association
}

3. Now create one consumption view ‘ZVS_C_MAT_STOCK’ on top of Interface view 'ZVS_I_MAT_STOCK': -

The consumption view zvs_c_mat_stock projects the data from the interface view zvs_i_mat_stock. This view is intended to expose the data for transactional operations, such as create, update, and delete. The consumption view allows clients to interact with the data, but the actual persistence and behavior are managed through the behavior definition.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'consumption view for material stock'
@Metadata.ignorePropagatedAnnotations: true
@Metadata.allowExtensions: true
@ObjectModel.usageType:{
    serviceQuality: #X,
    sizeCategory: #S,
    dataClass: #MIXED
}
define root view entity zvs_c_mat_stock provider contract transactional_query 
as projection on zvs_i_mat_stock
{
    key Matnr,
    Werks,
    Lgort,
    @Semantics.quantity.unitOfMeasure: 'meins'
    Labst,
    Meins,
    /* Associations */
    _plant,
    StorageLocDesc
}

4. Define Metadata Extension

Add Value Help with Additional Binding to your RAP Business Object.

Here:

This “@Consumption.valueHelpDefinition: [{ entity : { element: 'Werks' , name: 'zvs_i_plant_dt' } }]” Annotation to get the dropdown for WERKS(Plant) Field.

This “@Consumption.valueHelpDefinition: [{ entity : { element: 'StorageLocation' , name: 'zvs_i_storage_lc' }, additionalBinding: [{ element: 'Plant' ,localElement: 'Werks' }] }]” Annotation here, for additional binding. So based on selected plant it will dynamically filter the storage location.

The @Consumption.valueHelpDefinition annotation is used to define value help (similar to F4 help in SAP GUI) for a field. It allows you to provide dropdown-style suggestions or search help for users when they enter data into specific fields.

entity:
1. Specifies the data source for the value help.
2. element: 'StorageLocation': The field in the current CDS view where the value help is applied.
3. name: 'zvs_i_storage_lc': The CDS view providing the value help data.

additionalBinding:
1. Defines additional filtering criteria.
2. element: 'Plant': The field in the value help entity used for filtering.
3. localElement: 'Werks': The field in the current view that is used as the filtering key.

Metadata Extension Code for your reference:

@Metadata.layer: #CORE
annotate entity zvs_c_mat_stock with
{
  .facet: [{
     id: 'MaterialStock',
     purpose: #STANDARD,
     type: #IDENTIFICATION_REFERENCE,
     label: 'Material ID',
     position: 10
   }]

  : { lineItem: [{ position: 10, label: 'Material no.' }],
         identification: [{ position: 10, label: 'Material no.' }] }
  Matnr;

  : { lineItem: [{ position: 20, label: 'Plant' }],
     identification: [{ position: 20, label: 'Plant' }] }
  @Consumption.valueHelpDefinition: [{ entity : { element: 'Werks' , name: 'zvs_i_plant_dt' } }]
  Werks;

  : { lineItem: [{ position: 30, label: 'Storage location' }],
       identification: [{ position: 30, label: 'Storage location' }] }
  @Consumption.valueHelpDefinition: [{ entity : { element: 'StorageLocation' , name: 'zvs_i_storage_lc'  }
  ,additionalBinding: [{ element: 'Plant' ,localElement: 'Werks' }]
  }]
  Lgort;

  : { lineItem: [{ position: 40, label: 'Stock quantity' }],
       identification: [{ position: 40, label: 'Stock quantity' }] }
  Labst;

  : { lineItem: [{ position: 60, label: 'Storage location Description' }],
       identification: [{ position: 60, label: 'Storage location Description' }] }
  StorageLocDesc;
}

5. Define Behavior Definition

The labst (Stock Quantity) and meins (Unit of Measure) fields are read-only.
The behavior definition supports CRUD operations.

Now create a behavior definition on top of interface view 'ZVS_I_MAT_STOCK':

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

define behavior for zvs_i_mat_stock //alias <alias_name>
persistent table zvs_dt_mat_stock
lock master
authorization master ( instance )
//etag master <field_name>
early numbering
{
  create;
  update;
  delete;
  field ( readonly ) Matnr, StorageLocDesc;

  mapping for zvs_dt_mat_stock{
    Matnr = matnr;
    Werks = werks;
    Lgort = lgort;
    Labst = labst;
    Meins = meins;
  }
}

Now create a behavior definition on top of consumption view 'ZVS_C_MAT_STOCK':

projection;
strict ( 2 );

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

Go to front-end:

Here I will create one new record:

You can see here, all the storage location are coming if we didn’t provide plant:

So we'll select plant 1000 from dropdown:

You can see here storage location got filtered based on the selected plant:

If I select plant 1400, so based on that we are getting 0006 storage location:

After saving record you can see the result:

Conclusion:

This blog showed how to create a RAP-based Fiori app with value help that filters storage locations based on the selected plant. Using CDS views, associations, and annotations, the app becomes user-friendly, efficient, and easy to maintain.

Adobe Form/Smartform with RAP-Based OData Service Without SEGW

2025-04-22T18:43:19.937000+02:00

Hello, everyone!

This is my first blog, and I’m excited to share my experience while working with RAP-based OData services. As a learner diving into the RAP world, I struggled to find a method to directly display forms in RAP applications .During my exploration, I discovered a workaround to render Adobe forms using a RAP-based OData service—without relying on SEGW-generated services.

Here’s the code that I used:

 " Create object reference for HTTP response
    DATA: lo_cached_response TYPE REF TO if_http_response.

    " Set the output parameters for the Adobe form
    ls_outputparams = VALUE #( getpdf = 'X' nodialog = 'X' ).

    CALL FUNCTION 'FP_JOB_OPEN'
      CHANGING
        ie_outputparams = ls_outputparams.

    " Get the name of the generated function module for the Adobe form
    CALL FUNCTION 'FP_FUNCTION_MODULE_NAME'
      EXPORTING
        i_name     = 'YUS_DEMO' "Your Adobe Form 
      IMPORTING
        e_funcname = lv_fmname.

    IF sy-subrc = 0.
      " Call the generated function module to render the Adobe form
      CALL FUNCTION lv_fmname
        EXPORTING
          /1bcdwb/docparams  = ls_docparams
          t_bar              = lt_adobe_bar
          i_preview          = abap_true
        IMPORTING
          /1bcdwb/formoutput = ls_form_output
        EXCEPTIONS
          usage_error        = 1
          system_error       = 2
          internal_error     = 3.


      " Close the spool job for the Adobe form
      CALL FUNCTION 'FP_JOB_CLOSE'.
    ENDIF.

    " Create an HTTP response object for hosting the PDF
    CREATE OBJECT lo_cached_response
      TYPE cl_http_response
      EXPORTING
        add_c_msg = 1.

    " Generate a unique GUID for the PDF file
    CALL FUNCTION 'GUID_CREATE'
      IMPORTING
        ev_guid_32 = lv_guid.

    " Set the PDF data in the HTTP response
    lo_cached_response->set_data(
      data   = ls_form_output-pdf
      length = xstrlen( ls_form_output-pdf ) ).

    " Set the content type to PDF
    lv_app_type = 'application/pdf'.
    lo_cached_response->set_header_field(
      name  = if_http_header_fields=>content_type
      value = lv_app_type ).

    " Set the content disposition to inline with the generated filename
    lo_cached_response->set_header_field(
      name  = if_http_header_fields=>content_disposition
      value = |inline; filename="{ lv_guid }.pdf"| ).

    " Allow cross-origin requests
    lo_cached_response->set_header_field(
      name  = 'Access-Control-Allow-Origin'
      value = '*' ).

    " Set the HTTP response status

    lo_cached_response->set_status( code = 200 reason = 'OK' ).

    " Set the cache timeout for the response
    lo_cached_response->server_cache_expire_rel( expires_rel = 120 ).

    " Construct the base URL for the OData service
    CALL METHOD cl_wd_utilities=>construct_wd_url
      EXPORTING
        application_name = 'YUS_SR_DEMO_MAS_V2' "Your RAP Based Odata Service
      IMPORTING
        out_host         = lv_host
        out_port         = lv_port
        out_protocol     = lv_protocol.

    " Build the full URL for accessing the Adobe PDF 
    lv_link = |http://{ lv_host }:{ lv_port }|.
    lv_url = |{ lv_link }/sap/opu/odata/sap/YUS_SR_DEMO_MAS_V2/{ lv_guid }.PDF|.

    " Cache the constructed URL with the HTTP response object
    cl_http_server=>server_cache_upload(
      url      = lv_url
      scope    = 1
      response = lo_cached_response ).

    CONCATENATE   '/opu/odata/sap/YUS_SR_DEMO_MAS_V2/' lv_guid '.' 'PDF' INTO e_url.

How Does It Work? This method dynamically generates a PDF URL for the Adobe form and hosts it using an HTTP response object. The RAP-based OData service YUS_SR_DEMO_MAS_V2 is used here. You can replace this service with any RAP-based OData service you are using in your application.

Furthermore, once you have the URL of the PDF, you can integrate it into your UI5 application. Here's how you can do it:

Use this code in your custom entity cds, virtual element or RAP action to get the URL.
In your UI5 app, show the PDF in an iframe.

Here’s how you can configure your data source in the manifest file:

"DEMO_DEV": {
    "uri": "sap",
    "type": "OData",
    "settings": {
        "annotations": [],
        "odataVersion": "2.0"
    }
}

In the controller, resolve the destination URL and combine it with the PDF URL like this:

var sDestination = that.getOwnerComponent().getManifestObject().resolveUri(that.getOwnerComponent().getManifestEntry("sap.app").dataSources.DEMO_DEV.uri); //DEMO_DEV is a datasource in manifest

var sPdfUrl = sDestination + oData.preview.Url.toString(); //PDF Url

This approach allows you to seamlessly display the Adobe form PDF in your UI5 application using an iframe.

We can do the same with Smartforms as well. This method can also be adapted to render Smartforms in a similar manner.

Feedback and Best Practices While this method achieves the goal, I am unsure if it fully aligns with SAP’s best practices. If you have suggestions or alternative approaches for displaying forms directly in RAP applications, please share them. Your feedback would be immensely helpful!

Conclusion In this approach, we are hosting the Adobe form on our RAP-based OData service. Additionally, this workaround makes it easy to integrate the PDF into your UI5/RAP application. The same method works for Smartforms as well, offering a consistent and effective solution for both technologies.

Thank you for reading my first blog!

ABAP RESTful Application Programming Model

SAP Interactive Forms by Adobe

Filtering of RAP Business Events in SAP BTP ABAP Environment and in SAP Advanced Event Mesh

2025-04-23T13:18:38.307000+02:00

In this blog post, I show you how you can do source side filtering of events in SAP BTP ABAP environment, what Dynamic Topics are and how we can use them for routing and filtering of events in SAP Integration Suite Advanced Event Mesh.
Here, I represent two different ways of filtering of RAP business events in SAP BTP ABAP environment. On the left-hand side, you can see the SAP BTP ABAP environment system that produces some RAP business events. These events are then sent as CloudEvents to the right-hand side, to the Advanced Event Mesh instance.

In the first part, we discuss Source Side Filtering of events which is available from release 2402 in SAP S/4HANA Cloud and SAP BTP ABAP environment and in SAP S/4HANA and SAP S/4HANA Cloud Private Edition since release 2023 SP00. For a RAP business event, then you can define filterable properties from the actual payload of that event. This means, if there's a field called for example “country code”, you can make it filterable by exposing it as CloudEvents context attribute. Then you can define filter conditions as well, like the country code must match the amount US or DE. If this filter condition is not met, then the event is not sent out of the system. If you want to prevent some events to go out due to the data privacy protection issues or reduce traffic due to unnecessary events, then you can use event filtering.

In the second part, we discuss Dynamic Topic Filtering and routing of events with the integration with the Advanced Event Mesh. As a further remark, this feature is available from release 2408 in SAP S/4HANA Cloud Public Edition and SAP BTP ABAP environment and in SAP S/4HANA and SAP S/4HANA Cloud Private Edition since release 2023 SP02.

Source side filtering of RAP business events

Assume you are in your BTP ABAP environment system, and you have a RAP business event. This RAP business event has a corresponding abstract entity where you define your actual payload. Let's say you have a payload that contains a field “country code”:

This is a payload of a RAP business event without predefined filters. In the data part, the country code has the value DE and in the upper part you can see the header fields of the CloudEvent.
You want to know how you can make this property filterable? quite easy! As you define the event, you need to add the annotation “@Event.context.attribute” before the field you want to use as a filter and then give it a name like “xsapcountrycode” for example:

.context. attribute:'xsapcountrycode'
  CountryCode: abap.char(2);

Then, during the runtime, the country code value “DE” is exposed inside the CloudEvent Context as an additional attribute with the name you have defined as the value of the annotation explained above:

With that the payload field ‘CountryCode’ becomes a new filter attribute. the source side filtering is available for every event infrastructure that we currently support. However, there are some restrictions which must be considered, for example not all properties are allowed for exposing in header, e.g., amount fields or cf. annotation, more information can be found in Maintain Filters for Outbound Event Topics | SAP Help Portal Event Annotations | SAP Help Portal. This SAP Note describes in more detail what must be considered when creating filters and which restrictions apply.

The next step would be going to filter configuration UI and there you can select all the filterable fields like xsapcountrycode and define filter conditions like ‘eq ‘DE’ ’. You can also define filters containing multiple fields and add additional filter conditions for those fields.

Let’s look at the runtime, for example if you have an event with country code “DE”, this would be published because it would match the filter condition we already defined. Whereas if you have an event with country code “US”, this does not match the filter condition and would therefore be filtered out. This means if you want to prevent events from going out, for example due to data privacy protection or any other reason, then you can define corresponding filter conditions.

Define source side filters in your application

I already build a very simple application, an online shop as it is described in this tutorial. I added the field country code as well to use it later as a filter, so when I create a new item, I can assign a country code for the country I want to ship the item to.

Now, we want to make sure that only events created for items that are shipped to “DE” are also published to the event exchange infrastructure. I create the event that should be raised whenever an item is created and the parameter or the fields that should be in this event are defined in this abstract entity and it looks like this:

@EndUserText.label: 'Event parameter'
define abstract entity ZD_ItemOrdered_0000 {
    ItemName : abap.char(25);
@Event.context. attribute:'xsapcountrycode'
  CountryCode: abap.char(2);
}

To make this event filterable, I just add this simple annotation “@Event.context.attribute” and I call it xsapcountrycode. when I activate this entity, for all events that are raised in this system, the field “CountryCode” is propagated into the Cloud Event context and contains the values that is in the payload. As a next step, we must define the filter criteria for the given event channel as well.

After creating your communication arrangement, go to “Configure Channel Binding” application to configure the related channel and add your outbound topic which is created during event binding creation as is explained in the tutorial. As you see, there is no event filters defined yet. Keep in mind that you can only add filters to the existing outbound bindings.

You can see here we have an outbound topic which is the event from the application. Now I want to define the filter. You can create filters on each topic individually by clicking on it. Then in event filter tab, click on ‘Create’ and choose the filter property. By clicking on “Create” the filter will be generated successfully. All defined filters are displayed under Event Filter Expression.

We can head back to the channel and see that there is event filters configured:

Now let’s try to see if the filter works properly. For that, we will use our event monitor application which is a tool where you can monitor the status of your in/outbound events. First, you can see there are no events on this channel, we want to change that now.

I go into my Fiori application and press “Create” to create an order, a laptop for example, and I want to send that to Germany (DE). If you remember, this will match our filter criteria and therefore it would be sent out. An event can be monitored as expected, in the launchpad open the application “Enterprise Event Enablement-Event Monitor”, you can see an event reach your channel:

If we look at the payload, we see the country code “DE” in the header as well

Now to check if this filter works, I want to create another object in here, let's say I want to ship a tablet to Spain. I create this order and head back to our Event Monitor application. You can see the number of events hasn't changed, so the event with country code “ES” did not match our filter criteria and therefore was filtered. Note that you cannot monitor or log events that are filtered out. Such event behaves as if the event was never raised!

Dynamic topic filtering in Advanced Event Mesh

Dynamic Topics enable detailed event filtering and routing, ensuring that events are delivered only to the relevant components, improving efficiency and reducing unnecessary processing. The feature of Dynamic Topics is only available for channels integrating with the Advanced Event Mesh (AEM). For more information regarding AEM, please follow Get Started with SAP Integration Suite, Advanced Event Mesh.

Imagine you have your RAP business event in BTP ABAP environment system, with the same abstract entity, that represents the actual event payload with the country code field. Similarly, you must add an additional annotation to enable Dynamic Topic or to enable that the country code is added as an additional segment to the Dynamic Topic. The first part of the annotation is the same; we have the event context attribute and then we give it a name, and additionally, you also need to define a position. This is because you could have multiple Dynamic Topic segments, and we need to know at which position each one should be put, so you can order them in the way you need them.

.context:{attribute:'xsapcountrycode',position: 1}
  CountryCode: abap.char(2);

As you see below, the country code is exposed to the header part, but the difference is, you can see at the end of the standard topic the value of the country code field is added as well. Since you could define multiple properties, the position is so important to be added to the Dynamic Topic because we need to know at which position after the standard topic, the Dynamic Topic segment for the given property should be added

Besides, we want to use this field for routing and filtering the events in Advanced Event Mesh and for that, you also need to know the exact location of the specific property you want to use as a filter.

This is already everything you must do in BTP ABAP environment for your RAP business event. Assume you want to have two filters, one for the country code “DE” and the other one for the country code “US”. For that, you must define two queues in your Advanced Event Mesh.

Let's say for example in the “US” queue you only want to have events of the country code “US”. Then, you define this topic subscription accordingly and you need to do the same thing for the second queue where you want to receive the events with the country code “DE”.

Now I will show you how to route your events in practice. I have reverted all the changes I've made to enable source side filtering, so there is no event filters defined. Now we want to send out all the events and then put them into different queues depending on their properties. As it is explained before, this is how our abstract entity must look like:

@EndUserText.label: 'Event parameter'
define abstract entity ZD_ItemOrdered_0000 {
    ItemName : abap.char(25);
@Event.context:{attribute:'xsapcountrycode',position: 1}
  CountryCode: abap.char(2);
}

Create a channel for the integration with AEM, either by using the SAP GUI transaction in SAP S/4HANA, SAP S/4HANA Cloud Private Edition or respective communication arrangements in SAP S/4HANA Cloud Public Edition or SAP BTP ABAP Environment (as described Get Started with SAP Integration Suite, Advanced Event Mesh). You can enable Dynamic Topics by using the button “Enable Dynamic Topics” which is only enabled for Advanced Event Mesh channels. By clicking on this button and enabling the Dynamic Topics, you can see that something has changed, namely the topic now contains this Dynamic Topic segment “xsapcountrycode”:

Now I go to the connected Advanced Event Mesh broker and configure two queues, one for country code “DE” and another one for “US”:

In subscriptions section of “DE” queue for example, you can see the topic we have for “DE” country code

and for the “US” it's comparable. That's everything that needs to be done to route events.

Let's create a new order to be shipped to “US”. Then in our event monitor application, there is an event here and you can see also the outbound event tab has changed to signify this topic schema, so you know there are Dynamic Topics in place.

If we look at this event, we can see the Dynamic Topic segment is indeed “US” and if we check the payload, it's the same as before, we have our xsapcountrycode which is lifted to the header and the country code in there:

Now let's look at our queues and you can see one message has reached the US queue:

With that, you have a simple but powerful routing tool for your events.

Summary

Here I shortly presented the newly developed possibilities of event filtering and routing for ABAP Cloud. Source side filtering prevents events from being published based on the filters we define using the payload fields which are exposed to the CloudEvent context. This can be used to satisfy data privacy and protection restrictions or also in case you wanted to distribute the load among different connections.

By means of the Dynamic Topic feature we are now able to route and filter the events in Advanced Event Mesh broker. Both features are already available in the current SAP S/4HANA Cloud Public Edition, SAP S/4HANA, SAP S/4 HANA Cloud Private Edition as well as SAP BTP ABAP environment releases.

In the near future, the customer should also able to choose any valid payload fields of the given RAP event type as an event filter attribute without using annotation “@Event.context.attribute”. Please follow the community page to get informed regarding updates in Enterprise Event Enablement content.

Bypassing CDS Filters in SADL-Based OData Services for Flexible Fiori Applications

2025-04-29T18:03:45.228000+02:00

In modern SAP Fiori applications, developers often rely on CDS views exposed via SADL (Service Adaptation Definition Language) to build quick and efficient OData services. While this architecture promotes reusability and low-code development, it can become restrictive when CDS views include hardcoded filters or mandatory parameters.

IO_TECH_REQUEST_CONTEXT in GET_EXPANDED_ENTITYSET is an interface that provides:

1️⃣Request details (keys, headers, and $expand navigation properties)

2️⃣Access to OData query options like filters and expansions

3️⃣Contextual control for fetching a main entity with its related data in one call

(Think of it as a "request assistant" that tells your OData service exactly what data to return and how.)

/IWBEP/IF_MGW_REQ_ENTITYSET

🔍Implementing Query Options Using /IWBEP/IF_MGW_REQ_ENTITYSET

The interface /IWBEP/IF_MGW_REQ_ENTITYSET is a core component of SAP NetWeaver Gateway's code-based OData service implementation. It is primarily used within the GET_ENTITYSET method of the Data Provider Extension Class (DPC_EXT) to handle query options such as filtering, sorting, and paging.

📌Key Query Option Methods

This interface provides several methods to retrieve and handle query parameters passed from the client:

get_filter_string( )
Retrieves the raw filter string from the request URI. Useful for logging or manual parsing if needed.

get_filter( )
Returns a structured filter object that can be further analyzed using standard methods.

get_filter_select_options( )
Converts the filter into a select-option compatible internal table (/iwbep/t_mgw_select_option). This is particularly useful when passing filters to BAPIs, function modules, or for building dynamic WHERE clauses in ABAP.

get_top( ) and get_skip( )
Retrieve the $top and $skip values used for client-side paging.

get_orderby( )
Provides sorting information from the $orderby clause.

has_filter( )
Checks whether a filter condition was provided in the request.

If want know more Implementing Query Options

To enable value help functionality in a CDS view, we first define the necessary annotations. Specifically, we use:

@search.defaultSearchElement: true

@Consumption.valueHelpDefinition:[{ entity:{ element: 'MATNR' ,name: 'ZI_SEARCH_MARA2' } }]

In this context, ZI_SEARCH_MARA2 is a separate CDS view that serves as the value help entity.

In the CDS view ZI_SEARCH_MARA2, the annotation @ObjectModel.dataCategory: #VALUE_HELP is mandatory for enabling the view to function as a value help source in Fiori applications. Without this annotation, the CDS view will not be recognized by the Fiori framework as a valid value help provider, and the associated value help functionality will not work as expected

Registering CDS as OData Data Source

Right-click on your OData project
Select Referenced Data Sources
In the dialog:
Choose "Core Data Services" tab
Click "Add..." button
Search for your CDS view (Z_MATERIALMASTER)
Select and confirm

Now consuming the OData in SAP Fiori Generator by using the VS code by choosing the list report page

We can Preview Application .

Find the Entity Name From UI

Open Browser Developer Tools
Press F12 or Ctrl+Shift+I (Chrome/Edge)
Go to the Network tab
Trigger the Value Help
Click on the value help icon in your Fiori app
Watch for new network requests to appear
Locate the Batch Request ($batch)
Filter requests by typing "$batch" in the search box
Look for the most recent POST request to .../$batch
Inspect the Payload
Click on the $batch request
Go to the "Payload" tab (or "Request Payload")
Look for lines starting with GET followed by entity names like: GET EntitySetName?$filter=...

Locating the EntitySet Method for Value Help in OData Projects

Step-by-Step Guide to Find the Correct Method

After Identifying the Entity Name (from browser network inspection)
Example: You found entity Z_C_EntityName in the $batch payload
Navigate to Your OData Project in ADT/Eclipse
Open your OData service project
Expand the "Runtime Artifacts" folder
Open the DPC_EXT Class
Look for ZCL_[YourServiceName]_DPC_EXT
This is your custom extension class that inherits from the generated DPC class
Find the EntitySet Method
Search for methods with naming pattern:[ENTITYSET_NAME]_GET_ENTITYSET
For our example Z_C_ProductVH, look for:Z_C_PRODUCTVH_GET_ENTITYSET

1. Set Breakpoints:

Put a breakpoint in the method and trigger the value help again
Examine the io_tech_request_context contents during debugging

2.Check Base Class:

If not found in DPC_EXT, check the parent DPC class
Generated methods might be in the base class

3. Common Patterns:

Value help methods often:
Join multiple tables
Implement special search algorithms
Have _GET_ENTITYSET suffix

4. Related Methods:

Sometimes value help uses both:
..._GET_ENTITYSET for the list
..._GET_ENTITY for single record validation

This approach helps you quickly locate and modify the backend logic powering your Fiori app's value help functionality.

Now we can implement code here.

By Redefending the method

 

data(lv_filter) = io_tech_request_context->get_filter( )->get_filter_string( ). 
  
if lv_filter is NOT INITIAL. 
  
filter_string_url( 
   EXPORTING 
     iv_filter_string = lv_filter 
   IMPORTING 
     et_entityset     = ET_ENTITYSET 
 ).

data(lv_filter) = io_tech_request_context->get_filter( )->get_filter_string( ).

io_tech_request_context
The gateway request object containing all OData call details (URL, headers, queries).
->get_filter()
Accesses the $filter clause from the request, returning a filter object reference.
->get_filter_string()
Extracts the raw filter condition as a string (e.g., "(Price gt 100) and (Category eq 'Electronics')").
Key Purpose
Gets the unprocessed filter exactly as sent by the client for debugging or custom parsing.

filter_string_url This method is used to custom filtering implementation is written which returns the entityset based on the lv_filters

Lv_filter gives values like ( ( MATNR = ‘ 1 ’ ) or ( MATNR = ‘ 7 ’ ) )

  METHOD filter_string_url. 
     DATA:lt_Matnr_range TYPE RANGE OF mara-Matnr, 
          ls_Matnr_range LIKE LINE OF lt_Matnr_range. 
  
    IF iv_filter_string IS NOT INITIAL. 
  
      DATA:lv_string TYPE string. 
       DATA:lt_string TYPE TABLE OF string. 
  
      lv_string = iv_filter_string. 
  
      REPLACE ALL OCCURRENCES OF '(' IN lv_string WITH ''. 
       REPLACE ALL OCCURRENCES OF ')' IN lv_string WITH ''. 
       REPLACE ALL OCCURRENCES OF `'` IN lv_string WITH ''. 
       REPLACE ALL OCCURRENCES OF '&' IN lv_string WITH 'AND'. 
       REPLACE ALL OCCURRENCES OF 'and' IN lv_string WITH 'AND'. 
       REPLACE ALL OCCURRENCES OF 'le' IN lv_string WITH ''. 
       REPLACE ALL OCCURRENCES OF 'ge' IN lv_string WITH ''. 
       REPLACE ALL OCCURRENCES OF 'MATNR' IN lv_string WITH ''. 
       REPLACE ALL OCCURRENCES OF '=' IN lv_string WITH ''. 
  
      TRANSLATE lv_string TO UPPER CASE. 
  
      SPLIT lv_string AT 'AND' INTO TABLE lt_string. 
       SPLIT lv_string AT 'OR' INTO TABLE lt_string. 
  
      SORT lt_string. 
       CLEAR lv_string. 
       READ TABLE lt_string INTO lv_string INDEX 1. 
       IF sy-subrc = 0. 
         CONDENSE lv_string. 
         CALL FUNCTION 'CONVERSION_EXIT_MATN1_INPUT' 
           EXPORTING 
             input        = lv_string 
           IMPORTING 
             output       = ls_Matnr_range-low 
           EXCEPTIONS 
             length_error = 1 
             OTHERS       = 2. 
       ENDIF. 
  
      CLEAR lv_string. 
       IF lines( lt_string ) > 1. 
         READ TABLE lt_string INTO lv_string INDEX lines( lt_string ). 
         IF sy-subrc = 0. 
           CONDENSE lv_string. 
           CALL FUNCTION 'CONVERSION_EXIT_MATN1_INPUT' 
             EXPORTING 
               input        = lv_string 
             IMPORTING 
               output       = ls_Matnr_range-high 
             EXCEPTIONS 
               length_error = 1 
               OTHERS       = 2. 
           ENDIF. 
       ENDIF. 
       IF ls_Matnr_range-high IS NOT INITIAL. 
         ls_Matnr_range-sign = 'I'. 
         ls_Matnr_range-option = 'BT'. 
       ELSE. 
         ls_Matnr_range-sign = 'I'. 
         ls_Matnr_range-option = 'EQ'. 
       ENDIF. 
  
      APPEND ls_Matnr_range TO lt_Matnr_range. 
       CLEAR ls_Matnr_range. 
  
 
      IF lt_Matnr_range IS NOT INITIAL. 
         SELECT Matnr FROM mara INTO TABLE et_entityset WHERE Matnr IN lt_Matnr_range. 
       ENDIF. 
  
    ENDIF. 
   ENDMETHOD.

Conclusion:-

This approach provides the flexibility to:

Bypass restrictive CDS view filters when justified
Implement custom business logic for value help
Maintain control over data exposure
Improve user experience with dynamic filtering

Remember that while these techniques offer powerful customization options, they should be used judiciously to maintain system stability and security.

Consuming External API Tax Rate Information in RAP

2025-04-29T18:39:34.578000+02:00

Introduction

With the increasing need for real-time data integration, consuming external APIs directly within the ABAP RESTful Application Programming Model (RAP) is becoming a critical requirement. This blog post demonstrates how to integrate external tax rate data into a RAP-based application using unmanaged query implementation.

Scenario Overview

The goal is to expose tax rate information retrieved from an external API within an SAP Fiori application, structured using RAP. This example uses two custom entities:

ZI_TAXRATE_UQ (Root View)

ZI_TAXRATE_ITEM_UQ (Item View)

The backend implementation is handled in an ABAP class ZCL_TAXRATE_UQ that implements the interface IF_RAP_QUERY_PROVIDER.

Data Model Definition

The data model consists of:

Root Entity: ZI_TAXRATE_UQ

@EndUserText.label: 'Interface View for Unmanaged scenario' 
@Metadata.allowExtensions: true 
define root custom entity ZI_TAXRATE_UQ 
{ 
key Id : abap.int1; 
key Country : abap.char(2); 
key State : abap.char(2); 
key City : abap.char(20); 
key Postcode : abap.char(5); 
key Address1 : abap.char(50); 
key Address2 : abap.char(50); 
key TaxClass : abap.char(20); 
// Return Fields 
TaxRateLabel : abap.char(20); 
Shipping : abap.char(3); 
Rate : abap.dec(16, 4); 
Compound : abap.char(3); 
CompoundCriticality : abap.int1; 
Combined : abap.char(3); 
CombinedCriticality : abap.int1; 
CombineError : abap.char(3); 
CombineErrorCriticality : abap.int1; 
// This does not work with Custom Entities: _TaxrateItem : ... 
_TaxrateItem : composition [1..*] of zi_taxrate_item_uq; 
}

Item Entity: ZI_TAXRATE_ITEM_UQ

@EndUserText.label: 'Interface View from item details' 
//@ObjectModel.query.implementedBy: 'ABAP:ZCL_TAXRATE_UQ' 
@Metadata.allowExtensions: true 
define custom entity ZI_TAXRATE_ITEM_UQ 
{ 
// Filter Fields 
key TaxrateId : abap.int1; 
key Id : abap.int1; 
key Country : abap.char(2); 
key State : abap.char(2); 
key City : abap.char(20); 
key Postcode : abap.char(5); 
key Address1 : abap.char(50); 
key Address2 : abap.char(50); 
key TaxClass : abap.char(20); 
// Return Fields 
TaxRateLabel : abap.char(20); 
Shipping : abap.char(3); 
Rate : abap.dec(16, 4); 
Compound : abap.char(3); 
_TaxRate : association to parent zi_taxrate_uq 
on $projection.taxrateid = _TaxRate.id 
and $projection.country = _TaxRate.country 
and $projection.state = _TaxRate.state 
and $projection.city = _TaxRate.city 
and $projection.postcode = _TaxRate.postcode 
and $projection.address1 = _TaxRate.address1 
and $projection.address2 = _TaxRate.address2 
and $projection.taxclass = _TaxRate.taxclass; 
}

Custom Logic Implementation

CLASS zcl_taxrate_uq DEFINITION 
PUBLIC 
FINAL 
CREATE PUBLIC . 
PUBLIC SECTION. 
INTERFACES if_rap_query_provider . 
METHODS: 
constructor. 
PROTECTED SECTION. 
METHODS: 
build_taxrates_query IMPORTING sql_filter TYPE string, 
get_tax_rates RETURNING VALUE(tax_rates_combined) TYPE zif_gtax_rates=>ts_tax_rates_combined, 
sanitize_fields_for_insert, 
handle_paging IMPORTING io_request TYPE REF TO if_rap_query_request, 
get_value_from_sql_string 
IMPORTING 
VALUE(i_string) TYPE string " Input string with key-value pairs 
VALUE(i_key) TYPE string " Key to search for 
RETURNING 
VALUE(e_value) TYPE string. " Corresponding value 

PRIVATE SECTION. 
DATA: parameters TYPE if_rap_query_request=>tt_parameters, 
sql_filter TYPE string, 
offset TYPE int8, 
page_size TYPE int8, 
max_rows TYPE int8.
DATA: tr_query TYPE zif_gtax_rates=>ts_taxrates_query, 

use_mockdata TYPE abap_bool, 
tax_rates_combined TYPE zif_gtax_rates=>ts_tax_rates_combined, 
tax_rate TYPE zif_gtax_rates=>ts_tax_rates. 

DATA: compound_criticality TYPE i, 
combined TYPE string, 
combined_critically TYPE i, 
combine_error TYPE string, 
combine_error_critically TYPE i. 
ENDCLASS. 
CLASS zcl_taxrate_uq IMPLEMENTATION. 
METHOD constructor. 
use_mockdata = abap_false. 
ENDMETHOD. 
METHOD if_rap_query_provider~select. 
TRY. 
CASE io_request->get_entity_id( ). 
WHEN 'ZI_TAXRATE_UQ'. 
" Read parameters and filters 
parameters = io_request->get_parameters( ). "Parameters not used 
sql_filter = io_request->get_filter( )->get_as_sql_string( ). 

" Get tax rates from remote API 
build_taxrates_query( sql_filter = sql_filter ). 
tax_rates_combined = get_tax_rates( ). 
sanitize_fields_for_insert( ). 

" Append the received tax rates to internal table 
DATA lt_taxrate TYPE STANDARD TABLE OF zi_taxrate_uq. 
INSERT VALUE #( 
Id = 1 
Country = tr_query-country 
State = tr_query-state 
City = tr_query-city 
Postcode = tr_query-postcode 
Address1 = tr_query-address1 
Address2 = tr_query-address2 
TaxClass = tr_query-tax_class 
TaxRateLabel = tax_rates_combined-tax_rate-label 
Shipping = tax_rates_combined-tax_rate-shipping 
Rate = tax_rates_combined-tax_rate-rate 
Compound = tax_rates_combined-tax_rate-compound 
CompoundCriticality = compound_criticality 
Combined = combined 
CombinedCriticality = combined_criticality 
CombineError = combine_error 
CombineErrorCriticality = combine_error_criticality 
) INTO TABLE lt_taxrate. 
" Return requested data 
IF io_request->is_data_requested( ). 
handle_paging( io_request ). 
io_response->set_data( lt_taxrate ). 
ENDIF. 
" Return total number of records 
IF io_request->is_total_numb_of_rec_requested( ). 
io_response->set_total_number_of_records( lines( lt_taxrate ) ). 
ENDIF. 

WHEN 'ZI_TAXRATE_ITEM_UQ' . 
parameters = io_request->get_parameters( ). 
sql_filter = io_request->get_filter( )->get_as_sql_string( ). 
 
" Get tax rates from remote API 
build_taxrates_query( sql_filter = sql_filter ). 
tax_rates_combined = get_tax_rates( ). 
" Append the received tax rates to internal table 

DATA lt_taxrate_item TYPE STANDARD TABLE OF zi_taxrate_item_uq. 

DATA(lv_id) = 1. 
LOOP AT tax_rates_combined-tax_rates INTO tax_rate. 
INSERT VALUE #( 
TaxrateId = 1 
Id = lv_id 
Country = tr_query-country 
State = tr_query-state 
City = tr_query-city 
Postcode = tr_query-postcode 
Address1 = tr_query-address1 
Address2 = tr_query-address2 
TaxClass = tr_query-tax_class 
TaxRateLabel = tax_rate-label 
Shipping = tax_rate-shipping 
Rate = tax_rate-rate 
Compound = tax_rate-compound 
) INTO TABLE lt_taxrate_item. 
lv_id += 1. 
ENDLOOP. 

" Query table with id AND previous query if specific item is requested (by click on an item in the Tax Rate Items - Listview) 

DATA(id) = get_value_from_sql_string( i_string = sql_filter i_key = 'ID' ). 

IF id IS NOT INITIAL. 
SELECT * 
FROM _taxrate_item AS taxrates 
WHERE (sql_filter) 

ORDER BY Id 
INTO TABLE (lt_result). 
lt_taxrate_item = lt_result. 

ENDIF. 

" Return requested data 
IF io_request->is_data_requested( ). 
handle_paging( io_request ). 
io_response->set_data( lt_taxrate_item ). 

ENDIF. 
ENDCASE. 
CATCH cx_rap_query_provider. 
ENDTRY. 
ENDMETHOD. 

METHOD build_taxrates_query. 
IF use_mockdata = abap_false. 
tr_query-country = get_value_from_sql_string( i_string = sql_filter i_key = 'COUNTRY' ). 

tr_query-state = get_value_from_sql_string( i_string = sql_filter i_key = 'STATE' ). 

tr_query-city = get_value_from_sql_string( i_string = sql_filter i_key = 'CITY' ). 

tr_query-postcode = get_value_from_sql_string( i_string = sql_filter i_key = 'POSTCODE' ). 

tr_query-address1 = get_value_from_sql_string( i_string = sql_filter i_key = 'ADDRESS1' ). 

tr_query-address2 = get_value_from_sql_string( i_string = sql_filter i_key = 'ADDRESS2' ). 

tr_query-tax_class = get_value_from_sql_string( i_string = sql_filter i_key = 'TAXCLASS' ). 

ELSE. 
tr_query-country = 'US'. 
tr_query-state = 'CA'. 
tr_query-city = 'Mountain View'. 
tr_query-postcode = '94043'. 
tr_query-address1 = '1600 Amphitheatre Parkway'. 
tr_query-address2 = ''. 
tr_query-tax_class = ''. 

ENDIF. 

ENDMETHOD. 
METHOD get_tax_rates. 
DATA: gtax_client TYPE REF TO zcl_gtax_client, 
jsonpath TYPE REF TO zcl_jsonpath, 
tax_rates_json TYPE string.  

gtax_client = NEW zcl_gtax_client( ). 
jsonpath = NEW zcl_jsonpath( ). 

TRY. 
tax_rates_json = gtax_client->get_tax_rates( tr_query = tr_query use_mockdata = use_mockdata ). 
jsonpath->set( tax_rates_json ). 
jsonpath->get_data( EXPORTING query_string = '$' CHANGING data = tax_rates_combined ). 
CATCH cx_http_dest_provider_error cx_web_http_client_error INTO DATA(lx_error). 

"out->write( lx_error->get_text( ) ). 
"EXIT. 

ENDTRY. 
ENDMETHOD. 

METHOD sanitize_fields_for_insert. 
compound_criticality = 3. "Green 
IF tax_rates_combined-tax_rate-compound = 'yes'. 
compound_criticality = 2. "Orange 
ENDIF. 

combined = 'no '. 
combined_criticality = 3. "Green 
IF tax_rates_combined-combined = abap_true. 
combined = 'yes'. 
combined_criticality = 5. "Blue 
ENDIF. 

combine_error = 'no '. 
combine_error_criticality = 3. "Green 
IF tax_rates_combined-combine_error = abap_true. 
combine_error = 'yes'. 
combine_error_criticality = 2. "Orange 
ENDIF. 
ENDMETHOD. 

METHOD handle_paging. 
" Get Paging to prevent "NOT IMPLEMENTED" error 
offset = io_request->get_paging( )->get_offset( ). 
page_size = io_request->get_paging( )->get_page_size( ). 
max_rows = COND #( WHEN page_size = if_rap_query_paging=>page_size_unlimited THEN 0 ELSE page_size ). 
ENDMETHOD. 

METHOD get_value_from_sql_string. 
DATA: lt_parts TYPE TABLE OF string, 
lv_field TYPE string, 
lv_value TYPE string. 

" Replace all occurrences of 'AND' in i_string with ';' 
REPLACE ALL OCCURRENCES OF 'AND' IN i_string WITH ';'. 

" Split the transformed string into individual key-value pairs 
SPLIT i_string AT ';' INTO TABLE lt_parts. 

LOOP AT lt_parts INTO DATA(lv_part). 
" Split each key-value pair into key and value using '=' as the delimiter 
SPLIT lv_part AT '=' INTO lv_field lv_value. 
" Check if the current key matches the input key (i_key) 
IF lv_field = i_key. 
e_value = lv_value. 
RETURN. " Exit method once matching key is found 
ENDIF. 
ENDLOOP. 
ENDMETHOD. 
ENDCLASS.

External API Consumption
The get_tax_rates method uses a client class ZCL_GTAX_CLIENT to retrieve data from the remote endpoint. The JSON response is parsed using a helper class ZCL_JSONPATH.

Query Preparation
build_taxrates_query extracts input parameters from SQL filters and constructs the API request payload. Mock data can be used optionally for testing.

Result Formatting
The sanitize_fields_for_insert method enriches the result by computing criticality indicators for compound status, combination, and error handling.

Paging Support
Handled by handle_paging, which uses standard RAP query paging mechanisms to limit result sets.

Utility for SQL Filter Parsing
get_value_from_sql_string helps extract individual filter values (like Country, State, etc.) from a SQL string.

Service Definition and Binding
The first screenshot shows the Service Definition (ZUI_TAXRATE_O4) where both custom entities ZI_TAXRATE_UQ and ZI_TAXRATE_ITEM_UQ are exposed using the OData V4 protocol. The service is later bound in the Service Binding screen where the service endpoint is generated for UI consumption.

Fiori Preview

The initial screen before search execution shows an empty table, prompting the user to input filter values and trigger the tax rate retrieval.

This example shows the tax rate lookup for Austria (AT), where a VAT of 20% is retrieved based on the given input parameters. It highlights that the service is capable of handling international addresses.

The filter bar allows users to input specific address details like Country, State, City, Postcode, Address1, and Tax Class to trigger the API call and retrieve appropriate tax rate information dynamically.

The Address tab displays the country, state, city, postcode, and address information entered by the user, which is used to filter and query the correct tax rates from the external API.

Below image shows the list of Taxrate Items for a given address. Each line item represents a tax type like "CA COUNTY TAX", "CA STATE TAX", and "CA SPECIAL TAX", along with the respective tax rate and compound information.
Below image presents a detailed view of a single Taxrate Item. It displays the tax label, rate, and compound status retrieved from the external API.

Conclusion
This implementation demonstrates how RAP can be extended to consume and expose data from external APIs using unmanaged custom entities and ABAP logic. Key advantages of this design include:

Full control over API communication and data transformation.

Reusability and testability using mock data.

Seamless Fiori integration via RAP and CDS.

Implementing Deep Action for Bulk Approval In Rap

2025-04-29T18:56:26.024000+02:00

Introduction

In this blog, we will explore how to implement a deep action in the ABAP RESTful Application Programming Model (RAP). Our use case involves bulk approval of Purchase Orders (POs) along with their respective line items.

Deep Action :

A Deep Action in the ABAP RESTful Application Programming Model (RAP) is a custom behavior action that allows processing and manipulation of a hierarchical structure of entities—including the root entity and its related child entities—in a single transactional call.

Steps for end-to-end implementation,

CDS view creation

Behavior definitions

Abstract entities

Deep action logic

Metadata extensions

Service definition

Testing

Business scenario.

multiple purchase orders (POs) for procuring raw materials and equipment. Each PO contains several line items detailing the materials, quantities, and suppliers. Streamline operations, the company wants to implement a feature that allows bulk approval of selected POs along with their respective line items.

Implementation Steps:

Define the Data Model:

Behavior Definition:

Action Definition: In the behavior definition (behavior definition), define a deep action Approves that operates on PO Header and its associated PO Item entities.

Behavior Implementation:

Purchase Order Header Entity (PO Header):

Represents the main details of the purchase order, such as PO number, supplier, and approval status.

Database Table.

@EndUserText.label : 'purchase order header'

@AbapCatalog.enhancement.category : #EXTENSIBLE_ANY

@AbapCatalog.tableCategory : #TRANSPARENT

@AbapCatalog.deliveryClass : #A

@AbapCatalog.dataMaintenance : #RESTRICTED

define table zug_dt_poheader {



key client : abap.clnt not null;

key ebeln : ebeln not null;

bukrs : bukrs;

lifnr : lifnr;

ekorg : ekorg;

ekgrp : ekgrp;

bstyp : bstyp;

status : zug_postatus;



}

Purchase Order Item Entity (PO Item):

Contains details of each line item within a PO, including material ID, quantity, price, and item-specific approval status.

POitem.

@EndUserText.label : 'purchase order item'

@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE

@AbapCatalog.tableCategory : #TRANSPARENT

@AbapCatalog.deliveryClass : #A

@AbapCatalog.dataMaintenance : #RESTRICTED

define table zug_dt_poitem {



key client : abap.clnt not null;

@AbapCatalog.foreignKey.screenCheck : false

key ebeln : ebeln not null

with foreign key [0..*,1] zug_dt_poheader

where ebeln = zug_dt_poitem.ebeln;

key ebelp : ebelp not null;

matnr : matnr;

munit : abap.unit(3);

@Semantics.quantity.unitOfMeasure : 'zug_dt_poitem.munit'

menge : menge_d;

cunit : abap.cuky;

@Semantics.amount.currencyCode : 'zug_dt_poitem.cunit'

netpr : abap.curr(10,2);

status : zug_postatus;



}

Behavior Definition:

Action Definition: In the behavior definition (behavior definition), define a deep action Approves that operates on PO Header and its associated PO Item entities.

Interface entity.

unmanaged implementation in class zbp_ug_i_poheader2 unique;

strict ( 2 );
define behavior for zug_i_poheader1 

lock master

authorization master ( instance )

{
static action Bulkorderapprove deep parameter zug_s_poheader;

create;

update;

delete;
association _poitem { create; }
mapping for zug_dt_poheader

{
Bstyp = bstyp;

Bukrs = bukrs;

Ebeln = ebeln;

Ekgrp = ekgrp;

Ekorg = ekorg;

Lifnr = lifnr;

Status = status;

}

}

define behavior for zug_i_poitem1 


lock dependent by _poheader

authorization dependent by _poheader

{

update;

delete;

field ( readonly ) Ebeln;

association _poheader;

mapping for zug_dt_poitem

{

Ebeln = ebeln;

Ebelp = ebelp;

Matnr = matnr;

Menge = menge;

Munit = munit;

Netpr = netpr;

Status = status;

}

}

Association: Establish a composition association between PO Header and PO Item to model the hierarchical relationship.

Projection view.

projection;
strict ( 2 );
define behavior for zug_p_poheader1 //alias <alias_name>

{
use create;

use update;

use delete;

use action Bulkorderapprove;

use association _poitem { create; }

}
define behavior for zug_p_poitem //alias <alias_name>
{

use update;

use delete;

use association _poheader;

}

Abstract entity.

abstract;

strict ( 2 );

with hierarchy;

define behavior for zug_s_poheader //alias <alias_name>

{

association _poitem;

}



define behavior for zug_s_poitem //alias <alias_name>

{

}



Abstract Entities

@EndUserText.label: 'abstract entity'

define root abstract entity zug_s_poheader

{

key ebeln : ebeln ;

status : zug_postatus ;

last_changed_by : abp_locinst_lastchange_user;

last_changed_at : abp_locinst_lastchange_tstmpl;

_poitem : composition [0..*] of zug_s_poitem;

}

For item

@EndUserText.label: 'poitem abstarct entity'

define abstract entity zug_s_poitem



{

key ebeln : ebeln ;

key ebelp : ebelp ;

status : zug_postatus ;

last_changed_by : abp_locinst_lastchange_user;

last_changed_at : abp_locinst_lastchange_tstmpl;

_poheader : association to parent zug_s_poheader on $projection.ebeln = _poheader.ebeln;

}

Meta data extension for header

@Metadata.layer: #CORE

annotate entity zug_p_poheader1

with

{

@UI.facet: [{

id: 'Poheader',

purpose: #STANDARD,

position: 10 ,

label: 'Poheader',

type: #IDENTIFICATION_REFERENCE

},

{

id: 'Poitem',

purpose: #STANDARD,

position: 20 ,

label: 'Poitem',

type: #LINEITEM_REFERENCE,

targetElement: '_poitem'

}

]

@UI.lineItem: [{ position: 10 }]

@UI.identification: [{ position: 10 }]

Ebeln;

@UI.lineItem: [{ position: 20 }]

@UI.identification: [{ position: 20 }]

Bukrs;

@UI.lineItem: [{ position: 20 }]

@UI.identification: [{ position: 30 }]

Lifnr;

@UI.lineItem: [{ position: 40 }]

@UI.identification: [{ position: 40 }]

Ekorg;

@UI.lineItem: [{ position: 50 }]

@UI.identification: [{ position: 50 }]

Ekgrp;

@UI.lineItem: [{ position: 60 }]

@UI.identification: [{ position: 60 }]

Bstyp;

@UI.lineItem: [{ position: 70 }

, { type: #FOR_ACTION , dataAction: 'Bulkorderapprove' , label : 'Bulkorderapprove' }

]

@UI.identification: [{ position: 70 }]

Status;

}

Action Handler: Implement the Approves action in the behavior implementation class. This method will loop through the selected POs and their items, updating their approval statuses.

Implementing class

CLASS lhc_zug_i_poheader1 DEFINITION INHERITING FROM cl_abap_behavior_handler.

PRIVATE SECTION.

METHODS get_instance_authorizations FOR INSTANCE AUTHORIZATION

IMPORTING keys REQUEST requested_authorizations FOR zug_i_poheader1 RESULT result.

METHODS create FOR MODIFY

IMPORTING entities FOR CREATE zug_i_poheader1.

METHODS update FOR MODIFY

IMPORTING entities FOR UPDATE zug_i_poheader1.
METHODS delete FOR MODIFY

IMPORTING keys FOR DELETE zug_i_poheader1.

METHODS read FOR READ

IMPORTING keys FOR READ zug_i_poheader1 RESULT result.

METHODS lock FOR LOCK

IMPORTING keys FOR LOCK zug_i_poheader1.

METHODS rba_Poitem FOR READ

IMPORTING keys_rba FOR READ zug_i_poheader1\_Poitem FULL result_requested RESULT result LINK association_links.

METHODS cba_Poitem FOR MODIFY

IMPORTING entities_cba FOR CREATE zug_i_poheader1\_Poitem.

METHODS Bulkorderapprove FOR MODIFY

IMPORTING keys FOR ACTION zug_i_poheader1~Bulkorderapprove.

ENDCLASS.

CLASS lhc_zug_i_poheader1 IMPLEMENTATION.
METHOD get_instance_authorizations.

ENDMETHOD.

METHOD create.
data ls_c_o TYPE zug_dt_poheader.
data lt_c_o TYPE TABLE of zug_dt_poheader.
lt_c_o = CORRESPONDING #( entities mapping from ENTITY ).
ls_c_o = lt_c_o[ 1 ].
zcl_ug_h=>gs_tab_c = ls_c_o
ENDMETHOD.

METHOD update.
data ls_u_o TYPE zug_dt_poheader
data lt_u_o TYPE TABLE of zug_dt_poheader.

lt_u_o = CORRESPONDING #( entities mapping from ENTITY ).

ls_u_o = lt_u_o[ 1 ].

zcl_ug_h=>gs_tab_u = ls_u_o.
ENDMETHOD.


METHOD delete.

ENDMETHOD.

METHOD read.

SELECT from zug_dt_poheader FIELDS *

INTO TABLE (lt_porders).

result = CORRESPONDING #( lt_porders mapping to entity ).

ENDMETHOD.



METHOD lock.

ENDMETHOD.



METHOD rba_Poitem.

ENDMETHOD.



METHOD cba_Poitem.

ENDMETHOD.



METHOD Bulkorderapprove.

DATA lt_order TYPE TABLE for UPDATE zug_i_poheader1.

DATA lt_item TYPE TABLE for UPDATE zug_i_poitem1.
data(ls_s) = VALUE #( keys[ 1 ] OPTIONAL ).
lt_order = value #( ( ebeln = ls_s-%param-ebeln
status = ls_s-%param-status
) ).

lt_item = value #( for ls_i in ls_s-%param-_poitem ( ebeln = ls_i-ebeln

ebelp = ls_i-ebelp
) ).




MODIFY ENTITIES OF zug_i_poheader1 IN LOCAL MODE
ENTITY zug_i_poheader1
UPDATE from lt_order
ENTITY zug_i_poitem1
UPDATE FROM lt_item
FAILED DATA(lt_failed)

REPORTED data(lt_reported).
ENDMETHOD.

ENDCLASS.

CLASS lhc_zug_i_poitem1 DEFINITION INHERITING FROM cl_abap_behavior_handler.

PRIVATE SECTION.

METHODS update FOR MODIFY

IMPORTING entities FOR UPDATE zug_i_poitem1.

METHODS delete FOR MODIFY

IMPORTING keys FOR DELETE zug_i_poitem1.


METHODS read FOR READ

IMPORTING keys FOR READ zug_i_poitem1 RESULT result


METHODS rba_Poheader FOR READ

IMPORTING keys_rba FOR READ zug_i_poitem1\_Poheader FULL result_requested RESULT result LINK association_links

ENDCLASS.

CLASS lhc_zug_i_poitem1 IMPLEMENTATION.

METHOD update.
ENDMETHOD.

METHOD delete.
ENDMETHOD.

METHOD read.
ENDMETHOD.

METHOD rba_Poheader.
ENDMETHOD.

ENDCLASS.

CLASS lsc_ZUG_I_POHEADER1 DEFINITION INHERITING FROM cl_abap_behavior_saver.

PROTECTED SECTION.

METHODS finalize REDEFINITION.

METHODS check_before_save REDEFINITION.

METHODS save REDEFINITION

METHODS cleanup REDEFINITION.

METHODS cleanup_finalize REDEFINITION
ENDCLASS.

CLASS lsc_ZUG_I_POHEADER1 IMPLEMENTATION.
METHOD finalize.
ENDMETHOD.

METHOD check_before_save.
ENDMETHOD.

METHOD save.
if zcl_ug_h=>gs_tab_c is NOT INITIAL.
INSERT zug_dt_poheader from @zcl_ug_h=>gs_tab_c.
ELSEIF zcl_ug_h=>gs_tab_u Is NOT INITIAL.
INSERT zug_dt_poheader from @zcl_ug_h=>gs_tab_u.
ENDIF.

ENDMETHOD.

METHOD cleanup.

ENDMETHOD.

METHOD cleanup_finalize.

ENDMETHOD.

ENDCLASS.



DATA lt_order TYPE TABLE for UPDATE zug_i_poheader1.
DATA lt_item TYPE TABLE for UPDATE zug_i_poitem1
data(ls_s) = VALUE #( keys[ 1 ] OPTIONAL ).

lt_order = value #( ( ebeln = ls_s-%param-ebeln

status = ls_s-%param-status

) ).

lt_item = value #( for ls_i in ls_s-%param-_poitem ( ebeln = ls_i-ebeln

ebelp = ls_i-ebelp

) ).

MODIFY ENTITIES OF zug_i_poheader1 IN LOCAL MODE

ENTITY zug_i_poheader1

UPDATE

from lt_order

ENTITY zug_i_poitem1

UPDATE FROM

lt_item
FAILED DATA(lt_failed)

REPORTED data(lt_reported).

Service Exposure:

Service Definition: Expose the PO Header and PO Item entities through a service definition to make them available for consumption.

Service Binding: Create a service binding to expose the service via OData.

Service binding

Steps to test

Set Auth

In header you can pass these the click on get

After that we can post request and get the result

Header.

Po item.

Enable Multi-Input Field on the Object Page using RAP

2025-04-29T20:46:31.881000+02:00

How to enable Multi-Input Field on the Object Page using RAP?

Lets take a example of Procurement Project Business Object. In the BO there is a field "Company Code" for which multi-input needs to enabled in object page.

Below are the steps to enable above functionality using RAP:

1. Create a custom table with fields "company code" (here companycode is the field of root entity project ) and "procurementprojectuuid" ( here project uuid is the key field of root entity project)

@EndUserText.label : 'Procurement Project Company Code'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table zprocproj_cc {
  key client             : abap.clnt not null;
  key companycode        : bukrs not null;
  procurementprojectuuid : vdm_procurementprojectuuid;

}

2. Create a Interface view for custom table create at step 1.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Company COde'
@Metadata.ignorePropagatedAnnotations: true
@ObjectModel.usageType:{
    serviceQuality: #X,
    sizeCategory: #S,
    dataClass: #MIXED
}
define view entity ZI_Company_Code_XX
  as select from zprocproj_cc
  association to parent ZI_PROC_PROJ_XX as _procproj on $projection.procurementprojectuuid = _procproj.Procurementprojectuuid
{
  key companycode,
      procurementprojectuuid,
      _procproj



}

Here "ZI_Company_Code_XX" is the Interface View for CompanyCode custom table and "ZI_PROC_PROJ_XX" is the Root Interface View for Procurement Project BO.

You can also find association to parent relationship from companycode Interface view to root view procurement project.

3. Create 1:N composition relation from root entity to company code interface view which is created in step 2

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Procument Project Interface View'
@Metadata.ignorePropagatedAnnotations: true
@ObjectModel.usageType:{
    serviceQuality: #X,
    sizeCategory: #S,
    dataClass: #MIXED
}
define root view entity ZI_PROC_PROJ_XX
  as select from mmprocmtproj
  composition [0..*] of zi_proc_plant_xx as _plant
  composition [0..*] of ZI_Company_Code_XX as _CompanyCode
{
  key procurementprojectuuid       as Procurementprojectuuid,
      procurementproject           as Procurementproject,
      procurementprojectname       as Procurementprojectname,
      externalprojectreference     as Externalprojectreference,
      companycode                  as Companycode,
      @Semantics.user.createdBy: true
      createdbyuser                as Createdbyuser,
      @Semantics.user.lastChangedBy: true
      lastchangedbyuser            as Lastchangedbyuser,
      @Semantics.systemDateTime.createdAt: true
      creationdatetime             as Creationdatetime,
      @Semantics.systemDateTime.lastChangedAt: true
      lastchangedatetime           as Lastchangedatetime,
      procurementprojectactvtnsts  as Procurementprojectactvtnsts,
      procmtplanningsubprojectuuid as Procmtplanningsubprojectuuid,
      sourcingorigin               as Sourcingorigin,
      sourcingscenario             as Sourcingscenario,
      iseopblocked                 as Iseopblocked,

      _plant,
      _CompanyCode

}

Here root entity is ZI_PROC_PROJ_XX and it has 1:N composition relationship to child entity ZI_Company_Code_XX.

Make sure you activate ZI_PROC_PROJ_XX and ZI_Company_Code_XX together when you form the business object relationship.

4. Enhance ZI_Company_Code_XX behavior in base BO ZI_PROC_PROJ_XX

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

define behavior for ZI_PROC_PROJ_XX alias Project
persistent table mmprocmtproj
draft table zprocproj_dxx
lock master
total etag Lastchangedatetime
authorization master ( instance, global )
etag master Lastchangedatetime
with additional save
early numbering
{

  create;
  update;
  delete ( features : global );

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

    validation validate_companycode;
  }



  //field ( numbering : managed ) Procurementprojectuuid;


  //  field ( mandatory ) Companycode;
  field ( readonly : update ) Externalprojectreference;
  field ( readonly ) Sourcingscenario;
  //field ( mandatory : create, readonly : update ) Procurementproject;  //V4

  field ( features : instance ) Procurementproject;

  association _plant { create; with draft; }
  association _CompanyCode { create; with draft; }

  action ( features : instance ) setactive parameter zabstract_project_xx result [1] $self;


  validation validate_companycode on save { field Companycode; }

  determination set_status on modify { create; }

  determination set_project_key on save { create; }

  mapping for mmprocmtproj corresponding
  {
    Lastchangedatetime = lastchangedatetime;
  }
}

define behavior for zi_proc_plant_xx alias Plant
//persistent table mmpprojplant
draft table zprocplantd_xx
lock dependent by _project
authorization dependent by _project
//etag master <field_name>
with unmanaged save
{
  update;
  delete;

  field ( numbering : managed ) procmtprojectplantuuid;
  field ( readonly ) Procurementprojectuuid;
  association _project { with draft; }
}

define behavior for ZI_Company_Code_XX alias CompanyCode
persistent table zprocproj_cc
draft table zprocproj_ccd
lock dependent by _procproj
authorization dependent by _procproj
{
  update;
  delete;
  field ( readonly ) Procurementprojectuuid;

  association _procproj { with draft; }
}

What additions are added in the above behavior:

1. define behavior for ZI_Company_Code_XX

2. association _CompanyCode { create; with draft; } in root behavior ZI_PROC_PROJ_XX

3. draft table zprocproj_ccd created using quick fix.

5. Create a projection view ZC_PROC_CC_XX for interface view ZI_Company_Code_XX created in step 2

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Procement Project CC Projection View'
@Metadata.ignorePropagatedAnnotations: true
define view entity ZC_PROC_CC_XX as projection on ZI_Company_Code_XX
{
    key companycode,
    procurementprojectuuid,
    /* Associations */
    _procproj : redirected to parent ZC_PROC_PROJ_XX
    
}

Here "_procproj : redirected to parent ZC_PROC_PROJ_XX" relation is formed to root projection entity ZC_PROC_PROJ_XX

6. Create a relation from root project projection view ZC_PROC_PROJ_XX to company code project view zc_proc_cc_xx.

_CompanyCode : redirected to composition child zc_proc_cc_xx,

Make sure you activate ZC_PROC_PROJ_XX and zc_proc_cc_xx together when you form the business object relationship.

7. Enhance projection Company code behavior ZC_PROC_CC_XX in projection

projection;
strict ( 2 );
use draft;
define behavior for ZC_PROC_PROJ_XX //alias <alias_name>
implementation in class zcl_proc_proj_c_xx unique
use etag
{
  use create ( augment, precheck );
  use update;
  use delete;


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

  use action setactive;

  use association _plant { create; with draft; }
  use association _CompanyCode { create; with draft; }
}

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

  use association _project { with draft; }
}

define behavior for ZC_PROC_CC_XX
{
  use update;
  use delete;
  use association _procproj { with draft; }

}

What additions are added in the above behavior:

1. define behavior for ZC_PROC_CC_XX

2. use association _CompanyCode { create; with draft; } in root behavior ZC_PROC_PROJ_XX

8. Expose company code projection view ZC_PROC_CC_XX service definition.

@EndUserText.label: 'Service Binding for Procurement Project'
define service ZSD_PROC_PROJ_XX {
  expose ZC_PROC_PROJ_XX as ProcurementProject;
  expose ZC_PROC_PLANT_XX as ProcurementPlant;
  expose ZC_PROC_CC_XX as ProcurementCC;
}

Here "expose ZC_PROC_CC_XX as ProcurementCC;" added.

9. Enhance the metadata extension of root view ZC_PROC_PROJ_XX

  : { lineItem:       [ { position: 70, importance: #HIGH, value: '_CompanyCode.companycode' }
                 ] }
  .identification: [{ position: 70, importance: #HIGH, value: '_CompanyCode.companycode' }]
  _CompanyCode;

Here association _CompanyCode; is exposed in metadata extension and value property '_CompanyCode.companycode' is added to @ui.linetem and @ui.identification annotation.

10. Now preview the UI.

Now multi-input is enabled for company code field in Object page.

On save in display mode it appears like below:

In list page field it displays like below:

Introduction to @PrivilegedAccess Annotation in RAP with Real-Time Scenario

2025-05-05T10:37:47.676000+02:00

1.Introduction
In SAP ABAP RESTful Application Programming Model (RAP), access control is crucial for ensuring data security and controlled access to business operations. While regular users follow standard authorization rules, certain privileged users (e.g., Admins, Managers) may require special permissions to override these rules in exceptional scenarios.

To achieve this, SAP provides the @PrivilegedAccess annotation, which allows specific actions to be executed only by users with special permissions.

2.Why Use @PrivilegedAccess?

Allows special access to privileged users for actions that normal users cannot perform.

Enhances security by keeping sensitive operations restricted to authorized personnel.

Provides flexibility in business scenarios where exceptions or urgent modifications are required.

Ensures compliance with business rules while allowing controlled overrides.

3.Real-Time Scenario

Use Case: Purchase Order (PO) Approval System

A company has a Purchase Order (PO) approval system with the following requirements:

Regular Users can only submit POs for approval.

Managers (Privileged Users) should be able to override approvals in case of business urgency.

Using @PrivilegedAccess, we ensure that only managers can approve or override PO approvals while regular users cannot bypass the approval process.

4.Implementation: Step-by-Step Guide with Code and Explanation

Step 1: Create a CDS Entity for Purchase Orders

We define a CDS view entity that represents the Purchase Order table.

@EndUserText.label: 'Purchase Order' 
define root view entity ZI_PURCHASE_ORDER 
{ 
  key purchase_order_id : UUID; 
  supplier             : String(50); 
  total_amount         : Currency(10,2); 
  status               : String(20); // Values: 'PENDING', 'APPROVED', 'REJECTED' 
}

Explanation:

This defines a table with attributes like supplier, total amount, and status.

The status field stores the approval state (PENDING, APPROVED, REJECTED).

Step 2: Define the Behavior Definition with Privileged Access

We define two actions:

approve: Available to regular users for normal approval.

override_approval: Available only to privileged users using @PrivilegedAccess.

managed implementation in class ZBP_PURCHASE_ORDER unique; 
strict ( 2 ); 
 
define behavior for ZI_PURCHASE_ORDER alias PurchaseOrder   
{ 
  create; 
  update; 
  delete; 
 
  action approve; // Normal Approval Action 
 
  @PrivilegedAccess 
  action override_approval; // Only for privileged users 
}

Explanation:

The approve action is accessible to all authorized users.

The override_approval action is restricted to privileged users only via @PrivilegedAccess.

Step 3: Implement the Behavior in ABAP Class

The business logic for the approve and override_approval actions is written in the RAP behavior class.

CLASS zbp_purchase_order DEFINITION PUBLIC FINAL FOR BEHAVIOR OF zi_purchase_order. 
  PUBLIC SECTION. 
    METHODS: 
      approve FOR ACTION approve ON MODIFY, 
      override_approval FOR ACTION override_approval ON MODIFY. 
ENDCLASS. 
 
CLASS zbp_purchase_order IMPLEMENTATION. 
 
  METHOD approve. 
    " Regular approval process 
    MODIFY entities OF zi_purchase_order 
      ENTITY purchaseorder 
      SET status = 'APPROVED' 
      WHERE purchase_order_id = _order_id. 
 
    WRITE: / 'Purchase Order Approved Successfully'. 
  ENDMETHOD. 
 
  METHOD override_approval. 
    " Only privileged users can execute this action 
    MODIFY entities OF zi_purchase_order 
      ENTITY purchaseorder 
      SET status = 'FORCED_APPROVAL' 
      WHERE purchase_order_id = _order_id. 
 
    WRITE: / 'Purchase Order Approved with Privileged Access'. 
  ENDMETHOD. 
 
ENDCLASS.

Explanation:

The approve method updates the status to 'APPROVED'.

The override_approval method updates the status to 'FORCED_APPROVAL' but can be executed only by privileged users.

The @PrivilegedAccess annotation prevents unauthorized users from executing override_approval.

5.Testing the Implementation with Output

Test Case 1: Regular User Approves PO

Input:
User clicks on Approve button in Fiori App.

Execution:

CALL FUNCTION 'approve' 
  EXPORTING purchase_order_id = '12345'.

Output in Database:

PO ID	Supplier	Total Amount	Status
12345	ABC Ltd	5000	APPROVED

✅Message: "Purchase Order Approved Successfully"

Test Case 2: Privileged User Overrides Approval

Input:
Manager clicks Override Approval in Fiori App.

Execution:

CALL FUNCTION 'override_approval' 
  EXPORTING purchase_order_id = '12345'.

Output in Database:

PO ID	Supplier	Total Amount	Status
12345	ABC Ltd	5000	FORCED_APPROVAL

✅Message: "Purchase Order Approved with Privileged Access"

6.Code Explanation: How It Works

Step	Code Component	Purpose
1	ZI_PURCHASE_ORDER	Defines the PO table structure.
2	@PrivilegedAccess in behavior definition	Restricts override_approval action to privileged users only.
3	approve method	Allows regular users to approve POs.
4	override_approval method	Allows only privileged users to approve POs in special cases.
5	Fiori App Action Execution	Users interact with the Fiori UI to trigger the actions.

7. Key Learnings

Feature	Explanation
@PrivilegedAccess	Grants special permissions to execute restricted actions.
Use Case	Allows Managers to override standard approval processes.
Security Considerations	Ensures only privileged users can perform critical actions.
Business Benefit	Provides flexibility while maintaining strict security and compliance.

8.Conclusion

The @PrivilegedAccess annotation in RAP enables secure and controlled access to business-critical actions while maintaining the standard approval process for regular users. It is useful for managing exceptions, handling administrative actions, and ensuring compliance with business rules.

Part 2: Local Handler Class, Draft Functionality, and Attachment Handling

2025-05-08T09:35:03.828000+02:00

Local Handler Class

In an unmanaged RAP scenario, the local handler class is where you write the ABAP code to implement the behavior defined in the behavior definition. This includes implementing the standard CRUD (Create, Read, Update, Delete) operations and any custom actions.

Role of the Local Handler Class:
- It acts as the "brain" of your RAP business object, containing the code that interacts with the database and enforces business rules.
- It processes requests from the service layer and performs the necessary actions.
- It handles data manipulation, validation, and authorization.
- Keys in Local Handler Class:
  - Keys are crucial within the local handler class because they are used to identify specific instances of the business object.
  - For example, when updating a customer, the customer_id key is used to locate the correct customer record in the database.
  - When creating a new entity (like an attachment), the handler might need to generate a new unique key.
  - Key fields are often used in WHERE clauses in database operations to ensure that the correct data is being accessed or modified.
  - Entities:
    - Within the local handler class, the term "entities" refers to the data being processed—typically, a table of instances.
    - When creating new customers, the "entities" parameter would hold the data for the new customer records.
    - When updating customers, "entities" would contain the modified data for the customers being updated.
    - When deleting, "entities" would identify which customer instances to delete.
    - CRUD Operation Examples:
      - Create:
        This method handles the creation of new customer records.
        It iterates through the entities to be created.
        It generates a new customer_id (if it's not provided).
        It inserts the new customer data into the zztmfcustomer database table.
        It handles error situations (e.g., if the database insertion fails).
        It returns the created customer IDs with %cid (client ID) to the framework.
        Read:
        This method retrieves customer data based on the provided keys.
        It iterates through the keys (which contain the customer_id).
        It selects the customer data from the zztmfcustomer table using the customer_id in the WHERE clause.
        It appends the retrieved data to the result.
        It handles the case where a customer with the given ID is not found.
        Update:
        This method updates existing customer records.
        It iterates through the entities containing the updated data.
        It uses the MODIFY statement to update the corresponding record in the zztmfcustomer table, using the customer_id in the WHERE clause to identify the record.
        It handles potential errors during the update.
        Delete:
        This method deletes customer records.
        It iterates through the keys (containing the customer_id of the records to be deleted).
        It deletes the records from the zztmfcustomer table using the customer_id in the WHERE clause.
        It includes error handling.

    METHODS create FOR MODIFY IMPORTING entities FOR CREATE Customer.
    METHODS modify FOR MODIFY IMPORTING entities FOR UPDATE Customer.
    METHODS delete FOR MODIFY IMPORTING keys FOR DELETE Customer.
    METHODS read   FOR READ   IMPORTING keys FOR READ Customer RESULT result.

ASSOCIATION :

The Associated Child entities should be created only from a Parent Entity, in the above they are specified as Root\_Associated Entity , however the other operations of the class can be handled directly by declaring a method.

METHODS create_ContactMedium   FOR MODIFY IMPORTING entities FOR CREATE Customer\_ContactMedium.
    METHODS create_CreditProfile   FOR MODIFY IMPORTING entities FOR CREATE Customer\_CreditProfile.
    METHODS create_EventInput      FOR MODIFY IMPORTING entities FOR CREATE Customer\_EventInput.
    METHODS create_EventSubscription FOR MODIFY IMPORTING entities FOR CREATE Customer\_EventSubscription.
    METHODS create_Characteristic  FOR MODIFY IMPORTING entities FOR CREATE Customer\_Characteristic.
    METHODS create_PaymentMethod   FOR MODIFY IMPORTING entities FOR CREATE Customer\_PaymentMethod.
    METHODS create_RelatedParty    FOR MODIFY IMPORTING entities FOR CREATE Customer\_RelatedParty.
    METHODS create_TimePeriod      FOR MODIFY IMPORTING entities FOR CREATE Customer\_TimePeriod

Custom Action: copy

The behavior definition allows defining custom actions.

We defined a copy action for the Customer entity.

Why use it?

Efficiency: Quickly create similar records

Consistency: Maintain default values.

User Experience: Convenient for repetitive data entry.

Implementing the copy Action: Add a method in the local handler class to implement the copy logic.

define behavior for ZC_TMF_Customer alias Customer
authorization master ( instance )
draft table ZZTMFCUSTOMER_d
etag master last_changed_at
lock master total etag last_changed_at
early numbering
{
  // Root entity
  create;
  update;
  delete;
  action copy;

Implement the Method logic:

METHOD copy.


  DATA: lv_new_id TYPE zztmfcustomer-id,
        ls_customer TYPE zztmfcustomer,
        lt_accountref TYPE TABLE OF zztmfaccountref,
        lt_agreementre TYPE TABLE OF zztmfagreementre,
        lt_contactmedium TYPE TABLE OF zztmfcontactme,
        lt_creditprofile TYPE TABLE OF zztmfcreditpro,
        lt_eventinput TYPE TABLE OF zztmfeventinput,
        lt_eventsubscr TYPE TABLE OF zztmfeventsubscr,
        lt_characteris TYPE TABLE OF zztmfcharacteris,
        lt_paymentme TYPE TABLE OF zztmfpaymentme,
        lt_relatedpart TYPE TABLE OF zztmfrelatedpart,
        lt_timeperiod TYPE TABLE OF zztmftimeperiod.

  LOOP AT entities ASSIGNING FIELD-SYMBOL(<ls_entity>).

    " 1. Read original customer
    SELECT SINGLE * FROM zztmfcustomer  WHERE id = @<ls_entity>-customer_id INTO _customer.
    IF sy-subrc <> 0.
      CONTINUE.
    ENDIF.

    " 2. Get new customer id
    SELECT MAX( id ) FROM zztmfcustomer INTO _new_id.
    lv_new_id =  lv_new_id + 1.

    " 3. Insert new customer (copy, but new id)
    ls_customer-id = lv_new_id.
    INSERT zztmfcustomer FROM _customer.

    " 4. Copy AccountRef
    SELECT * FROM zztmfaccountref  WHERE id = @<ls_entity>-customer_id INTO TABLE _accountref.
    LOOP AT lt_accountref ASSIGNING FIELD-SYMBOL(<ls_acc>).
      <ls_acc>-id = lv_new_id.
    ENDLOOP.
    IF lt_accountref IS NOT INITIAL.
      INSERT zztmfaccountref FROM TABLE _accountref.
    ENDIF.

    " 5. Copy AgreementRe
    SELECT * FROM zztmfagreementre  WHERE id = @<ls_entity>-customer_id INTO TABLE _agreementre.
    LOOP AT lt_agreementre ASSIGNING FIELD-SYMBOL(<ls_agr>).
      <ls_agr>-id = lv_new_id.
    ENDLOOP.
    IF lt_agreementre IS NOT INITIAL.
      INSERT zztmfagreementre FROM TABLE _agreementre.
    ENDIF.

    " 6. Copy ContactMedium
    SELECT * FROM zztmfcontactme  WHERE id = @<ls_entity>-customer_id INTO TABLE _contactmedium.
    LOOP AT lt_contactmedium ASSIGNING FIELD-SYMBOL(<ls_con>).
      <ls_con>-id = lv_new_id.
    ENDLOOP.
    IF lt_contactmedium IS NOT INITIAL.
      INSERT zztmfcontactme FROM TABLE _contactmedium.
    ENDIF.

    " 7. Copy CreditProfile
    SELECT * FROM zztmfcreditpro  WHERE id = @<ls_entity>-customer_id INTO TABLE _creditprofile.
    LOOP AT lt_creditprofile ASSIGNING FIELD-SYMBOL(<ls_cred>).
      <ls_cred>-id = lv_new_id.
    ENDLOOP.
    IF lt_creditprofile IS NOT INITIAL.
      INSERT zztmfcreditpro FROM TABLE _creditprofile.
    ENDIF.

    " 8. Copy EventInput
    SELECT * FROM zztmfeventinput  WHERE id = @<ls_entity>-customer_id INTO TABLE _eventinput.
    LOOP AT lt_eventinput ASSIGNING FIELD-SYMBOL(<ls_evi>).
      <ls_evi>-id = lv_new_id.
    ENDLOOP.
    IF lt_eventinput IS NOT INITIAL.
      INSERT zztmfeventinput FROM TABLE _eventinput.
    ENDIF.

    " 9. Copy EventSubscription
    SELECT * FROM zztmfeventsubscr  WHERE id = @<ls_entity>-customer_id INTO TABLE _eventsubscr.
    LOOP AT lt_eventsubscr ASSIGNING FIELD-SYMBOL(<ls_evs>).
      <ls_evs>-id = lv_new_id.
    ENDLOOP.
    IF lt_eventsubscr IS NOT INITIAL.
      INSERT zztmfeventsubscr FROM TABLE _eventsubscr.
    ENDIF.

    " 10. Copy Characteristic
    SELECT * FROM zztmfcharacteris  WHERE id = @<ls_entity>-customer_id INTO TABLE _characteris.
    LOOP AT lt_characteris ASSIGNING FIELD-SYMBOL(<ls_char>).
      <ls_char>-id = lv_new_id.
    ENDLOOP.
    IF lt_characteris IS NOT INITIAL.
      INSERT zztmfcharacteris FROM TABLE _characteris.
    ENDIF.

    " 11. Copy PaymentMethod
    SELECT * FROM zztmfpaymentme  WHERE id = @<ls_entity>-customer_id INTO TABLE _paymentme.
    LOOP AT lt_paymentme ASSIGNING FIELD-SYMBOL(<ls_pay>).
      <ls_pay>-id = lv_new_id.
    ENDLOOP.
    IF lt_paymentme IS NOT INITIAL.
      INSERT zztmfpaymentme FROM TABLE _paymentme.
    ENDIF.

    " 12. Copy RelatedParty
    SELECT * FROM zztmfrelatedpart  WHERE id = @<ls_entity>-customer_id INTO TABLE _relatedpart.
    LOOP AT lt_relatedpart ASSIGNING FIELD-SYMBOL(<ls_rel>).
      <ls_rel>-id = lv_new_id.
    ENDLOOP.
    IF lt_relatedpart IS NOT INITIAL.
      INSERT zztmfrelatedpart FROM TABLE _relatedpart.
    ENDIF.

    " 13. Copy TimePeriod
    SELECT * FROM zztmftimeperiod  WHERE id = @<ls_entity>-customer_id INTO TABLE _timeperiod.
    LOOP AT lt_timeperiod ASSIGNING FIELD-SYMBOL(<ls_tim>).
      <ls_tim>-id = lv_new_id.
    ENDLOOP.
    IF lt_timeperiod IS NOT INITIAL.
      INSERT zztmftimeperiod FROM TABLE _timeperiod.
    ENDIF.

    " 14. Return new key
    APPEND VALUE #( %tky = VALUE #( customer_id = lv_new_id ) ) TO mapped-customer.

  ENDLOOP.

Draft Functionality

Draft functionality enhances the user experience by allowing users to create or modify business objects without immediately saving the changes to the database. This is particularly useful for complex objects or when multiple steps are involved in creating or editing data.

Draft Lifecycle:

Edit: The user starts editing an existing object or creates a new one, and the data is saved to a draft.
Activate: The user confirms the changes, and the draft data is saved to the active database table.
Discard: The user cancels the changes, and the draft data is deleted.
Resume: The user returns to a previously started draft to continue editing.
Draft Implementation Examples:
- Activate:
  - This method activates a draft, saving the changes to the active table.
  - It reads the draft data from the zztmfcustomer_d (draft table).
  - It copies the data to a structure (ls_customer).
  - It updates the zztmfcustomer (active table) with the data.
  - It deletes the draft record from zztmfcustomer_d.
  - It includes error handling for database operations.
  - Discard:
    - This method discards a draft, deleting the draft data.
    - It deletes the draft record from the zztmfcustomer_d table.
    - It includes error handling.
    - Draft functions is handled automatically in the RAP framework, all you need to is create a table like below and specify it in Behaviour Definition.

@EndUserText.label : 'Table to Store Customer details'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table zztmfcustomer_d {

  key customer_id    : char10 not null;
  link               : char100;
  name               : char20 not null;
  status             : char20;
  statusreason       : char30;
  validfor           : datab;
  last_changed_at    : timestampl;
  locallastchangedat : timestampl;
  "%admin"           : include sych_bdl_draft_admin_inc;

}

ATTACHMENT HANDLING in RAP

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

  key attach_id   : char10 not null;
  key customer_id : char10 not null;
  file_name       : char100 not null;
  file_type       : char20 not null;
  file_content    : abap.rawstring(999999);
  created_on      : timestampl;
  last_changed_at : timestampl;

}


METHOD create_Attachment.
    DATA: lt_attach TYPE TABLE OF zztmcustatt,
          lv_max_id TYPE zztmcustatt-attach_id.

*    " Determine next attachment id

*
    LOOP AT entities ASSIGNING FIELD-SYMBOL(<ls_entity>).
      DATA(lt_target) = <ls_entity>-%target.
        SELECT MAX( attach_id ) FROM zztmcustatt  where customer_id = @<ls_entity>-customer_id INTO _max_id.
    IF sy-subrc = 0.
      " Convert lv_max_id to a number, increment
      lv_max_id = lv_max_id + 1.
    ELSE.
      lv_max_id = '0000000001'. " initial value, formatted as needed
    ENDIF.
      LOOP AT lt_target ASSIGNING FIELD-SYMBOL(<ls_target>).
        APPEND VALUE #(
          attach_id    = lv_max_id
          customer_id  = <ls_entity>-customer_id   " Parent key from the Customer
          file_name    = <ls_target>-FileName
          file_type    = <ls_target>-FileType
          file_content = <ls_target>-Attachment
          created_on   = sy-datum && sy-uzeit   " or use GET TIME STAMP
        ) TO lt_attach.
        " Increment attachment key (format as needed)
        lv_max_id = lv_max_id + 1.
      ENDLOOP.
    ENDLOOP.

    IF lt_attach IS NOT INITIAL.
      INSERT zztmcustatt FROM TABLE _attach.
      " Map created attachments back
      LOOP AT lt_attach ASSIGNING FIELD-SYMBOL(<ls_att>).
        APPEND VALUE #( %tky = VALUE #( AttachId = <ls_att>-attach_id ) )
          TO mapped-Attachment.
      ENDLOOP.
    ENDIF.
  ENDMETHOD.

Create a Service Definition and Service Binding to test the application using FIORI ELEMENTS.

Creation of New Record with Draft Functionality & Attachment
- The Records is not Created but its in Draft Status
- A new Attachment is uploaded and Created

Conclusion

In Part 2, we covered the implementation details of our Customer Management application. We explored the role of the local handler class in processing business logic, implemented draft functionality to enhance the user experience, and enabled attachment handling to manage files.

This two-part series provided a comprehensive guide to building a Customer Management application with unmanaged RAP. By understanding the concepts and examples presented here, you can create your own robust and user-friendly RAP applications. Remember to adapt the code and techniques to the specific requirements of your projects.

With this you can integrate your RAP application with Process Build Automation for Approval. A workflow handler class should be called in the determination of RAP to call the created Workflow.

As of now, SAP BTP Trial has not provided integration part for free, it can be done only in Licensed mode.

SAP SEGW vs RAP vs CAP: Making the most of Function Imports, Actions and Functions (Part 1)

2025-05-08T09:35:18.963000+02:00

After working on several SAP projects, I have noticed a common trend consisting in a plethora of SEGW projects full of function imports that are generally misused or unnecessary. With my experience—and after delving into the SAP documentation—I have decided to write this blog to shed some light on function imports. I will explain what they are, what they are used for, when to use them and when to avoid using them, and will do so not only for SAP SEGW projects, but also for their equivalents within the more recent SAP RAP and CAP frameworks—since I am actively diving into these modern development approaches and working on business projects that leverage them. To make this more concrete, I’ll walk through a practical example, which I’ve made available on GitHub.

Let's clear up the confusion together. So, grab your coffee, and let’s dive in !

Part 1. SEGW Context
Part 2. SAP RAP and SAP CAP + github project

SAP SEGW Context

A function import in OData is a way to define and call custom operations in one’s service that goes beyond the standard data handling actions—like creating, reading, updating, or deleting records (CRUD). These standard actions are typically handled through the HTTP methods POST, GET, PUT/MERGE, and DELETE.

However, if you need to perform a more specialized task that does not neatly fit into the standard CRUD operations, you can create a function import in your data model using Service Builder. These custom operations can then be triggered using either the GET or POST HTTP methods.

But first, a small word of caution: these specific function imports are only to be used for actions that cannot be done with standard traditional CRUD operations. If the task can be handled through regular create, read, update, or delete, then a function import is not required.

Let’s look at an example to understand.

Example : Flight management system with CRUD and custom operations

Core CRUD operations :

These operations cover the basic data management needs for flight records

Create: Add new flight (e.g., POST /flight with origin, destination, departure, arrival..).
Read: Retrieve existing flight (e.g., GET /flight/{id}).
Update: Modify flight (e.g., PUT /flight/{id} to adjust departure time).
Delete: Remove canceled flight (e.g., DELETE /flight/{id}).

Custom operations :

These are business-specific operations that go beyond standard CRUD

Print details: Generate and print comprehensive flight information (e.g., schedule, aircraft, and seating).
Generate report: Create operational or statistical reports for flights over a specified date range.
…

Custom operations are separated from CRUD because they encapsulate domain-specific behavior that cannot be addressed by simple data manipulation alone. While CRUD operations focus on creating, reading, updating, or deleting records, custom actions often perform calculations, trigger workflows, or apply business rules across multiple entities.

This distinction supports a cleaner and more maintainable architecture—where CRUD handles core data persistence, and custom operations handle the more nuanced logic of the application domain.

Implementation example

Below is an implementation example of how to call a function import defined in SEGW.

On the front-end, the function import is triggered via an OData request using callFunction(), for example: /sap/opu/odata/SERVICE_NAME/FunctionImportName(...).

On the back-end, it is handled by redefining the EXECUTE_ACTION method in the *_DPC_EXT class. Inside this method, the iv_action_name parameter is used to identify the specific function being called. Input parameters are accessed through the it_parameter table, and the corresponding backend logic is implemented accordingly.

Front-end code:

let oModel = this.getView().getModel();
let mParameters = {
  FlightID: "12345"
};

oModel.callFunction("/PrintFlightDetails", {
  method: "POST",
  urlParameters: mParameters,
  success: function(oData, response) {
    MessageToast.show(oData.Message);
  },
  error: function(oError) {
    MessageToast.show("Error printing flight details");
  }
});

Back-end code : (Assuming we have previously defined the function import in the SEGW project and an ABAP OO class to manage the business object Flight)

METHOD execute_action.
  
  " Check if the action name is 'PrintFlightDetails'
  IF iv_action_name = 'PrintFlightDetails'.
    " Retrieve input parameter
    READ TABLE it_parameter INTO DATA(ls_parameter) WITH KEY name = 'FlightID'.
    IF sy-subrc = 0.
      DATA(lv_flightid) = ls_parameter-value.
    ELSE.
      " Manage error
    ENDIF.

    " Instantiate the flight manager class
    DATA(lo_flight) = NEW zcl_flight( lv_flightid ).

    " Call the method to update the flight status
    DATA(lv_message) = lo_flight->print_flight_details( ).

    ...

  ENDIF.
ENDMETHOD.

Conclusion

Function imports are a powerful tool, but like any tool, they must be used wisely. In SEGW, it is best to reserve them for operations that do not fit naturally into the CRUD. Misuse can lead to bloated, unclear services and unnecessary complexity.

In the next part of this series, I'll explore how similar use cases are handled in RAP and CAP - with a GitHub project to illustrate it all in action.

Stay tuned!

SAP SEGW vs RAP vs CAP: Making the most of Function Imports, Actions and Functions (Part 2)

2025-05-08T09:36:59.881000+02:00

Let's clear up the confusion together. So, grab your coffee, and let’s dive in !

Part 1. SEGW Context
Part 2. SAP RAP and SAP CAP + github project

SAP’s new frameworks

SAP RAP (RESTful ABAP Programming Model) and SAP CAP (Cloud Application Programming Model) are the two modern frameworks from SAP designed for building applications.

Both frameworks support extending standard CRUD operations by allowing developers to define custom logic—commonly known as actions or functions. In RAP, these are introduced in behavior definitions, while in CAP, they're modeled in the service layer. This functional similarity makes it natural to discuss them together.

As a quick note for context: this blog won’t delve into the differences between static and instance-based implementations, bound and unbound actions and functions.. as those topics are beyond the scope of this post — although they might be the subject of a future blog post.

SAP RAP Context

SAP RAP is SAP’s modern framework for developing OData services and business applications using ABAP. It serves the same core purpose as SAP SEGW (Service Gateway), which is to expose data and operations from SAP systems via OData.

Unlike SEGW, which relies heavily on manual coding and separate models, RAP uses a streamlined, model-driven approach with better integration into the ABAP RESTful environment, leveraging CDS (Core Data Services) to define and manage the data models in a more declarative way.

SAP CAP Context

SAP CAP is SAP’s modern development framework for building services and applications, particularly optimized for the SAP Business Technology Platform (BTP). It provides a streamlined, full-stack development experience with built-in support for defining data models, service APIs, and custom logic using a combination of Core Data Services (CDS), Node.js, or Java.

While SAP RAP is more ABAP-centric and suited for on-premise or S/4HANA systems, CAP is cloud-native and ideal for developing applications in the BTP environment.

Unlike traditional approaches like SEGW or even ABAP RAP, which are deeply rooted in the ABAP stack, CAP is open and service-oriented by design. It promotes strong integration with SAP HANA, SAP Fiori, and external services through open standards like OData and REST.

Standard vs Non-Standard Operations in RAP and CAP

Both SAP RAP and SAP CAP distinguish between standard and non-standard OData operations. Standard operations refer to the CRUD functionalities, which are automatically handled by the frameworks. In addition to CRUD, both frameworks also manage transactional behavior, draft handling, validation, and persistence with minimal configuration.

Non-standard operations, on the other hand, are used to implement custom business logic beyond CRUD, following the same conceptual model as Function Imports in the classical SEGW approach.

Actions and Functions in RAP and CAP

In both RAP and CAP, Actions and Functions represent non-standard operations that integrate custom logic into the application. Actions are used for logic that may change data or cause side effects while Functions are read-only operations that return data.

In RAP, these are defined in the behavior definition and implemented in the behavior pool class, ensuring proper transactional and authorization handling.

In CAP, they are defined in the CDS service definition, and the implementation resides in service handlers (Node.js or Java).

Both frameworks ensure these operations are fully OData V4-compliant and seamlessly consumable by Fiori Elements or other OData clients.

Fundamental difference between SEGW and SAP RAP/CAP

SAP SEGW (SAP Gateway Service Builder) is based on a flexible approach for managing CRUD operations. When creating or updating a service, the framework generates standard methods such as CREATE_ENTITY, UPDATE_ENTITY, DELETE_ENTITY, etc., which developers can redefine to incorporate more complex business logic tailored to functional requirements.

When a batch call is made from the front end, for example via a SubmitChanges operation, the grouped operations (creating entry C, updating entry A, deleting entry B, etc.) are dispatched individually in the backend. In other words, each operation is handled separately by the corresponding method (CREATE_ENTITY, UPDATE_ENTITY, etc.).

However, this approach introduces certain limitations, particularly in error handling within batch processing. Since each operation is processed independently, managing scenarios involving partial rollbacks or consistent error propagation across the batch becomes more complex.

SAP RAP and SAP CAP adopt a structured, model-based approach for managing data and business logic. Both rely on OData v4 and Core Data Services (CDS) to define entities, their relationships, and their behaviors.

CRUD operations such as CREATE and UPDATE are defined at the entity level and are designed to be handled individually, meaning they are executed on a single instance at a time. To manage more complex processing or scenarios involving multiple entities, RAP and CAP recommend the use of actions or functions, which allow business logic to be encapsulated without being directly embedded in the standard operations.

However, if no specific logic is required, it is still possible to perform batch processing (bulk update) using standard CRUD operations. That said, this approach is not recommended, as CRUD operations are intended for single-record processing, with validations, lifecycle hooks (such as before, after, check, etc.), and line-by-line error handling. Using batch processing via CRUD can lead to inconsistent behavior, difficult-to-control partial rollbacks, and a loss of control over overall business and transactional logic.

In addition, using actions offers many other advantages, such as:

Automatic interface generation: Actions are automatically exposed as buttons or menu items in Fiori Elements interfaces. They can be triggered on multiple selections (multi-select) with consistent UX behavior, and they allow for explicit naming of specific business processes (e.g., "Validate All", "Send Invoices").
Precise control over business logic: An action encapsulates business logic clearly, separate from generic CRUD operations. You can easily include custom validations, complex rules, calls to other services, and more.
Robust transaction and error handling: Actions enable centralized exception management, the return of structured user messages, and support for global rollbacks when needed.
...

A core principle in RAP and CAP is the clear separation between basic CRUD operations and business logic. This distinction enhances data consistency, code readability, and, most importantly, long-term maintainability of applications. Each action represents a clear business intent, integrated within a well-defined service structure.

In summary, SAP SEGW offers greater implementation freedom, which can be suitable for simple use cases with minimal business logic. However, it lacks a structured framework for handling complex scenarios or bulk processing. In contrast, SAP RAP and CAP enforce a more rigorous architecture, ensuring more reliable and scalable application management—both on the backend and frontend.

Now that we've covered the theory, let's explore some practical examples to see how this approach is implemented in these modern frameworks.

RAP implementation example

Below is an implementation example of how to call an action and a static function defined in SAP RAP.

In the front-end (e.g., Fiori Elements), the action setStatusToCanceled is triggered via the UI using the OData POST call to /EntitySet(...)/setStatusToCanceled. This is handled in the back-end by redefining the setStatusToCanceled method in the behavior implementation class (lhc_ZFM_C_FLIGHTS), where the logic modifies the entity’s status.

For the static function GetNumberOfDelayedFlights, it is triggered by a GET call like /EntitySet/GetNumberOfDelayedFlights, and its logic is implemented in the getnumberofdelayedflights method, returning a result structure with the computed data.

Flight Root Entity CDS View

define root view entity ZFM_C_FLIGHTS as select from ZFM_I_FLIGHTS
{
   key Flight,
   Origin,
   Destination,
   Departure,
   Arrival,
   Delay,
  
   .lineItem: [{ position: 70 }, { type: #FOR_ACTION, dataAction: 'setStatusToCanceled' , label: 'Cancel flight'}]
   Status
}

Behavior Definition

managed implementation in class zbp_fm_c_flights unique;
strict ( 2 );
define behavior for ZFM_C_FLIGHTS
persistent table zfm_flights
lock master
authorization master ( instance )
{
 create;
 update;
 delete;


 field ( numbering : managed, readonly ) Flight;


 action setStatusToCanceled result [1] $self;
 static function GetNumberOfDelayedFlights result [1] ZD_GETDELAYEDFLIGHTS_RESULT;


 mapping for zfm_flights {
     Flight = flight_id;
     Origin = origin_code;
     Destination = destination_code;
     Departure = departure;
     Arrival = arrival;
     Delay = delay;
     Status = status_code;
 }
}

Behavior Projection

projection;
strict ( 2 );
define behavior for ZFM_P_FLIGHTS
{
 use create;
 use update;
 use delete;
 use action setStatusToCanceled;
 use function GetNumberOfDelayedFlights;
}

Behavior Implementation Class (ABAP)

CLASS lhc_ZFM_C_FLIGHTS DEFINITION INHERITING FROM cl_abap_behavior_handler.
 PRIVATE SECTION.
   METHODS get_instance_authorizations FOR INSTANCE AUTHORIZATION
     IMPORTING keys REQUEST requested_authorizations FOR zfm_c_flights RESULT result.
   METHODS setstatustocanceled FOR MODIFY
     IMPORTING keys FOR ACTION zfm_c_flights~setstatustocanceled RESULT result.
   METHODS getnumberofdelayedflights FOR READ
     IMPORTING keys FOR FUNCTION zfm_c_flights~getnumberofdelayedflights RESULT result.
ENDCLASS.
CLASS lhc_ZFM_C_FLIGHTS IMPLEMENTATION.
 METHOD get_instance_authorizations.
 ENDMETHOD.
 METHOD setStatusToCanceled.
   MODIFY ENTITIES OF zfm_c_flights IN LOCAL MODE
          ENTITY zfm_c_flights
             UPDATE FROM VALUE #( FOR key IN keys
             ( Flight = key-Flight
               Status = 'CAN' " Cancelled
               %control-Status = if_abap_behv=>mk-on ) )
             FAILED failed
             REPORTED reported.
       "Read changed data for action result
       READ ENTITIES OF zfm_c_flights IN LOCAL MODE
         ENTITY zfm_c_flights
         ALL FIELDS WITH
         CORRESPONDING #( keys )
         RESULT DATA(flights).
       result = VALUE #( FOR flight IN flights
                ( %tky   = flight-%tky
                  %param = flight ) ).
 ENDMETHOD.
 METHOD getNumberOfDelayedFlights.
       DATA: ls_delayedflights TYPE zd_getdelayedflights_result.
       " Read all flights where status_code = 'CAN'
       SELECT COUNT( * ) FROM zfm_flights
                       WHERE delay > 0
                       INTO _delayedflights .
     " Count how many were found
        APPEND VALUE #( %param = CORRESPONDING #( ls_delayedflights  ) ) TO result.
 ENDMETHOD.
ENDCLASS.

CAP implementation example

If you’ve made it this far, it means you’re really interested in the topic — great!

To illustrate the fundamental differences between SEGW and CAP/RAP, I have implemented a more comprehensive CAP project. In this implementation, the use of an action instead of a batch update clearly proves its value through its seamless integration with Fiori Elements, as well as its ability to encapsulate business logic and handle errors effectively during mass processing.

To make things a bit more fun, here are three example use cases that I implemented in the following CAP example. Try to guess for each one whether it should be handled with a function or an action. The detailed answers are provided just below the implementation — but give it a try first!

Add delay to a flight – This updates the flight's delay and adjusts the arrival and/or departure time depending on the flight status.
Add delay to a list of flights – Same rules apply, but now you're looping through several flights, recalculating times, updating them, and optionally showing success or warning messages.
Retrieve the number of delayed flights – returns how many flights are currently delayed.

CDS Service Definition (srv/service.cds)

using { flightManagement as fm } from '../db/schema'; 

service FlightsService @(path: '/flights') {

    .draft.enabled
    entity Flights as projection on fm.Flights actions {
        action addDelay(
            delay: Integer 
            @label: '{i18n>addDelayAction_delayParameter}'          ) returns Flights;     };

        function getNbOfDelayedFlights() returns Integer;
}

Service Implementation (srv/service.js)

const cds = require('@sap/cds');
const TextBundle = require('@sap/textbundle').TextBundle;

module.exports = cds.service.impl(srv => {

    const { Flights } = srv.entities;

    // Validate and adjust flight data before update
    srv.before('UPDATE', 'Flights.drafts', async (req) => {
 
        // Recalculate departure/arrival if delay is updated
        if ('delay' in req.data) {
            try {
                let { departure, arrival } = await this._recalculate_departure_arrival(req.data.ID, req.data.delay);
                if (departure === undefined && arrival === undefined) {
                    req.reject(400, 'ERR_UPDATING_CAN_OR_LAN', 'delay');    
                }
                req.data.departure = departure;
                req.data.arrival = arrival;
            } catch (error) {
                req.reject(400, 'ERR_UPDATING_DELAY', 'delay');
            }
        }
    });

srv.on('addDelay', async (req) => {
        const locale = req.locale;
        const bundle = new TextBundle('./i18n/i18n', locale);

        // Loop through all flights
        for (let flight of req.params) {
            let { departure, arrival } = await this._recalculate_departure_arrival(flight.ID, req.data.delay);
            
            if (departure === undefined && arrival === undefined) {
                // If calculation failed, send a failure notification for this flight
                req.warn({
                    message: bundle.getText('WARNING_UPDATING_DELAY_CAN_OR_LAN', [flight.ID])
                })
                continue; // Skip updating this flight
            }
            
            // Update the flight with the new delay, departure, and arrival times
            const result = await UPDATE(Flights) .where({ ID: flight.ID }) .set({ delay: req.data.delay, departure, arrival });
            
            if (result === 1) {
                // Success: 1 row was affected
                req.notify({
                    code: 1,
                    message: bundle.getText('SUCCESS_UPDATING_DELAY', [flight.ID, req.data.delay, departure, arrival])
                });
            } else {
                // Failure: no rows were updated
                req.error({
                    message: bundle.getText('FAILURE_UPDATING_DELAY', [flight.ID])
                });
            }
        }
    });    

    // Function: Return the number of delayed flights
    srv.on('getNbOfDelayedFlights', async () => {
        const result = await SELECT `count(*) as count` .from(Flights) .where `delay > 0`;
        return (Array.isArray(result) && result.length > 0) ? result[0].count : 0;
    });
};

You’ve probably already figured out the answers by looking at the implementation, but let me walk you through the reasoning behind each choice:

For the first use case, “Add delay to a flight”, this one was a bit of a trick — it can be neatly handled within a before UPDATE hook, making it a natural candidate for standard CRUD logic.

In contrast, the action “Add delay to a list of flights” introduces more complexity. Since it involves applying business logic across multiple records as well as front-end integration, it is best implemented as a custom action. This approach also enables the generation of a button directly in the table header, along with an input popup, improved error handling, and, at the end of the process, a summary popup listing the operations that were processed in the user interface.

It is possible to enable standard bulk deletion management in Fiori Elements, handled by the framework. This is because it can be sent in batch without any business logic, as in the application I developed. We can also see the ease of integrating the action into a Fiori Elements through annotations. Finally, with the business complexity and error handling, we get feedback regardless of whether it's a success or failure, something that would have been complicated with a batch send. This example illustrates why these new frameworks recommend actions for such cases.

Lastly, the most straightforward case, “Retrieve the number of delayed flights”, simply returns data with no side effects. This makes it a perfect fit for a function.

The complete project is available on my GitHub repository => https://github.com/ValentinCadart/FlightManagement.

Conclusion

In a nutshell, Function Imports, Actions, and Functions are key components across SAP SEGW, RAP, and CAP that enable you to implement custom business logic, transcending basic CRUD functionality. While each platform offers its unique features and methods of defining and invoking these operations, understanding when and how to use them is essential for building efficient, scalable SAP applications.

Sooo.. one more misuse of function imports, actions or functions and I’m calling Basis to revoke your service deployment privileges. You’ve been warned !

Unlocking Customer Management in RAP: A Deep Dive (Part 1 - Data Model and Behavior)

2025-05-12T22:14:11.348000+02:00

Data Model

The data model defines the structure of our application's data. In our Customer Management scenario, we have a central Customer entity and several related child entities. This parent-child relationship allows us to organize and manage customer information effectively.

Entities:
- Customer (Parent): Stores core customer information.
- Child Entities:
  - Account Reference
  - Agreement Reference
  - Contact Medium
  - Payment Method
  - Customer Attachment
  - Characteristic
  - Credit Profile
  - Event Input
  - Event Subscription
  - Related Party
  - Time Period

We use database tables to persist the data for these entities.

Database Table Examples:
- Customer Table (zztmfcustomer):
  - id: Primary key, uniquely identifies each customer. The not null constraint ensures that every customer record has an ID.
  - name: Customer's name.
  - status: Current status of the customer.
  - href: A general link or reference field.
  - last_changed_at: A timestamp to track when the record was last modified, useful for concurrency control.

@EndUserText.label : 'Table to Store Customer details'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table zztmfcustomer {

  key id          : char10 not null;
  href            : char100;
  name            : char20 not null;
  status          : char20;
  statusreason    : char30;
  validfor        : datab;
  last_changed_at : timestampl;

}

Account Reference Table (zztmfaccountref):
- id, name: Combined primary key, ensuring each account reference has a unique ID and name combination.
- description: Additional details about the account reference.

@EndUserText.label : 'Account Reference'
@AbapCatalog.enhancement.category : #EXTENSIBLE_ANY
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table zztmfaccountref {

  key id          : char10 not null;
  key name        : char40 not null;
  href            : char100;
  description     : char255;
  last_changed_at : timestampl;

}

Primary Keys:
- Primary keys are essential for uniquely identifying each record in a database table. They ensure data integrity and are used to establish relationships between tables.
- In zztmfcustomer, id is the primary key.
- In zztmfaccountref, the combination of id and name forms the primary key.

CDS Views

CDS (Core Data Services) views are virtual data models defined on top of database tables. They simplify data access and provide features like data aggregation, calculations, and annotations. In RAP, CDS views are crucial for exposing data to the service layer.

CDS View Examples:
- Basic Customer View (ZC_TMF_Customer):
  - This view selects fields from the zztmfcustomer table and exposes them as the ZC_TMF_Customer entity.
  - The key annotation marks the id field as the key, which is essential for identifying customer records.

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Customer'
@Metadata.ignorePropagatedAnnotations: true
@Metadata.allowExtensions: true

define root view entity ZC_TMF_Customer 

  as select from zztmfcustomer as Customer 
composition [0..*] of  ZC_TMF_AccountRef as _AccountRef // on _AccountRef.customer_id = Customer.id
 composition [0..*] of ZC_TMF_AgreementRe as _AgreementRe // on _AgreementRe.customer_id = Customer.id
 composition [0..*] of ZC_TMF_ContactMedium as _ContactMedium // on _ContactMedium.customer_id = Customer.id
composition [0..*] of ZC_TMF_CreditProfile as _CreditProfile //on _CreditProfile.customer_id = Customer.id
composition [0..*] of ZC_TMF_EventInput as _EventInput //on _EventInput.customer_id = Customer.id
composition [0..*] of ZC_TMF_Characteristic as _Characteristic //on _EventInput.customer_id = Customer.id
composition [0..*] of ZC_TMF_EventSubscription as _EventSubscription // on _EventSubscription.customer_id = Customer.id
 composition [0..*] of ZC_TMF_PaymentMethod as _PaymentMethod // on _PaymentMethod.customer_id = Customer.id
composition [0..*] of ZC_TMF_RelatedParty as _RelatedParty // on _RelatedParty.customer_id = Customer.id
composition [0..*] of ZC_TMF_TimePeriod as _TimePeriod //on _TimePeriod.customer_id = Customer.id
 composition [0..*] of ZC_TMF_CustomerAttachment as _Attachments
   
{
  key 
Customer.id as customer_id,

  Customer.name as Name,
  Customer.href as Link,
  Customer.status as Status,
last_changed_at,
_AccountRef,
      _AgreementRe,
      _ContactMedium,
     _CreditProfile,
      _EventInput,
      _EventSubscription,
      _Characteristic,
      _PaymentMethod,
      _RelatedParty,
      _TimePeriod,
      _Attachments
}

Customer View with Associations (ZC_TMF_Customer):
- This view includes associations (_AccountRef, _AgreementRe, etc.) to child entities. These associations define the relationships between the Customer entity and its related data.
Associations:
- Associations in CDS views define relationships between entities. They allow you to navigate from one entity to another, retrieving related data.
- In our example, the associations in the ZC_TMF_Customer view enable you to access a customer's account references, agreements, and other related information.
- Associations are crucial for creating a hierarchical data structure and simplifying data retrieval.
- Why use associations to the parent? Associations from child entities back to the parent (_Customer) are used to establish the context of the child data. This is essential for:
  - Data integrity: Ensuring child records are linked to a valid parent.
  - Navigation: Allowing the UI and service to easily navigate from a child record to its corresponding customer.
  - Data retrieval: Simplifying queries to fetch child data in the context of a specific customer.

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'CDS view for Account Ref'
@Metadata.ignorePropagatedAnnotations: true
@Metadata.allowExtensions: true
//@AbapCatalog.sqlViewName: 'ZCTMFV_ACCR'
define view entity ZC_TMF_AccountRef as select from zztmfaccountref as accou
association to parent ZC_TMF_Customer  as _Customer on $projection.Id = _Customer.customer_id {

    key id as Id,
      key  name as name,
    accou.href as Href,
    description as Description,
 last_changed_at,
    _Customer
   
}

Composition:
- Composition is a stronger form of association that implies ownership. When you compose child entities within a parent, the lifecycle of the child is dependent on the parent. If you delete the parent, the children are typically deleted as well.
- While the provided CDS views use associations, composition would be suitable if the child entities exclusively belong to the parent Customer and should not exist independently.
- Why composition is used: Composition is used to model strong ownership relationships. It ensures data consistency and simplifies data management by automatically handling the lifecycle of child entities.

Metadata Annotations

Metadata annotations are used to enrich CDS views with semantic information that controls how the data is presented and processed by the UI and service layer.

Annotation Examples:
- @ui.lineItem:
  - This annotation specifies how the customer_Id field should be displayed in a list (e.g., in a table).
  - position: Determines the order of the column.
  - label: Provides a user-friendly column header.
  - importance: Controls the column's visibility based on screen size.
- @ui.facet:
  - This annotation defines sections or groups of fields in the UI (e.g., in an object page).
  - type: #IDENTIFICATION_REFERENCE: Creates an identification facet (header section).
  - type: #FIELDGROUP_REFERENCE: References a field group to display fields together.
  - position: Determines the order of the facet.
  - label: Provides a user-friendly header for the facet.

@Metadata.layer: #CUSTOMER
@UI: {
  headerInfo: {
    typeName: 'Customer',
    typeNamePlural: 'Customers',
    title: { type: #STANDARD, label: 'Customer ID', value: 'customer_id' },
    description: { label: 'Name', value: 'name' }
  }
}

annotate view ZC_TMF_Customer with
{
  @UI.facet: [
    { 
      id: 'General', 
      type: #IDENTIFICATION_REFERENCE,
      position: 10, 
      label: 'Customer Data'
    },
    { 
      type: #FIELDGROUP_REFERENCE, 
      position: 10, 
      targetQualifier: 'BasicInfo',
      parentId: 'General', 
      isSummary: true, 
      isPartOfPreview: true
    },
    { 
      id: 'AccountRefsFacet',
      purpose: #STANDARD, 
      type: #LINEITEM_REFERENCE,
      label: 'Account References', 
      position: 20, 
      targetElement: '_AccountRef'
    },
    { 
      id: 'AgreementReFacet',
      purpose: #STANDARD, 
      type: #LINEITEM_REFERENCE,
      label: 'Agreements', 
      position: 30, 
      targetElement: '_AgreementRe'
    },
   
    { 
      id: 'ContactMediumFacet',
      purpose: #STANDARD, 
      type: #LINEITEM_REFERENCE,
      label: 'Contact Mediums', 
      position: 40, 
      targetElement: '_ContactMedium'
    },
    { 
      id: 'CreditProfileFacet',
      purpose: #STANDARD, 
      type: #LINEITEM_REFERENCE,
      label: 'Credit Profiles', 
      position: 50, 
      targetElement: '_CreditProfile'
    },
    { 
      id: 'EventInputFacet',
      purpose: #STANDARD, 
      type: #LINEITEM_REFERENCE,
      label: 'Event Inputs', 
      position: 60, 
      targetElement: '_EventInput'
    },
    { 
      id: 'EventSubscriptionFacet',
      purpose: #STANDARD, 
      type: #LINEITEM_REFERENCE,
      label: 'Event Subscriptions', 
      position: 70, 
      targetElement: '_EventSubscription'
    },
    { 
      id: 'CharacteristicFacet',
      purpose: #STANDARD, 
      type: #LINEITEM_REFERENCE,
      label: 'Characteristics', 
      position: 80, 
      targetElement: '_Characteristic'
    },
    { 
      id: 'PaymentMethodFacet',
      purpose: #STANDARD, 
      type: #LINEITEM_REFERENCE,
      label: 'Payment Methods', 
      position: 90, 
      targetElement: '_PaymentMethod'
    },
    { 
      id: 'RelatedPartyFacet',
      purpose: #STANDARD, 
      type: #LINEITEM_REFERENCE,
      label: 'Related Parties', 
      position: 100, 
      targetElement: '_RelatedParty'
    },
        { 
      id: 'CustAttFacet',
      purpose: #STANDARD, 
      type: #LINEITEM_REFERENCE,
      label: 'Attachment', 
      position: 110, 
      targetElement: '_Attachments'
    },
    { 
      id: 'TimePeriodFacet',
      purpose: #STANDARD, 
      type: #LINEITEM_REFERENCE,
      label: 'Time Periods', 
      position: 120, 
      targetElement: '_TimePeriod'
    }
  ]

  // List and Identification fields
  @UI.lineItem: [{ position: 10, label: 'Customer ID', importance: #HIGH }]
  @UI.identification: [{ position: 10, label: 'Customer ID' }]
  @UI.selectionField: [{ position: 10 }]
  @EndUserText.label: 'Customer ID'
  customer_id;
  
  @UI.lineItem: [{ position: 20, label: 'Name', importance: #HIGH }]
  @UI.identification: [{ position: 20, label: 'Name' }]
  @UI.fieldGroup: [{ qualifier: 'BasicInfo', position: 10, importance: #HIGH }]
  Name;
  
  @UI.lineItem: [{ position: 30, label: 'Link', importance: #HIGH }]
  @UI.identification: [{ position: 30, label: 'Link' }]
  @UI.fieldGroup: [{ qualifier: 'BasicInfo', position: 20, importance: #HIGH }]
  Link;
  
  
  @UI.lineItem: [
  { position: 40, label: 'Status', importance: #HIGH },
  { type: #FOR_ACTION, dataAction: 'copy', label: 'Copy', position: 100 }
]
@UI.identification: [{ position: 40, label: 'Status' }]
@UI.fieldGroup: [{ qualifier: 'BasicInfo', position: 30, importance: #HIGH }]
Status;
//  @UI.lineItem: [{ position: 40, label: 'Status', importance: #HIGH }]
//  @UI.identification: [{ position: 40, label: 'Status' }]
//  @UI.fieldGroup: [{ qualifier: 'BasicInfo', position: 30, importance: #HIGH }]
//  
//  Status;

}

Associated Child Entities :

@Metadata.layer: #CUSTOMER
annotate entity ZC_TMF_AgreementRe
    with 
{
  @UI.facet: [
    { 
      type: #IDENTIFICATION_REFERENCE, 
      position: 10, 
      id: 'AgrHdr', 
      label: 'Agreement'
    },
    { 
      type: #FIELDGROUP_REFERENCE, 
      position: 10, 
      targetQualifier: 'AgrBasic', 
      parentId: 'AgrHdr',
      isSummary: true, 
      isPartOfPreview: true 
    }
  ]

  @UI.lineItem: [{ position: 10, label: 'ID', importance: #HIGH }]
  @UI.identification: [{ position: 10, label: 'ID' }]
  Id;
  
  @UI.lineItem: [{ position: 20, label: 'Href', importance: #HIGH }]
  @UI.identification: [{ position: 20, label: 'Href' }]
  @UI.fieldGroup: [{ qualifier: 'AgrBasic', position: 10, importance: #HIGH }]
  Href;
  
  @UI.lineItem: [{ position: 30, label: 'Name', importance: #HIGH }]
  @UI.identification: [{ position: 30, label: 'Name' }]
  @UI.fieldGroup: [{ qualifier: 'AgrBasic', position: 20, importance: #HIGH }]
  Name;
}

Behavior Definition

The behavior definition defines the behavior and properties of a RAP business object. It specifies the standard operations (CRUD - Create, Read, Update, Delete) and other actions that can be performed on the entity.

Behavior Definition Example (ZC_TMF_Customer):
- unmanaged implementation in class zbp_c_tmf_customer unique;: Specifies that we are responsible for implementing the behavior (CRUD operations) in the zbp_c_tmf_customer class.
- with draft;: Enables draft functionality for the entity.
- define behavior for ZC_TMF_Customer alias Customer: Defines the behavior for the ZC_TMF_Customer entity.
- authorization master ( instance 😞 Specifies authorization control.
- draft table ZZTMFCUSTOMER_d: Links the entity to its draft table.
- create; update; delete;: Enables the standard CRUD operations.
- action copy;: Defines a custom action.
- draft action ...: Enables draft-specific actions.
- field ( readonly ) customer_Id;: Makes the customer_Id field read-only.
- association ... { create; }: Defines associations to child entities and allows creating them.
- // validation ...: A commented-out example of validation logic.
Unmanaged Scenario:
- In an unmanaged scenario, the developer is responsible for writing the ABAP code to implement the standard CRUD operations and any custom business logic.
- Why use an unmanaged scenario?
  - Flexibility: Provides maximum control over the implementation.
  - Complex logic: Suitable for scenarios with intricate business rules or performance-critical operations.
  - Legacy integration: Can be necessary when integrating with existing, non-RAP code.
ETag:
- etag master last_changed_at: ETags (Entity Tags) are used for optimistic locking. They help prevent data loss when multiple users edit the same data concurrently.
- The last_changed_at field is used as the ETag. When a user updates a Customer, the last_changed_at value is checked against the value that the user originally read. If they don't match, it means someone else has changed the data in the meantime, and the update is prevented.
Entities:
- In the context of the behavior definition, "entities" refers to the instances of the business object (e.g., Customer records) that are being processed by the defined operations (Create, Update, Delete). For example, in a CREATE operation, "entities" would contain the data for the new Customer records being created.

unmanaged implementation in class zbp_c_tmf_customer unique;
with draft;

define behavior for ZC_TMF_Customer alias Customer
authorization master ( instance )
draft table ZZTMFCUSTOMER_d
etag master last_changed_at
lock master total etag last_changed_at
early numbering
{
  // Root entity
  create;
  update;
  delete;
  action copy;

  // Draft handling
  draft action Edit;
  draft action Activate;
  draft action Discard;
  draft action Resume;
  draft determine action Prepare;


  field ( readonly ) customer_Id;
  association _AccountRef { create; }
  association _AgreementRe { create; }
  association _ContactMedium { create; }
  association _CreditProfile { create; }
  association _EventInput { create; }
  association _EventSubscription { create; }
  association _Characteristic { create; }
  association _PaymentMethod { create; }
  association _RelatedParty { create; }
  association _TimePeriod { create; }
  association _Attachments{ create; }

  // Draft validation
 // validation validateName on save { create; update; }
}

define behavior for ZC_TMF_CUSTOMERATTACHMENT alias Attachment
implementation in class zbp_c_tmf_customer unique
draft table zztmcustatt_d
lock dependent
{
  field ( readonly ) AttachId, CustomerId; // Parent key
  field (mandatory ) Attachment;

  //create;
  update;

delete;
  association _Customer;
}
define behavior for ZC_TMF_AccountRef alias AccountRef
implementation in class zbp_c_tmf_customer unique
draft table zztmfaccount_d
lock dependent
{
  field ( readonly ) Id; // Parent key
  field (mandatory ) name;

  //create;
  update;

delete;
  association _Customer;
}

define behavior for ZC_TMF_AgreementRe alias AgreementRe
implementation in class zbp_c_tmf_customer unique
draft table zztmfagreem_d
lock dependent
{
  field ( readonly ) Id; // Parent key
  field ( mandatory) Name;
  //create;
  delete;
  update;
  association _Customer;
}

define behavior for ZC_TMF_ContactMedium alias ContactMedium
implementation in class zbp_c_tmf_customer unique
draft table zztmfcontactme_d
lock dependent
{
  field ( readonly ) customer_id; // Parent key
  field ( mandatory ) Mediumtype;
  update;
  //create;
  delete;
  association _Customer;
}

define behavior for ZC_TMF_CreditProfile alias CreditProfile
implementation in class zbp_c_tmf_customer unique
draft table zztmfcreditpro_d
lock dependent
{
  field ( readonly ) customer_id; // Parent key
  field ( mandatory ) Creditprofiledate;
  update;
  //create;
  delete;
  association _Customer;
}

define behavior for ZC_TMF_Characteristic alias Characteristic
implementation in class zbp_c_tmf_customer unique
draft table zztmfcharacte_d
lock dependent
{
  field ( readonly ) id, customer_id; // Parent key
  field ( mandatory ) Name, Value;
  update;
  //create;
  delete;
  association _Customer;
}

define behavior for ZC_TMF_EventInput alias EventInput
implementation in class zbp_c_tmf_customer unique
draft table zztmfeventinp_d
lock dependent
{
  field ( readonly ) customer_id; // Parent key
  field ( mandatory ) Callback;
  update;
  //create;
  delete;
  association _Customer;
}

define behavior for ZC_TMF_EventSubscription alias EventSubscription
implementation in class zbp_c_tmf_customer unique
draft table zztmfeventsubs_d
lock dependent
{
  field ( readonly ) customer_Id; // Parent key
  field ( mandatory ) Callback;
  update;
  //create;
  delete;
  association _Customer;
}

define behavior for ZC_TMF_PaymentMethod alias PaymentMethod
implementation in class zbp_c_tmf_customer unique
draft table zztmfpaymentme_d
lock dependent
{
  field ( readonly ) customer_Id; // Parent key
  field ( mandatory ) Name;
  update;
  //create;
  delete;
  association _Customer;
}

define behavior for ZC_TMF_RelatedParty alias RelatedParty
implementation in class zbp_c_tmf_customer unique
draft table zztmfrelatedpa_d
lock dependent
{
  field ( readonly ) customer_Id; // Parent key
  field ( mandatory ) Name, Role;
  update;
  //create;
  delete;
  association _Customer;
}

define behavior for ZC_TMF_TimePeriod alias TimePeriod
 implementation in class zbp_c_tmf_customer unique
 draft table zztmftimeperi_d
 lock dependent
{
  field ( readonly ) customer_id; // Parent key
  field ( mandatory ) Startdatetime;
  update;
  delete;
  //create;
  association _Customer;
}

Conclusion

In Part 1, we defined the foundation of our Customer Management application by creating the data model, CDS views, and behavior definition. We explored key concepts like primary keys, associations, metadata annotations, and the unmanaged RAP scenario.