SAP Community - ABAP RESTful Application Programming Model

Using Prechecks and how to combine them.

2024-02-09T16:00:46.387000+01:00

A very common activity when working with RAP and Fiori Elements is the validation of user input. Unfortunately, validations are only ever carried out when saving and you often want to give the user feedback earlier - especially when using draft mode. What is the best way to do this? The way to go in this case is to use prechecks. So far all good, but unfortunately the wizard makes it a bit more difficult than necessary, because after defining the prechecks in the behavior definition (or the behavior projection, which I prefer to use) it generates 2 methods if you want to perform the same check for CREATE and UPDATE - e.g. that the customer number should always be filled.

define behavior for ZC_MyEntity alias Entity

{
  use create ( augment, precheck );
  use update ( augment, precheck );
  use delete;
}

The following is generated here:

    METHODS precheck_create FOR PRECHECK
      IMPORTING entities FOR CREATE Entity.

    METHODS precheck_update FOR PRECHECK
      IMPORTING entities FOR UPDATE Entity.

However, a look at the documentation shows that there is a simpler way:

    METHODS precheck FOR PRECHECK
      IMPORTING entities_create FOR CREATE Entity
                entities_update FOR UPDATE Entity.

So that you only have to go through one loop, you then pack the almost identical structures together.

  METHOD precheck.

    DATA(entities_check) = entities_create.

    entities_check = VALUE #( BASE entities_check FOR entity_update IN entities_update
                             ( CORRESPONDING #( entity_update ) ) ).

    LOOP AT entities_check INTO DATA(entitiy_check).

    ENDLOOP.

  ENDMETHOD.

This approach saves code duplication and also makes maintenance easier.

Important

If you use DRAFT, then, depending on the use case, you unfortunately still have to read the "unchanged fields" during the update, as only the delta (i.e. the changed fields) is transferred via a PATCH. This is hopefully done before the loop - you can find here my personal favorit on how to this.

I hope this helps you and makes your life easier - enjoy 😀

Prechecks on Update in RAP when using DRAFT

2024-02-11T15:58:56.151000+01:00

I already wrote a small Post on Combination of Prechecks - but when using Prechecks in DRAFT- enabled scenarios, you'll face an other Problem: Updates only contain changed fields - how to deal with it?

First, we look at the definition. This can be done both at the level of the behavior definition and at the level of the behavior projection - I personally usually prefer this in the projection, as it makes sense to map the check again as a Determination on Save, so that a clean integrity of the BO is ensured:

define behavior for ZC_MyEntity alias Header
{
  use create ( augment, precheck );
  use update ( augment, precheck );
  use delete;
  ...
}

After defining the behavior, we come to the method definition:

    METHODS precheck FOR PRECHECK
      IMPORTING entities_create FOR CREATE Header
                entities_update FOR UPDATE header.

And yes: last but not least, implementation:

    DATA(entities_check) = entities_create.

    LOOP AT entities_update INTO DATA(entity_update).

      READ ENTITIES OF ZC_MyEntity IN LOCAL MODE
           ENTITY Header
           ALL FIELDS WITH VALUE #( ( %tky = entity_update-%tky ) )
           RESULT DATA(header_read).

      IF lines( header_read ) = 0.
        CONTINUE.
      ENDIF.

      APPEND INITIAL LINE TO entities_check ASSIGNING FIELD-SYMBOL(<entity_check>).

      <entity_check> = CORRESPONDING #( header_read[ 1 ] ).
      <entity_check> = CORRESPONDING #( BASE ( <entity_check> ) entity_update USING CONTROL ).

    ENDLOOP.


    LOOP AT entities_check INTO DATA(entity_check).
* Here are our checks!
    ENDLOOP.

What do we do here?

Line 1: Here we define a variable that should finally contain ALL entries that we want to check
Line 3: We loop over the ENTITIES_UPDATE, as we have to read the other contents for these
Line 5: Now comes a READ ENTITIES - depending on where we implement our precheck, on the ZI_* or the ZC_*
Line 7: This is particularly important for DRAFT newcomers! We do not use %KEY, but %TKY - we may want to read the content of the DRAFT - and not what is only activated.
Line 10: As always, we should also make sure that there is already something and that we are not in the first change
Line 17: Now we combine "old values" and "new values" - we use the CONTROL flags that RAP provides us with instead of performing a manual comparison
Line 22ff: Now we can let off steam with all our magic 🙂

Enjoy!

CRUD Operation Using RESTful API in SAP

2024-02-13T09:02:35.581000+01:00

Title: CRUD Operation Using RESTful API in SAP

Introduction:

SAP (Systems, Applications, and Products in Data Processing) is a renowned enterprise resource planning (ERP) software and integrating RESTful APIs with SAP can significantly enhance its capabilities. In this blog, we will delve into the basics of CRUD operations in REST API within the SAP environment, exploring the fundamental concepts and demonstrating how to perform Create, Read, Update, and Delete operations seamlessly.

Understanding CRUD Operations:

CRUD operations form the core of database interactions and are crucial for any application's functionality. In a REST API context, CRUD corresponds to the following HTTP methods:

Create (POST): This method is used to add new data to the server.

Read (GET): Retrieve information from the server without modifying it.

Update (PUT): Modify existing data on the server.

Delete (DELETE): Remove data from the server.

Setting Up SAP for REST API Integration:

Before diving into CRUD operations, you need to ensure that your SAP environment is set up to support REST API integration. This may involve configuring SAP Gateway, enabling web services, and securing communication between SAP and your application.

In this blog, we'll explore how to Perform CRUD operation from Restful API

Generally REST describes a machine-to-machine interface. In Web development, REST allows content to be rendered when it is requested, often referred to as Dynamic Content. RESTful Dynamic content uses server-side rendering to generate a Web site and send the content to the requesting Web browser, which interprets the server’s code and renders the page in the user’s Web browser.

PROCEDURE: -

Here We have to create structure and table type for sales order line-item condition

Here we have to create structure and table type for Sales order line item and pass Deep component(Structure which includes a Table type).

Here we have to create Structure for sales order header information and here we have to pass Deep component(Structure which includes a Table type).

In SE24 create a class for request provider and request handler class.

GET OPERATION: -

METHOD if_rest_resource~get. 
    DATA : ls_so    TYPE zna_ty_sales_order, 
            lv_result   TYPE string, 
            lv_vbeln TYPE vbeln. 
 
    DATA : ls_item_condition TYPE zna_ty_sales_ord_item_cond, 
            lt_item_condition TYPE STANDARD TABLE OF zna_ty_sales_ord_item_cond, 
            ls_item           TYPE zna_ty_sales_ord_item, 
            lt_item           TYPE STANDARD TABLE OF zna_ty_sales_ord_item. 
 
    "read the uri parameter 
     lv_vbeln = mo_request->get_uri_query_parameter( 
                  iv_name    = 'VBELN' 
*                 iv_encoded = abap_true 
                ). 
 
    IF lv_vbeln IS NOT INITIAL. 
      lv_vbeln = |{ lv_vbeln ALPHA = IN }|.                 . 
       " Select header data 
 
      select SINGLE * FROM vbak INTO @DATA(ls_vbak) WHERE vbeln = @lv_vbeln. 
         IF ls_vbak-vbeln IS NOT INITIAL. 
 
"select line item data 
SELECT * FROM vbap INTO TABLE @DATA(lt_vbap) WHERE vbeln = @ls_vbak-vbeln. 
 
  "select conditions 
   SELECT * FROM konv INTO TABLE @DATA(lt_konv) WHERE knumv = @ls_vbak-knumv. 
 
    "pass the data to structure 
 
    ls_so-VBELN  = ls_vbak-vbeln. 
     ls_so-KUNNR  = ls_vbak-kunnr. 
     ls_so-VKORG  = ls_vbak-vkorg. 
     ls_so-VTWEG  = ls_vbak-vtweg. 
     ls_so-SPART  = ls_vbak-spart. 
     ls_so-BSTNK  = ls_vbak-bstnk. 
     ls_so-BSTDK  = ls_vbak-bstdk. 
*   MESSAGE 
*    ITEMS 
 
    LOOP AT lt_vbap INTO DATA(ls_vbap). 
       clear ls_item. 
       MOVE-CORRESPONDING ls_vbap TO ls_item. 
 
 
      LOOP AT lt_konv INTO DATA(ls_konv) WHERE knumv = ls_vbak-knumv 
                                              and kposn = ls_vbap-posnr. 
 
        CLEAR ls_item_condition. 
 
       ls_item_condition-VBELN = ls_vbap-vbeln. 
        ls_item_condition-POSNR = ls_vbap-posnr. 
        ls_item_condition-KPOSN = ls_konv-kposn. 
        ls_item_condition-stunr = ls_konv-stunr. 
        ls_item_condition-KSCHL = ls_konv-kschl. 
        ls_item_condition-KWERT = ls_konv-kwert. 
 
       APPEND ls_item_condition TO lt_item_condition. 
 
CLEAR ls_konv. 
       ENDLOOP. 
 
      ls_item-item_condition[] = lt_item_condition[]. 
 
      APPEND ls_item TO lt_item. 
 
CLEAR : ls_vbap,lt_item_condition[]. 
     ENDLOOP. 
 
    ls_so-items[] = lt_item[]. 
 
    ELSE. 
       ls_so-message = 'Sales order does not exist'. 
       ENDIF. 
 
 
      ELSE. 
    ls_so-message = 'Kindly enter the sales order number'. 
     ENDIF. 
 
    /ui2/cl_json=>serialize( 
       EXPORTING 
         data             =    ls_so   
       RECEIVING 
         r_json           =  lv_result                 " JSON string 
     ). 
 
    mo_response->create_entity( )->set_string_data( iv_data = lv_result  ). 
 
    mo_response->set_header_field( 
       EXPORTING 
         iv_name  =    'content-Type'              " Header Name 
         iv_value =    'application/json'              " Header Value 
     ). 
  ENDMETHOD.

Implement the request handler class method “GET_ROOT_HANDLER”

method IF_REST_APPLICATION~GET_ROOT_HANDLER. 
   
     DATA(lv_router) = NEW cl_rest_router( ). 
     lv_router->attach( 
       EXPORTING 
         iv_template      = '/zna_so'                 " Unified Name for Resources 
         iv_handler_class =  ' ZCL_NA_REST_RESOURCE_EXT '                " Object Type Name 
*        it_parameter     =                  " Resource contructor parameters 
     ). 
 
    ro_root_handler = lv_router. 
 
  endmethod.

In T-code:- SCIF, we have to create host and test the service.

In this we have to add Handler name and provide sales order number and click on enter.

We have to execute browser and postman tool also.

CREATE OPERATION(POST): -

Here we are inserting the data into the sales order database table.

method IF_REST_RESOURCE~POST. 
  DATA : lv_string1 type VBELN,                "string, 
             lv_string2 type string, 
             lv_response TYPE string, 
             ls_so TYPE zna_t_so. 
 
DATA(lv_entity) = mo_request->get_entity( ). 
  DATA(lv_responce1) = mo_response->create_entity( ). 
 
*Read string data i.e json 
  DATA(lv_json) = lv_entity->get_string_data( ). 
 
/ui2/cl_json=>deserialize( 
    EXPORTING 
      json             =   lv_json              " JSON string 
   
    CHANGING 
      data             =    ls_so             " Data to serialize 
  ). 
INSERT INTO zna_t_so VALUES ls_so. 
 
/ui2/cl_json=>serialize( 
    EXPORTING 
      data             =  ls_so                " Data to serialize 
   
    RECEIVING 
      r_json           =     lv_response             " JSON string 
  ). 
 
lv_responce1->set_string_data( iv_data = lv_response ). 
   endmethod.

Before doing post operation we can get csrf token from the postman tool and after getting token we can pass to value tab.

In body section, we need to pass the record and click on send.

Here we get success code 200 output data will be successfully inserted.

Data will be inserted .

UPDATE OPERATION(PUT): -

method IF_REST_RESOURCE~PUT. 
  DATA : lv_string1 type VBELN,                "string, 
             lv_string2 type string, 
             lv_response TYPE string, 
             ls_so TYPE zna_t_so. 
 
DATA(lv_entity) = mo_request->get_entity( ). 
  DATA(lv_responce1) = mo_response->create_entity( 
*                         iv_multipart = abap_false 
                      ). 
 
*Read string data i.e json 
  DATA(lv_data) = lv_entity->get_string_data( ). 
 
/ui2/cl_json=>deserialize( 
    EXPORTING 
      json             =   lv_data               " JSON string 
   
    CHANGING 
      data             =    ls_so             " Data to serialize 
  ). 
 
UPDATE ZNA_T_SO FROM ls_so. 
 
/ui2/cl_json=>serialize( 
    EXPORTING 
      data             =  ls_so                " Data to serialize 
   
    RECEIVING 
      r_json           =     lv_response             " JSON string 
  ). 
 
lv_responce1->set_string_data( iv_data = lv_response ). 
   endmethod.

We can change the field value and click on send.

BEFORE: -

AFTER: -

DELETE OPERATION: -

METHOD if_rest_resource~delete. 
     DATA : lv_string1  TYPE vbeln,                "string, 
            lv_string2  TYPE string, 
            lv_response TYPE string, 
            ls_so       TYPE zna_t_so. 
 
    DATA(lv_entity) = mo_request->get_entity( ). 
     DATA(lv_responce1) = mo_response->create_entity( 
*                         iv_multipart = abap_false 
                         ). 
 
*Read string data i.e json 
     DATA(lv_data) = lv_entity->get_string_data( ). 
 
    /ui2/cl_json=>deserialize( 
        EXPORTING 
          json             =   lv_data               " JSON string 
   
        CHANGING 
          data             =    ls_so             " Data to serialize 
      ). 
 
 
 
    DELETE zna_t_so FROM ls_so. 
 
    /ui2/cl_json=>serialize( 
        EXPORTING 
          data             =  ls_so                " Data to serialize 
   
        RECEIVING 
          r_json           =     lv_response             " JSON string 
      ). 
 
    lv_responce1->set_string_data( iv_data = lv_response ). 
   ENDMETHOD.

Here we delete the value 00000000003.

BEFORE DELETE: -

AFTER DELETE: -

How to create a value help for custom and released domain fixed values?

2024-02-15T02:15:22.925000+01:00

Introduction

For creating value helps based on domain fixed values in ABAP Cloud the recommendation so far was to create custom CDS views based on the released CDS views DDCDS_CUSTOMER_DOMAIN_VALUE and DDCDS_CUSTOMER_DOMAIN_VALUE_T.

The drawback of this solution is

that you have to create dedicated CDS views for each domain and
that the aforementioned CDS views only work for domains that reside in software components owned by customers.

Based on a question in a forum of the German SAP user group DSAG where the question was raised whether there is no alternative solution I thought again about this requirement.

Instead of using CDS views it is possible just use one single custom entity which uses RTTI to retrieve the domain fixed values.

Result

When adding the new value help to the projection view as follows:

      @Consumption.valueHelpDefinition: 
      [{ entity: { name : 'ZI_DOMAIN_FIX_VAL' , element: 'low' } ,
         additionalBinding: [{ element: 'domain_name',
                               localConstant: 'BEL_API_RETCODE', usage: #FILTER }]
                               , distinctValues: true
                               }]
      Low,

We get the following result:

Implementation

The challenge to get this to work with just one custom entity is, to provide the name of the domain that is used as a value help via additional binding.

This can be achieved by using localConstant key word and in addition it needs the usage parameter set to #FILTER. This way we can specify the name of the domain whose domain fixed values shall be used within the coding.

Be careful !

It doesn't work if the element ("domain_name" in this case) is hidden in the Value Help CDS View (e.g. through "UI.hidden: true").

Custom Entity

The DDL source code of the custom entity looks like this:

@EndUserText.label: 'Get domain fix values'
@ObjectModel.resultSet.sizeCategory: #XS
@ObjectModel.query.implementedBy: 'ABAP:ZCL_GET_DOMAIN_FIX_VALUES'
define custom entity ZI_DOMAIN_FIX_VAL
{
      @EndUserText.label     : 'domain name'
      @UI.hidden : true 
  key domain_name : sxco_ad_object_name;
      @UI.hidden  : true
  key pos         : abap.numc( 4 );
      @EndUserText.label     : 'lower_limit'
      low         : abap.char( 10 );
      @EndUserText.label     : 'upper_limit'
      high        : abap.char(10);
      @EndUserText.label     : 'Description'
      description : abap.char(60);


}

Query implementation class

And the code of the query implementation class is as follows:

The domain name is retrieved from the filter that is filled via the additional binding.

Once the domain name has been retrieved the domain fixed values are being retrieved using RTTI as described in the following blog post Fetching texts for domain fixed values - SAP Community by Michał Badura.

Another option would be to use the XCO library.

CLASS zcl_get_domain_fix_values DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC .

  PUBLIC SECTION.
    INTERFACES if_rap_query_provider.
  PROTECTED SECTION.
  PRIVATE SECTION.
ENDCLASS.



CLASS zcl_get_domain_fix_values IMPLEMENTATION.


  METHOD if_rap_query_provider~select.
    DATA business_data TYPE TABLE OF zi_domain_fix_val .
    DATA business_data_line TYPE zi_domain_fix_val .
    DATA(top)     = io_request->get_paging( )->get_page_size( ).
    DATA(skip)    = io_request->get_paging( )->get_offset( ).
    DATA(requested_fields)  = io_request->get_requested_elements( ).
    DATA(sort_order)    = io_request->get_sort_elements( ).

    DATA domain_name  TYPE sxco_ad_object_name  .
    DATA pos TYPE i.

    TRY.
        DATA(filter_condition_string) = io_request->get_filter( )->get_as_sql_string( ).
        DATA(filter_condition_ranges) = io_request->get_filter( )->get_as_ranges(  ).

        READ TABLE filter_condition_ranges WITH KEY name = 'DOMAIN_NAME'
               INTO DATA(filter_condition_domain_name).

        IF filter_condition_domain_name IS NOT INITIAL.
          domain_name = filter_condition_domain_name-range[ 1 ]-low.
        ELSE.
          "do some exception handling
          io_response->set_total_number_of_records( lines( business_data ) ).
          io_response->set_data( business_data ).
          EXIT.

        ENDIF.

        business_data_line-domain_name = domain_name .

        CAST cl_abap_elemdescr( cl_abap_typedescr=>describe_by_name( domain_name ) )->get_ddic_fixed_values(
          EXPORTING
            p_langu        = sy-langu
          RECEIVING
            p_fixed_values = DATA(fixed_values)
          EXCEPTIONS
            not_found      = 1
            no_ddic_type   = 2
            OTHERS         = 3 ).

        IF sy-subrc > 0.
          "do some exception handling
          io_response->set_total_number_of_records( lines( business_data ) ).
          io_response->set_data( business_data ).
          EXIT.
        ENDIF.

        LOOP AT fixed_values INTO DATA(fixed_value).
          pos += 1.
          business_data_line-pos = pos.
          business_data_line-low = fixed_value-low .
          business_data_line-high = fixed_value-high.
          business_data_line-description = fixed_value-ddtext.
          APPEND business_data_line TO business_data.
        ENDLOOP.

        IF top IS NOT INITIAL.
          DATA(max_index) = top + skip.
        ELSE.
          max_index = 0.
        ENDIF.

        SELECT * FROM business_data AS data_source_fields
           WHERE (filter_condition_string)
           INTO TABLE business_data
           UP TO max_index ROWS.

        IF skip IS NOT INITIAL.
          DELETE business_data TO skip.
        ENDIF.

        io_response->set_total_number_of_records( lines( business_data ) ).
        io_response->set_data( business_data ).

      CATCH cx_root INTO DATA(exception).
        DATA(exception_message) = cl_message_helper=>get_latest_t100_exception( exception )->if_message~get_longtext( ).

        DATA(exception_t100_key) = cl_message_helper=>get_latest_t100_exception( exception )->t100key.

        "do some exception handling

    ENDTRY.
  ENDMETHOD.
ENDCLASS.

Creating tree tables with OData V4 on SAP BTP ABAP Environment

2024-02-15T09:48:04.555000+01:00

Since end of last year, it is possible to implement hierarchies in SAP BTP ABAP Environment. Since this feature is fairly easy to implement, here is an end-to-end guide on how to create tree tables on ABAP Environment.

Step 1: Create a ABAP Package with a name of your choice

Step 2: Create a database table

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

  key employee_id : abap.char(20) not null;
  first_name      : abap.sstring(255);
  last_name       : abap.sstring(255);
  salary          : abap.dec(8,2);
  salary_currency : abap.cuky;
  manager         : abap.char(20);

}

Step 3: Create ABAP Class and fill table with demo data
Note: make sure to add the if_oo_adt_classrun interface to you class to be able to execute the class.

CLASS z_fill_employee_data DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC .

  PUBLIC SECTION.

    INTERFACES if_oo_adt_classrun .

    DATA:
        lt_employees TYPE TABLE OF zmriemployee.

  PROTECTED SECTION.
  PRIVATE SECTION.
ENDCLASS.



CLASS z_fill_employee_data IMPLEMENTATION.


  METHOD if_oo_adt_classrun~main.

    APPEND VALUE #(
      employee_id = '00000001'
      first_name = 'John'
      last_name = 'Travolta'
      salary = '100000.99'
      salary_currency = 'CHF'
 ) TO lt_employees.


    APPEND VALUE #(
      employee_id = '00000002'
      first_name = 'Will'
      last_name = 'Smith'
      salary = '80000.99'
      salary_currency = 'USD'
      manager = '00000001' ) TO lt_employees.


    APPEND VALUE #(
      employee_id = '00000003'
      first_name = 'Jessica'
      last_name = 'Alba'
      salary = '85000.99'
      salary_currency = 'CHF'
      manager = '00000002' ) TO lt_employees.


    APPEND VALUE #(
      employee_id = '00000004'
      first_name = 'Monica'
      last_name = 'Belucci'
      salary = '45987.99'
      salary_currency = 'EUR'
      manager = '00000002' ) TO lt_employees.


    APPEND VALUE #(
      employee_id = '00000005'
      first_name = 'Jack'
      last_name = 'Nicolson'
      salary = '80000.99'
      salary_currency = 'CHF'
      manager = '00000002' ) TO lt_employees.

    APPEND VALUE #(
      employee_id = '00000006'
      first_name = 'Cameron'
      last_name = 'Diaz'
      salary = '47856.99'
      salary_currency = 'USD'
      manager = '00000005' ) TO lt_employees.


    out->write( name = `Employee data to be inserted:` data = lt_employees ).

    DELETE FROM zmriemployee.

    INSERT zmriemployee FROM TABLE @lt_employees.

    COMMIT WORK.

    CLEAR lt_employees.

    out->write( `Insert successful ` ).

  ENDMETHOD.
ENDCLASS.

The table data should look like this:

Note: there is a relationship between the employee_id and the manager field. Where the field manager is empty (i.e. inital), we have no allocation to another employee, hence this person is the highest ranked employee.

Step 4: Create view entity as interface view for employee data
When creating the data definition, choose the view entity template and import all fileds into the view (CTRL + SPACE) and implement the many to one association to the database table

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Interface view for employee demo data'
@Metadata.ignorePropagatedAnnotations: true
@ObjectModel.usageType:{
    serviceQuality: #X,
    sizeCategory: #S,
    dataClass: #MIXED
}
@Metadata.allowExtensions: true
define view entity Z_I_EMPLOYEE_DATA as select from zmriemployee
  association of many to one Z_I_EMPLOYEE_DATA as _Manager on $projection.Manager = _Manager.EmployeeId
{
   key employee_id as EmployeeId,
    first_name as FirstName,
    last_name as LastName,
    salary as Salary,
    salary_currency as SalaryCurrency,
    manager as Manager,
    
    _Manager
}

Step 5: Define Hierarchy mapping
When creating the data definition, choose the Define Parent Child Hierarchy Template and define the hierarchy relationship.

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Hierarchy: Read Only: Employee Hierarchy'

define hierarchy Z_I_EMPLOYEE_DATA_HN
  as parent child hierarchy(
    source Z_I_EMPLOYEE_DATA
    child to parent association _Manager
    start where
      Manager is initial
    siblings order by
      LastName ascending
  )
{
  key EmployeeId,
      Manager
}

Step 6: Create consumption view (data definition) with reference to the hierarchy entity.

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Hierarchy: Read Only: Employee'

@Metadata.allowExtensions: true
@Search.searchable: true

@OData.hierarchy.recursiveHierarchy:[{ entity.name: 'Z_I_EMPLOYEE_DATA_HN' }]

define view entity Z_C_EMPLOYEE_DATA
  as select from Z_I_EMPLOYEE_DATA
  association of many to one Z_C_EMPLOYEE_DATA as _Manager on $projection.Manager = _Manager.EmployeeId
{

  key EmployeeId,

      @Search: {
      defaultSearchElement: true}
      FirstName,

      LastName,

      Salary,

      SalaryCurrency,

      Manager,

      /* Associations */
      _Manager
}

Step 7: Create Metadata Extension with UI5 annotations.

@Metadata.layer: #CORE
@UI: { headerInfo: {
                     typeName: 'Employee',
                     typeNamePlural: 'Employees',
                     title: { type: #STANDARD, value: 'EmployeeId' }
                   },
       presentationVariant: [{
           sortOrder: [{ by: 'EmployeeId', direction: #ASC }],
           visualizations: [{type: #AS_LINEITEM}]
         }]
     }
annotate entity Z_C_EMPLOYEE_DATA
    with 
{
@UI: {
      facet:          [
                       { id:            'EmployeeId',
                         purpose:       #STANDARD,
                         type:          #IDENTIFICATION_REFERENCE,
                         label:         'EmployeeId',
                         position:      10
                       }
                      ]
    }

  @UI: {
      lineItem:       [{ position: 20 , label: 'The emoloyee id'}],
      identification: [{ position: 20 }]
    }
  EmployeeId;

  @UI: {
      selectionField: [{ position: 30 }],
      lineItem:       [{ position: 30 }],
      identification: [{ position: 30 }]
    }
  FirstName;

  @UI: {
      selectionField: [{ position: 30 }],
      lineItem:       [{ position: 40 }],
      identification: [{ position: 40 }]
    }
  LastName;

  @UI: {
      lineItem:       [{ position: 50 }],
      identification: [{ position: 50 }]
    }
  Salary;

  @UI: {
      lineItem:       [{ position: 70 }],
      identification: [{ position: 70 }]
    }
  Manager;
    
}

Step 8: Create Service Definition to expose the consumption view.

@EndUserText.label: 'Service Defintion'
@ObjectModel.leadingEntity.name: 'Z_C_EMPLOYEE_DATA'
define service Z_UI_Employee_DATA {
  expose Z_C_EMPLOYEE_DATA as Employee;
}

Step 9: Create Service Binding of Binding Type "OData V4 UI" and publish service binding.

Step 10: Click on the preview button and voilà: the table is rendered with a tree structure.

Note: It is important to comply with the data type and strucure of the node_id which is the central component for rendering the tree structure. If you are running into an error when calling your Fiori Fontend, use the Ecplise Debugger to trace down the error. Most likely it is because the field which is used for the hierarchy association does not match the expected data type and you will run into an ABAP Runtime error (e.g. RAISE_SHORTDUMP) or a HTTP error ($batch failed).

Dynamically show/hide enable/disable fields in Fiori Elements

2024-02-19T08:05:02.709000+01:00

Sometimes you need to hide or disable the field in UI dynamically based on condition, for example based on entered data in edit mode.

You can make it in backend using hide annotation with value based on control field. Changing the value of control field via value help additional bindings or determination with side effects.

Use Case: In our app for order creation user is entering order code first. Based on the value of order code the device location field or the device number field should be enabled dynamically in edit mode. I one is enabled for entering the other must be read only.

1. Hide annotation based on another field

First of all we create two additional read only fields in Interface and projection views

devloc as deviceLocation,
devloc as deviceLocationRO,
...
_Equipment.SerialNumber as deviceNumber,
_Equipment.SerialNumber as deviceNumberRO,

Then we make read only fields read only in behaviour definition

field ( readonly ) deviceNumberRO, deviceLocationRO;

The idea is to hide the editable field showing the readonly field what makes user thinking the field is disabled/enabled dynamically.

So we add another four control fields, which will contain true or false based on condition, and will be used as value for hide annotation

_OrderCode.hideDevLoc as hideDevLocation,
_OrderCode.hideSerNum as hideDevNumber,
_OrderCode.hideDevLocRO as hideDevLocationRO,
_OrderCode.hideSerNumRO as hideDevNumberRO,

We need four of them to be able to hide all of fields until user enters order code.

Now we bind all this together, making aur fields be hideable depending of the value of control fields. I am using annotation.xml in UI, but the same can be done in backend metadata extension.

<Record Type="UI.DataField">
  <PropertyValue Property="Value" Path="deviceNumber"/>
  <Annotation Term="UI.Hidden" Path="hideDeviceNumber" />
</Record>
<Record Type="UI.DataField">
  <PropertyValue Property="Value" Path="deviceNumberRO"/>
  <Annotation Term="UI.Hidden" Path="hideDevNumberRO" />
</Record>
...
<Record Type="UI.DataField">
  <PropertyValue Property="Value" Path="deviceLocationRO"/>
  <Annotation Term="UI.Hidden" Path="hideDevLocationRO" />
</Record>
<Record Type="UI.DataField">
  <PropertyValue Property="Value" Path="deviceLocation"/>
  <Annotation Term="UI.Hidden" Path="hideDevLocation"/>
</Record>
...

In the same way for deviceLocation and deviceLocationRO.

The next step here is to set the values of control fields as additional binding of order code value help view ZI_DM_CSORDER_OCODE_VH:

define view ZI_DM_CSORDER_OCODE_VH
  as select from ...
{
...
@UI.hidden: true
cast(case when bzgsobjtyp='01' then 'X' else '' end as boolean) as hideSerNum,
@UI.hidden: true
cast(case when bzgsobjtyp='03' then 'X' else '' end as boolean) as hideDevLoc,
@UI.hidden: true
cast(case when bzgsobjtyp='01' then '' else 'X' end as boolean) as hideSerNumRO,
@UI.hidden: true
cast(case when bzgsobjtyp='03' then '' else 'X' end as boolean) as hideDevLocRO,
...
}

Value Help for order code is defined as following:

@Consumption.valueHelpDefinition: [
      { entity : {name: 'ZI_DM_CSORDER_OCODE_VH', element: 'orderCode'},
      { localElement: 'hideDevLocation', element: 'hideDevLoc', usage: #RESULT  },
      { localElement: 'hideDevNumber', element: 'hideSerNum', usage: #RESULT  },
      { localElement: 'hideDevLocationRO', element: 'hideDevLocRO', usage: #RESULT  },
      { localElement: 'hideDevNumberRO', element: 'hideSerNumRO', usage: #RESULT  }
      ]
orderCode,

As of now, when user changed order code, the control fields hideDevice* will be updated with the values generated in value help view causing dynamically hiding of fields in edit mode. The same behaviour may be achieved with determination code and side effects.

How it looks in UI.

Case 1 - user enters order code for device location. Device location is showing, device number is hided.

Case 2 - user enters order code for device number. Device number is showing for edit, device location is showing read only, because it will be determined later based on device number data.

CDS-based BOPF to RAP Migration Tool

2024-02-20T09:28:33.171000+01:00

CDS-based BOPF to RAP Migration Tool

Have you built CDS-based BOPF business objects using the ABAP Programming Model for SAP Fiori and ever wondered whether and how they can be integrated into ABAP RESTful Application Programming Model (RAP)?

With SAP S/4HANA 2023 and SAP S/4HANA Cloud Private Edition 2023, the long-awaited migration tool is now available for pilot customers.

Follow the instructions provided in SAP Note 3392337 to enable the tool for your system.

Upgrade your existing CDS-based BOPF BOs

But why should you migrate your existing business objects (BOs) based on Core Data Service (CDS) and the Business Object Processing Framework (BOPF) to RAP?

RAP is an essential element of ABAP Cloud and offers great new concepts and features to enhance and interact with RAP business objects:

Interact programmatically with RAP BOs using the Entity Manipulation Language (EML),
easily expose RAP BOs as OData V2 or V4 services for Integration Services or SAP Fiori,
define and raise RAP Business Events,
use or enable developer extensibility for modification-free enhancements,
apply the same standard development model as used in SAP S/4HANA.

You can benefit from these capabilities and enhance your business object with new RAP features while reusing your implemented business logic. Your existing OData service and Fiori application can continue to be used as well. Nevertheless, adapting to the RAP standard by modernizing your service exposure to service definition and service binding is a worthwhile investment.

CDS-based BOPF to RAP Migration and ABAP Cloud

A migration of your CDS-based BOPF BO opens the possibility to enable your BO for consumption in the 3-Tier Extensibility Model of ABAP Cloud: A new RAP BO Interface with release contract Use System-Internally ( Contract C1 ) and visibility Use in Cloud Development can be defined for the migrated BO. The BOPF BO remains in Tier 3 and therefore is not part of ABAP Cloud. However, the business logic can now be consumed in ABAP Cloud via the released RAP BO interface.

The Migration Tool

The migration tool is integrated into ADT and can be easily accessed by right-clicking on your BOPF BO in the Project Explorer and then selecting RAP Business Object > Migrate.

The tool provides two different modes:

A simulation mode for documenting results in a log without making any changes,
a migration mode for migrating the artifacts in the system.

In both cases, the tool analyzes your CDS-based BOPF BO and underlying CDS views and provides information on the necessary pre- or post-processing steps required for a successful migration to RAP.

The migration tool provides a lot of support and automated steps for the migration process. Nevertheless, the migration of a CDS-based BOPF BO to a RAP BO can be a complex task. Therefore please make sure to consider the messages provided by the tool, as well as the constraints documented in the migration guide.

Check out the Migration Guide in the SAP help portal to start your migration journey 😊

Useful Links

Migration Guide

RAP Online Documentation

ABAP Cloud: Background Concepts and Overview

3 Tier Extensibility Model

SAP Programming Model for SAP Fiori

How to reuse access control from a released SAP CDS entity in ABAP Cloud?

2024-02-28T15:14:56.649000+01:00

Introduction

When you want to reuse the access control settings from a released SAP CDS entity such as I_BUSINESSUSERBASIC in ABAP Cloud (e.g in SAP BTP ABAP Environment or in a software component in an SAP S/4HANA on prem or private cloud system that uses software components with ABAP Cloud) you might try the following DCL source code:

@EndUserText.label: 'Test DCL inheritence'
@MappingRole: true
define role ZI_BUSINESSUSERBASIC_NOTWORK {
grant
select
on
ZI_BUSINESSUSERBASIC
where
INHERITING CONDITIONS FROM ENTITY I_BUSINESSUSERBASIC;
}

This however would cause the following error message:

The use of inheritance is restricted in this language version

The reason is that the reuse of access control requires a special syntax.

Solution

In order to reuse the access controll settings of a base entity that has been released by SAP you have to equip your custom code entity with a [1..1] association _toBaseEntity that points back to the base entity.

@AccessControl.authorizationCheck: #MANDATORY
@EndUserText.label: 'test dcl inheritence'
define view entity ZI_BusinessUserBasic
as select from I_BusinessUserBasic

association [1..1] to I_BusinessUserBasic as _toBaseEntity on $projection.BusinessPartner = _toBaseEntity.BusinessPartner

{
key BusinessPartner,
BusinessPartnerUUID,
LastName,
FirstName,
PersonFullName,
FormOfAddress,
AcademicTitle,
AcademicSecondTitle,
CorrespondenceLanguage,
MiddleName,
AdditionalLastName,
BirthName,
NickName,
Initials,
LastNamePrefix,
LastNameSecondPrefix,
NameSupplement,
UserID,
IsMarkedForArchiving,
BusinessPartnerIsBlocked,
CreatedByUser,
CreationDate,
CreationTime,
LastChangedByUser,
LastChangeDate,
LastChangeTime,
IsBusinessPurposeCompleted,
AuthorizationGroup,
DataControllerSet,
DataController1,
DataController2,
DataController3,
DataController4,
DataController5,
DataController6,
DataController7,
DataController8,
DataController9,
DataController10,
/* Associations */
_BusinessPartnerExternalID,
_BusinessPartnerRole,
_User,
_WorkplaceAddress,
_toBaseEntity
}

In addition you have to use the following syntax in your DCL.

The statement

REPLACING { ROOT WITH _toBaseEntity }

makes sure that inheritence will still work even if SAP would add additional authorization checks in the where clause of the DCL that protects the released base entity I_BusinessUserBasic.

Though the syntax seems to be not self explaining at a first glance it is straight forward to simply create the above mentioned [1..1] association to the based entity.

@EndUserText.label: 'Test DCL inheritence'
@MappingRole: true
define role ZACL_ZI_BUSINESSUSERBASIC {
    grant
        select
            on
                ZI_BUSINESSUSERBASIC
                    where             
                        INHERITING CONDITIONS FROM ENTITY I_BUSINESSUSERBASIC
                         REPLACING { ROOT WITH _toBaseEntity }                         
                         // AND ...    to make it more restricive                         
                         // OR ....   to widen access for additional autorizations 
                         ;
                        
}

Hope this helps when you run into this issue.

SAP Learning Journey – Building OData Services with SAP Gateway

2024-02-29T15:30:09.480000+01:00

Since it was announced at SAP TechEd 2021, SAP offers digital learnings free of charge to everybody interested in SAP products on https://learning.sap.com. In this blog post, I want to present to you the learning journey Building OData Services with SAP Gateway and keep you up to date on the latest additions.

If you are more interested in a customer course for SAP Gateway, please read my blog post:
Customer course GW100 (SAP Gateway – Building OData Services) available for SAP S/4HANA 2021

Latest Additions

2023-11 Learning journey available

Introduction

This learning journey is based on the customer course GW100 (SAP Gateway – Building OData Services). The course structure was reworked to provide a clear path following the learning goals of each unit. Many animations and videos support the digital learning experience inviting you to interact with the material.

Nearly every lesson provides at least one exercise showing steps in a written form. Some can be performed directly by using some public resource like the SAP Gateway Demo System, but most exercises are based on SAP S/4HANA 2021 FPS02. In addition to the written form, these exercises provide a simulation of the steps in an SAP Learning system.

The units in the current version are the following:

SAP Gateway Overview
OData Overview
SAP Gateway and CDS Views

Content

1. SAP Gateway Overview

Unit 1 first describes SAP Gateway in general showing examples of where and how it is used in todays SAP solutions. The second lesson digs deeper in the releases and the components of SAP Gateway culminating in the deployment options for on-premise and SAP Business Technology Platform (BTP).

The following is exercised:

Prepare the SAP Learning System

2. OData Overview

Unit 2 covers the OData standard from the perspective of SAP Gateway. A short introduction to REST is followed by a comprehensive explanation of the OData protocol, how to perform OData operations and how to handle OData queries.

The following is exercised:

3. SAP Gateway and CDS Views

Unit 3 jumps to the world of Core Data Services (CDS) and shows the four ways an SAP Gateway service can be generated based on CDS views. This includes a short excursion to the ABAP RESTful Application Programming Model (RAP) but without getting into the details. The focus is to provide SAP Gateway services first by mapping or referencing a CDS view as data source in the SAP Gateway Service Builder (SEGW). Publishing a CDS view as SAP Gateway service or defining business services are performed in the ABAP Development Tools (ADT).

The following is exercised:

Summary

If you have read so far, it seems that you are really thinking about consuming the learning journey. Don’t hesitate and jump right in:

https://learning.sap.com/learning-journeys/building-odata-services-with-sap-gateway

If you are more interested in a customer course for SAP Fiori, please visit https://training.sap.com. The GW100 (SAP Gateway – Building OData Services) is a 5-day-course offered as physical and virtual event:

https://training.sap.com/course/GW100

For any other questions around the offerings of SAP Learning Services, please jump to our community page and get in contact with us:

https://pages.community.sap.com/topics/training-certification

Happy learning
Stefan

Customer Course GW100 (SAP Gateway – Building OData Services) Available for SAP S/4HANA 2021

2024-02-29T15:33:56.276000+01:00

Now that I finished the course development of the GW100 (again), I thought it is time to summarize all the new and updated topics in a central place. I decided that a blog post here would be a good way to share this to fellow ABAP developers. So welcome to my first blog post about the customer training GW100 (SAP Gateway – Building OData Services).

If you are more interested in a digital learning for SAP Gateway, please read my blog post:
SAP Learning Journey – Building OData Services with SAP Gateway

Introduction

Starting in 2014, this is now the seventh incarnation of how to develop OData services with SAP Gateway. The course shows all parts of SAP Gateway, which are available since SAP NetWeaver Application Server 7.0 (SAP Gateway 2.0), as well as parts added up to SAP S/4HANA 2021. The whole bandwidth of SAP Gateway covering all releases is shown.

The units in the current version are the following:

SAP Gateway Overview
OData Overview
SAP Gateway Service Implementation
SAP Gateway Service Generation
SAP Gateway Service Redefinition
SAP Gateway and CDS Views
SAP Gateway Hub Functionalities
Advanced OData Options
SAP Gateway Security
Further Information

If customers are interested, they can order a customer specific version of the course including only those topics suitable for their release or purpose.

System Landscape

Let’s start with the system release: SAP S/4HANA 2021 FPS02. Our system landscape – we call it universal target – is used in many technology courses and offers full access for the participants from the SAP Fiori launchpad (FLP) in the browser down to SAP HANA on the SUSE Linux Enterprise server (SLES). Everything is set up following the newest guidelines of SAP so that it can really act as a template for customers.GW100 System Landscape (Screenshot from System Setup Guide)

In addition, we offer an instance of the SAP Business Application Studio (BAS) to show the consumption of OData services. If you want to know more about this topic, check out our courses for SAP Fiori development.

OData

The unit explaining the OData foundation was greatly increased to cover all aspects of the protocol including OData V4. Many more slides were added to visualize the structure of an OData service. Here is an example about function and action imports:Function and Action Imports (Screenshot from GW100)A new section covering ?sap-ds-debug=true was added to explain the features of this debugging query option. Although it was always part of exercises, there was only one slide showing it. Now the following one is just the first one:SAP Debugging Query Option for Any Browser (Screenshot from GW100)The lesson about performing OData requests was enhanced in its visualization and some additional slides were added like this one for batch processing:OData Option $batch (Screenshot from GW100)

Implementation

The structure of the units covering code-based implementation got refined to better fit the current state of development. This includes more graphical explanations of how the source code is structured in the system like this one:Data Provider Base Class – Source Code (Screenshot from GW100)Other slides were enhanced using semantical colors consistently throughout the material. In this example, you see blue used for ABAP code, gold for HTTP requests, and green for (successful) HTTP responses:Create Operation Essentials (Screenshot from GW100)But of course, at the end of the day, it is all about source code. There are now more code snippets outside of exercises and the code is explained in more detail on slides:Implement Paging (Screenshot from GW100)

CDS Views

The evolution of CDS views was driving SAP Gateway from the beginning. That is why there is an own unit keeping track of all possibilities to generate SAP Gateway services based on CDS views:OData Service Development with CDS – Comparison (Screenshot from GW100)The decision, which generator is the right one for your project, does not only depend on the release you are using. Especially in a brown field approach, the data source reference in the SAP Gateway Service Builder (SEGW) is still a viable option for reusing existing source code in SAP Gateway services based on CDS views: How to Reference a Data Source (Screenshot from GW100)The newest generators are Business Services, which are part of the ABAP RESTful Application Programming Model (RAP). They are recommended by SAP as soon as they are available in your system and include the generation of OData V4 services:How to Create a Service Definition and Binding (Screenshot from GW100)

Summary

If you have read so far, it seems that you are really thinking about attending the course. Don’t hesitate and check out the physical and virtual events we offer:

https://training.sap.com/course/GW100

If you are more interested in a digital learning, please visit https://learning.sap.com. Some parts of the GW100 are already available free-of-charge:

https://learning.sap.com/learning-journeys/building-odata-services-with-sap-gateway

For any other questions around the offerings of SAP Learning Services, please jump to our community page and get in contact with us:

https://pages.community.sap.com/topics/training-certification

I hope even if you won’t attend the GW100 in any kind, you found some useful information around SAP Gateway in this blog post.

Happy learning
Stefan

Can I extend a certain app? With Clean Core? How?

2024-03-05T18:31:05.449000+01:00

Extensibility is a very important part in SAP S/4HANA. Although we recommend to have a fit-to-Standard approach, we know that not everything can be covered; there is a need for extensibility. But we don't just want to go hack about our system (anymore), we want to do it Clean Core compliant, meaning:

Extensions are clearly separated from SAP's code
Extensions do not modify any SAP objects
Extensions use only stable, released SAP APIs and extension points

Please note for on-premise and private cloud customers: I want to be honest and add here that not absolutely everything can be achieved Clean Core compliant yet for those systems. One such example are so called classic coding blocks in Finance, which are still used and can be "published" as key user extensibility with transaction SCFD_EUI. That said, this blog post focuses on trying to solve your requirement with Clean Core; always try that first!

But so now, how to go about this? Well, I'm hoping to give some help on that. In this blog post I'm focusing on extending an SAP S/4HANA Standard app, as an example.

First of...

I want to start by saying that the below "guide" isn't exactly a guide, but rather a collection of ideas. I want to be fully honest and say that there are tons of ways to do an extension, and depending on your exact situation, one may be favored over another. So, do not see this as "the only way", but "a way" that could help you solve your extension need.

Please also note, as mentioned before, we are focusing on an extension for an existing standard app. Some extensions may include data from other systems than your S/4HANA and maybe are viable for side-by-side development (development in SAP BTP) using SAP Build, BAS, Integration Suite and/or other services. I will not touch on those scenarios in this blog, but we focus on extending directly in your S/4HANA system.

I found an app and I want to extend it - can I?

This is often the very first question that reaches me; can I extend app Fxxxx? The simple truth is, there isn't a super simple answer. There are several ways to go about checking if your app can be extended, here are some:

Part 1: Check Key User Extensibility

Make sure your user as the required roles for key user extensibility (SAP_UI_FLEX_KEY_USER for being able to adapt the UI and SAP_BR_EXTENSIBILITY_SPEC for being able to use extensibility apps such as Custom Fields and Custom Logic).
Open the app and the screen you wish to extend. In your user menu, select Adapt UI:

If this option is available, the app probably can be extended with Key User Extensibility (apps still can react differently on different UI sections and fields, and you simply need to try and see what’s possible when the mode is activated). If this option is not available, we come to that further below.
Whether you want to add a new field or define new logic for your extension, right click onto an appropriate group, and press "+ Add: Field" (if this option is greyed out/disabled, new fields can’t be added for that group of data):

In the next dialog you will see a list of existing fields which are currently not on the screen.

To add a new custom field, you can click on the plus icon in the upper right corner -> this will take you to the Custom Fields app in a new tab in your browser. When opening the app this way, the app is prepared to only show the business context of the app you are trying to extend:

By clicking the plus icon in the upper right corner here, you can add your custom field (there are lots of guides on how to do this, I don't focus on that in this blog post).

If the option "+ Add: Field" was greyed out, you can still check whether you can add your own logic by opening the Custom Logic app (use the new version, not depreciated, if available in your system -> check the Fiori Apps Reference Library). Using Adapt UI first, gives the advantage of you giving you the corresponding business context, which you must otherwise select manually.

Clicking on Create in the Custom Logic app lists all extension points released for Key User extensibility. You can search by free text or via Business Context to see if you find an extension point that fulfills your requirement:

If you found what you need, create a new custom logic and write your code there (there are lots of guides on how to do this, I don't focus on that in this blog post).

If none of the extension points fit, you can continue to see if Developer Extensibility is possible...

Part 2: Check On-Stack Developer Extensibility

Go to the Fiori Apps Reference Library and find your app there, for example:

Make sure you are on the correct SAP S/4HANA release for your solution (blue box). Open Implementation Information tab and check all the yellow marked boxes:

If the Application Type isn’t SAP Fiori, it could be more difficult or not possible to extend (especially for Web-Dynpro apps – GUI transactions can possibly be modified with SAP Screen Personas for simpler requests)
Under Extensibility you may find a documentation for extending the app (an SAP Help page) and you may find the technical name of the frontend application (BSP containing SAPUI5 application), which can be used for Adaptation Projects in SAP BTP BAS.
Under Configuration you can find the OData Service(s) of the app. These contain the data model and underlying business logic for the app. A developer can analyze the main OData Service (sometimes there are several listed, for example an extra service for handling attachments that has otherwise nothing to do with the main business context of the app) to see whether it is extensible.

In-Depth development objects analysis

Checking the Fiori apps reference library should have given you some idea if the app can be extended with developer extensibility. You now need a developer to check further. At this point, I want to mention once more that below steps are not the only way to do these checks, but a possibility.

At this point we assume that our requirement cannot be solved with Key User extensibility. So now we want to check if we can extend the underlying OData service of the app to achieve our need.

Usually I start by determining in which Programming Model the OData service of the app was created:

Old Programming Model with a code-based OData service created in transaction SEGW
ABAP RESTful Application Programming Model (RAP) / ABAP Cloud development model

If the name of the OData service in the Fiori apps reference library ends with _CDS, we have a RAP service that was generated from a CDS view. If not, let's find out how the service was created (remember that this analysis is usually done by a developer):

In SAP GUI, open transaction se16n and enter table /IWBEP/I_SBD_GA
Under TROBJ_NAME enter the name of the OData service
Under TROBJ_TYPE enter value IWSV for OData service
Hit Execute (F8)

If nothing is found, the OData service should have been made with RAP. If you find a record, you find the name of the SEGW project in the first column:

SEGW Project

If the previous step led you to an SEGW project, open the transaction SEGW and open the project as found in the previous step. Depending on how the data model was built, we have more or less opportunities for extensions, for example:

Data Model -> Entity Types: these types were manually created (field by field) in SEGW without any underlying CDS view, meaning we cannot affect these data models without changing the SAP project, which we will not do in Clean Core!
Data Resource Reference -> Exposures via SADL -> CDS Entity Exposures: if we have CDS entities listed here, we may have some extension possibilities. Continue to "Analyze RAP Objects" below.

Even if this step ended in only manual entity types, we still have the option to check if an Adaptation Project can do our requirement. More on those further below.

Analyze RAP Objects (CDS, Business Service etc.)

If either our whole OData service was made with RAP or we have some CDS entities that used by an older OData service, we may have some options for extensions.

In ABAP Development Tools for Eclipse (ADT), connect to your system.

Check OData Service

Use Ctrl + Shift + A to open any development object. Enter the name of the OData service, for example:

Open the object with the purple icon for Service Binding. In the Service Binding you can find the Service Definition and all Entities exposed via this OData Service:

In the lower part of the screen, you find a Properties tab. Here you can for example find the Development Package of the service, which can help to find further objects.

Let's start by opening the Service Definition we can see on the Service Binding. Sadly, it is currently not possible to navigate forward (F3) from the Service Binding to the Service Definition and it’s also not possible to copy the name of the Service Definition. Either retype it into Ctrl + Shift + A or add the package from properties to your Favorite Packages (remember that not all RAP objects will be in that exact package, but most probably the Service Definition that belongs to the Service Binding will be):

Opening the Service Definition will list all the CDS objects exposed:

Start by checking the Properties of the Service Definition, and under it, the tab API State:

Here we can see all the "contracts" the object has been released for. In the above example, there is no Contract C0 for extensions, meaning this Service Definition cannot be extended. Not all is lost yet; this simply means we cannot expose additional CDS on this Service Definition, but we can still check the exposed CDS, if we can extend those (since they are exposed, if we extend them the change is reflected in the OData service because the underlying model changed).

Check CDS entities

From the Service Definition, we can click on a row with a CDS name and use forward navigation (F3) to open it. Once it’s open, we can check the API State here:

In the above example we can see that the CDS can indeed be extended, but only by Key User Apps; Cloud Development is not enabled for this object. In this case, we are back to Part 1: using UI Adaptation, Custom Fields, Custom Logic etc. apps.

In the same way as shown above, you can check the API state of any SAP object, for example a CDS entity you found in a SEGW project.

Open the CDS directly with Ctrl + Shift + A and enter its name, then check API State under Properties.

What about behavior or logic of an app? If the OData service is built with RAP, we can check the Behavior Definition of a CDS entity, whether it can be extended or not. Copy the name of the CDS entity and use again Ctrl + Shift + A and enter the name to find the behavior definition for it (they should have the same name), for example:

The purple B icon is for Behavior Definition. Open it and check its API state as explained before.

Check Extension Points

If your OData service is not made with RAP, or the behavior cannot be extended, then you have to look for released extension points to add your own logic. We already quickly looked at the Custom Logic app: the extension points listed there are released for Key User Extensibility. There could be more extension points available, for Developer Extensibility (as we've seen in the above contract C0, an object can be released for Key User or for Development, or for both).

My recommendation is to always check Key User first. If it is not sufficient, we need to try and find an extension point that is. How can we do that? Again, several options.

Check on Business Accelerator Hub under Categories - Business Add-Ins, for example:

Once you found your extension point, you can see its Release State when you click on it:

The other option is to directly check in ADT via the "Released Objects" tree (which you may need to add by customizing your ADT tree):

Part 3: It's still not enough - what now?

Once you’ve checked both Key User Extensibility and Developer Extensibility and are still not able to fulfill your requirement, you still have a couple of options:

Create your own app, reusing standard CDS as much as possible (but wrapping them inside custom namespace, for example ZR_SalesOrderTP for reusing R_SalesOrderTP or I_SalesOrder etc.)
1. Add your new fields and/or behavior to your custom CDS
2. If you need your own custom table, consider if using Custom Business Objects works for your case. If not, be sure to build the RAP object properly (Database table, Basic interface view, View entity, View projection, Behavior, Behavior projection). Remember that custom business objects can have automatic Change Document handling, as well as System Administrative Data (created at, by, changed at, by) handling out-of-the-box.
  1. How do I find my Custom Business Object in ADT? Open your Custom Business Object in the app and refer to Name of Technical Service:
  2. In ADT, use again Ctrl + Shift + A and enter the name, but discard the final _CDS:
Try to extend the app by using an Adaptation Project with SAP Business Application Studio on SAP BTP. Keep in mind that Adaption Projects are mostly used to modify the UI and actions on the UI. If this does not fulfill your need, you may need to go with option 1 or 3.
There is a third, hybrid option: one other feature of Adaption Projects is to add your own OData service or even replace the main OData service. If you prefer to keep the standard app instead of making your own (and making a new version for it via the Adaptation Project), you could try this option. You would create your own OData service with RAP and then create an Adaptation Project for the standard app, combining option 1 and 2:

Conclusion

One last time, I'd like to remind everyone that the above described options may not be the only ones, but are here to help you find your way to a clean extension. In general, when "everything fails", check if you cannot create your own custom development; on-stack or maybe even side-by-side. This is preferable over modifying the core. A well established Change Management and development/extension governance should also be in place!

Have a standard first approach: if there is a standard app, use it
- Be sure to keep checking for new released apps or app changes, which may replace a custom development or extension you built
- Extend the standard app, when needed, before coding your own
Always review all your options before starting to code:
- Is the extension really needed?
- Technical feasibility: how should the extension be implemented?
Document your custom development and extensions well; this way you have a quick and easy overview and can see if a new release may replace an extension that was previously needed

Hope this helps! And this is also to show there is no "one exact answer for all", but it's case-by-case. Be sure to check with an expert, if you are unsure, and keep that core clean!

How to search in the new SAP community for the latest content related to an SAP managed tag?

2024-03-13T17:46:57.400000+01:00

The workaround is very simple. I am basically searching for the SAP managed tag as a string by surrounding the tag in question by double quotes, for example:
"ABAP RESTful Application Programming Model".

In addition I choose a sortorder by Date so that the newest posts will show up first.

So the following link will produce a list of the latest posts that have used the SAP managed tag "ABAP RESTful Application Programming Model".

It is also possible to store such a search as an RSS Feed.

https://community.sap.com/t5/forums/searchpage/tab/message?q=%22ABAP%20RESTful%20Application%20Programming%20Model%22&noSynonym=false&sort_by=-topicPostDate&collapse_discussion=true

How to add a new entity to the RAP BO of a customizing table

2024-03-15T14:18:55.104000+01:00

Introduction

You have created a RAP BO based on one or more customizing tables by using the BC Maintenance Object ADT Wizard as described in this tutorial.

You want to extend the RAP BO by adding an additional customizing table to the data model.

The business configuration maintenance object supports RAP BO whose height of the composition tree is less than or equal to 2. For example, root entity A has two child entities B and C. Entity C has a child entity D. D cannot have any further child entities.
Depending on the back-end version, while the ADT wizard can handle multiple tables at the same time, the most complex supported scenarios require a manual enhancement after generation.

This blog is relevant for:

Example RAP BO

You have used the following table ZCB_HEAD with the ADT wizard to generate a maintenance object:

@EndUserText.label : 'Header'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zcb_head {
  key client            : abap.clnt not null;
  key head_key          : zcb_id not null;
  head_content          : abap.char(30);
  last_changed_at       : abp_lastchange_tstmpl;
  local_last_changed_at : abp_locinst_lastchange_tstmpl;
}

The table ZCB_ITEM that you want to add has the following structure and is a child entity of table ZCB_HEAD:

@EndUserText.label : 'Item'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zcb_item {
  key client            : abap.clnt not null;
  @AbapCatalog.foreignKey.keyType : #KEY
  @AbapCatalog.foreignKey.screenCheck : false
  key head_key          : zcb_id not null
    with foreign key zcb_head
      where client = zcb_item.client
        and head_key = zcb_item.head_key;
  key item_key          : abap.numc(3) not null;
  item_content          : abap.char(30);
  local_last_changed_at : abp_locinst_lastchange_tstmpl;
}

Data model & behavior

CDS View

Create a CDS view for table ZCB_ITEM with

an association to parent table ZCB_HEAD
an association to the singleton entity based on a calculated field SingletonID
if you do not have a projection layer, add the annotation @Metadata.allowExtensions: true

@EndUserText.label: 'Header'
@AccessControl.authorizationCheck: #CHECK
@Metadata.allowExtensions: true
define view entity ZI_Item
  as select from zcb_item
  association        to parent ZI_Header as _Header    on $projection.HeadKey = _Header.HeadKey
  association [1..1] to ZI_Header_S      as _HeaderAll on $projection.SingletonID = _HeaderAll.SingletonID
{
  key head_key              as HeadKey,
  key item_key              as ItemKey,
      item_content          as ItemContent,
      @Semantics.systemDateTime.localInstanceLastChangedAt: true
      @Consumption.hidden: true
      local_last_changed_at as LocalLastChangedAt,
      @Consumption.hidden: true
      1                     as SingletonID,
      _Header,
      _HeaderAll
}

Add a composition to ZI_Item in the CDS View of table ZCB_HEAD:

@EndUserText.label: 'Header'
@AccessControl.authorizationCheck: #CHECK
define view entity ZI_Header
  as select from zcb_head
  association to parent ZI_Header_S as _HeaderAll on $projection.SingletonID = _HeaderAll.SingletonID
  composition [0..*] of ZI_Item     as _Item
{
  key head_key              as HeadKey,
      head_content          as HeadContent,
      @Semantics.systemDateTime.lastChangedAt: true
      last_changed_at       as LastChangedAt,
      @Semantics.systemDateTime.localInstanceLastChangedAt: true
      @Consumption.hidden: true
      local_last_changed_at as LocalLastChangedAt,
      @Consumption.hidden: true
      1                     as SingletonID,
      _HeaderAll,
      _Item
}

If you have a projection layer, create a projection CDS view for ZI_Item with redirection to entity ZC_Header and the singleton entity. Save and activate.

@AccessControl.authorizationCheck: #CHECK
@Metadata.allowExtensions: true
@EndUserText.label: 'Maintain Item'
define view entity ZC_Item as projection on ZI_Item
{
  key HeadKey,
  key ItemKey,
  ItemContent,
  @Consumption.hidden: true
  LocalLastChangedAt,
  @Consumption.hidden: true
  SingletonID,
  _Header : redirected to parent ZC_Header,
  _HeaderAll : redirected to ZC_Header_S
}

If you have a projection layer, add a redirection to composition child ZI_Item in the projection CDS view of ZI_Header:

@EndUserText.label: 'Maintain Header'
@AccessControl.authorizationCheck: #CHECK
@Metadata.allowExtensions: true
define view entity ZC_Header
  as projection on ZI_Header
{
  key HeadKey,
      HeadContent,
      LastChangedAt,
      @Consumption.hidden: true
      LocalLastChangedAt,
      @Consumption.hidden: true
      SingletonID,
      _HeaderAll : redirected to parent ZC_Header_S,
      _Item      : redirected to composition child ZC_Item
}

Behavior definition

In the behavior definition ZI_HEADER_S, add the following definition for entity ZI_Item:

define behavior for ZI_Item alias Item
persistent table ZCB_ITEM
draft table ZCB_ITEM_D
etag master LocalLastChangedAt
lock dependent by _HeaderAll
authorization dependent by _HeaderAll

{
  field ( mandatory : create )
   ItemKey;

  field ( readonly )
   SingletonID,
   HeadKey,
   LocalLastChangedAt;

  field ( readonly : update )
   ItemKey;

  field ( notrigger )
   SingletonID,
   LocalLastChangedAt;


  update( features : global );
  delete( features : global );

  mapping for ZCB_ITEM
  {
    HeadKey = HEAD_KEY;
    ItemKey = ITEM_KEY;
    ItemContent = ITEM_CONTENT;
    LocalLastChangedAt = LOCAL_LAST_CHANGED_AT;
  }

  association _HeaderAll { with draft; }
  association _Header { with draft; }

  validation ValidateTransportRequest on save ##NOT_ASSIGNED_TO_DETACT { create; update; delete; }
}

In the entity definition of ZI_Header, add an association to ZI_Item:

association _Item { create ( features : global ); with draft; }

Save the behavior definition. Place the cursor on the draft table ZCB_ITEM_D and use the quick assist (Ctrl+1) to generate the draft table. After activating the draft table, activate the behavior definition.
Place the cursor on ZI_Item underlined by a warning message and use the quick assist to generate the missing method implementations.

If you have a projection layer, adjust the behavior projection:

projection;
strict;
use draft;

define behavior for ZC_Header_S alias HeaderAll

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

  use association _Header { create; with draft; }
}

define behavior for ZC_Header alias Header

{
  use update;
  use delete;

  use association _HeaderAll { with draft; }
  use association _Item { create; with draft; }
}

define behavior for ZC_Item alias Item

{
  use update;
  use delete;

  use association _HeaderAll { with draft; }
  use association _Header { with draft; }
}

Behavior implementation

Edit the behavior implementation class.
Add the table entity relation for ZCB_ITEM:

CLASS LHC_RAP_TDAT_CTS IMPLEMENTATION.
  METHOD GET.
    result = mbc_cp_api=>rap_tdat_cts( tdat_name = 'ZHEADER'
                                       table_entity_relations = VALUE #(
                                         ( entity = 'Header' table = 'ZCB_HEAD' )
                                         ( entity = 'Item' table = 'ZCB_ITEM' )
                                       ) ) ##NO_TEXT.
  ENDMETHOD.
ENDCLASS.

Implement the methods of LHC_ZI_ITEM and move the class definition LHC_RAP_TDAT_CTS up:

CLASS lhc_rap_tdat_cts DEFINITION FINAL.
  PUBLIC SECTION.
    CLASS-METHODS:
      get
        RETURNING
          VALUE(result) TYPE REF TO if_mbc_cp_rap_tdat_cts.

ENDCLASS.

CLASS lhc_item DEFINITION INHERITING FROM cl_abap_behavior_handler.

  PRIVATE SECTION.

    METHODS get_global_features FOR GLOBAL FEATURES
      IMPORTING REQUEST requested_features FOR Item RESULT result.

    METHODS ValidateTransportRequest FOR VALIDATE ON SAVE
      IMPORTING keys FOR Item~ValidateTransportRequest.

ENDCLASS.

CLASS lhc_item IMPLEMENTATION.

  METHOD get_global_features.
    DATA edit_flag TYPE abp_behv_flag VALUE if_abap_behv=>fc-o-enabled.
    IF lhc_rap_tdat_cts=>get( )->is_editable( ) = abap_false.
      edit_flag = if_abap_behv=>fc-o-disabled.
    ENDIF.
    result-%update = edit_flag.
    result-%delete = edit_flag.
  ENDMETHOD.

  METHOD ValidateTransportRequest.
    DATA change TYPE REQUEST FOR CHANGE ZI_Header_S.
    SELECT SINGLE TransportRequestID
      FROM zcb_head_d_s
      WHERE SingletonID = 1
      INTO (TransportRequestID).
    lhc_rap_tdat_cts=>get( )->validate_changes(
                                transport_request = TransportRequestID
                                table             = 'ZCB_ITEM'
                                keys              = REF #( keys )
                                reported          = REF #( reported )
                                failed            = REF #( failed )
                                change            = REF #( change-item ) ).
  ENDMETHOD.

ENDCLASS.

If you are using the VALIDATE_ALL_CHANGES method, delete the ValidateTransportRequest method from the LHC_ITEM class and adjust the ValidateTransportRequest method of the LHC_ZI_HEADER class:

VALIDATETRANSPORTREQUEST FOR VALIDATE ON SAVE
        IMPORTING
          KEYS_HEADER FOR Header~ValidateTransportRequest
          KEYS_ITEM FOR Item~ValidateTransportRequest.
[...]
  METHOD VALIDATETRANSPORTREQUEST.
    DATA change TYPE REQUEST FOR CHANGE ZI_Header_S.
    IF keys_Header IS NOT INITIAL.
      DATA(is_draft) = keys_Header[ 1 ]-%IS_DRAFT.
    ELSEIF keys_Item IS NOT INITIAL.
      is_draft = keys_Item[ 1 ]-%IS_DRAFT.
    ELSE.
      RETURN.
    ENDIF.
    READ ENTITY IN LOCAL MODE ZI_Header_S
    FROM VALUE #( ( %IS_DRAFT = is_draft
                    SingletonID = 1
                    %CONTROL-TransportRequestID = if_abap_behv=>mk-on ) )
    RESULT FINAL(transport_from_singleton).
    IF lines( transport_from_singleton ) = 1.
      DATA(transport_request) = transport_from_singleton[ 1 ]-TransportRequestID.
    ENDIF.
    lhc_rap_tdat_cts=>get( )->validate_all_changes(
                                transport_request     = transport_request
                                table_validation_keys = VALUE #(
                                                          ( table = 'ZCB_HEAD' keys = REF #( keys_Header ) )
                                                          ( table = 'ZCB_ITEM' keys = REF #( keys_Item ) )
                                                               )
                                reported              = REF #( reported )
                                failed                = REF #( failed )
                                change                = REF #( change ) ).
  ENDMETHOD.

Add the %ASSOC-_Item statement to the GET_GLOBAL_FEATURES method of LHC_ZI_HEADER:

  METHOD get_global_features.
    DATA edit_flag TYPE abp_behv_flag VALUE if_abap_behv=>fc-o-enabled.
    IF lhc_rap_tdat_cts=>get( )->is_editable( ) = abap_false.
      edit_flag = if_abap_behv=>fc-o-disabled.
    ENDIF.
    result-%update = edit_flag.
    result-%delete = edit_flag.
    result-%ASSOC-_Item = edit_flag.
  ENDMETHOD.

Metadata extension

Create a metadata extension for ZI_Item or ZC_Item when using a projection layer:

@Metadata.layer: #CUSTOMER
@UI: {
  headerInfo: {
    typeName: 'Item', 
    typeNamePlural: 'Items', 
    title: {
      type: #STANDARD, 
      label: 'Item', 
      value: 'ItemKey'
    }
  }
}
annotate entity ZC_Item with
{
  @UI.identification: [ {
    position: 1 , 
    label: 'ItemKey'
  } ]
  @UI.lineItem: [ {
    position: 1 , 
    label: 'ItemKey'
  } ]
  @UI.facet: [ {
    id: 'ZI_Item', 
    purpose: #STANDARD, 
    type: #IDENTIFICATION_REFERENCE, 
    label: 'Item', 
    position: 1 
  } ]
  ItemKey;
  
  @UI.identification: [ {
    position: 2 , 
    label: 'ItemContent'
  } ]
  @UI.lineItem: [ {
    position: 2 , 
    label: 'ItemContent'
  } ]
  ItemContent;
}

Add a facet to _Item in the metadata extension of ZI_Header or ZC_Header when using a projection layer:

[...]
annotate entity ZC_Header with
{
  @UI.identification: [ {
    position: 1 
  } ]
  @UI.lineItem: [ {
    position: 1 
  } ]
  @UI.facet: [ {
    id: 'ZI_Header', 
    purpose: #STANDARD, 
    type: #IDENTIFICATION_REFERENCE, 
    label: 'Header', 
    position: 1 
  }, 
  {
    id: 'ZI_Item', 
    type: #LINEITEM_REFERENCE, 
    label: 'Item', 
    position: 2 , 
    targetElement: '_Item'
  } ]
  HeadKey;
[...]

Access Control

Create an access control object for ZI_Item:

@MappingRole: true
define role ZI_Item {
  grant select on ZI_Item
  where INHERITING CONDITIONS FROM ENTITY ZI_Header;
}

If you are using a projection layer, create an access control object for ZC_Item:

@MappingRole: true
define role ZC_Item {
  grant select on ZC_Item
  where INHERITING CONDITIONS FROM ENTITY ZI_Item;
}

Transport Object

Add table ZCB_ITEM to the transport object definition ZHEADER:

  "tableItems": [
    {
      "tableName": "ZCB_HEAD",
      "isPrimaryTable": true
    },
    {
      "tableName": "ZCB_ITEM"
    }
  ]

If you are using SAP S/4HANA On Premises 2023, use transaction SOBJ instead of ADT to adjust the transport object definition.

Business Service

Add entity ZC_Item to the service definition:

define service ZUI_HEADER {
  expose ZC_Header_S as HeaderAll;
  expose ZC_Header   as Header;
  expose ZC_Item     as Item;
}

Maintenance Object

No adjustments are necessary. You have the option to define specific table settings for the new entity, for example, to change the table creation mode.

You can now restart the Custom Business Configurations app to review the changes.

How to enable an OData V4 service for anonymous access?

2024-03-19T21:57:57.546000+01:00

Introduction

This requirement stems from a customer that asked how to publish an OData V4 service in an SAP S/4HANA on premise system such that it could be used on a public web site without the need to provide any authentication.

With OData V2 this requirement can be achieved more easily since here every service has it's own SICF node where it would be possible to store credentials just for this service.

In OData V4 we have only one SICF node, namely /sap/opu/odata4/.

This is obviously a problem since there is no service specific node available in SICF.

Solution

The problem can be solved using the following approach.

Create a role that only contains the S_START authorization for the one single OData V4 service we want to publish ,
help.sap.com/doc/saphelp_nw75/7.5.5/de-DE/c6/dd838722ce4b8d9cc4a0741d93d864/frameset.htm
Create a technical user that has only the authorization to access the single OData V4 service we want to make accessible.
Create an alias in SICF for the node /sap/opu/odata4/
Store the credentials of the aforementioned user in the alias
Test the service

Result

As we can see accessing the service zrap630ui_shop_o4_05a via the alias zodatav4 works.

https://10.79.21.221:44301/sap/opu/zodatav4/sap/zrap630ui_shop_o4_05a/srvd/sap/zrap630ui_shop_o4_05a/0001/?sap-client=100

Whereas accessing a second OData V4 service zrap630ui_shop_o4_05b via the alias zodatav4 does NOT work

This has been achieved by assigne the follwoing role the technical user which only contains the authorization to start the first service based on the authorization object S_START.

Please note:
Since OData V4 service use the authorization object S_START which is based on the service name it would for example be possible to publish several services that are in the same name range like

zrap630ui_shop_o4_05A, zrap630ui_shop_o4_05B, ... zrap630ui_shop_o4_05Z,

How to section

Create the role

Using PFCG and the role template /IWBEP/RT_MGW_USR we create a role as shown in the screen shot above that only contains the S_START authorization of one OData V4 service called ZRAP630UI_SHOP_O4_05A.

Create the user

As a user we create a technical user whose credentials will be stored in the system alias.

Create the system alias

1. We start by right-clicking on the node opu and choose New subelement.

2. We create a new service element called ZODATAV4_2 and choose the option Alias to an existing service.

3. We choose the tab Target, select the node OdataV4 by double-clicking on it.

4. We navigate to the tab Logon Data, choose Alternative Logon Procedure and enter the credentials of our service user.

5. We navigate down and remove all logon procedures beside Logon using service data.

6. Do not forget to activate the link in SICF.

7. Check the result

How to get a "Display only" Fiori app from a "Manage" Fiori app

2024-03-22T09:32:32.218000+01:00

Ever come across a really good Standard Fiori app which you would like to use both for users that are allowed to create new business context, but also for those who should only display them? Sometimes there is a "display" or "List" app available, but not always. In this blog you'll learn how you can create your own "display only" app without having to redo everything SAP standard "did for you".

Example Case

In this example I'll be using "Manage Sales Order" app (F3893): Manage Sales Orders - Version 2

CDS Development

Step 1: Get Main CDS

The first thing we have to do is to figure out the main CDS view of the original standard app. In this example it's very simple because with have an OData service that was developed with RAP according to ABAP Cloud: C_SALESORDERMANAGE_SRV. We open this object in ADT and soon find the main CDS: C_SalesOrderManage.

I won't go into details here how to find the main CDS. In another blog post I have explained how to check an OData service and find CDS, please check there. If you still need help, maybe I make a new blog for that topic alone, we'll see.

Step 2: Decide Approach (yes, there is more than one)

Now that we have C_SalesOrderManage open (this is a projection view), we can check from which CDS it gets the data; R_SalesOrderTP. Looking at that CDS tells us that this is a root view entity which has composition children. So we can't just select from R_SalesOrderTP in our own CDS and reuse the compositions. For example R_SalesOrderItemTP is linked to R_SalesOrderTP and we cannot change SAP Standard so that it links to our own CDS. Meaning we go 1 level lower to the basic interface view that is used by R_SalesOrderTP; I_SalesOrder. Here some help how the CDS looks like:

We can see that for "as select from" we have I_SalesOrder. This is the one we want to use, because looking at it confirms it's no root view entity, but a regular CDS view/entity which we can reuse for our purpose.

At this point we should make a choice:

Do we want to have full functionality as in the original app, for example navigating from a sales order details page, all the way into a sales order item details page?
Or is it enough with one list report and one detail page? Namely in this example, a way to search for sales orders via filters, then clicking on a sales order and display all wanted details, but no further navigation.

Important: both are possible.

Choice one, full functionality: this means more wrappers and more work. You will basically create your own root view entity, with your own composite child entities (all wrapping around standard ones so you don't create them from scratch, thus called wrapper) for all the data you wish to display in your display-only app. You will then create the proper projection view, just like C_SalesOrderManage, create service definition and binding, which then gives you your OData service for the Fiori app.
Choice two: if we just need a simple list report with details page, we can generate an OData service directly from a CDS view entity. In this example I will go with this option, for simpleness sake. But basically the steps are as said just above, creating a wrapper for all CDS you want in the end and creating a proper OData service with RAP and ABAP Cloud.

Step 3: Create wrapper for CDS

Create a new data definition: ZC_SalesOrderTP (we give it C in its name for "consumption" because we will directly expose this CDS as OData service, and "TP" for transactional processing).
As reference CDS view, be sure to enter I_SalesOrder as identified in the previous step. If you do, ADT will add all fields and associations for you.
First off, at the beginning of your view entity you will need below two semantics. The first will make sure we don't just blindly take over all semantics from I_SalesOrder (this could be handy and potentially faster, but since we may not use absolutely all associations etc., it is in my opinion better to recreate your own semantics and thus the syntax checker will also help you to make sure everything is correct). The second one allows us to create an extra metadata extension file, which we can use for all UI annotations, which makes the whole thing less messy. I always recommend to separate UI annotations from other semantics.

@Metadata.ignorePropagatedAnnotations: true
@Metadata.allowExtensions: true

Next we add that we want to publish this CDS as OData service (with @OData.publish: true). This is only needed if you are going the more simple option. Otherwise you leave this out and create the OData service via Service Definition and Binding, once you built the complete RAP object.
Next I copied some of the semantics from the standard CDS and here is the complete start of my CDS so far:
Add the associations you want to use (again, simply copy from standard CDS) - if you are doing the more functionality route, be sure to use composite child instead of association and you have to create z-wrappers for each, and use the z-CDS here, not for example R_SalesOrderItemTP:

association [0..*] to I_SalesOrderItem as _Item
  on $projection.SalesOrder = _Item.SalesOrder
association [0..*] to R_SalesOrderTextTP as _Text
  on $projection.SalesOrder = _Text.SalesOrder
association [0..*] to I_SalesOrderPartner as _Partner
  on $projection.SalesOrder = _Partner.SalesOrder
association [0..1] to I_SalesOrderPartner as _SoldToParty 
  on  $projection.SalesOrder = _SoldToParty.SalesOrder
  and _SoldToParty.PartnerFunction = 'AG'
association [0..1] to C_SlsDocStdPartnerContactInfo as _SoldToPartyContactInfo 
  on  $projection.SalesOrder = _SoldToPartyContactInfo.SalesDocument
  and $projection.SoldToParty = _SoldToPartyContactInfo.SoldToParty
  and $projection.SalesOrderType = _SoldToPartyContactInfo.SalesDocumentType
association [0..1] to I_SalesOrderPartner as _ShipToParty 
  on  $projection.SalesOrder = _ShipToParty.SalesOrder
  and _ShipToParty.PartnerFunction = 'WE'
association [0..1] to I_SlsOrganizationDistrChnl as _SlsOrganizationDistrChnl 
  on  $projection.SalesOrganization = _SlsOrganizationDistrChnl.SalesOrganization
  and $projection.DistributionChannel = _SlsOrganizationDistrChnl.DistributionChannel

//Extension Association
association [1] to E_SalesDocumentBasic as _Extension on $projection.SalesOrder = _Extension.SalesDocument

Now I do the same per field that is important: add semantics to have a good UX. Here a couple of examples (I won't add everything as it would just get too big):

@Search: {
  defaultSearchElement: true,
  fuzzinessThreshold: 0.9,
  ranking: #HIGH }
key SalesOrder.SalesOrder,

@ObjectModel.text.element: ['CustomerName']
@Search: {
  defaultSearchElement: true,
  fuzzinessThreshold: 0.8 }
SalesOrder.SoldToParty,

@Semantics.text:true
_SoldToParty.FullName as CustomerName,

If you go the more functionality route, you keep creating your z-version for each "composition [0..*] of " that you feel you want to use in your display-only app. Once the wrappers are done, you can come back to the main one and activate it with the correct children-links.

Step 4: Authorization

If you paid attention above, we of course want to make sure that users still only see the sales orders they are supposed to see; the standard authorization. Once again, we don't need to redo this, we can inherit the standard one.

In ADT, create a new Access Control with the same name as your CDS you want to be checked, in my case ZC_SalesOrderTP. Then simply enter the "inheriting conditions from entity", save and done:

@EndUserText.label: 'Sales Order for Display Access'
@MappingRole: true
define role ZC_SALESORDERTP {
  grant
    select on ZC_SalesOrderTP
      where
        inheriting conditions from entity R_SalesOrderTP;
}

Step 5: UI Annotations for Fiori

I recommend to add all UI annotations that you want Fiori display via a metadata extension file. In ADT, create a metadata extension file that has the exact same name as your CDS, in my case ZC_SalesOrderTP. Here once again I opened the standard metadata extension file with Ctrl + Shift + A in ADT, and entering the same name as the main CDS: C_SalesOrderManage. In the dialog that shows all the hits, choose the metadata extension file instead of the Data Definition.

Now, at this point you may need some extra time. Instead of blindly copying all the annotations from the standard file, I went through and only added the facets that I wanted on my display-only app, and only the fields that I wanted. If you add too much (meaning you add annotations to something that doesn't exist in your z-wrapper CDS) syntax check will catch it but, there can be some "hidden" errors. And those will result in your Fiori app not functioning properly. For example, let's say you add a certain facet:

{
  id: 'CompletionStatus',
  label: 'Completion Status',
  purpose: #STANDARD,
  type: #FIELDGROUP_REFERENCE,
  parentId: 'StatusTab',
  importance: #HIGH,
  position: 30,
  targetQualifier: 'CompletionStatus'
},

The above looks all fine and will pass syntax check. We have the "CompletionStatus" and we can add fields to this facet. BUT, if you paid close attention, you may noticed this line: parentId: 'StatusTab'. This means our CompletionStatus facet is inside another, a parent facet. If you now didn't copy that parent facet, and there is no facet with id StatusTab, then your Fiori application will not work properly, because it cannot resolve this.

This is probably the part where you spend most of your time on. Myself when I did this example it took me about 1-2 hours.

Step 6: Publish OData Service

Next we need to publish our custom OData service with transaction /IWFND/MAINT_SERVICE for OData V2 services or /IWFND/V4_ADMIN for OData V4. Note that when using @OData.publish: true the system will add _CDS to your OData service name. Confirm your service and metadata was loaded successfully before continuing.

Fiori Development

Next up, we create our display-only Fiori elements app.

Open Business Application Studio (BAS) on your SAP BTP and start a space for Fiori development.

Create a new Project from Template and choose SAP Fiori application. The first thing we need to do is connect to a data source. In my case an S/4HANA on-premise system that I have connected to my SAP BTP via Cloud Connector. I select in this step the Destination to that S/4HANA system via Cloud Connector, and then I select my OData service:

Next, we enter the project details, for example:

You should add deployment configuration and also FLP configuration here. I again select my S/4HANA system destination and enter a technical name for the Fiori app to be created on the ABAP platform of my S/4HANA system. You also need to enter package and transport at this point.

For the FLP configuration it's business as usual, except be careful with your semantic object and action. Be sure to not reuse what standard is using, for example I used SalesOrder as object (because that is correct) and then I said the action is "displayOnly" to be sure to not have another intent like that:

Once the wizard is done, simply test your app. Because we have done all the UI annotations, you should be good to go.

Deploy your app and we are almost done.

Adding your App to the Fiori Launchpad

The app is now in our system but it has no catalog etc. So we gotta do this per usual practice. I won't go into super details here:

Create a technical catalog if you don't have a suitable one using Launchpad App Manager - Cross Client
From your technical catalog, choose Add App to add an "app descriptor item", or Tile and Target Mapping in other words (so we are still in Launchpad App Manager - Cross Client we have created/navigated to our technical catalog, in edit mode and choose Add App)
Here under application component ID you have to enter the full application name you chose for your Fiori application when you first created it in BAS. In my case i had namespace "disp" and name "salesorderdisplay", meaning disp.salesorderdisplay. If you enter this, the app should fetch all the necessary FLP config you already did in BAS (it will also fetch ICF path for you):
In my case, because I chose "Mange Sales Orders" app, I also added all the parameters which that app uses - be sure not to forget this!
Save this.
Next, we need to add the app to a business catalog (maybe create a new business catalog if needed) or several, depending on your setup
Then we need to add our business catalog(s) for this app to all the appropriate roles who should have this display-only app
Lastly, if the app should be on a Space and Page, we need to do that config

All done! You have a display-only app, using standard CDS which you have wrapped into a custom OData service, for a custom app.

And if you were wondering; Is this Clean Core? Then yes. Custom development that follows the ABAP Cloud programming model is "clean". One thing to consider when you create such "wrappers" (Tier 2) is to keep an eye out if SAP Standard delivers a solution that makes your custom development unnecessary; then you should switch to SAP Standard and retire your own development (and you will be on Tier 1).

Solution

The final app - list report page (including smart links to customer, without us having to code it ourselves):

Details/Object page:

Hope this was helpful! Let me know if you wonder anything.

Step by Step process to publish standard Business events from S/4 Hana to Event Mesh

2024-03-27T10:04:35.331000+01:00

Hi All,

This blog explains Outbound Configuration to send events from S/4 Hana on premise to Event Mesh and test the same.

You need to have below roles

1. SAP_IWXBE_RT_XBE_ADM

2. SAP_IWXBE_RT_XBE_BUSI

3. SAP_IWXBE_RT_XBE_MDT

In S/4 system, please follow below steps.

Create a Channel using T-code “/n/IWXBE/CONFIG”.

Click on “Via Service key”.

Enter Channel name and Description. Get the Event mesh instance key from Basis team. Copy and paste the service key of event mesh as shown below.

select the channel and activate it.

Once it is activated, click on Check connection. You will get the below message if connection successfull.

To Create Outbound binding, please select channel and click on outbound bindings.

Click on create and then F4.

Select the topic from F4 and save it. If you don't find topics in F4 help, you need to implement note "3346777".

Now, you need to create a Queue in Event Mesh and subscribe the topic.

Open Event Mesh and click on Create Queue.

Provide some name and click on create

Once the Queue is created, click on highlighted button and select Queue Subscriptions.

Enter Topic name along with the namespace and click on add button to subscribe to the topic.

Configuration is done in S/4 Hana system and in the BTP Event Mesh.

To test the messages,

Trigger Standard Business Partner Events by creating a business partner using T-Code BP.

Click on Person.

Enter First name and last name and then save it.

Message has been sent to Event Mesh.

Check the payload after consuming the message in CPI by integration team.

Message number decreased to zero in Event Mesh after consuming the message in CPI.

Happy to hear the feedback 🙂

Upload Excel using SAP RAP Only

2024-04-16T12:50:21.211000+02:00

Develop an SAP RAP based App to upload excel (CSV) file just like you used to develop SE38 classical report.

We often get this requirement of developing a utility to create/update mass data for a BO such as Purchase Orders, Materials, Sales Orders etc. In S/4 HANA, the customer prefers to use SAP Fiori applications, rather than using the old classical reports. But can we develop a Fiori application to upload a file without involving using SAP UI5? Yes, we can.

Using the following annotations, we can attach any file to our BO in SAP RAP –

@Semantics.largeObject

The only constraint is that we would need a table holding the uploaded attachment large object. Let’s dive into the steps –

First, we will create database tables. We need to create two DB tables. The first table i.e. parent table will store the file attachment, and the second table i.e. child table will store the data from the uploaded file. In our scenario, we will be uploading and processing CSV file.

File table - ZSES_FILE_TABLE

@EndUserText.label : 'User File Table'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table zses_file_table {
  key client            : abap.clnt not null;
  key end_user          : uname not null;
      status            : abap.char(1);
      attachment        : xstringval;
      mimetype          : abap.char(128);
      filename          : abap.char(128);
      local_created_by      : abp_creation_user;
      local_created_at      : abp_creation_tstmpl;
      local_last_changed_by : abp_locinst_lastchange_user;
      local_last_changed_at : abp_locinst_lastchange_tstmpl;
      last_changed_at       : abp_lastchange_tstmpl
}

Excel data table - ZSES_DB

@EndUserText.label : 'Excel Data'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #ALLOWED
define table zses_db {
  key mandt      : mandt not null;
  key end_user   : uname not null;
  key entrysheet : lblni not null;
  key ebeln      : ebeln not null;
  key ebelp      : ebelp not null;
  ext_number     : lblne1;
  begdate        : lzvon;
  enddate        : lzbis;
  @Semantics.quantity.unitOfMeasure : 'zses_db.base_uom'
  quantity       : mengev;
  base_uom       : meins;
  fin_entry      : final;
  error          : boolean;
  error_message  : char100;
}

Now, let's create Interface views on top of the tables we just created.

For parent interface view, we create ZI_SES_PARENT.

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Excel File Table'
define root view entity zi_ses_parent
  as select from    usr02           as _user
    left outer join zses_file_table as _ses_file on _user.bname = _ses_file.end_user
  composition [0..*] of zi_ses_excel_data as _ses_excel
{
  key _user.bname                                                                                              as end_user,
      _ses_file.status                                                                                         as status,

      cast( case when _ses_file.filename is initial and _ses_file.status is      initial then 'File Not Uploaded'
                 when _ses_file.filename is not initial and  _ses_file.status is initial  then 'File Uploaded'
                 when _ses_file.filename is initial then 'File Not Uploaded'
                 when  _ses_file.status is not initial then 'File Processed' else ' ' end as abap.char( 20 ) ) as FileStatus,
      cast( case when _ses_file.filename is initial and _ses_file.status is initial then '1'
                 when _ses_file.filename is not initial and  _ses_file.status is initial  then '2'
                 when _ses_file.filename is initial then '1'
                 when  _ses_file.status is not initial then '3' else ' ' end as abap.char( 1 ) )               as CriticalityStatus,
      cast( case when _ses_file.filename is not initial then ' ' else 'X' end as boolean preserving type  )    as HideExcel,
      @Semantics.largeObject:
      { mimeType: 'MimeType',
      fileName: 'Filename',
      acceptableMimeTypes: [ 'text/csv' ],
      contentDispositionPreference: #INLINE }  // This will store the File into our table 
      _ses_file.attachment                                                                                     as Attachment,
      @Semantics.mimeType: true
      _ses_file.mimetype                                                                                       as MimeType,
      _ses_file.filename                                                                                       as Filename,
      @Semantics.user.createdBy: true
      _ses_file.local_created_by                                                                               as Local_Created_By,
      @Semantics.systemDateTime.createdAt: true
      _ses_file.local_created_at                                                                               as Local_Created_At,
      @Semantics.user.lastChangedBy: true
      _ses_file.local_last_changed_by                                                                          as Local_Last_Changed_By,
      //local ETag field --> OData ETag
      @Semantics.systemDateTime.localInstanceLastChangedAt: true
      _ses_file.local_last_changed_at                                                                          as Local_Last_Changed_At,
      //total ETag field
      @Semantics.systemDateTime.lastChangedAt: true
      _ses_file.last_changed_at                                                                                as Last_Changed_At,

      _ses_excel
}
where
  _user.bname = $session.user

Looks complicated? Let me explain -

1. We select primary data from USR02 table and left outer join it with our parent table ZSES_FILE_TABLE, so that every user can use the app without worrying about locking. As this application serves as a utility for excel file upload, multiple users can use it simultaneously.
2. FileStatus field is introduced to decorate the application and show state to the user whether the file is uploaded, processed or not.

Then we create interface view of child entity as ZI_SES_EXCEL_DATA.

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'SES_excel_data'
@Metadata.allowExtensions: true 
define view entity zi_ses_excel_data
  as select from zses_db
  association to parent zi_ses_parent as _ses_file on $projection.end_user = _ses_file.end_user
{
  key end_user              as end_user,
  key zses_db.entrysheet   as Entrysheet,
  key zses_db.ebeln         as Ebeln,
  key zses_db.ebelp         as Ebelp,
      zses_db.ext_number    as Ext_Number,
      zses_db.begdate       as Begdate,
      zses_db.enddate       as Enddate,
      zses_db.quantity      as Quantity,
      zses_db.base_uom      as Base_Uom,
      zses_db.fin_entry     as Fin_Entry,
      zses_db.error         as Error,
      zses_db.error_message as Error_Message,

      _ses_file
}

Now, let's go for consumption views. These are pretty straightforward.

For parent, we create ZC_SES_PARENT.

@EndUserText.label: 'Consumption View for File'
@AccessControl.authorizationCheck: #NOT_REQUIRED
@Metadata.allowExtensions: true
define root view entity zc_ses_parent
  provider contract transactional_query
  as projection on zi_ses_parent
{
  key end_user,
      @EndUserText.label: 'Processing Status'
      FileStatus as status,
      Attachment,
      MimeType,
      Filename,
      Local_Created_By,
      Local_Created_At,
      Local_Last_Changed_By,
      @EndUserText.label: 'Last Action On'
      Local_Last_Changed_At,
      Last_Changed_At,
      CriticalityStatus,
      HideExcel,
      
      /* Associations */
      _ses_excel : redirected to composition child zc_ses_excel
}

For child, we create ZC_SES_EXCEL.

@EndUserText.label: 'Consumption View for Ses Excel Data'
@AccessControl.authorizationCheck: #NOT_REQUIRED
@Metadata.allowExtensions: true 
define view entity zc_ses_excel
  as projection on zi_ses_excel_data
{
  key end_user,
  key Entrysheet,
  key Ebeln,
  key Ebelp,
      Ext_Number,
      Begdate,
      Enddate,
      Quantity,
      Base_Uom,
      Fin_Entry,
      Error,
      Error_Message,
      /* Associations */
      _ses_file : redirected to parent zc_ses_parent
}

We then create Metadata Extensions for both of our consumption/projection views -

@Metadata.layer: #CORE
annotate entity zc_ses_parent with
{
  @UI.facet: [
      /* Header Fecets and Datapoints */
      { purpose: #HEADER,             id:'HDR_USER',        type: #DATAPOINT_REFERENCE,      position: 10, targetQualifier: 'end_user'                                             },
      { purpose: #HEADER,             id:'HDR_FILE',        type: #DATAPOINT_REFERENCE,      position: 20, targetQualifier: 'Local_Last_Changed_At'                                },
      { purpose: #HEADER,             id:'HDR_STATUS',      type: #DATAPOINT_REFERENCE,      position: 30, targetQualifier: 'status'                                               },
  //**----  Body facets
      { label: 'File Information',    id: 'Attachment',     type: #COLLECTION,               position: 10                                                                        },
      { label: 'Invoice Details',     id: 'Invoicedet',     type: #IDENTIFICATION_REFERENCE, position: 10,                             parentId: 'File',        purpose: #STANDARD },
      {                               id: 'Upload',         type: #FIELDGROUP_REFERENCE,     position: 20  ,targetQualifier: 'Upload', parentId: 'Attachment',  purpose: #STANDARD },

  //** --- Excel data Facet **
      { label: 'Excel Data',          id: 'Data',           type: #LINEITEM_REFERENCE,       position: 30,  targetElement: '_ses_excel', parentId: 'Attachment', purpose: #STANDARD } ]// , hidden: #(HideExcel) } ]


  @UI: { lineItem:       [ { position: 10, importance: #HIGH , label: 'Person Responsible'}  ] ,
         identification: [ { position: 10 , label: 'Person Responsible' } ],
                     //      { type: #FOR_ACTION, dataAction: 'uploadExcelData', label: 'Validate and Show' } ] ,
         dataPoint:        { title: 'Responsible Person', targetValueElement: 'end_user' } }
  end_user;
  @UI: { lineItem:       [ { position: 20, importance: #HIGH , label: 'Processing Status'} ] ,
         identification: [ { position: 20 , label: 'Processing Status' } ] ,
         dataPoint:        { title: 'Processing Status', targetValueElement: 'status' ,criticality: 'CriticalityStatus' ,criticalityRepresentation: #WITHOUT_ICON} }
  status;
  @UI: { fieldGroup:     [ { position: 50, qualifier: 'Upload' , label: 'Attachment'} ]}
  @UI: { identification: [ { position: 30 , label: 'File' } ] }
  Attachment;

  @UI.hidden: true
  MimeType;

  @UI.hidden: true
  Filename;
  @UI: { dataPoint:{ title: 'Last Action On', targetValueElement: 'Local_Last_Changed_At' } }
  Local_Last_Changed_At;

}

@Metadata.layer: #CORE
annotate entity zc_ses_excel with
{

  @UI.facet: [{
      id: 'SES',
      type: #FIELDGROUP_REFERENCE,
      purpose: #STANDARD,
      label: 'SES',
      targetQualifier: 'SESDetails'
   }]
  @UI.lineItem: [{ position: 1 }]
  end_user;
  @UI.lineItem: [{ position: 10 , label: 'SES Number', invocationGrouping: #ISOLATED },
  { type: #FOR_ACTION, dataAction: 'createSES', label: 'Process SES' }]
  @UI.fieldGroup: [{ position: 10 , label: 'SES Number', qualifier: 'SESDetails' }]
  Entrysheet;
  @UI.lineItem: [{ position: 20 , label: 'PO' }]
  @UI.fieldGroup: [{ position: 20 , label: 'PO', qualifier: 'SESDetails' }]
  Ebeln;
  @UI.lineItem: [{ position: 30 , label: 'PO Item' }]
  @UI.fieldGroup: [{ position: 30 , label: 'PO Item', qualifier: 'SESDetails' }]
  Ebelp;
  @UI.lineItem: [{ position: 40 , label: 'SES Name' }]
  @UI.fieldGroup: [{ position: 40 , label: 'SES Name', qualifier: 'SESDetails' }]
  Ext_Number;
  @UI.lineItem: [{ position: 50 , label: 'Valid From' }]
  @UI.fieldGroup: [{ position: 50 , label: 'Valid From', qualifier: 'SESDetails' }]
  Begdate;
  @UI.lineItem: [{ position: 60 , label: 'Valid To' }]
  @UI.fieldGroup: [{ position: 60 , label: 'Valid To', qualifier: 'SESDetails' }]
  Enddate;
  @UI.lineItem: [{ position: 70 , label: 'Quantity' }]
  @UI.fieldGroup: [{ position: 70 , label: 'Quantity', qualifier: 'SESDetails' }]
  Quantity;
  @UI.lineItem: [{ position: 80 , label: 'UOM' }]
  @UI.fieldGroup: [{ position: 80 , label: 'UOM', qualifier: 'SESDetails' }]
  Base_Uom;
  @UI.lineItem: [{ position: 90 , label: 'Final Entry' }]
  @UI.fieldGroup: [{ position: 90 , label: 'Final Entry', qualifier: 'SESDetails' }]
  Fin_Entry;
  @UI.lineItem: [{ position: 100 , label: 'Error' , hidden: true}]
  @UI.fieldGroup: [{ position: 100 , label: 'Error' , hidden: true}]
  Error;
  @UI.lineItem: [{ position: 110 , label: 'Error Message' }]
  @UI.fieldGroup: [{ position: 110 , label: 'Error Message', qualifier: 'SESDetails' }]
  Error_Message;
}

Now, we create behavior definition ZI_SES_PARENT -

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

define behavior for zi_ses_parent alias File
persistent table zses_file_table
lock master
total etag end_user
draft table zses_file_tabled
authorization master ( instance )
etag master end_user
{
  create;
  update;
  delete;
  // Logic to convert uploaded excel into internal table and save to the child entity is written here
  action ( features : instance ) uploadExcelData  result [1] $self;

  association _ses_excel { create; with draft; }
  // Logic to trigger action uploadExcelData
  determination fields on modify { field Filename ; }
  draft action Edit ;
  draft action Activate;
  draft action Discard;
  draft action Resume;
  draft determine action Prepare ;
}

define behavior for zi_ses_excel_data alias ExcelData
persistent table ZSES_DB
lock dependent by _ses_file
draft table zses_dbd
authorization dependent by _ses_file
etag master Begdate
{
  update;
  delete;
  field ( readonly ) end_user;
  association _ses_file { with draft; }
  // Logic to process the uploaded data from excel
  action createSES result [1] $self;
}

And the behavior projection ZC_SES_PARENT -

projection;
strict ( 2 );
use draft;

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

  field ( readonly ) status , Local_Last_Changed_At ;
  use action Edit;
  use action Activate;
  use action Discard;
  use action Resume;
  use action Prepare;
  use association _ses_excel { create; with draft; }
}

define behavior for zc_ses_excel //alias <alias_name>
{
  use update;
  use delete;
  use association _ses_file { with draft; }
  use action createSES;
}

Now, in the behavior implementation class - ZBP_I_SES_PARENT, we have two important methods -

Determination method - 'Fields' -

METHOD fields.

    SELECT @abap_true INTO @DATA(lv_valid) FROM zses_file_table UP TO 1 ROWS WHERE end_user = @SY-uname.
    ENDSELECT.

    IF lv_valid <> abap_true.
      INSERT zses_file_table FROM @( VALUE #( end_user = sy-uname ) ).
    ENDIF.

    MODIFY ENTITIES OF zi_ses_parent IN LOCAL MODE
    ENTITY file
    UPDATE FROM VALUE #( FOR key IN keys ( end_user        = key-end_user
                                           status          = ' ' " Accepted
                                           %control-status = if_abap_behv=>mk-on ) ).

    IF keys[ 1 ]-%is_draft = '01'.

      MODIFY ENTITIES OF zi_ses_parent IN LOCAL MODE
      ENTITY file
      EXECUTE uploadexceldata
      FROM CORRESPONDING #( keys ).
    ENDIF.
  ENDMETHOD.

Explanation:
1. We save an entry with our username to the parent table, so that the once an instance is created and it goes inside the draft, it finds an instance to edit.
2. We call the action uploadexceldata such that whenever a new file is uploaded, it converts the data and store it into the child table.

Action method 'uploadExcelData' -

    READ ENTITIES OF zi_ses_parent IN LOCAL MODE
      ENTITY file
      ALL FIELDS WITH
      CORRESPONDING #( keys )
      RESULT DATA(lt_inv).

    DATA(lv_attachment) = lt_inv[ 1 ]-attachment.

    DATA: rows          TYPE STANDARD TABLE OF string,
          content       TYPE string,
          conv          TYPE REF TO cl_abap_conv_in_ce,
          ls_excel_data TYPE zses_db,
          lt_excel_data TYPE STANDARD TABLE OF zses_db,
          lv_quantity   TYPE char10,
          lv_entrysheet TYPE ebeln.

    conv = cl_abap_conv_in_ce=>create( input = lv_attachment ).
    conv->read( IMPORTING data = content ).

    SPLIT content AT cl_abap_char_utilities=>cr_lf INTO TABLE rows.

    LOOP AT rows INTO DATA(ls_row).
      SPLIT ls_row AT ',' INTO ls_excel_data-entrysheet
                               ls_excel_data-ebeln
                               ls_excel_data-ebelp
                               ls_excel_data-ext_number
                               ls_excel_data-begdate
                               ls_excel_data-enddate
                               lv_quantity
                               "ls_attdata-BASE_UOM
                               ls_excel_data-fin_entry.

      ls_excel_data-entrysheet = lv_entrysheet = |{ ls_excel_data-entrysheet ALPHA = IN }|.
      ls_excel_data-ebeln      = |{ ls_excel_data-ebeln ALPHA = IN }|.
      ls_excel_data-ebelp      = |{ ls_excel_data-ebelp ALPHA = IN }|.
      ls_excel_data-quantity = CONV #( lv_quantity ).
      
      APPEND ls_excel_data TO lt_excel_data.
      CLEAR: ls_row, ls_excel_data.
ENDLOOP.

Explanation -
1. Read the excel file (CSV in our case) from the entity and append it to internal table LT_EXCEL_DATA.
2. Use EML to insert the data from LT_EXCEL_DATA to the child table.

Please refer below code for the implementation class -

CLASS lhc_exceldata DEFINITION INHERITING FROM cl_abap_behavior_handler.

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

    METHODS createses FOR MODIFY
      IMPORTING keys FOR ACTION exceldata~createses RESULT result.

ENDCLASS.

CLASS lhc_exceldata IMPLEMENTATION.

  METHOD get_instance_authorizations.
  ENDMETHOD.

  METHOD createses.

    READ ENTITIES OF zi_ses_parent IN LOCAL MODE
        ENTITY exceldata
        ALL FIELDS WITH
        CORRESPONDING #( keys )
        RESULT DATA(lt_data).

    DATA:
      ls_header_data TYPE i_serviceentrysheettp_2,
      ls_item_data   TYPE i_serviceentrysheetitemtp_2,

      lt_header_crt  TYPE TABLE FOR CREATE i_serviceentrysheettp_2\\serviceentrysheet,
      lt_item_cba    TYPE TABLE FOR CREATE i_serviceentrysheettp_2\\serviceentrysheet\_serviceentrysheetitem.

* Create SES with reference to a Service Purchase Order Item

*--- Prepare Header Data
    ls_header_data-serviceentrysheetname  = 'Demo SES'.
    ls_header_data-purchaseorder          = `4500000286`.
    ls_header_data-sesoriginobjecttype    = `EX`.

*--- Prepare Item Data
    ls_item_data-purchaseorderitem              = '00010'.
    ls_item_data-confirmedquantity              = '1'.
    ls_item_data-accountassignmentcategory      = 'K'.
    ls_item_data-serviceperformancedate         = '20230207'.
    ls_item_data-multipleacctassgmtdistribution = '0'.


*--- Prepare Payload
    APPEND INITIAL LINE TO lt_header_crt ASSIGNING FIELD-SYMBOL(<ls_hdr_crt>).
    <ls_hdr_crt> = CORRESPONDING #( ls_header_data CHANGING CONTROL ).
    <ls_hdr_crt>-%cid     = `HEADER_1` .

    APPEND INITIAL LINE TO lt_item_cba ASSIGNING FIELD-SYMBOL(<ls_itm_cba>).
    <ls_itm_cba>-%cid_ref = 'HEADER_1'.

    APPEND INITIAL LINE TO <ls_itm_cba>-%target ASSIGNING FIELD-SYMBOL(<item_data>).
    <item_data>       = CORRESPONDING #( ls_item_data CHANGING CONTROL ).
    <item_data>-%cid  = 'Item_1'.


    MODIFY ENTITIES OF i_serviceentrysheettp_2
      ENTITY serviceentrysheet
        CREATE
          FROM lt_header_crt
         CREATE BY \_serviceentrysheetitem
          FROM  lt_item_cba
      FAILED DATA(ls_failed_crt)
      REPORTED DATA(ls_reported_crt)
      MAPPED DATA(ls_mapped_crt).

  ENDMETHOD.

ENDCLASS.

CLASS lhc_file DEFINITION INHERITING FROM cl_abap_behavior_handler.
  PRIVATE SECTION.

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

    METHODS uploadexceldata FOR MODIFY
      IMPORTING keys FOR ACTION file~uploadexceldata RESULT result.
    METHODS fields FOR DETERMINE ON MODIFY
      IMPORTING keys FOR file~fields.
    METHODS get_instance_features FOR INSTANCE FEATURES
      IMPORTING keys REQUEST requested_features FOR file RESULT result.

ENDCLASS.

CLASS lhc_file IMPLEMENTATION.

  METHOD get_instance_authorizations.
  ENDMETHOD.

  METHOD uploadexceldata.

** Check if there exist an entry with current logged in username in parent table
    SELECT @abap_true INTO @DATA(lv_valid) FROM zses_file_table UP TO 1 ROWS WHERE end_user = @SY-uname.
    ENDSELECT.
** Create one entry, if it does not exist
    IF lv_valid <> abap_true.
      INSERT zses_file_table FROM @( VALUE #( end_user = sy-uname ) ).
    ENDIF.
** Read the parent instance
    READ ENTITIES OF zi_ses_parent IN LOCAL MODE
      ENTITY file
      ALL FIELDS WITH
      CORRESPONDING #( keys )
      RESULT DATA(lt_inv).

** Get attachment value from the instance
    DATA(lv_attachment) = lt_inv[ 1 ]-attachment.

** Data declarations
    DATA: rows          TYPE STANDARD TABLE OF string,
          content       TYPE string,
          conv          TYPE REF TO cl_abap_conv_in_ce,
          ls_excel_data TYPE zses_db,
          lt_excel_data TYPE STANDARD TABLE OF zses_db,
          lv_quantity   TYPE char10,
          lv_entrysheet TYPE ebeln.

** Convert excel file with CSV format into internal table of type string 
    conv = cl_abap_conv_in_ce=>create( input = lv_attachment ).
    conv->read( IMPORTING data = content ).

** Split the string table to rows
    SPLIT content AT cl_abap_char_utilities=>cr_lf INTO TABLE rows.

** Process the rows and append to the internal table
    LOOP AT rows INTO DATA(ls_row).
      SPLIT ls_row AT ',' INTO ls_excel_data-entrysheet
                               ls_excel_data-ebeln
                               ls_excel_data-ebelp
                               ls_excel_data-ext_number
                               ls_excel_data-begdate
                               ls_excel_data-enddate
                               lv_quantity
                               "ls_attdata-BASE_UOM
                               ls_excel_data-fin_entry.

      ls_excel_data-entrysheet = lv_entrysheet = |{ ls_excel_data-entrysheet ALPHA = IN }|.
      ls_excel_data-ebeln      = |{ ls_excel_data-ebeln ALPHA = IN }|.
      ls_excel_data-ebelp      = |{ ls_excel_data-ebelp ALPHA = IN }|.
      ls_excel_data-quantity = CONV #( lv_quantity ).

      APPEND ls_excel_data TO lt_excel_data.

      CLEAR: ls_row, ls_excel_data.
    ENDLOOP.

** Delete duplicate records
    DELETE ADJACENT DUPLICATES FROM lt_excel_data.
    DELETE lt_excel_data WHERE ebeln IS INITIAL.

** Prepare the datatypes to store the data from internal table lt_excel_data to child entity through EML
    DATA lt_att_create TYPE TABLE FOR CREATE zi_ses_parent\_ses_excel.

    lt_att_create = VALUE #( (  %cid_ref  = keys[ 1 ]-%cid_ref
                                %is_draft = keys[ 1 ]-%is_draft
                                end_user  = keys[ 1 ]-end_user
                                %target   = VALUE #( FOR ls_data IN lt_excel_data ( %cid       = |{ ls_data-ebeln }{ ls_data-ebelp }|
                                                                                   %is_draft   = keys[ 1 ]-%is_draft
                                                                                   end_user    = sy-uname
                                                                                   entrysheet  = ls_data-entrysheet
                                                                                   ebeln       = ls_data-ebeln
                                                                                   ebelp       = ls_data-ebelp
                                                                                   ext_number  = ls_data-ext_number
                                                                                   begdate     = ls_data-begdate
                                                                                   enddate     = ls_data-enddate
                                                                                   quantity    = ls_data-quantity
                                                                                  " BASE_UOM    = ls_data-
                                                                                   fin_entry   = ls_data-fin_entry
                                                                                  %control = VALUE #( end_user    = if_abap_behv=>mk-on
                                                                                                      entrysheet  = if_abap_behv=>mk-on
                                                                                                      ebeln       = if_abap_behv=>mk-on
                                                                                                      ebelp       = if_abap_behv=>mk-on
                                                                                                      ext_number  = if_abap_behv=>mk-on
                                                                                                      begdate     = if_abap_behv=>mk-on
                                                                                                      enddate     = if_abap_behv=>mk-on
                                                                                                      quantity    = if_abap_behv=>mk-on
                                                                                                     " BASE_UOM    = ls_data-
                                                                                                      fin_entry   = if_abap_behv=>mk-on  ) ) ) ) ).
    READ ENTITIES OF zi_ses_parent IN LOCAL MODE
    ENTITY file
    BY \_ses_excel
    ALL FIELDS WITH
    CORRESPONDING #( keys )
    RESULT DATA(lt_excel).

** Delete already existing entries from child entity
    MODIFY ENTITIES OF zi_ses_parent IN LOCAL MODE
    ENTITY exceldata
    DELETE FROM VALUE #( FOR ls_excel IN lt_excel (  %is_draft = ls_excel-%is_draft
                                                     %key      = ls_excel-%key ) )
    MAPPED DATA(lt_mapped_delete)
    REPORTED DATA(lt_reported_delete)
    FAILED DATA(lt_failed_delete).

** Create the records from the new attached CSV file
    MODIFY ENTITIES OF zi_ses_parent IN LOCAL MODE
    ENTITY file
    CREATE BY \_ses_excel
    AUTO FILL CID
    WITH lt_att_create.


    APPEND VALUE #( %tky = lt_inv[ 1 ]-%tky ) TO mapped-file.
    APPEND VALUE #( %tky = lt_inv[ 1 ]-%tky
                    %msg = new_message_with_text( severity = if_abap_behv_message=>severity-success
                                                  text = 'Excel Data Uploaded' )
                   ) TO reported-file.

    MODIFY ENTITIES OF zi_ses_parent IN LOCAL MODE
    ENTITY file
    UPDATE FROM VALUE #( ( %is_draft = keys[ 1 ]-%is_draft
                           end_user  = sy-uname
                           status     =  'P'
                          " %data     = VALUE #( status = 'P' )
                           %control  = VALUE #( status = if_abap_behv=>mk-on ) ) )
    MAPPED DATA(lt_mapped_update)
    REPORTED DATA(lt_reported_update)
    FAILED DATA(lt_failed_update).

    READ ENTITIES OF zi_ses_parent IN LOCAL MODE
    ENTITY file
    ALL FIELDS WITH CORRESPONDING #( keys )
    RESULT DATA(lt_file_status).

    MODIFY ENTITIES OF zi_ses_parent IN LOCAL MODE
    ENTITY file
    UPDATE FROM VALUE #( FOR ls_file_status IN lt_file_status ( %is_draft = ls_file_status-%is_draft
                                                                %tky      = ls_file_status-%tky
                                                                %data     = VALUE #( status = 'C'  )
                                                                %control  = VALUE #( status = if_abap_behv=>mk-on )
                                                     ) ).

    READ ENTITIES OF zi_ses_parent IN LOCAL MODE
       ENTITY file
       ALL FIELDS WITH
       CORRESPONDING #( keys )
       RESULT DATA(lt_file).



    result = VALUE #( FOR ls_file IN lt_file ( %tky   = ls_file-%tky

                                               %param = ls_file ) ).

  ENDMETHOD.

  METHOD fields.

    SELECT @abap_true INTO @DATA(lv_valid) FROM zses_file_table UP TO 1 ROWS WHERE end_user = @SY-uname.
    ENDSELECT.

    IF lv_valid <> abap_true.
      INSERT zses_file_table FROM @( VALUE #( end_user = sy-uname ) ).
    ENDIF.

    MODIFY ENTITIES OF zi_ses_parent IN LOCAL MODE
    ENTITY file
    UPDATE FROM VALUE #( FOR key IN keys ( end_user        = key-end_user
                                           status          = ' ' " Accepted
                                           %control-status = if_abap_behv=>mk-on ) ).

    IF keys[ 1 ]-%is_draft = '01'.

      MODIFY ENTITIES OF zi_ses_parent IN LOCAL MODE
      ENTITY file
      EXECUTE uploadexceldata
      FROM CORRESPONDING #( keys ).
    ENDIF.
  ENDMETHOD.


  METHOD get_instance_features.

    READ ENTITIES OF zi_ses_parent IN LOCAL MODE
           ENTITY file
             FIELDS ( end_user )
                WITH CORRESPONDING #( keys )
              RESULT DATA(lt_file).


    result = VALUE #( FOR ls_file IN lt_file ( %key = ls_file-%key
                                               %is_draft = ls_file-%is_draft
                                               %features-%action-uploadexceldata = COND #( WHEN ls_file-%is_draft = '00'
                                                                                           THEN if_abap_behv=>fc-f-read_only
                                                                                           ELSE if_abap_behv=>fc-f-unrestricted ) ) ).

  ENDMETHOD.

ENDCLASS.

After this, create service definition, expose both the parent and child consumption views, create a service binding and see the wonders.
The list report page would look like -

Since, we used where clause to filter the parent records based on the current logged-in user in the interface view ZI_SES_PARENT, we should see only 1 record here. You can also skip the list report page in SAP BAS and deploy the app which directly opens the object page.
When navigate to the object page and click on edit.

Once saved, we should see the records -

You can write the logic to process these records in an instance action for child entity, just like we have an action defined as 'Process SES'.
With this process, you can upload CSV file and process the records. You can try changing the logic to process XSLX file as well.

Writing/Unveiling ABAP Unit Tests for Table Functions

2024-04-16T13:01:57.878000+02:00

Introduction

In SAP ABAP development, writing robust code is essential for ensuring the stability and reliability of applications. One powerful tool for achieving this is the ABAP Unit, which allows developers to automate the testing process and validate the behavior of their code. In this blog post, we will explore how to write ABAP unit tests specifically for table functions.

ABAP CDS - Table Functions

A CDS table function is defined in the DDL source code of a CDS data definition in the ABAP development tools for Eclipse using the statement DEFINE TABLE FUNCTION in the CDS DDL of the ABAP Core Data Services (CDS). A CDS table function includes the following (including an example that is included later in the blog):

The CDS entity (e.g., ZFLIGHTS )
An AMDP function implementation ( e.g., ZCL_FLIGHT_DETAILS )

Here, we'll use a classic example of SFLIGHT data to illustrate the creation of the query within the table function.

- Table Function CDS Entity:

The following is the table function, equipped with a parameter to facilitate filtering during selection.

@EndUserText.label: 'Flights and its Details'
@ClientHandling.algorithm: #SESSION_VARIABLE
@ClientHandling.type: #CLIENT_DEPENDENT
define table function ZFLIGHTS
  with parameters
    @Environment.systemField: #CLIENT
    P_mandt     : abap.clnt,
    P_CarrierId : s_carr_id
returns
{
  key mandt        : abap.clnt;
  key carrierId    : s_carr_id;
  key connectionId : s_conn_id;
  key flightDate   : s_date;
      name         : s_carrname;
      planeType    : s_planetye;
      seatsMax     : s_seatsmax;
      currencyCode : s_currcode;
}
implemented by method
  ZCL_FLIGHT_DETAILS=>get_details;

- Implementation of the table AMDP function is below:

CLASS zcl_flight_details DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC .

  PUBLIC SECTION.
    INTERFACES if_amdp_marker_hdb.
    CLASS-METHODS get_details FOR TABLE FUNCTION zflights.

  PROTECTED SECTION.
  PRIVATE SECTION.

ENDCLASS.

CLASS zcl_flight_details IMPLEMENTATION.

  METHOD get_details BY DATABASE FUNCTION
              FOR HDB
              LANGUAGE SQLSCRIPT
              OPTIONS READ-ONLY
              USING s_flights s_carrier.

    RETURN select _flight.mandt,
                  _flight.CarrierId,
                  _flight.ConnectionId,
                  _flight.FlightDate,
                  _carrier.Name,
                  _flight.planetype,
                  _flight.seatsmax,
                  _flight.currencyCode
                  from
                  s_flights as _flight
                  left outer join
                  s_carrier as _carrier
                  on    _flight.mandt     = _carrier.mandt     and
                        _flight.CarrierId = _carrier.CarrierId
                  where _flight.mandt     = :P_mandt           and
                        _flight.CarrierId = :P_CarrierId;
  ENDMETHOD.

ENDCLASS.

Setting Up an ABAP Unit Environment

Before crafting tests for table functions, it is imperative to establish the ABAP unit environment. This process entails crafting a test class along with methods to assess the functionality of the table function. Let's initiate the creation of a class named ZCL_AUNIT_ZFLIGHTS, within which we'll create a local test class termed LCL_CL_AUNIT_ZFLIGHTS.

CLASS lcl_cl_aunit_zflights DEFINITION FINAL FOR TESTING DURATION SHORT RISK LEVEL HARMLESS.

  PUBLIC SECTION.
    CLASS-DATA: environment TYPE REF TO if_amdp_test_environment.

  PRIVATE SECTION.
    CLASS-METHODS class_setup.
    CLASS-METHODS class_teardown.
    METHODS setup.
ENDCLASS.

CLASS lcl_cl_aunit_zflights IMPLEMENTATION.

  METHOD class_setup.
    " For testing an AMDP table function which is a CDS table function source,
    " 1. One would need to configure the AMDP table function class and the method name in the AMDP test configuration step.

    " Here the AMDP method 'ZCL_FLIGHT_DETAILS=>GET_DETAILS' is a table function which is used as a source for the CDS table function 'CDSFRWK_TF_FLIGHT_BOOKING'.
    DATA(environment_config) = cl_amdp_test_environment=>create_test_configuration( ).
    environment_config->add_amdp_class( 'ZCL_FLIGHT_DETAILS' )->add_methods_for_unit_test( VALUE #( ( 'GET_DETAILS' ) ) ).

    environment = cl_amdp_test_environment=>create( environment_config ).
  ENDMETHOD.

  METHOD class_teardown.
    IF environment IS NOT INITIAL.
      environment->destroy( ).
    ENDIF.
  ENDMETHOD.

  METHOD setup.
    " Clears any existing test configuration on the test doubles which are set by other unit test methods.
    environment->clear_doubles( ).
  ENDMETHOD.
ENDCLASS.

In the method class_setup, the environment configuration is done, in which the name of the AMDP class and its method to be tested need to be given.

Mocking Data

For mocking data, we'll create a new method named test_cds_table_function within the private section of the test class. This method will facilitate the generation of mock data for testing purposes.

PRIVATE SECTION.
METHODS test_cds_table_function FOR TESTING RAISING cx_static_check.

By default, if no client is specified, the system client will be assumed. Since I aim to demonstrate data mocking at the client level, I'll simulate data for two distinct clients and execute the query with client-specific information.

- Procedure to mock the data:

"To get the object instance of the dependency used in the AMDP Implementation Class
DATA(lo_object) = environment->get_test_double( DEPENDENCY ).

"Set the client for which the data is being mocked
lo_object->get_view_content_config( )->for_client( CLIENT-INFO ).

"Set the content of the dependency
lo_object->get_view_content_config( )->set_content( CONTENT ).

The actual Implementation of the method is below:

  METHOD test_cds_table_function.

    DATA: lt_flights_001 TYPE STANDARD TABLE OF s_flights,
          lt_flights_714 TYPE STANDARD TABLE OF s_flights,
          lt_carrier_001 TYPE STANDARD TABLE OF s_carrier,
          lt_carrier_714 type standard table of s_carrier.

    lt_flights_001 = VALUE #( ( CarrierId = 'AA' ConnectionId = '0101' FlightDate = '20240101' planetype = 'A340-600'
                                seatsmax = '330' currencycode = 'USD' )
                              ( CarrierId = 'DL' ConnectionId = '0102' FlightDate = '20240201' planetype = 'A340-600'
                                seatsmax = '330' currencycode = 'USD' )
                              ( CarrierId = 'DL' ConnectionId = '0103' FlightDate = '20240301' planetype = 'A340-600'
                                seatsmax = '330' currencycode = 'USD' ) ).

    lt_carrier_001 = VALUE #( ( carrierid = 'AA' Name = 'American Airlines' )
                              ( carrierid = 'DL' Name = 'Delta Airlines' ) ).

    lt_flights_714 = VALUE #( ( CarrierId = 'AA' ConnectionId = '0104' FlightDate = '20240401' planetype = 'A340-600'
                                seatsmax = '330' currencycode = 'USD' )
                              ( CarrierId = 'DL' ConnectionId = '0105' FlightDate = '20240501' planetype = 'A340-600'
                                seatsmax = '330' currencycode = 'USD' )
                              ( CarrierId = 'DL' ConnectionId = '0106' FlightDate = '20240601' planetype = 'A340-600'
                                seatsmax = '330' currencycode = 'USD' ) ).

    lt_carrier_714 = VALUE #( ( carrierid = 'AA' Name = 'American Airlines' )
                              ( carrierid = 'DL' Name = 'Delta Airlines' ) ).

    " Get the test double of "S_FLIGHTS" & "S_CARRIER" from the test environment.
    DATA(lo_flight) = environment->get_test_double( 'S_FLIGHTS' ).
    DATA(lo_carrier) = environment->get_test_double( 'S_CARRIER' ).

    lo_flight->get_view_content_config( )->for_client( '001' ).
    lo_carrier->get_view_content_config( )->for_client( '001' ).

    lo_flight->get_view_content_config( )->set_content( lt_flights_001 ).
    lo_carrier->get_view_content_config( )->set_content( lt_carrier_001 ).

    lo_flight->get_view_content_config( )->for_client( '714' ).
    lo_carrier->get_view_content_config( )->for_client( '714' ).

    lo_flight->get_view_content_config( )->set_content( lt_flights_714 ).
    lo_carrier->get_view_content_config( )->set_content( lt_carrier_714 ).

    SELECT * FROM zflights( p_carrierid = 'DL' ) USING CLIENT '714' INTO TABLE (lt_result).

    cl_abap_unit_assert=>assert_equals(
      EXPORTING
        act                  = lines( lt_result )     " Data object with current value
        exp                  = 2                      " Data object with expected type
    ).

  ENDMETHOD.

While executing the query for client '714', LT_RESULT acquired the following records. The assertion verifies the successful retrieval of 2 records for client '714'.

Conclusion

Writing ABAP unit tests holds significant importance in SAP ABAP development. Thorough testing not only confirms the accuracy of table functions but also enhances the overall stability and performance of the system.

Happy Coding 🙂

Consume Restful Webservices using POST MAN

2024-04-19T15:56:31.284000+02:00

HTTP-based APIs integrate easily with RESTful web services. There are many ways to use HTTP methods to consume and update and retrieve these API data.

HTTP API methods and understand how to use them appropriately on resources

Method 1: GET

The most common HTTP method is GET, which returns a representational view of a resource's contents and data. GET should be used in read-only mode, which keeps the data safe, You should get the same results no matter how many times you use this method, unless it is modified by another client in the interim.

Method 2: POST

Post request used to create resource (Record ) in server, While creating record we have to pass Body data Parameters(key, values) to create the Record as JSON, Form formats are supported.

While submitting the data we have to update Header tab content type with application/JSON.

After create new record by using browser you will received updated data. By default Browsers using HTTP Protocol with GET method to retrieve data from service.

Method 3: PATCH

PATCH is another HTTP method used to update resources. As opposed to replacing resources, like the PUT method does, PATCH only modifies resource contents. As a general rule, these modifications worked based on Key.

While submitting the data we have to update Header tab content type with application/JSON.

Patch update the record based on Id, after update you will find latest records by refresh your browser.

We have create additional record 4 for other operations in above list.

Method 5: DELETE

The last HTTP method DELETE. When a DELETE method targets a single resource, that resource is removed entirely(Hard Delete). we have to pass based on Key ID (4).

Delete Method will delete the 4th record based on Key. after we can refresh browser data.

Authentication

Authentication tab help to protect the API data using different security ways.

Basic Authentication

Basic Authentication is a method of securing HTTP requests through a special header:

Authorization Tab

let’s send a GET request to a Basic Auth-secured endpoint and expect an Unauthorized status for the response:

Now, let’s add the credentials. To do this, we simply go to the “Authorization” tab and select “Basic Auth” as the authorization type. After that, we insert the username and password and we’re all set:

2) Authorization: Basic <credentials>

To generate the credentials token, we need to write the username and password, joined by the semicolon character. After that, we need to encode the resulting string with Base64.

Let’s assume the username is “admin” and the password is “baeldung“. First, we’ll create the credentials string, which will be “admin:baeldung“. Then, we’ll encode it with Base64, add the “Basic” keyword, and set it as the header’s value:

What is Bearer Authentication?

HTTP provides a framework for controlling access to protected resources. HTTP authentication is performed by sending authentication credentials in the authorization header to access the protected resource. Bearer authentication (also called token authentication) is one of the HTTP authentication schemes that grant access to the bearer of this token. Bearer token authentication is done by sending a security token with every HTTP request we make to the server. You can do bearer authentication with any programming language.

Bearer Token Authentication Syntax

Authorization: Bearer {token}

Postman displays the response data sent from the server in the lower pane.

Exploring GraphQL and REST for SAP Developers

2024-04-26T14:10:06.068000+02:00

I came across GraphQL while working on a side project and as a SAP Developer who worked a lot with REST APIs, I was wondering what advantages GraphQL could offer me, and how to apply it for different use cases. So, I decided to explore both APIs and how to use them in the SAP context. Here is a brief overview of my thoughts about both APIs.

Introduction

let's start with a brief definition of the APIs concept, APIs are the lifeblood of modern software development, bridging the gap between different systems. They define rules for accessing functionality and data remotely. Let's delve into API concepts and see how GraphQL and REST fit into the SAP world.

Over the past decade, REST has been the go-to for web APIs, but it's not without its flaws. Enter GraphQL, developed to tackle the shortcomings of REST and provide more flexibility and efficiency for developers.

Understanding APIs: APIs act as intermediaries facilitating communication between software applications. They come in two main flavors: SOAP, known for its strict standards, and REST, favored for its simplicity and scalability.

GraphQL: GraphQL, developed by Facebook, offers a more powerful alternative to REST. It allows clients to request specific data, reducing over-fetching issues common in REST APIs.

REST: REST, an architectural style for building networked applications, relies on stateless, client-server communication via HTTP.

Key Differences

Data Fetching: GraphQL enables precise data fetching with a single request, unlike REST which may lead to over-fetching or under-fetching.
Endpoint Complexity: REST APIs often require multiple endpoints, while GraphQL offers a single endpoint handling various data requests.
Versioning: REST commonly relies on versioning, unlike GraphQL which allows backward-compatible changes without versioning.
Caching: REST APIs leverage HTTP caching mechanisms, while GraphQL responses typically require additional configuration for caching.

Similarities

Both GraphQL and REST facilitate data exchange between services or applications, following a client-server model.

Architecture

Both are stateless and use a client-server model based on HTTP.

Resource-based Design

Both REST and GraphQL design data interchange around resources, each with its unique identifier and set of operations.

Data Exchange

Both support JSON as the primary data exchange format and caching for improved performance.

When to Use What?

Use REST When:

You need a straightforward and widely adopted solution.
Your data requirements are consistent and well-defined.
Caching is crucial for your application's performance.
You're working with legacy systems that are compatible with REST.

Use GraphQL When:

Your data requirements are dynamic and vary across different clients.
Over-fetching or under-fetching of data is a concern.
You want to reduce the number of API calls and improve efficiency.
You're developing a new application or service and want flexibility in data retrieval.

Conclusion

GraphQL and REST are vital for integration and data exchange in the SAP ecosystem. While REST is popular for its simplicity, GraphQL's flexibility is gaining traction. Understanding their nuances empowers SAP developers to design effective APIs for their solutions.