At what level should the business logic be implemented and integrated in SAP S/4HANA? In the ABAP environment, the answer is relatively clear.
Business logic (as we understand it here) runs on the application server and is implemented in ABAP. Reasons for this include the scalability of the application servers and the extensive existing business logic in SAP S/4HANA, which should of course be accessible and reused. This approach isn’t contradictory to the goal of shifting the data-intensive logic to the database.
Optimally, SAP HANA is used, of course, for all read operations, and transformations are mapped as far as possible using SQL when reading data. This also applies especially to authorization checks leveraging the CDS access control language to avoid transferring data to the application server to just remove it again. This pushdown approach can also be used in a reasonable way in transactional logic.
Consider the following example: In sales order processing, before the sales order can be confirmed, the credit limit of the customer should be checked based on the current order and the open items. The open items are calculated using aggregation (total of open items) in the SAP HANA database. Only the result of the calculation is transferred to the application server. In the application server in the corresponding check, this value is added to the current order value and compared with the customer’s credit limit. If this limit is exceeded, a corresponding message is generated, and, if necessary, a corresponding status is set in the document.
The ABAP platform enables the use of CDS models as the basis for modeling transactional applications. In this context, all the requirements defined in the previous section for transactional applications or for a corresponding infrastructure must be considered. For this purpose, the ABAP RESTful application programming model has been introduced as the logical successor of the ABAP programming model for SAP Fiori.
The ABAP RESTful application programming model is the common foundation that the programming model of SAP S/4HANA is based on. It fosters the application architecture to clearly separate the database model and database layer, the application logic (business logic), and the UI. While the separation of the UI (and related user experience [UX]) is technically ensured by following the SAP Fiori technology approach leveraging OData as the protocol of choice, the ABAP RESTful application programming model allows you to further clearly separate the model and implementation of the different layers: the common general base model and application logic (business logic) on one side, and the service-specific model and application logic on the other side, while leaving the protocol implementation to the infrastructure. Thus, the ABAP RESTful application programming model ensures that the complete application implementation is protocol agnostic and can also be reused when switching to a different protocol or protocol version.
As for CDS entities, all ABAP RESTful application programming model-specific artifacts needed for implementing transactional applications can be created and edited via ABAP in Eclipse (aka ABAP Development Tools [ADT]).
The ABAP RESTful application programming model supports both greenfield and brownfield implementations, which is a major enhancement compared to the ABAP programming model for SAP Fiori. The consumption of the ABAP RESTful application programming model implementation is completely integrated into the ABAP language, and the type of implementation is hidden from the consumers of the application, whether it’s within ABAP or via different channels such as OData.
We’ll focus on consuming the application via REST and OData as a web standard because the ABAP platform already offers end-to-end support for these standards. The infrastructure takes over the complete protocol handling and automatically forwards all operations, that is, read and write requests, to the database or the provider implementation. All non-transactional read and analytical requests are delegated directly to the SAP HANA database via the ABAP SQL interface by leveraging the related CDS data model. Transactional requests for reading or writing data are passed to the transactional runtime and the transactional buffer in the application server. This combines efficient processing of all persistent data by the SAP HANA database with the advantages of the transactional runtime being executed on the ABAP application server and the possible reuse of the existing business logic.
The Service Adaptation Definition Language (SADL) of the ABAP platform is used to translate OData GET requests to SQL queries. SADL is an infrastructure for model-based reading and processing of data.
For more information about SADL, visit the SAP Help Portal at https:// help.sap.com, and search for “Consuming Business Entities with SADL” (http://s-prs.co/v529412).
For a schematic representation of the ABAP infrastructure for transactional applications with the most important runtime components, see the figure below.
Editor’s note: This post has been adapted from a section of the book Core Data Services for ABAP by Renzo Colle, Ralf Dentzer, and Jan Hrastnik.
Comments