ABAP RESTful Application Programming Model (RAP)

 What is RAP(RESTful Application Programming)

The ABAP RESTful Application Programming Model (RAP) is the centerpiece of the ABAP Cloud development model for efficiently building cloud-ready, transactional business apps and extensions on SAP BTP ABAP Environment, SAP S/4HANA Cloud, SAP S/4HANA Cloud ABAP environment, and SAP S/4HANA 1909 and higher.

RAP consists of a set of concepts, tools, languages, and powerful frameworks which help developers both to build innovative, cloud-ready, enterprise applications and Web APIs; and to easily extend SAP standard applications on the ABAP platform, in the cloud as well as on-premise.

RAP offers a standardized development flow based on Core Data Services (CDS), the ABAP language, and business services in the modern, Eclipse-based ABAP Development Tools (ADT).

DATA MODELING AND BEHAVIOUR

Data Model Consist of entities which involved in business scenario, ABAP RAP uses CDS to define and organize the data model. CDS Entity are fundamental building block of application.

CDS Entity View

Since release 7.55, CDS view entities are available. They are defined using the statement DEFINE VIEW ENTITY. They have evolved from CDS DDIC-based views, serve the same purpose and have the same structure as their predecessor. But they offer several advantages over the “classic” CDS DDIC-based views, such as the following:

> No additional ABAP Dictionary view is created on activation.

> Improved performance during view activation.

> Optimization and simplification of syntax.

> Stricter syntax checks indicate problematic situations more explicitly, for example, annotation checks.

Difference Between CDS View and CDS Entity View

> There’s no DDIC view. The annotation @AbapCatalog.sqlViewName is not required and each view                has only one name.

> Fewer annotations are required. For example, client handling takes place implicitly and doesn’t require         any development effort.

> Overhauled buffer handling by means of CDS tuning objects offers more flexibility 

> Overhauled extension concept with CDS view entity extends (EXTEND VIEW ENTITY) offers much             faster activation performance, see ABAP Core Data Services: New syntax for extending CDS entities.

> Annotations are checked to ensure that only annotations defined as CDS objects in a CDS annotation         definition can be used.

> Expressions can be nested within each other. Situations that previously required a view stack can now be     implemented within a single view.

> Operand positions, such as the WHERE-clause, allow a greater variety of operands.

> Some features that haven’t been widely used are no longer supported in view entities. Here are some           examples (but the list is not exhaustive):

    > In DDIC-based views it is possible to assign alternative element names to elements of a SELECT-list            using a name list. CDS view entities don’t support name lists.

    > Domain fixed values in front of literals cannot be defined in CDS view entities.

    > The syntax SELECT * to select all elements from the data source is supported in CDS DDIC-based               views, but not in CDS view entities.

   Example: CDS View

   @AbapCatalog.sqlViewName: 'ZCDS_FLIGHT'

   @AbapCatalog.compiler.compareFilter: true

   @ClientHandling.algorithm: #SESSION_VARIABLE

   @AbapCatalog.preserveKey: true

   @AccessControl.authorizationCheck: #NOT_ALLOWED 

   define view zdemo_cds_flight

      as select from spfli

        join scarr on scarr.carrid = spfli.carrid

    {

      key spfli.carrid          as id,

      key scarr.carrname   as carrier,

      key spfli.connid         as flight,

             spfli.cityfrom     as departure,

             spfli.cityto          as destination

  }

CDS Entity View

@AccessControl.authorizationCheck: #NOT_ALLOWED

    define view entity zdemo_cds_flight

        as select from spfli

          join scarr on scarr.carrid = spfli.carrid

       {

          key spfli.carrid            as id,

          key scarr.carrname    as carrier,

          key spfli.connid          as flight,

                 spfli.cityfrom       as departure,

                 spfli.cityto            as destination

      }

So in above syntax we can see additional annotation is not required.

BUSINESS SERVICE

It is defined by exposing its data model together with the associated behavior. A business service consists of a service definition and a service binding.

Service Binding Defines the Communication protocol such as ODATA V2/V4

SERVICE CONSUMPTION

Service can be exposed as a UI Service and consumed by SAP Fiori Elements app

MANAGED RAP 

It implements the standard CRUD operations for creating (create), reading (read), updating (update), and deleting (delete) instances of the respective CDS entity during the interaction phase and the save sequence. This is also accompanied by the handling of the transaction buffer.

STEP TO CREATE MANAGED APPLICATION

1. Create Table
2. Create Class to generate Data
3. Create CDS Root entity view
4. Create Metadata Extension
5. Create Behavior Definition
6. Create Service Definition
7. Create Service Binding
8. Publish and Preview