This short overview of abstract entities concept in the context of non-standard RAP business object operations. It outlines their purpose, advantages, and implementation strategies, emphasizing their role in enhancing modularity and flexibility in data modeling.

Purpose

Abstract entities are Core Data Services (CDS) constructs specifically designed to model complex input parameters for non-standard RAP BO operations(actions and functions).

Database Independence

One of the key features of abstract entities is their independence from database persistence. They are particularly suited for parameter modeling and give possibility to redefine parameters on next modelling level.

Reusability

Abstract entities promote reusability across multiple operations. This characteristic enables developers to adopt a more modular approach, allowing the same abstract entity to be utilized in different contexts without the need for redundant definitions.

Parameter Flexibility

These entities support complex structures, including multi-level nested components. This flexibility allows for more sophisticated data representations and enhances the capability to handle intricate business logic.

Binding

Unlike traditional entities, abstract entities are not bound to specific BO nodes. They provides greater adaptability in how they are integrated into various operations.

Improved Separation of Concerns

By decoupling input parameter modeling from the actual business logic, abstract entities facilitate a clearer separation of concerns. This simplification in design leads to more maintainable and understandable code, as the focus can be placed on each aspect of the application independently.

In conclusion, abstract entities serve as a powerful tool for modeling complex input parameters in non-standard RAP BO operations.

2. Implementation details.

I want to highlight how to effectively use abstract entities in ABAP development. One of their key applications is for typing, particularly for action parameters in RAP actions. Let’s begin with a straightforward example.

We make a simple abstract entity with four fields.

@EndUserText.label: 'ABSTRACT ENTITY'
define root abstract entity ZPRU_ABS_ENTITY
{
    ABSTRACTENTITYNAME : char40;
    SURNAME : char40;
    AGE : int4;
    EMAIL : char40;
    
    CHILD : composition [ * ] of ZPRU_ABS_CHILD;
    CHILD_2: composition [ * ] of ZPRU_ABS_CHILD_2;
}

Next, I created a RAP business object with a root entity view (the specifics of which aren’t important for this example) and defined the ‘sendEntity’ action with an input parameter of type ZPRU_ABS_ENTITY.

Let’s have a look at action definition:

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

define behavior for ZPRU_ROOT_ENTITY alias ROOT
persistent table zpru_dn
lock master
authorization master ( instance )
{
  create;
  update;
  delete;
  field ( readonly ) dn_no, freq, prod;

  //Flat
  action sendEntity parameter ZPRU_ABS_ENTITY;
  // Deep
  action sendEntity2 deep parameter ZPRU_ABS_ENTITY;
  // Deep Table
  action sendEntity3 deep table parameter ZPRU_ABS_ENTITY;

}

Right now, let’s check RAP business object implementation class.

CLASS lhc_root DEFINITION INHERITING FROM cl_abap_behavior_handler.
  PRIVATE SECTION.

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

    METHODS sendentity2 FOR MODIFY
      IMPORTING keys FOR ACTION root~sendentity2.

    METHODS sendentity FOR MODIFY
      IMPORTING keys FOR ACTION root~sendentity.

    METHODS sendentity3 FOR MODIFY
      IMPORTING keys FOR ACTION root~sendentity3.

ENDCLASS.

CLASS lhc_root IMPLEMENTATION.

  METHOD get_instance_authorizations.
  ENDMETHOD.

  METHOD sendentity2.
    DATA(lv_deep_field_from_abs_entity) = keys[ 1 ]-%param-child[ 1 ]-abstractchildname.
  ENDMETHOD.

  METHOD sendentity.
    DATA(lv_field_from_abs_entity) = keys[ 1 ]-%param-abstractentityname.
  ENDMETHOD.

  METHOD sendentity3.
    DATA(lv_deep_table_field) = keys[ 1 ]-%param[ 1 ]-child[ 1 ]-abstractchildname.
  ENDMETHOD.

ENDCLASS.

Derived type:

As a result, you’ll see the KEYS table, where each row contains a %PARAM component. This component is typed as the structure ZPRU_ABS_ENTITY.

The next step is to demonstrate the use of the ‘deep parameter AbstractBDEF’ and the ‘deep table parameter AbstractBDEF’ in defining a BDEF action parameter.

To do this, we need to extend the abstract entity by adding a BDEF of type Abstract with a hierarchy.

First, I added the ‘root’ keyword to the abstract entity:

One important note: when adding a BDEF to an abstract entity, we initiate the creation of an abstract business object. As a result, we need to construct this business object in a way that’s quite similar to how we build standard RAP business objects. This is why we use keywords like ‘root’, ‘composition’, and ‘association to parent.’

I also created a new abstract entity, ZPRU_ABS_CHILD. Then, I added mutual associations between ZPRU_ABS_ENTITY as the root and ZPRU_ABS_CHILD as the child.

Then, I’ve created BDEF with ZPRU_ABS_ENITY as root entity and Abstract implementation type:

Let’s overview new abstract BDEF:

abstract;
strict ( 2 );
with hierarchy;

define behavior for ZPRU_ABS_ENTITY alias ABS
{
  association CHILD;
  association CHILD_2;
}

define behavior for ZPRU_ABS_CHILD alias CHILD
{

  association ROOT;

}

define behavior for zpru_abs_child_2 {

association third_level;

}

There are 3 main points:

1. add keyword ‘with hierarchy’ to make BDEF opt to deep expanding.
   
2. recreate RAP BO composition tree, add root entity and child entity.
   
3. explicitly mark association to ZPRU_ABS_CHILD.

Finally, I’ve added addition keyword ‘deep’ to action definition to expand action parameter type.

Let’s have a look into typing:

%PARAM typing:

You can notice that to component %PARAM a new nested table with the name CHILD has been added. It’s an effect of keyword ‘deep’ in action parameter definition. Component CHILD has type of table due to cardinality [ * ] in definition of composition in abstract root entity ZPRU_ABS_ENTITY.

Last topic is about addition ‘deep table’ to action parameter definition.

Let’s add it:

Hence, let’s check what has been changed in typing:

As you can see component %PARAM became table, before it was a structure. This is the effect of keyword ‘table’ in action parameter definition.

Lastly, the same principles apply to typing action output parameters. However, one key difference is that we can’t use the ‘deep’ addition when defining output parameters. As a result, the %PARAM component will be incorporated into the output’s derived type as a structure.

A table with summarizing:

The post CDS Abstract Entity and ABAP RESTful Application Programming Model: Input parameter modelling appeared first on ERP Q&A.

Challenge: background processing framework has been introduced by SAP from Cloud 2311 version. Without this framework, it is not possible to trigger an asynchronous task from a stateless UI.

Solution: To simulate similar functionality we can use existing ABAP artifacts like RFC and submitting program in background job.

Overview: In this example, I have implemented the following:

• a new action with parameters is defined in the behavior definition. The key of the RAP object will hold the keys of the table that need to be changed. The new values to be updated are passed by the UI as parameters to the action

action (features : instance) upload_file  parameter ZSD_ABS_CONTRACTUAL_INDATA;

• an RFC function module is created that accepts the data from the file in the form of an internal table
  
• Above RFC function module is called from the RAP action implementation ( with the addition destination ‘NONE’ as otherwise commit cannot be done from the FM to schedule the job ).

METHOD upload_file.

    DATA: gt_return   TYPE STANDARD TABLE OF zsds_soitem_message,
          lt_sch_data TYPE zsdt_soschdata.

    IF NOT keys[] IS INITIAL.
      LOOP AT keys INTO DATA(ls_keys).
        APPEND INITIAL LINE TO lt_sch_data ASSIGNING FIELD-SYMBOL(<ls_sch_data>).
        <ls_sch_data>-vbeln = ls_keys-salesdocument.
        <ls_sch_data>-posnr = ls_keys-salesdocumentitem.
        <ls_sch_data>-del_dt = COND #( WHEN ls_keys-%param-newcontractualdt IS NOT INITIAL
                                       THEN ls_keys-%param-newcontractualdt ).
        <ls_sch_data>-email = cond #( WHEN ls_keys-%param-email IS NOT INITIAL
                                       THEN ls_keys-%param-email ).

      ENDLOOP.

      CALL FUNCTION 'ZSD_DEL_DATE_UPD_FILE' DESTINATION 'NONE'
        EXPORTING
          it_sch_data   = lt_sch_data
        EXCEPTIONS
          error_message = 99.

    ENDIF.

  ENDMETHOD.

• The function module calls the ‘JOB_OPEN’ and ‘JOB_CLOSE’ function modules to submit another program via a background job.
  
• The program runs asynchronously as a job and updates the data and also sends an email with the results to the email-id ( the parameter email in the previous screenshot )
  
• Email functionality has been implemented so the user is informed of the success or failure of the task as the UI doesn’t wait for a response and simply displays a message that the data will be updated in background.
  
• The button and the popup that allows the user to upload an excel file:

Conclusion: The above approach can be used to call an asynchronous task from an RAP object for OP SAP versions. With SAP Cloud 2311, it will also be possible to update the UI once the asynchronous task is completed using event driven actions.

The post Handle Asynchronous task in background job from a stateless UI application using RAP business object appeared first on ERP Q&A.

The existing workaround approaches present several drawbacks:

• Custom UI Extensions: Require specialized UI5 development expertise.
• Third-Party Solutions: Introduce risks related to licensing compliance and potential security vulnerabilities.
• Object Page Manipulations: Involve complex, multi-step processes, such as creating a dummy object page, facilitating file upload, temporarily storing the file data in a table field, and requiring a final user action (a button press) to initiate processing. This temporary data storage is often unnecessary, complicating the data model.

However, SAP has recently introduced ABAP / CAP annotations that offer a cloud-ready solution, potentially eliminating approximately 95% of the development effort typically associated with integrating an Excel upload into the backend. This innovation allows developers to prioritize implementing core business logic over developing reusable technical artifacts.

I will now detail the implementation steps.

A business requirement to manage mass processing listings for a library was selected to demonstrate this use case. The implementation requires several steps, with steps 3 through 6 being the special or additional configurations needed, while all others are considered routine.

Implementation Steps

1. A database table for the listing entity is created. This involves fields such as Id, Title, Type, and Author.

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

  key client            : abap.clnt not null;
  key listing_uuid      : sysuuid_x16 not null;
  id                    : abap.numc(10);
  title                 : abap.char(40);
  type                  : abap.char(5);
  author                : abap.char(40);
  publisher_studio      : abap.char(40);
  isbn_ean              : abap.char(40);
  language_code         : abap.lang;
  publication_year      : abap.numc(4);
  description           : abap.char(40);
  totalcopies           : abap.int2;
  available_copies      : abap.int2;
  location_shelf_id     : abap.char(40);
  lending_duration_days : abap.int2;
  status                : abap.char(40);
  cover_image_url       : abap.char(100);
  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;

}

2. A RAP Business Object (BO) is generated, followed by the requisite UI artifacts. The specific RAP BO scenario (Managed, Unmanaged, Draft, or Non-Draft) is noted as not influencing the core Excel upload use case. The RAP Generator is used to simplify the demonstration.

3. A root abstract entity is created for the file to be uploaded. (This entity is highly reusable and can be applied across different RAP BOs).

@EndUserText.label: 'Abs. Entity For Attachment'
define root abstract entity ZRK_D_FILE_STREAM
{
  @Semantics.largeObject.mimeType: 'MimeType'
  @Semantics.largeObject.fileName: 'FileName'
  @Semantics.largeObject.contentDispositionPreference: #INLINE
  @EndUserText.label: 'Select Excel file'
  StreamProperty : abap.rawstring(0);
  
  .hidden: true
  MimeType : abap.char(128);
  
  .hidden: true
  FileName : abap.char(128);   
}

4. The abstract behavior definition for the file entity is implemented.

abstract;
strict(2);
with hierarchy;
define behavior for ZRK_D_FILE_STREAM {
}

5. A second abstract entity is created to serve as an action parameter. This entity includes an association to the file abstract entity (from Step 3).

@EndUserText.label: 'Action Param for Uploading Excel'
define root abstract entity ZRK_D_UPLOAD_EXCEL
{
// Dummy is a dummy field
@UI.hidden: true
dummy : abap_boolean;
     _StreamProperties : association [1] to ZRK_D_FILE_STREAM on 1 = 1;
    
}

6. The abstract behavior definition for the action parameter is implemented, including the association to the earlier entity.

abstract;
strict ( 2 );
with hierarchy;
define behavior for ZRK_D_UPLOAD_EXCEL //alias <alias_name>
{
association _StreamProperties with hierarchy;
}

7. An action is defined on the RAP BO Behavior definition, with the parameter specified in Step 5.

static action ExcelUpload deep parameter ZRK_D_UPLOAD_EXCEL ;

managed implementation in class ZRK_BP_R_LIB_LISTINGS unique;
strict ( 2 );
with draft;
extensible;
define behavior for ZRK_R_LIB_LISTINGS alias Listings
persistent table ZRK_LIB_LISTINGS
extensible
draft table ZRK_LIB_LSTNGS_D
etag master LocalLastChangedAt
lock master total etag LastChangedAt
authorization master( global )
{
  field ( readonly )
   ListingUUID,
   LocalCreatedBy,
   LocalCreatedAt,
   LocalLastChangedBy,
   LocalLastChangedAt,
   LastChangedAt;

  field ( numbering : managed )
   ListingUUID;


  create;
  update;
  delete;

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

  static action ExcelUpload deep parameter ZRK_D_UPLOAD_EXCEL ;

  mapping for ZRK_LIB_LISTINGS corresponding extensible
  {
    ListingUUID = listing_uuid;
    ID = id;
    Title = title;
    Type = type;
    Author = author;
    PublisherStudio = publisher_studio;
    IsbnEan = isbn_ean;
    LanguageCode = language_code;
    PublicationYear = publication_year;
    Description = description;
    Totalcopies = totalcopies;
    AvailableCopies = available_copies;
    LocationShelfID = location_shelf_id;
    LendingDurationDays = lending_duration_days;
    Status = status;
    CoverImageUrl = cover_image_url;
    LocalCreatedBy = local_created_by;
    LocalCreatedAt = local_created_at;
    LocalLastChangedBy = local_last_changed_by;
    LocalLastChangedAt = local_last_changed_at;
    LastChangedAt = last_changed_at;
  }

}

8. The business logic is implemented to read the Excel content. A released API, XCO_CP_XLSX , is used for this demonstration.

METHOD ExcelUpload.
    TYPES : BEGIN OF ty_sheet_data,
              id                  TYPE zrk_r_lib_listings-id,
              title               TYPE zrk_r_lib_listings-title,
              type                TYPE zrk_r_lib_listings-Type,
              author              TYPE zrk_r_lib_listings-author,
              PublisherStudio     TYPE zrk_r_lib_listings-PublisherStudio,
              IsbnEan             TYPE zrk_r_lib_listings-IsbnEan,
              LanguageCode        TYPE zrk_r_lib_listings-LanguageCode,
              PublicationYear     TYPE zrk_r_lib_listings-PublicationYear,
              description         TYPE zrk_r_lib_listings-Description,
              Totalcopies         TYPE zrk_r_lib_listings-Totalcopies,
              AvailableCopies     TYPE zrk_r_lib_listings-AvailableCopies,
              LocationShelfID     TYPE zrk_r_lib_listings-LocationShelfID,
              LendingDurationDays TYPE zrk_r_lib_listings-LendingDurationDays,
              status              TYPE zrk_r_lib_listings-Status,
            END OF ty_sheet_data.

    DATA lv_file_content   TYPE xstring.
    DATA lt_sheet_data     TYPE STANDARD TABLE OF ty_sheet_data.
    DATA lt_listing_create TYPE TABLE FOR CREATE zrk_r_lib_listings.

    lv_file_content = VALUE #( keys[ 1 ]-%param-_streamproperties-StreamProperty OPTIONAL ).

    " Error handling in case file content is initial

    DATA(lo_document) = xco_cp_xlsx=>document->for_file_content( lv_file_content )->read_access( ).

    DATA(lo_worksheet) = lo_document->get_workbook( )->worksheet->at_position( 1 ).

    DATA(o_sel_pattern) = xco_cp_xlsx_selection=>pattern_builder->simple_from_to(
      )->from_column( xco_cp_xlsx=>coordinate->for_alphabetic_value( 'A' )  " Start reading from Column A
      )->to_column( xco_cp_xlsx=>coordinate->for_alphabetic_value( 'N' )   " End reading at Column N
      )->from_row( xco_cp_xlsx=>coordinate->for_numeric_value( 2 )    " *** Start reading from ROW 2 to skip the header ***
      )->get_pattern( ).

    lo_worksheet->select( o_sel_pattern
                                     )->row_stream(
                                     )->operation->write_to( REF #( lt_sheet_data )
                                     )->set_value_transformation(
                                         xco_cp_xlsx_read_access=>value_transformation->string_value
                                     )->execute( ).

    lt_listing_create = CORRESPONDING #( lt_sheet_data ).

    MODIFY ENTITIES OF zrk_r_lib_listings IN LOCAL MODE
           ENTITY Listings
           CREATE AUTO FILL CID FIELDS ( Id Title Type author PublisherStudio IsbnEan LanguageCode PublicationYear description Totalcopies AvailableCopies LocationShelfID LendingDurationDays status )
           WITH lt_listing_create
           " TODO: variable is assigned but never used (ABAP cleaner)
           MAPPED DATA(lt_mapped)
           " TODO: variable is assigned but never used (ABAP cleaner)
           REPORTED DATA(lt_reported)
           " TODO: variable is assigned but never used (ABAP cleaner)
           FAILED DATA(lt_failed).

    " Communicate the messages to UI - not in scope of this demo
    IF lt_failed IS INITIAL.
      APPEND VALUE #( %msg = new_message_with_text( severity = if_abap_behv_message=>severity-success
                                                    text     = 'Listings have been uploaded - please refresh the list!!' ) )
             TO reported-listings.
    ENDIF.
  ENDMETHOD.

9. The action is utilized on the projection behavior and subsequently exposed in the metadata extension.

use action ExcelUpload;

projection implementation in class ZRK_BP_C_LIB_LISTINGS unique;
strict ( 2 );
extensible;
use draft;
use side effects;
define behavior for ZRK_C_LIB_LISTINGS alias Listings
extensible
use etag
{
  use create;
  use update;
  use delete;

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

  use action ExcelUpload;

}

.lineItem: [{ type:#FOR_ACTION , dataAction: 'ExcelUpload' , label: 'Upload Excel' }]

10. The service binding is published, and the application is then ready for execution.

Note:

This feature is currently functional on the BTP ABAP Environment. However, an issue appears to exist with metadata generation on S/4HANA 2023 On-Premise deployments, even though the objects are syntactically correct. It is anticipated that this constraint will be addressed in the S/4HANA 2025 release, making the full feature set available on the S/4HANA On-Premise version following a brief waiting period.

The post ABAP RAP: Excel upload through custom action popup (No UI5 Extension, No Object Page workaround) appeared first on ERP Q&A.

Unmanaged SAP RAP refers to a development approach where developers have more control over the data persistence and business logic compared to the managed approach. Here are some key aspects

1. Custom Logic: In unmanaged RAP, developers write their own custom logic for handling data retrieval, manipulation, and persistence. This gives more flexibility in how data is processed and stored.
   
2. Direct Database Access: Developers can directly access the database tables and define their own data models using Core Data Services (CDS) views or ABAP classes.
   
3. Explicit Service Definition: Unlike managed RAP, where service definitions are automatically generated based on annotations, unmanaged RAP requires developers to explicitly define service implementations and behaviors.
   
4. Manual CRUD Operations: CRUD (Create, Read, Update, Delete) operations need to be implemented explicitly in unmanaged RAP, giving full control over how data is managed.
   
5. Integration with Existing Systems: Unmanaged RAP is often used when integrating with existing systems or when there is a need for complex business logic that cannot be easily handled by the managed approach.
   
6. Flexibility: Developers have more freedom to implement complex validation rules, authorization checks, and other custom requirements directly in the application logic.

Overall, unmanaged SAP RAP provides a more hands-on approach to application development compared to the managed approach, allowing developers to leverage their expertise in ABAP programming and database handling while building modern RESTful APIs.

Top of Form

In this example, we will show a simple application for Employee build with RAP Unmanaged flavors.

Development steps.

To be summarized below object will be created for Unmanaged scenario.

Table ZT01_EMPLOYEE

Base CDS View Z_I_EMPLOYEES_U

Consumption CDS view Z_C_EMPLOYEES_U

Behavior Definition

Bottom of Form

Behavior definition

Implement the Create method

Implement Update Method

Implement Delete Method

Implement Adjust_Numbers method.

Implement Save method.

Test

1. Open the Application.

2. Click on Create. Give Input value and Create.

3. New Record got created.

4. Select any Row , click on Edit.

5. Change the value and Save.

6. Record will be updated.

7. Select the Rows and click on Delete.

8. Records will be deleted.

9. In the Database table also you can see the records.

So, all the CRUD operation is successful using RAP Unmanaged flavors.

The post SAP RAP Unmanaged scenario example-Simplified appeared first on ERP Q&A.

The SAP landscape has evolved significantly, with businesses seeking simpler, more efficient solutions that offer excellent user experiences. Many organizations remain deeply embedded in the SAP ecosystem, primarily focusing on ABAP over other languages. So, is it possible to develop feature-rich applications without other frontend languages? Yes, leveraging ABAP with RAP (ABAP Restful Application Programming) makes it possible.

Restful Application Programming is an ABAP programming model for creating business applications and services in an AS ABAP or BTP ABAP environment. RAP offers a standardized way of developing applications using Core Data Services (CDS), the modernized extended ABAP language, OData protocol, and the concept of business objects and services. RAP applications can only be created through ABAP development tools (ADT) and it’s available in SAP BTP ABAP Environment, SAP S/4 HANA Cloud, and AS ABAP >=7.56.

Before digging deeper into RAP, let’s explore CDS, annotations, and business services. To illustrate these concepts, let’s create a simple read-only list report application.

Developing an OData Service for simple list reporting

An OData service follows the best practices for developing and consuming RESTful APIs. This service can be used in SAP Fiori applications and can also be exposed as Web APIs. Below are the steps for creating a simple list report application:

Let’s explore each step in detail by creating the application.

Sample requirement: Create a read-only list report application which shows purchase order information.

• Create an interface CDS view which takes data from Purchase Order Header (EKKO) and Item (EKPO).

• Create two interface CDS views for showing master data of purchase order type and material details.

• Make an association between the purchase order type CDS view and material details CDS view from the purchase order header/item CDS view. The associated views will act as Search Help in the list report after applying the annotations.

• Create a consumption view on top of the Purchase Order Header/Item interface view (ZI_PURCHASE_ORDER_RVN).

The UI annotations needed for the application are written in the consumption CDS View or Metadata Extensions.

Now, we have the data model and the required annotations to manifest semantics for it. The next step is to create the OData service and binding the service.

To define a service, we first need to create a service definition. In service definition, we specify the CDS entities that need to be exposed. In this example, the gateway client is replaced by the service definition and service binding.

As a last step, create the service binding for service definition.

Set the binding type as OData V2 – UI, since this is an OData V2 service.

After publishing the service, the exposed entity and associated entities will be visible. Click on the entity and click the preview button to see the preview of the application.

Purchasing Doc Type Search Help

Material Search Help

Conclusion

This blog serves as an introduction to developing OData services for simple list reporting using the ABAP Restful Application Programming (RAP) model. By following the steps outlined, you can create a read-only list report application that showcases purchase order information. We have covered the basics of creating CDS views, defining and binding OData services, and incorporating annotations for enhanced functionality.

The post ABAP RESTful Application Programming Model (RAP) appeared first on ERP Q&A.

With the latest SAP BTP ABAP 2208 release the RAP framework now supports OData streams. It is now possible to enable your RAP application to maintain and handle Large Objects(LOBs).This feature provides end users an option to upload external files of different file formats such as PDF, XLSX, binary file format and other types hence allowing media handling.

In this Blog we will explore how to upload and handle Large Object such as PDF or Binary files without the need to extend the RAP application in BAS.

Large objects are modeled by means of the following fields:

• Attachment
• Mimetype
• Filename

The field Attachment contains the LOB itself in a RAWSTRING format and is technically bound to the field Mimetype and Filename using semantics annotation.

Mimetype represents the content type of the attachment uploaded and the values for the fields Mimetype and Filename are derived from the field Attachment by the RAP framework based on the maintained CDS annotations. No attachment can exist without its mimetype and vice versa.

For example, when a PDF is uploaded the Mimetype field will be derived and populated with ‘APPLICATION/PDF’.

To try this feature out I have built a simple RAP application to upload files directly using RAP Framework.

Database Table

A Database table was built as per code snippet below.

The field attachment has a data type of RAWSTRING. In BTP ABAP environment you cannot use RAWSTRING domain directly so create a custom domain with data type as RAWSTRING and Length as ‘0’ . This is important as length being ‘0’ would indicate that the RAWSTRING has No length restriction and can accommodate file of larger size. ZMIMETYPE and ZFILENAME are both of type Character and length 128.

@EndUserText.label : 'Invoice Table'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table zinvoicetable {
  key client            : abap.clnt not null;
  key invoice           : ebeln not null;
  comments              : char30;
  attachment            : zattachment;
  mimetype              : zmimetype;
  filename              : zfilename;
  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;

}

Interface View

CDS annotation @Semantics.largeObject technically binds the MimeType and Filename to the Attachment.

The annotation contentDispositionPreference can be used to define whether, depending on the browser settings, the file attachment is either displayed in the browser (setting #INLINE) or downloaded when selected (option #ATTACHMENT).

Annotation @Semantics.largeObject.acceptableMimeTypes can be used to restrict the Media types which can be uploaded. The validation and Error handling on upload of unsupported media type is handled by the RAP framework.

CDS annotation @Semantics.mimeType: true was used to define the field MimeType as such.

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Invoice Table'
define root view entity ZI_INVOICETABLE
  as select from zinvoicetable
{
  key invoice               as Invoice,
      comments              as Comments,
      @Semantics.largeObject:
      { mimeType: 'MimeType',
      fileName: 'Filename',
      contentDispositionPreference: #INLINE }
      attachment            as Attachment,
      @Semantics.mimeType: true
      mimetype              as MimeType,
      filename              as Filename,
      @Semantics.user.createdBy: true
      local_created_by      as LocalCreatedBy,
      @Semantics.systemDateTime.createdAt: true
      local_created_at      as LocalCreatedAt,
      @Semantics.user.lastChangedBy: true
      local_last_changed_by as LocalLastChangedBy,
      //local ETag field --> OData ETag
      @Semantics.systemDateTime.localInstanceLastChangedAt: true
      local_last_changed_at as LocalLastChangedAt,

      //total ETag field
      @Semantics.systemDateTime.lastChangedAt: true
      last_changed_at       as LastChangedAt
}

Consumption View

@EndUserText.label: 'Invvoice Table'
@AccessControl.authorizationCheck: #NOT_REQUIRED
@Metadata.allowExtensions: true
define root view entity ZC_INVOICE_TABLE
  provider contract transactional_query
  as projection on ZI_INVOICETABLE
{
  key Invoice,
      Comments,
      Attachment,
      MimeType,
      Filename,
      LocalLastChangedAt
}

Metadata Extension

From an UI perspective the User only needs to interact with the Attachment and hence Mimetype and Filename is hidden.

@Metadata.layer: #CORE
@UI: { headerInfo: {
typeName: 'Invoice',
typeNamePlural: 'Invoices',
title: { type: #STANDARD, value: 'Invoice' },
         description: { type: #STANDARD, value: 'Invoice' } },
         presentationVariant: [{
         sortOrder: [{ by: 'Invoice', direction: #ASC }],
         visualizations: [{type: #AS_LINEITEM}] }] }
annotate entity ZC_INVOICE_TABLE with
{
  @UI.facet: [    {
                label: 'General Information',
                id: 'GeneralInfo',
                type: #COLLECTION,
                position: 10
                },
                     { id:            'Invoicedet',
                    purpose:       #STANDARD,
                    type:          #IDENTIFICATION_REFERENCE,
                    label:         'Invoice Details',
                    parentId: 'GeneralInfo',
                    position:      10 },
                  {
                      id: 'Upload',
                      purpose: #STANDARD,
                      type: #FIELDGROUP_REFERENCE,
                      parentId: 'GeneralInfo',
                      label: 'Upload Invoice',
                      position: 20,
                      targetQualifier: 'Upload'
                  } ]

  @UI: { lineItem:       [ { position: 10, importance: #HIGH , label: 'Invoice Number'} ] ,
          identification: [ { position: 10 , label: 'Invoice Number' } ] }
  Invoice;
  @UI: { lineItem:       [ { position: 20, importance: #HIGH , label: 'Comments'} ] ,
           identification: [ { position: 20 , label: 'Comments' } ] }
  Comments;
  @UI:
  { fieldGroup:     [ { position: 50, qualifier: 'Upload' , label: 'Attachment'} ]}
  Attachment;

  @UI.hidden: true
  MimeType;

  @UI.hidden: true
  Filename;

}

I have created a managed Behavior definition with Draft and Created a Service definition and Service binding to expose this as a V4 UI .

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

define behavior for ZI_INVOICETABLE alias Invoice
persistent table ZINVOICETABLE
draft table zinvoicetdraft
lock master
total etag LocalLastChangedAt
authorization master ( instance )
etag master LastChangedAt
{

 // administrative fields: read only
  field ( readonly ) LastChangedAt, LocalLastChangedBy, LocalLastChangedAt , LocalCreatedBy ,
                      LocalCreatedAt;

  create;
  update;
  delete;

  draft action Edit ;
  draft action Activate;
  draft action Discard;
  draft action Resume;

  draft determine action Prepare ;
}

Once the OData is published through service binding, we can preview the application.

You can click on create to Create a new Instance.

On “Upload File” the File Open Dialog comes up to select the file from Presentation Server .

Once the File is uploaded the Hyperlink can be used to access the file and based on annotation contentDispositionPreference the file would either open in a new window or downloaded when selected.

Once the Instance is saved we can see the new file encoded in RAWSTRING format along with its Mimetype and Name saved in the database.

In Conclusion, with the Support of OData streams, we can now handle LOBs directly using RAP framework, this really caters to a lot of missing features for which extensions were needed before. The above application is a very simple example of how this feature can be used.

The post Streams in RAP: Uploading PDF, Excel and Other Files in RAP Application appeared first on ERP Q&A.