Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
JensWeiler
Advisor
Advisor
You’ve already been introduced to ABAP Cloud by Boris’s Blog Post, if not, I highly recommend reading it.

In this blog post, you’ll gain insight into the architectural idea of ABAP Cloud and its essential parts.

If you are directly interested in the supported technical use cases and recommended technologies, you can find them in this complementary document.

Before we dive into the details, let's briefly recap what is ABAP Cloud and where you can use it.

ABAP Cloud is the one common development model to build cloud-ready extensions and  applications, both in on-stack and side-by-side scenarios. It’s available in all current SAP S/4HANA editions and in the SAP BTP ABAP Environment.

Figure 1 - ABAP Cloud development model in SAP Products


 

This development model is a comprehensive development approach that covers all end-to-end aspects of the development process. It’s an overarching term that encompasses different things, both concrete and abstract, such as the underlying architecture, the actual tools used for development, development guidelines and much more. While those components are different by nature, the collection of these components support you with state-of-the-art ABAP development.

We’ll have a detailed look at each of these parts that make up ABAP Cloud, but first I want to talk about:

  • Who will use ABAP Cloud,

  • Some of the key concepts of this development model, and

  • The general architecture of ABAP Cloud.


We will then go into a detailed analysis of the development model, with a special focus on the ABAP Cloud programming model.

Who Will Use ABAP Cloud?


ABAP Cloud is all about building enterprise grade extensions, services and applications. In general, we consider two different personas who will venture this task.

Figure 2 - ABAP Cloud Personas


 

Business experts, key users, and implementation consultants (key-user extensibility)

can use the key user extensibility tools.
Key user tools offer a web-based authoring environment that can be invoked from within a running SAP Fiori application. They allow users with none or limited development experience to build fully functional extensions, yet the capabilities are naturally limited.
Typical tasks are changing the user interface, adding, or removing fields, renaming labels or creating custom business objects.

Developers (developer extensibility)

use the integrated development environment (ABAP development tools for Eclipse) to create ABAP projects containing the typical ABAP artefacts such as Dictionary Objects, Core Data Services, ABAP Classes etc. This allows to leverage ABAP development expertise to fulfill even complex extensibility scenarios.

One person may of course take on both roles, especially in smaller organizations, but the approach remains different. Knowing who will be involved with ABAP Cloud, let us now look at some important concepts.

Key Concepts of ABAP Cloud


The ABAP Cloud programming model builds on the following key concepts to support lifecycle stable, cloud-ready, and efficient development in all environments:

  • Released APIs: Stability of custom code is a key requirement for cloud development. This stability is guaranteed for all parties by the usage of released APIs. These APIs are stable interfaces which rely on the release contract framework and are thus safe from any incompatible changes. In other words: When developing with ABAP Cloud you can leverage the development done by SAP by using the released APIs and adapt it to your business requirements without any risk during upgrades. An overview of released APIscan be found on the SAP API Hub in the category Developer Extensibility.

  • Cloud-Optimized ABAP Language: The ABAP language scope has been adapted to support ABAP Clouddevelopment, and the language versions „ABAP for Cloud Development” and “ABAP for Key Users” have been introduced. Details for the ABAP Language versions are available in the SAP Help Portal.

  • Cloud-Optimized Architecture: With the architecture blueprint of RAP, the domain-specific implementation is conceptually separated from the business service exposure in different protocols. This supports the efficient reuse of data models across different domain-specificimplementations and for different purposes. In the next section, let us take a closer look at this architecture.


Architecture


ABAP Cloud is based on a model-driven architecture approach where the development efficiency is driven by standardization and formalization of the programming model and the tooling environment.

Programming models generally define the design-time software architecture with specific technologies, concepts, and development objects. It essentially defines a standard architecture for app and service development from the database to the business service exposure.

ABAP Cloud builds on the strengths of powerful frameworks and a standardized architecture for different use cases It aims at saving as much implementation time as possible while providing you with flexibility. You can model your business processes with apps and services based on your business requirements along predefined technical processes. The runtime orchestration is handled by the frameworks whenever possible to decrease the probability of consistency errors during runtime in implementations involving multiple business objects or services.

Components of ABAP Cloud


Having discussed some more general points, let us now look at the different components of ABAP Cloud. The goal of this blog post is not only that you get a better understanding of ABAP Cloud, but that you are able to visualize how the different pieces work together, and that you become familiar with the corresponding terminology.

Terminology


Figure 3 - ABAP Cloud terminology


 

At the core of the ABAP Cloud development model is its programming model, which defines the design-time and runtime architecture of all extensions, services, and applications. When talking about the programming model, we generally consider three different aspects:

  • Transactional (OLTP): With ABAP Cloud you can build business objects and expose them as services, to consume them in UIs and integration scenarios. All standard behavior is supported (create, read, update, delete). Think of the well-known Sales Order business object as an example.

  • Analytical (OLAP): ABAP Cloud is equally equipped for creating services and UIs for data analysis, for drilling down in multiple dimensions, like integrating the data in SAP Analytics Cloud.

  • Integration: Both previous aspects are complemented by strong data and application integration to cater to today's service-oriented environments.

  • Don’t worry, these aspects will be discussed in more detail in the following chapter.


The programming model doesn’t stand on its own but is accompanied by two key differentiators:

  • The re-use services & libraries with core business services like the number ranges, the application jobs, an ABAP integrated SAP Fiori Launchpad and UI repository to deploy SAPUI5 and SAP Fiori Elements UIs.

  • The built-in qualities offering end-to-end extensibility in the programming model, major cloud qualities like scalability and upgrade stable APIs and many more.


Both reduce the needed development effort and ensures, that ABAP Cloud is the new standard to build enterprise grade solutions.
This collection is further complemented by the following two components:

  • A set of tools like ABAP Development Tools in Eclipse (ADT), which for example, includes rich debugger, profiling, refactoring support.

  • A reliable lifecycle management built on the hardened ABAP Change and Transport Management (CTS) and extending it with support for git-based code management.


 

ABAP Cloud Programming Model


Diving further into the ABAP Cloud programming model, we see that it can be divided into the following three layers: Business Service Exposure, Domain-Specific Implementation and Data Access.

Those layers are common in all programming model aspects, as we will see later in more detail.


Figure 4 - ABAP Cloud programming model


 

Data forms the foundation of pretty much all business processes. It is therefore no surprise that the database plays a crucial role in ABAP Cloud, as has always been the case with ABAP in general. The Data Access layer provides and stores this data, which is in turn consumed and modified in the Implementation layer. ABAP Cloud integrates with a SAP HANA database by default, profiting from a high degree of synergy. However, data today is not always local, but has to be retrieved from remote sources. The Data Access layer is therefore complemented by the Business Service Consumption capabilities of ABAP Cloud, allowing you to integrate with external services with support for various protocols (see chapter Integration Aspect for more information).

In the Domain-Specific Implementation your domain-specific models (for example your business object) are defined using Core Data Services CDS entities, RAP business objects, or analytical providers like dimensions or cubes. The domain-specific implementation (for example the business logic consisting of determinations, validations and actions) is developed using the ABAP Language, ABAP SQL or CDS implementations.

The Business Service Exposure is also a core part of the development flow and represents the foundation for services and apps. The business service exposure concept in ABAP Cloud originates from the ABAP RESTful Application Programming Model and has since become the architecture blueprint for most other business consumption scenarios besides OData like, for example, the Information Access protocol (InA) for analytical apps. This layer can be divided into two categories: UI Services and Integration Services. The categories are quite self-explanatory - UI services are consumed by business users in user interfaces, while integration services are consumed in integration scenarios in machine-to-machine communication.

When developing UI services and OData-based integration services, CDS projections allow you to introduce an additional abstraction layer to your data models. This allows you to expose different scopes of a single implementation, facilitating flexible service consumption as well as role-based service designs. CDS projections are thus protocol agnostic, but service specific. This enables maximum reuse, for example across transactional and analytical services; data models need to be built only once and can then be used in different business contexts depending on the specific requirements, with minimal additional development effort. This separation of concerns between designing the application tier and exposing the business service in a specific protocol is a strength of ABAP Cloud. It supports maximum flexibility and reuse across different use cases.

 

ABAP Cloud Programming Model Aspects


As already mentioned, we differentiate between three programming model aspects in the ABAP Cloud programming model.

All three of them follow the general ABAP cloud architecture as described earlier. Let’s take a closer look at each of the aspects.

Transactional – The ABAP RESTful application programming model (RAP)


Most of you have probably heard of RAP. It is the main pillar when building transactional apps and services in ABAP Cloud.

The center piece of RAP is the Business Object (RAP BO). These are modeled using CDS and enriched with transactional behavior using the Behavior Definition (BDEF). A prominent example of such a business object is the Sales Order[1] or the Business Partner. Both are developed and provided by SAP in ABAP Cloud.

RAP BOs can be exposed as services using the Service Binding. We differentiate between two exposure use cases. UI scenarios, namely for creating SAP Fiori UIs, are supported using the OData protocol, while integration scenarios are supported with Business Events, OData services and SQL services.


Figure 5 – ABAP Cloud transactional programming model aspect


 

An example

You want to create a booking service with SAP Fiori UIs for airlines.

  • The essential UI and service needed is the booking of a flight. Thus, your domain is flight booking.

  • The overall model for the booking is a RAP BO consisting of a CDS implementation (data model) and a behavior definition (events like determinations, validations, and actions).

  • The implementation of the logic is done using ABAP. In the CDS model you can already implement UI annotations to automatically create SAP Fiori Elements UIs later.

  • The data is stored and retrieved in tables in the SAP HANA

  • The service exposure is done on top of this RAP BO. The service definition contains all relevant entities which are needed, including your "Booking BO”, as well as the associated master data like airplanes and business partners. The exposure using OData for the UI (including your annotation metadata) is done in the service binding (for example as a service binding of the type OData V4 for UI).


Analytical


The analytical aspect comprises the end-to-end development process for analytical services. The analytical aspect uses analytical providers like cubes and dimensions to build multidimensional domain-specific models. The domain-specific logic is implemented with CDS.

The CDS analytical provider can be exposed as an InA[1] service for different analytical clients. One of these possible clients is the SAP Analytics Cloud (SAC).


Figure 6 - ABAP Cloud analytical programming model aspect




Integration


The integration aspects enable system-to-system communication using several different protocols. Integration services enable either inbound communication or outbound system communication based on communication scenarios. Inbound communication enables a system to act as service provider, since outbound communication enables a system to act as service consumer.

Figure 7 - ABAP Cloud programming model aspect for integration


 
Business Service Exposure

The main service exposure channels for ABAP Cloud are OData and Business Events, which have clear domain-specific data models. However, it’s not always possible to cover each use case with a fully standardized model. To mitigate for this, ABAP Cloud offers the HTTP service: here you can make specific implementations to meet your needs (with full access to the request and response data of the HTTP request).


In order to ensure compatibility and to support highly optimized scenarios RFC services are equally available in ABAP Cloud. RFC can also be used for pure data integration as well as for SQL integration, which is based on ODBC (currently read-only).



Business Service Consumption

As touched on earlier in this blog post, it’s obvious that not all data resides in the local database of your system. Service consumption therefore plays a major role, which is why ABAP Cloud offers the service consumption model as an easy way to consume external services with typed APIs in your implementation.

ABAP Cloud Development Model


Now that we’ve examined the programming model of ABAP Cloud, let’s look at the other pillars of the ABAP Cloud development model to complete the picture.


Figure 8 - ABAP Cloud Development model – ABAP Cloud map


 

Reuse Services and Libraries


A key element of ABAP Cloud is the existence of powerful reuse services and libraries. They are offered directly on-stack and automatically come with the respective product environment without any additional cost. Reuse services and libraries are well integrated into the ABAP Cloud programming model to optimally reduce total cost of development for apps and services. All ABAP Cloud reuse services and libraries preserve ABAP Cloud built-in qualities and can be used across all programming model aspects.

A variety of reuse services is available and ready-to-run, ranging from applications jobs, application logs, forms, and email integration up to change documents and workflows. You can find more information in your product’s documentation, for example here.

Built-In Qualities


Built-in qualities represent the quality foundation of ABAP Cloud.

In other words, they represent common characteristics all ABAP Cloud developments and extension share. They represent the best-practices and basic quality principles upon which ABAP Cloud is built on. The built-in qualities equally apply to all aspects, as well as all apps and services. They are:

  • Development Efficiency

  • Cloud Qualities

  • Transactional Consistency

  • Documentability

  • Security

  • Testability

  • Supportability

  • Extensibility

  • Performance

  • Localization and Internationalization

  • Business Configuration


And next…


If you are now interested in the technical Use Cases and recommended technologies of ABAP Cloud, please take a deeper look at our ABAP Cloud – Technical use cases and recommended technologies  document.

More content and possibilities to engage with the community is available in the ABAP Development Community.

Stay tuned for more details on ABAP Cloud in our next blog posts where we will get into more details on the re-use services & libraries, the built-in qualities, the lifecycle management, and the tools of ABAP Cloud.

 

Footnotes

[1] Only available in the SAP S/4HANA editions

[2] Information Access – A SAP proprietary analytical protocol
11 Comments
ThomasSchneider
Product and Topic Expert
Product and Topic Expert
Hi Jens,

thank you for this post and the very informative figures and explanations. These will help to structure customer use cases. The is this complementary document also very helpful and will answer a lot of questions.

Best regards,

Thomas

.
mhappe
Participant
0 Kudos
Hi Jens,

Is it possible to consume raised business events within ABAP cloud itself without the need to use event mesh on BTP?

 

Thanks!

 

Kind Regards,
Mattijs Happé
daniel_gerecht
Advisor
Advisor
Hi Mattijs,

 

local consumption of Business Events within ABAP Cloud are on our roadmap, see Integration Services | SAP Help Portal.

Best regards,
Daniel
Juwin
Active Contributor
When I first read the title of the blog, I read the word Comprise as Compromise 😊

Many would feel that way, moving from OnPrem programming model to On cloud.
Tomas_Buryanek
Active Contributor
0 Kudos
Hehe 😄 Me too "ABAP Cloud – What Does It Compromise?"
mhappe
Participant
0 Kudos
Thanks voor de quick response. We are looking forward to it!

 

Currently we try to implement Badi "MM_PUR_S4_PR_POST" in a S4 cloud system.:

Short text

POST Method

Use

This Business Add-In (BAdI) enables you to trigger a variety of follow-on processing operations for purchase requisitions at the time of posting.

Standard settings

· In the standard system, the BAdI is not active.

· The BAdI is filter-independent.

Activities

Method: POST

Parameters:

Import Parameters:



















PURCHASEREQUISITIONITEM_NEW: The purchase requisition item with the latest changes made in "Edit" mode.
PURCHASEREQUISITIONITEM_OLD: The last saved version of the purchase requisition item. Note that this is empty when the purchase requisition item is not in "Edit" mode.
PURCHASEREQACCASSGNMT_NEW: The account assignment details of the purchase requisition item with the latest changes made in "Edit" mode.
PURCHASEREQACCASSGNMT_OLD: The last saved version of the account assignment details of the purchase requisition item. Note that this is empty when the purchase requisition item is not in "Edit" mode.

 

But we are unable to trigger some kind of follow-on processing, all options we tried are running into a shortdump. Options we tried Trigger a custom BO update using EML, executing a background job, trigger a RFC.... All without success.

Can you tell me which option we'll need to implement for triggering some following up actions?

 

Thanks again!
felix_wente
Explorer
0 Kudos
Hello Matthijs,

the reason for this is the BAdI is categorized as "functional", which does not allow data modification or  RFC or bgRFC breakouts. A new concept for this BAdIs is in planning, but will not make it for 2308.

Kind regards,

Felix
freilinger
Participant
0 Kudos
Hi  jens.weiler,

thanks a lot for the post - in the analytical case the image (no. 6) is a little missleading from my perspective.

The text states, that the domain-specific logic has to be implemented (=modelled) via CDS, but the image also contains ABAP for the domain-specific programming in addition.

So from my perspective the image would imply, that if CDS is not sufficient for the implementation of the data provisioning, I can also use ABAP to enhance it (for example some kind of exit, which I can use, after the data is retrieved via CDS to implement more complex logic against it after CDS.

This was not supported in the former model as well, when you tried to create a SEGW-ReferenceDataService on top of an analytical query cds view, you got an error message. So I assume, ABAP is not possible here as well and therefore the image is not correct?

Don't get me wrong - it would be obviously very nice, if the image is correct and now you have the possibility to add ABAP on top, but I doubt it 😉

Best regards,

Sebastian
peter_peng
Advisor
Advisor
0 Kudos
Very helpful blog, thank you!

one question: you mentioned 'An overview of released APIscan be found on the SAP API Hub in the category Developer Extensibility'. but I found 'Developer Extensibility' is located under 'SAP S/4HANA Cloud, Public Edition' only, not in 'SAP S/4HANA'.

So my question is why there is no 'Developer Extensibility' under 'SAP S/4HANA' in API Hub?
JensWeiler
Advisor
Advisor
0 Kudos
Hi,

the Developer Extensibility and with that the released APis are available in all S/4HANA Editions (of course depending on the release - for on prem we recommend to be at least on 2021, better on 2022).

The Business Accelerator Hub aka API Hub will relfelct these changes hopefully soon. I know the colleagues are working on it.

Cheers

Jens

 
peter_peng
Advisor
Advisor
0 Kudos
thank you for the clarification, it's clear.