Modernizing Applications with RAP in SAP ABAP: Recommendations and Best Practices

This blog is used to guide all Abapers on how to create a User Interface without using any Fiori Elements and also how to use RAP (RESTful Application Programming) Model.

SAP Application Programming Model:

• SAP Application Programming Model is a framework consisting of several languages, libraries and tools used to build enterprise grade services and applications.
• There are two types of sub models under SAP Application Model namely RAP (Restful Application Programming Model) and CAP (Cloud Application Programming Model).
• RAP uses ABAP language to develop the applications, services or API’s.
• CAP uses Node.js and Java languages to develop the applications, services or API’s.

 

RAP (Restful Application Programming Model):

• RAP is used to create enterprise ready services, API’s and UI’s without using Fiori Elements.
• The ABAP Restful Application Programming Model (RAP) defines the architecture for efficient development of Fiori apps without using Fiori Elements.
• It is based on technology such as Core Data Services (CDS) and framework such as Eclipse for defining data models.

Architecture of RAP:

 

Business Object:

• A Business Object (BO) is a collection of tree Nodes (Entities) where each Node (Entity) represents one CDS View.
• It is a term to represent a real world artifact such as the Product, Travel, or the Sales Order.
• In general, a business object contains several nodes such as Items and common transactional operations such as creating, updating and deleting data and additional application-specific operations.

Behaviour of a Business Object:

• The behaviour definition is a crucial aspect of any CDS data model as it defines the actions that can be performed on the data, such as creating, updating, and deleting records.
• Every Entity of the Business Object offers standard operations such as Create, Read, Update and Delete.
• A behaviour definition always refers to a CDS data model. As shown in the figure below, a behaviour definition relies directly on the CDS root entity. One behaviour definition refers exactly to one root entity and one CDS root entity has at most one behaviour definition (a 0..1 relationship), which also handles all included child entities.

Business Object’s Runtime Implementation:

-There are 2 kinds of Runtime Implementations of Business Objects.

1. Managed Implementation:

• Recommended for development scenarios in which all essential parts are    developed from scratch, without a large amount of existing code (also known as greenfield development) with standard implementation.
• All the CRUD Operations can be managed by the framework itself.

2. Unmanaged Implementation:

•  Recommended for development scenarios in which business logic already exists and is intended to be reused (also known as brownfield development).
• All the CRUD Operations and Actions must be managed by the developer.

Business Service:

• A Business Service is a RESTful service that could be called by a consumer according to his requirement.
• It is defined by exposing data models and behaviour models. It consists of a Service definition and a Service binding which are illustrated in the figure below.

 

Service Definition:

• A service definition is used to project the type of a data model to be exposed.
• Used to define which entity to be exposed as a Business Service.

Example:

DEFINE SERVICE service_definition_name

{

EXPOSE cds_entity_1 [AS alias_1];

EXPOSE cds_entity_2 [AS alias_2];

EXPOSE …

EXPOSE cds_entity_m [AS alias_m];

}

 

Service Binding:

• The service binding is an ABAP Repository object used to bind a service definition to a client-server communication protocol such as OData.

 

Evolution of ABAP Programming Model:

 

 

Prerequisites:

• The key players in the ABAP Restful Application Programming (RAP) Model are:

 ABAP Development Tools (ADT)                      Languages:                                 Powerful Framework

                in Eclipse                                     ABAP and CDS                                 such as Eclipse

• ABAP Development Tool must be added to the framework Eclipse.
• Developer must have knowledge on languages such as ABAP and CDS.
• A Powerful Framework must be installed such as Eclipse.

 

Steps to Create User Interface using RAP:

The steps that we follow to create a User-interface using RAP are:

1. Create a package.
2. Create a custom table.
3. Insert data to table.
4. Create Interface CDS view.
5. Create Consumption CDS view.
6. Add Metadata Extension File.
7. Define Business Objects – ‘DEFINE ROOT VIEW’.
8. Create Behaviour definition for Interface View.
9. Create a Class from the Behaviour Definition for Managed Implementation.
10. Create Behaviour definition for Consumption View.
11. Create Service Definition – Expose Consumption View Name.
12. Create Service Binding and bind a service definition to client-server communication protocol – Right Click on Service Definition and then create Service Binding.
13. Showing Result in the Preview.

 

Step-1:- Create a Package:

 

Step-2:- Create a Custom Table:

 

Step-3:-Insert Data to Table:

 

Step-4:-Create Interface CDS View:

• Create an Interface View for the Student.

• Choose the template “Define Root View Entity” for the Interface Entity.

• Insert all the elements from the Custom table into the Interface Entity.

 

Step-5:-Create Consumption CDS View:

• Create a Consumption View for the Student for Projection.

• Choose the template “Define Root View Entity” for the Projection Entity.

• Insert all the elements from the Custom table into the Projection Entity.
• “Provider Contract” is the syntax used to specify the type of Projection View.

CDS Transactional Query:

• CDS transactional queries are used to model the projection layer of a RAP business object.
• They represent top-most layer of a data model and used to prepare the data for a particular use case.
• The role of a CDS projection view of type transactional query is as below:

Example:

 

@EndUserText.label: ‘CDS Transactional Query’

@AccessControl.authorizationCheck: #NOT_REQUIRED

define root view entity CDS_PV_PARENT

provider contract transactional_query

as projection on CDS_VIEW_PARENT

redefine association _child

redirected to composition child CDS_PV_CHILD

{

key ID,

INT,

/* Associations */

_child.INT as field

}

CDS Analytical Query:

• CDS analytical queries are used to model analytical queries within a data model.

Example:

@AccessControl.authorizationCheck: #NOT_ALLOWED

define transient view entity CDS_CASE

provider contract analytical_query

as projection on CDS_VIEW

{

so_key,

currency_sum,

//selection-related case expression

@Semantics.amount.currencyCode: ‘currency_sum’

case when lifecycle_status between ‘A’ and ‘B’

then amount_sum else null end as QuantityAB,

//formula-related case expression

@Aggregation.default: #FORMULA

case

when created_on = $session.system_date

then abap.int ‘200’

else abap.int ‘700’

end  as formula_demo

}

where created_on = $session.system_date

CDS Transactional Interface:

• CDS transactional interfaces are used to represent a released API.
• The role of a CDS projection view of type transactional interface is as below:

Example:

 

@EndUserText.label: ‘CDS transactional interface’

@AccessControl.authorizationCheck: #NOT_REQUIRED

define root view entity CDS_INTERFACE_PARENT

provider contract transactional_interface

as projection on CDS_INTERFACE_ROOT

{

key PurchaseDocument,

Description,

Status,

Priority,

/* Associations */

_PurchaseDocumentItem:

redirected to CDS_INTERFACE_CHILD

}

Step-6:-Add Metadata Extension File:

• A CDS metadata extension extends a CDS entity with CDS annotations that are not specified in the DDL source code of the data definition.

• Create a Metadata Extension with the Extended Entity as the Projection View.

• Choose the template “Annotate View” for Metadata Extension.

• The annotation @Metadata.layer defines the layer of the Meta Data Extension according the priority of the layers.
• The Meta Data Extension simply adds annotations or overrides existing annotations for the whole view, elements or parameters of lower layers.
• The possible layers are #CORE, #LOCALIZATION, #INDUSTRY, #PARTNER, #CUSTOMER, where the priority increases from left to right.

• Meta Data Extension will be allowed only if the annotation “@Metadata.allowExtensions” is made ‘true’ in the Projection View that is maintained as Extended Entity in Metadata Extension.

• ‘@UI.lineItem.position’ is the annotation that is used to specify the order of columns of the list. This annotation is mandatory to display fields in the User Interface.
• ‘@UI.lineItem.label’ is the annotation that is used to specify the customized names for the fields that are displayed in the User Interface.

 

Step-7:-Define Business Objects:

• In ABAP RAP Model a Business Object is a collection of tree Nodes (Entities) where each Node (Entity) represents one CDS View.
• There must be always one Entity which must be represented as ‘ROOT’.
• So, we are mentioning Interface and Consumption Views as ‘ROOT’ Views. These Root Views mention our Business Object.
• Business Object will have Behaviour Definition. There can be only one Behaviour Definition per Entity. This Behaviour Definition contains different operations such as Create, Update, Delete etc.
• Business Object then can have Behaviour Implementations.

 

Step-8:- Create Behaviour definition for Interface View:

• Create a Behaviour Definition for the Interface View and choose Implementation Type as Managed so that CRUD operations can be managed by the framework.

 implementation in class [unique]

• “managed implementation in class ClassName unique” is the Language Element that is used to mention that the Behaviour Implementation Part is managed in the Class that is mentioned.

strict(2)

• When strict mode is switched on, outdated syntax which normally produces a syntax check warning leads to a syntax check error. Strict mode version 2 introduces mainly stricter checks for the RAP BO. Strict mode version 2 is a prerequisite for releasing a RAP BO.

persistent table

• “persistent table” is the Language Element that is used to define a persistent database table for storing the data changes that result from transactional behaviour.

                  lock master [unmanaged], lock dependent, lock : none

• “lock master” is the Language Element that is used to specify RAP Locking Mechanism for RAP BO.
• The RAP locking mechanism prevents simultaneous modification access to data on the database by more than one user.
• Whenever a lock is requested for a specific entity instance, its lock master and all lock-dependent entity instances are locked for editing by a different user, in other words, as soon as one node receives a locking request, the whole BO instance is locked.
• If the optional addition unmanaged is used, the lock mechanism must be implemented manually in the method FOR LOCK of the behaviour pool.
• If the optional addition lock dependent is used, it defines an entity as lock dependent, this means that locking requests are delegated to the lock master entity. The association from the lock dependent entity to the lock master entity must be explicitly defined in the entity behaviour definition.
• If the optional addition lock: none is used, it prevents the locking mechanism for the entity instance.

                         authorization master { ( global ) | ( instance ) }

• Authorization Master protects business object against unauthorized access to data.
• If the addition global is used, then it limits access to data to perform certain operations for a complete RAP BO, independent of individual instances of entities.
• If the addition instance is used, then authorization check will be dependent on the state of an entity instance.

    etag master

• ETag Master is used to enable transactional access to data by multiple users while avoiding inconsistencies by changes of already modified data.
• Defines an entity as ETag master and assigns a field for change logging. ETag masters logs the changes of every business object entity that is part of the BO.

• “Mapping for Database_Table” is used to map fieldnames from database table to field names from the current data model.

 

Step-9:- Create a Class from the Behaviour Definition for Managed Implementation:

• Create a Class for the Behaviour Implementation. Double Click on the “Create Behaviour Definition” to Create Class.

• Assign Package and give description for the class that is being created for Behaviour Implementation.

• Class Definition and Class Implementation gets automatically generated for Behaviour Implementation and for operations such as CRUD.

 

Step-10:- Create Behaviour definition for Consumption View:

• Create a Behaviour definition for Consumption View and choose Implementation Type as ‘Projection’ as Consumption View is used for Projection.

• “projection” is the Language Element that is used to represent a direct projection of its base behaviour definition. It exposes a subset of the base behaviour definition’s operations and characteristics.

 

Step-11:- Create Service Definition:

• Create a Service Definition to Expose Consumption View Name.

• Choose the Template “Define Service” as we are creating a new Service Definition.

• Exposing Consumption View ‘Z2948C_STUDENT’ in the Service Definition. We can even expose more than one Views in a single Service Definition.

 

Step-12:- Create Service Binding:

• Right Click on the Service Definition and Create a Service Binding to bind a service definition to client-server communication protocol.

• Choose the Binding Type according to the User Requirement among the list.

• As we are creating a User Interface, we can choose it as OData V2 – UI.

• Click on the Button Publish to get the Service URL as well as Entity Sets.

• Select the Entity Set according to the requirement and click the button Preview.

• It automatically opens browser to show the Preview. Give the details such as Username and Password from SAP GUI.

 

Step-13:- Showing Result in the Preview:

• The User Interface gets Displayed as the Preview.

• Click on the button ‘Go’ to display the Fields.

• “@UI.selectionField” is the annotation that is used to specify a particular field as selection field that is as a Filter Bar.

• A Filter Bar is displayed for the selected field.

• “@Consumption.filter” is the annotation used to specify a particular field a mandatory field and also a Default Value for the field.

• The above mentioned Code Lines must be added to the Metadata Extension for the Header to the Object Page.
• ‘Title’ is used to give the Main Header for the Object Page and ‘Description’ is used to give certain Description for the Main Header.

• Choose any value among the list.

• It displays the FirstName as Main Header and Subject as it’s Description.
• Annotations belonging to UI.facet allow a hierarchical semantic grouping of information.
• UI.facet can allow Array as it can take many references such as Identification Reference, Field Group Reference etc.

• “@UI.facet.id” is the annotation that is used as the identifier of the Facet.
• “@UI.facet.type:#COLLECTION” is the annotation that defines all the fields in the object page as a Group.
• “@UI.facet.label” is the annotation that is used to give a Text to the Reference of the Object Page.
• “@UI.facet.position” is the annotation that is used to assign a position to the Facet in the Object Page.

• “@UI.facet.type:#IDENTIFICATION_REFERENCE” is the annotation that is used to add some of the form fields from the list to object page using the annotation ‘@UI.identification’.
• “@UI.facet.parentId” is the annotation that is used to specify that the element is the identifier of the parent facet.
• “@UI.facet.targetQualifier” is the annotation that is used as the Qualifier to refer to the elements that are to be Identification Reference. More than one Identification Reference can be used with different targetQualifiers.

• “@UI.identification.position” is the annotation used to mention the position of the element in the Object Page.
• “@UI.identification.qualifier” is the annotation used to refer the particular element under the specific Identification Reference.

• “@UI.facet.type:#FIELDGROUP_REFERENCE” is the annotation that is used to add some fields to the Object Page similar to Identification Reference, but it could be used when we have field groups. It means if there are more than one fields belongs to the same group.

• “@UI.fieldGroup.position” is the annotation used to mention the position of the element in the Object Page.
• “@UI.fieldGroup.qualifier” is the annotation used to refer the particular element under the specific Field Group Reference.

 

 

 

By following my profile Sairoop Gubbala , you will receive updates on new blog posts and other content related to ABAP development best practices.

Follow the SAP ABAP environment Topic page: SAP ABAP

This page is a great resource for staying up-to-date on the latest news and developments in the SAP HANA environment. You can follow the page to receive updates, post and answer questions, and read other posts on the topic

If you have any queries related to SAP and ABAP Developments you can post here https://answers.sap.com/tags/73554900100700000996, you can also find many topics related to your query.