Describing The Different Use Cases For ABAP Cloud

We've seen how cloud native has required an evolution of the ABAP programming language (ABAP language version "ABAP for Cloud Development" or "ABAP for Key Users" as opposed to "ABAP Classic") 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, the 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 was not supported and 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. The ABAP RESTful application programming model is the successor to the ABAP Programming Model for SAP Fiori and is the programming model used in ABAP Cloud for transactional use cases.

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). Business objects built with the ABAP RESTful application programming model can be used as local APIs (to be discussed shortly).

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. The ABAP RESTful application programming model is designed from the ground up to be consistent with the microservices concept.

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

Let's understand the different layers.

• Data Access

  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 Programming

  The ABAP language and ABAP Core Data Services (CDS) are the main languages used to provide the domain-specific implementation of read-only queries and transactional business objects in the context of the ABAP RESTful application programming model.

  The ABAP language version "ABAP for Cloud Development" provides cloud-optimized language constructs used in the context of ABAP Cloud to implement the business logic. The ABAP language is enhanced with an Entity Manipulation Language (EML) to natively control the transactional behavior of business objects built with the ABAP RESTful application programming model.

  CDS provides a powerful data modeling infrastructure to define semantically rich data models on the ABAP application server. The various CDS artifacts 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
• Domain-Specific Data Modeling

  Domain-specific models determine the design time artifacts of your data model depending on the programming model aspect. You can develop read-only queries and transactional business objects with the ABAP RESTful application programming model. Every real-world entity is represented by a business object (BO), which consists of one or more nodes with a parent-child relationship between the nodes. A business object always starts with a root node.

  Taking the customers and orders example just mentioned, for each of them, two possibilities exist in the ABAP RESTful application programming model. 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 ABAP CDS. Transactional functionality is defined with a CDS behavior definition along with the ABAP language and also EML. On a conceptual level therefore, a BO consists of a data model defined with ABAP CDS entities and the associated transactional capability defined with a CDS behavior definition and implemented with the ABAP language and EML. The data model of each BO node is represented by one CDS view entity defined on top of a datable table or other CDS entities. So, in a customers / orders scenario, for example, there would be two main CDS view entities, one for each respectively.

• 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.

In addition to its transactional use cases, ABAP Cloud is up to the challenge for 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.

Finally we look at integration use cases. In understanding this scenario it helps to define the term 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. By combining the comprehensive portfolio of SAP products such as SAP S/4HANA Cloud and SAP Ariba along with SAP Business Technology Platform 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 ABAP Cloud. Deprecated integration technologies can no longer be used in ABAP Cloud (for example, IDoc) – only released frameworks can be. 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.

We conclude this lesson by acknowledging that at first glance it may appear that the terms ABAP Cloud development model and ABAP RESTful application programming model may be referring to the same concept. They do not. The two terms refer to different things which is important to understand.

The scope of what ABAP Cloud refers to is larger. It encompasses the complete development model. This includes (but is not limited to) programming models, lifecycle specifics, APIs, rules for custom and extension development and even specifics related to identity and access management.

The scope of what ABAP RESTful application programming model refers to on the other hand is smaller and more specific. It refers to a specific programming model (i.e., tools, technologies and techniques) to build specific development artifacts for specific purposes. The programming model is a part of (and incorporated into) ABAP Cloud. It's equally appropriate to define the relationship in the other direction (i.e., ABAP Cloud references ABAP RESTful application programming model to implement transactional, analytical and integration use cases).