Evolution of the ABAP Programming Model

Classic ABAP Application Programming

Most SAP customers are using SAP enterprise software based on the ABAP release 7.50 or lower.

On these ABAP releases, various UI technologies are available for building applications, e.g. classic Dynpro, Web Dynpro ABAP, Floorplan Manager and WebClient UI framework.

With the ABAP release 7.4, SAP started to heavily optimize the ABAP platform for its in-memory database SAP HANA. In this context ABAP Core Data Services (CDS) were introduced to offer the next generation data modeling infrastructure and data access. CDS-based data models are semantically rich data models that can be used for all application domains. Additionally, SAP Gateway became an integral part of the AS ABAP with release 7.4 and the Business Object Processing Framework (BOPF) also found its way into the ABAP platform with release 7.5.

For several reasons – e.g. modern web application user experience, mobile enablement and cloud readiness – SAP decided to support a RESTful communication between backend and frontend. Combined with the decision to apply a new role-based and consumer-grade user experience using a modern UI design paradigm, the new SAP Fiori development stack was born with:

• SAPUI5 as SAP’s UI development toolkit for HTML5 – with SAP Fiori Elements offering reuse building blocks and complete floorplans for a higher UI development productivity for the most common application patterns
• OData as REST-based protocol including metadata allowing a model driven approach and enabling SAP Fiori Elements-based UI development
• the ABAP Platform for the business logic
• ABAP Development Tools in Eclipse and SAP Web IDE for the backend and the frontend development respectively

SAP’s decision to make SAPUI5 and OData as core technologies of the SAP Fiori development stack brought new challenges regarding the development of applications – especially transactional apps.

This led the ABAP platform team at SAP to work on the introduction of a new programming model that will offer an efficient and standardized way for building all types of delightful and SAP HANA-optimized apps, i.e., transactional, analytical and search apps, and also best support product qualities such as continuous work and device switch on the UX level, extensibility and scalability on the cloud-readiness level, when at the same time preserving the well-known ABAP platform assets like lifecycle management and supportability. Another important aspect was to enable an easy onboarding of developers without having to read tones of documentation first.

The ABAP Programming Model for SAP Fiori was introduced for this purpose.

ABAP Programming Model for SAP Fiori

With release 7.5, the ABAP Programming Model for SAP Fiori was first made generally available and then further enhanced with the following releases.

The ABAP Programming Model for SAP Fiori offers a standardized way to efficiently develop modern and intrinsically SAP HANA-optimized web-based applications of all types, i.e., search, analytical and transactional apps. It is the current best practice for application developments in SAP S/4HANA.

The ABAP Programming Model for SAP Fiori is mainly based on modern and proven technologies such as CDS, BOPF and SAP Gateway, especially using the advanced SEGW option Referenced Data Source (RDS) to easily exposed a given scope of an CDS data model as OData service. A lightweight CDS-based flavor of the BOPF framework is used in this context for the transactional processing.

With ABAP 7.51 the draft capability which is used for setting exclusive locks and storing intermediate – and even inconsistent – data was introduced. It enables the development of complex SAP Fiori apps with stateless communication and new application qualities such as continuous work and device switch.

The underlying application infrastructure integrates and orchestrates the different technologies in the best possible manner for supporting Greenfield scenarios where new applications, including their custom logic, are designed and implemented from scratch. Greenfield scenarios allow a high level of flexibility regarding the application design and architecture.

The situation looks quite different for Brownfield scenarios where the custom transactional application logic typically already exists based on coarse-grained create, update and delete operations and thus allow less flexibility with respect to application design and architecture. Brownfield scenarios are not supported by the ABAP Programming Model for SAP Fiori.

After the consolidation of the ABAP Programming Model for SAP Fiori, the next logical step was to integrate the different concepts into the ABAP and CDS languages, as well as to support the complete backend development flow natively in the ABAP Development Tools to reduce the total cost of development (TCD). Another important aspect was to tackle the different limitations due to the use of existing technologies in a non-disruptive manner.

With the aim to tackle the different aspects of the SAP Fiori development stack mentioned above, the ABAP RESTful Application Programming Model was introduced!

ABAP RESTful Application Programming Model

The ABAP RESTful Application Programming Model (aka ABAP RESTful Programming Model) is the evolutionary successor of the ABAP Programming Model for SAP Fiori. It enables the efficient and standardized development of web-based applications and Web APIs. It is generally available to customers and partners within SAP Cloud Platform ABAP Environment starting with release 1808.

SAP has opted here for a cloud-first delivery approach in the SAP Cloud Platform with a quarterly update cycle and plans to deliver it on-premise with SAP S/4HANA at a later time*.

The illustration below shows the big picture of the ABAP RESTful Programming Model with three main layers:

• Data Modeling and Behavior where the business object modeling and the queries definition occurs. At this layer the transactional behavior is defined and implemented.
• Business Service Provisioning where the OData exposure of the backend Data occurs in two steps. First the protocol service scope definition where the relevant data model entities are specified, and then the proper binding to the OData protocol.
• Service Consumption where the scenario dependent consumption occurs – using for example SAP Fiori Elements.

The golden rules of the ABAP RESTful Application Programming Model are:

• Eclipse-based experience for the backend development tasks in the ABAP Development Tools
  • Eclipse-based editors provided for all involved standard tasks; SAP GUI no longer needed
  • Clear entry point and clear development flow from one task to the next one
  • Fast developer on-boarding without reading tons of documentation
• ABAP Language and CDS are the main interfaces to the developers 
  • Direct support for business object development (data modelling and transactional enablement) in CDS and the ABAP Language;
  • No need for separate framework such as BOPF and framework-specific tools; No code generation and therefore avoidance of possible code redundancies and inconsistencies
  • Standard implementation tasks via typed APIs supporting useful IDE features like static code checks, auto-completion and element info
  • Avoidance of runtime errors by using static code checks thanks to typed APIs
• Powerful frameworks for runtime components 
  • Taking over and standardizing the technical implementation tasks
  • With dedicated code exits for application-specific business logic provided on protocol agnostic layers

Similarly to the ABAP Programming Model for SAP Fiori, business objects remain the major entities in the ABAP RESTful Application Programming Model.

Beside the Greenfield scenarios, Brownfield scenarios are also supported – allowing the reuse of existing legacy code.

The OData exposure is now done via business services created in two steps. As first step, a protocol-agnostic service definition where the relevant business objects and additional information (e.g. value helps) to be exposed are specified. And then as second step the binding of the service definition to a given protocol and scenario – UI or Web API. Currently only OData is supported as communication protocol.

Watch this SAP TechEd 2018’s replay of session CNA215 to get an a big picture overview of the ABAP RESTful Programming Model on the SAP TechEd Online platform. [⚠ 2023-05-03] Sorry but this SAP TechEd archive is no longer available. Instead, check out 🟢 A Beginner’s Guide to RAP

How can SAP customers and partners be prepared for the new world?

In order to enable a smooth move to the ABAP Programming Model for SAP Fiori at a later time, we’ve compiled a list of recommendations (DOs and DONTs) for customers and partners developing new applications on ABAP release 7.4 and downwards.

These recommendations are also valid for a smooth move to the ABAP RESTful Application Programming Model.

What about applications built with the ABAP Programming Model for SAP Fiori?

This is a valid question from SAP customers and partners who want to safeguard their investments.

SAP is aware of this and plans to provide an integration option of the CDS-based BOPF BOs within the ABAP RESTful Application Programming Model to reduce significantly the migration effort from the ABAP Programming Model for SAP Fiori.

The current state of planning is to offer such option in the year 2020*.

On the other hand, SAP will continue to support the ABAP Programming Model for SAP Fiori beside the ABAP RESTful Application Programming Model in the future for upwards compatibility reasons.

 Related Information