ABAP Cloud - Transactional (OLTP) Aspects: The ABAP RESTful Application Programming Model
We've seen how cloud native has required an evolution of the programming language (ABAP Cloud) and the primary IDE (ABAP development tools for Eclipse). So, it will come as no surprise that the primary programming model used by ABAP would need to evolve also. Classical ABAP technologies such as SAP GUI or Web Dynpro are not compatible with the needs of cloud native.
As mentioned in the previous lesson, REST has emerged as one of the most popular API architectural models used by developers today, and one of the most popular implementations of REST is the Open Data Protocol (OData). Often referred to as "ODBC for the Web", OData is designed from the ground up to optimize the type of data processing and data manipulation that a business program needs to do. While not technically required, more often than not, the business data manipulated via OData resides in a database. As the SAP HANA database is the underlying database for SAP S/4HANA Cloud, REST in general and OData in particular are natural directions for an evolved ABAP programming model that takes into account the needs of cloud native to take. The result of this evolution is the ABAP RESTful application programming model.
But there was a small pit stop first.
The first generation of REST-compliant OData services were based on the precursor programming model to the ABAP RESTful application programming model, ABAP Programming Model for SAP Fiori. While at the time of its creation this model was a best practice for creating services, there were a few challenges. Development using the ABAP Programming Model for SAP Fiori with brownfield scenarios could be challenging n some instances, and also the tool support consisted of several transaction codes as opposed to a unified tooling environment. In addition, some aspects of the programming model used a framework implementation providing a little less transparency with regards to ABAP code than what ABAP developers have become used to.
While these challenges were manageable, the next evolutionary step was to eliminate them by consolidating the entire development flow in Eclipse with ABAP development tools for Eclipse and also to simplify and consolidate the development artifacts into a simple and intuitive list. ABAP RESTful application programming model is the successor to the ABAP Programming Model for SAP Fiori and is the programming model used by ABAP Cloud.
The ABAP RESTful application programming model allows for the creation of REST-compliant OData services from a small number of simple and intuitive artifacts. These services can be used either as the service layer for SAP Fiori apps running at the user layer, or as a standalone Web API (consumable by any type of client whether UI based or not).
In the previous lesson, we mentioned that a microservices design where an application is partitioned into a separate user layer, service layer, and a data layer is an important element of cloud native development. ABAP RESTful application programming model is designed from the ground up to be consistent with the microservices concept.
ABAP RESTful Application Programming Model
ABAP RESTful application programming model artifacts are organized around the following four layers:
- Data Access
- Domain Model and Implementation
- Business Service Exposure
- Business Service Consumption
At the base layer of the ABAP RESTful application programming model are database tables, which hold business data needed for transactions and analytics. That database of course is SAP HANA. By using SAP HANA, ABAP RESTful application programming model automatically benefits from in-memory architecture, columnar store, real time data, and machine learning technology, amongst other technologies.
- Domain Model and Implementation
The domain model and implementation comprises the representation of the different concepts involved in a business scenario, for example customers and orders, their relationships, for example the parent-child relationship between customers and orders and finally the implementation of these entities and relationships.
- Domain-Specific Data Modeling
ABAP RESTful application programming model uses a straightforward set of artifacts for domain-specific data modeling. Taking the customers and orders example just mentioned, for each of them, two possibilities exist. Those would be read-only scenarios (that is, query functionality) and also transactional scenarios (that is, create, update, and delete functionality). Queries are modeled using Core Data Services (CDS). Every real-world entity is represented by one CDS entity. So, in a customers / orders scenario, for example, there would be two CDS entities one for each respectively. When using the CDS entity for a data selection, the data access is executed via SQL / SQLScript access. Transactional capability is modeled as a business object (BO). Again, in a customers / orders scenario, there would be two ABAP RESTful application programming model BOs, one for each respectively.
CDS entities are defined using the following:
- CDS Type Definition Language (TDL)
- CDS Data Definition Language (DDL)
- CDS Service Definition Language (SDL)
- CDS Data Control Language (DCL)
- CDS Annotations
Business objects are defined using the following:
- ABAP RESTful application programming model Behavior Definition Language
- ABAP statements for ABAP RESTful application programming model
- Business Service Exposure
A business service is where the REST capabilities of ABAP RESTful application programming model come to fruition. It consists of the following:
- A service definition exposing the query and transactional capabilities that can are accessible via REST.
- A service binding associating a service definition with a REST protocol, which enables the service for consumption.
A service definition can be published multiple times by different service bindings using different protocol depending on what type of consumption is preferred.
Business Service Consumption
Consumption is possible using a variety of options. As mentioned earlier, a service binding based off of OData can enable SAP Fiori apps development. OData can also be used for app to app (or system to system) integration. In this case, any UI metadata in the Domain Modeling and Implementation layer is ignored. Event-driven architecture enables asynchronous communication between an event provider and an event consumer in use cases where no direct response from the event consumer is required. Using SAP Event Mesh, a service in SAP BTP, an ABAP RESTful application programming model BO can act as an event consumer or an event provider.
ABAP Cloud – Analytical (OLAP) Aspects
In addition to its transactional aspects, ABAP Cloud is up to the challenge of analytical scenarios as well. Analytical use cases involve analyzing and evaluating multidimensional data models to derive real-time data-driven business decisions. The analytical programming model aspect focuses on creating data models to analyze business data in embedded or cross-system setups and to visualize the data in dashboards or as part of apps.
End-to-end development for these analytical use cases is possible using ABAP Cloud. Analytical providers, such as a reusable star or snowflake schema (based on cubes, dimensions, and hierarchies) can be designed to build multidimensional domain-specific models. The domain-specific logic is implemented with CDS. The CDS analytical provider can be exposed using the Information Access (InA) protocol service for different analytical clients, such as SAP Analytics Cloud or SAP Analysis for Office. In addition, OData exposure for access via SAP Fiori UIs is possible.
ABAP Cloud – Integration Aspects
The Intelligent, Sustainable Enterprise
An intelligent, sustainable enterprise is one that consistently applies advanced technologies and best practices within agile, integrated, business processes. SAP supports our customers in becoming intelligent enterprises by providing solutions for integrating data and processes, building flexible value chains, innovating with industry best practices, understanding and acting on customer, partner, and employee sentiment, and managing environmental impact.
SAP enables our customers to become intelligent, sustainable enterprises by bringing together our comprehensive portfolio of solutions and technology in service to customers' business process needs. With SAP Business Technology Platform as the foundation for our intelligent suite applications and industry cloud, SAP has the unique ability to integrate business processes end-to-end.
SAP's Intelligent Enterprise consists of the following four core end-to-end processes:
- Lead To Cash
- Design To Operate
- Source To Pay
- Recruit To Retire
Each of these processes requires connectivity across several different SAP products and solutions, including SAP S/4HANA Cloud. As a result, connectivity options continue to be necessary and are provided as part of the ABAP Cloud development model. Deprecated integration technologies can no longer be used in the ABAP Cloud development model (for example, IDoc) – only released frameworks are available. The following connectivity frameworks are available:
- OData services
- Business Events
- HTTP services
- RFC via cloud enabled WebSocket RFC
- SOAP consumption (SOAP service provider planned)
- SQL service for external ODBC Clients
- SAP information access (InA) for analytical clients
Along with these frameworks is the Cloud Connector, which enables connectivity to systems located in internal landscapes.
To ensure content separation between credentials, customers do not have direct access to classical transactions for destinations (SM59) and logical ports (SOAMANGER) in SAP S/4HANA Cloud. Instead, a series of SAP Fiori apps (known as Cloud Communication Management) is used to set up all the logical artifacts required to implement communication scenarios along with the necessary user and authentication options.