Category: ABAP RAP

  • SAP ABAP RAP Runtime

    Preface – This post is part of the SAP ABAP RAP series.

    Introduction

    In the previous article, we have learnt RAP runtime consists of two phases: Interaction phase and Save phase. Now we will understand what are the steps involved in these phases and how they are segregated.

    INTERACTION phase can be segregated in Lock, Read, Modify methods whereas, the SAVE phase involves some predefined methods finalise(), check_before_save(), adjust_numbers(), save(), cleanup(), cleanup_finalise() which are called sequentially.

    Business Object Runtime

    SAP ABAP RAP supports three types of implementations UNMANAGED, MANAGED and MANAGED with save. Currently, only Unmanaged and managed scenarios are supported. Managed with save will come in future release.

    Business object Runtime

    Figure 1: Business object Runtime

    Unmanaged, Managed and Managed with save

    Figure 2: Unmanaged, Managed and Managed with save

    In the interaction phase, modify method consists of create, create_by_association, update, delete and action methods which are used to change the data in the database. The reads methods consist of read entities, read_by_association, and execute_functions. The read methods are used to retrieve data, they do not change the behaviour of data. The lock method is used for lock properties. Once the interaction phase is completed and changes are stored in the transactional buffer, the save phase comes into the picture.

     

    The save phase consists of predefined methods that are executed sequentially.

    • finalise() : The first method executed in save phase is finalise(). It finalises the final calculations with business objects determinations before the data is persisted on the database.

     

    • check_before_save(): The next method executed after finalise is check_before_save(). Before saving the data to the database, the validations are called within this method. For successful save, the BO runtime must provide the feedbacks in checks. This is the point of no-return i.e. once the control reaches this method and there is no failure detected, the execution will go to the next step and data will be saved successfully in the database.

    In case, there is failure detected in this method, the further execution will be terminated and the control will go to the cleanup_finalise() method. And the data will not be saved.

     

    • adjust_numbers(): This method is required when we have modelled late numbering in our business object behaviour definition.

    Late numbering: The final number or the key number is generated just before the instance of data is stored in the database. It is a concept to generate gap-free numbers. For example, if you are creating an Info record, the info record number is generated just before data is stored in the database. (Not supported for managed implementation).

    Early numbering: In case we are using early numbering in a business object, the key number is generated beforehand i.e. after the modify method is called. The key values are available in the transactional buffer.

     

    • save(): This method saves the data from the transactional buffer to the database.

     

    • cleanup(): The cleanup method is called when the save() method is executed successfully. This clears the transactional buffer or variables to prevent form any inconsistencies.

     

    • cleanup_finalise(): This method is called when finalise() and check_before_save() returned any failed key and the data is not persisted in the database. The cleanup_finalise() clears the transactional buffers or variables if execution fails in finalise or check_before_save.
  • SAP RAP Architecture

    Preface – This post is part of the SAP ABAP RAP series.

    Introduction

    THE SAP ABAP RESTful Application Programming model (RAP) supports the efficient end-to-end development of SAP OData based SAP Fiori services and Web APIs intrinsically optimized for SAP HANA on SAP BTP (Business Technology Platform) ABAP environment or on-prem SAP S/4 HANA.

    Architecture Overview

    The below rough version of SAP RAP Architecture depicts the major functionalities that we can utilize:

    What is SAP RAP

    The below figure displays the major artifacts you have to deal with while developing the OData services using the SAP ABAP RESTful Application Programming model. It depicts the bottom-up approach that illustrates the application development flow.

    SAP RAP Architecture

    Figure 1: SAP ABAP RAP Architecture Overview

    The SAP ABAP RAP is three-layered architecture: Data Modelling and Behaviour; Business Services and; Service Consumption. Let’s see briefly.

    Data Modelling and Behaviour

    The base layer of RAP is DATA Modelling and Behaviour. Here, we define the business object models, query definitions and their transactional behaviour. Taking an example of a simple SAP Fiori based application, we define the database table and expose the data using CDS. As soon as the CDS for the root entity is created, we define the transactional behaviour also.

    Business Services

    In the middle layer, the OData exposer is done in two steps: the first step is where the protocol service scope definition of relevant data entities is defined, and the second step is data binding to the OData model. For example, we have 50 CDS views relevant to Sales-Order but we want only 1 view to be exposed to the outside world. This scenario can be achieved via this layer. (See Figure 2)

    Design-time artifacts

    Figure 2: Design-time artifacts

    Service Consumption

    The topmost layer is the Service Consumption layer. Here, an OData Service can be exposed as a UI service which can be consumed by SAP Fiori or Web API, that can later be consumed by any client.

    Illustration of OData Service consumption by SAP Fiori UI and WEB API

    Figure 3: Illustration of OData Service consumption by SAP Fiori UI and WEB API

  • Introduction to SAP RAP: ABAP RESTful Application Programming Model

    Preface – This post is part of the SAP ABAP RAP series.

    Introduction

    SAP has introduced various programming models helping the organizations via development of efficient applications that meets their business needs. Over time, with changing requirements and technologies, these programming models have evolved from DYNPRO and list programming models for SAP GUI based applications to WEB DYNPRO model for web-based applications and thereafter to SAP ABAP programming model for SAP Fiori.

    While SAP ABAP programming model for SAP Fiori is a key advantage in terms of evolving landscape, flexibility and efficient modelling for SAP Fiori, SAP HANA; lacks certain criteria like simplicity and typed access to business entities which seems to be the basic need for application development. Here RAP, a new programming model by SAP, fills the gap.

    SAP ABAP RAP provides the intrinsic approach to build SAP Fiori based applications that are optimized for S/4 HANA and can run over on-premise as well as on the cloud.

    Evolution of ABAP programming model

    Let’s take a look at how programming models are changed over the years:

    Evolution of ABAP programming modelFigure 1: The evolution of the ABAP Programming model

    Traditional ABAP programming model

    The traditional ABAP programming models include Classical ABAP Programming- such as DYNPRO and list programming for SAP GUI based applications and business servers and WEB DYNPRO for web-based applications. This model was designed for a traditional on-prem environment.

    ABAP Programming model for SAP Fiori

    The model is based on CDS, BOPF and SAP Gateway. It reduces the complexity with advanced SEGW option reference data source (RDS) to expose the scope of the CDS model to an OData service.

    Additionally, it supports service to transactional applications. To enable transactional services we need to provide the special annotation that links the CDS model to the corresponding BOPF framework model which supports transactional oriented behaviour via artifacts:  validations, determinations and actions.

    Both CDS and BOPF are different in nature and as they both are modelling frameworks; you must need to maintain both in parallel. CDS is a typed framework that is embedded in ABAP design time and runtime where type checking is done at design time, in contract BOPF is very generic and most of the errors happen at runtime which is difficult to debug. Also, while developing a typical standard application, many artifacts are created which adds to the complexity while implementation or changing model parts. To overcome this limitation of the ABAP Programming model for SAP Fiori, SAP ABAP RAP model was introduced.

    SAP ABAP RESTful Application Programming model

    SAP ABAP RESTful Application Programming Model (RAP) was introduced by SAP Cloud Platform ABAP environment and is available with 1808 release and higher.

    The RESTful Application Programming model is built on the top of the semantic data model (CDS) and the transactional services are exposed in behaviour definition and implementation in implementing behaviour class. It also allows adapting the existing applications to be modelled which is intended to be used over a long time.  You can start from scratch (greenfield implementation) or you can reuse existing business logic (brownfield implementation).

    One can develop the following end-to-end scenarios:

    • SAP Fiori service
    • Service consumption
    • Web APIs

    What is SAP RAP?

    In simple words, SAP RAP is a new way to develop Fiori Applications based upon HANA features. This programming model uses ABAP programming methodology.
    It uses the following:
    1. ADT (ABAP Development Tools in eclipse or HANA Studio): This is used to develop tasks

    2. CDS (Core Data Services in eclipse or HANA Studio): This is used for the implementation of business object layer

    3. A New Framework: This is used to handle business logics. It generates web APIs that can be consumed by Fiori or any other applications.

    The rough diagram of SAP RAP is shown below:

    What is SAP RAP

    This programming model looks very similar to the classical ABAP OData and CDS based UI5 Development. This programming model will replace the old way of developing apps via OData SEGW and BOPF.