ABAP Cloud ... without BTP?
In this article, we explore the question of whether ABAP Cloud is possible without BTP and what you should consider.
Table of contents
This article was inspired by Michael Keller with the idea of using ABAP Cloud only on-premises. If you would like to read more from Michael, you will find additional material at the end of the article.
Introduction
In this article, we would like to address the question: Can we become Clean Core if we implement all our extensions with ABAP Cloud On-Stack? We will look at various aspects of development, what already works well with it, and what you cannot currently use.
ABAP Cloud is the development model for implementing Clean Core and Cloud Ready. In this article, we will focus on the topic of Clean Core, as we assume that we are a company that cannot (requirement) or does not want to (cost) move its processes to the public cloud. We will discuss its use in the architecture.
For a long time, it has been said that we can only achieve Clean Core if we implement our extensions outside of the system and do not change the core system. The BTP was also provided for this purpose, providing various services for creating the extensions side-by-side. Since the introduction of ABAP Cloud, this is no longer the case; BTP is optional in many scenarios.
Prerequisite
To get started properly with Clean Core, you need an S/4HANA 2023 release, as ABAP Cloud is very well supported here. Currently, there are too many gaps and functions that are not available in the 2022 release, so we recommend starting with a 2023 release. Starting with this release, many features will also be available in RAP, which facilitates the development of RAP-based applications. Starting with the 2025 release, even more features will be added, such as editable trees, very likely the Analytical Table (replacement for ALV), and in the private cloud, Joule for Developers.
Implementation
In this chapter, we will look at the implementation of ABAP Cloud, the preparation for implementation, and the development with Key User and On-Stack Extensiblity.
Photo from Oscar Nilsson on Unsplash
Configuration
So, in the next step, let's assume If you want to keep your options open to migrate some of your applications to the ABAP environment at a later date, you should adhere to a certain architecture when creating software components. You should create multiple SWCs and ensure they are separated from each other. This ensures that individual components can be easily migrated to the ABAP environment. Why ABAP environment? You can continue running your ABAP code on this platform and don't have to switch programming languages, as is the case with CAP, for example.
You can find out how to make ABAP Cloud available in your system and take the first steps in our checklist.
Extensibility
The first step would always be to check whether you can extend your system using Key User Extensibility. This option is also available in the public cloud and supports many of the system extension scenarios. However, any extensions you create with it cannot be moved to the BTP; such extensions are considered tightly coupled and always remain on the core system.
You should no longer use all classic extension techniques, whether modification, enhancement (explicit or implicit), or user exits; these are now obsolete. Here, you should look for standard BADIs, preferably those released by ABAP Cloud. Based on the current status, this will rarely be the case in the edge modules, but you can still cleanly implement a classic BADI. This form of extension will also remain on the system in the future.
Custom Development
You would create your own data models and applications using software components. A software component in ABAP Cloud automatically specifies the rules for what technology and APIs you can use in the system. This provides you with guidelines for developing ABAP Cloud-compatible applications, and you can't go wrong. Concepts such as RAP applications, application jobs, and business configuration are already predefined and established. Application jobs can currently be used on-premises, but only with version 2 will they become fully usable and the current teething issues be resolved. These new features will be available with the 2025 release.
If you use functions from the standard, you should make sure to use released APIs, but also to wrap APIs in wrappers that make sense.
Challenges
In this chapter, we'll look at various challenges and how you can address them to be ready for the BTP on-premises as well.
Photo from Alicia Christin Gerald on Unsplash
Available APIs
Depending on the module, the availability of APIs can be quite daunting, especially at the beginning. This is especially true if the appropriate BADI isn't available in an ABAP Cloud-compatible format for extensions. The first step here is to check whether a cloud-compatible successor already exists, meaning the module is no longer available. If this isn't the case and individual components are already available with Core Data Services and Fiori applications, you can continue with the modernization.
Wrappers
Wrappers are a key component when not all APIs are available, but you want to implement many components in ABAP Cloud. To do this, you must use suitable standard objects and provide suitable wrappers. For BAPIs, for example, you can generate a wrapper using the transaction ACO_PROXY once the appropriate information has been imported into the system. BAPIs, classes, Core Data Services, and tables are suitable for releasing the appropriate functions for TIER-1.
We recommend close coordination within the development teams so that wrappers are only created once, but also have certain qualities such as testability, reusability, and encapsulation. This allows important APIs to be made available right at the start of a project to support development. If no data model is available in CDS, we recommend creating one and using it centrally.
File Access
If you are still using file interfaces, you can continue to do so for now. However, you should map all access to local or remote files in ABAP classes as separate APIs in TIER-2. During a later migration, you can easily replace the wrapper, especially if you are moving to the cloud and access to the file system is no longer possible. Instead of an OPEN DATASET, an HTTP API call can then be made, for example, to read the file from Document Management or via another service.
This means that the class/API ultimately delivers the file stream, regardless of which technology is used in the background or where the data needs to be read from. The decoupling of the technology is perfect for the transition to the new world.
Workflow
Currently, on-premise workflows are no longer clean core, as modeling is done via the SAP GUI, and many interactions currently take place there. SAP's successor solution is called SAP Build Process Automation. However, since we want to forego workflows for the time being, as we're doing everything on-premises, you should write a wrapper to, for example, start workflows or retrieve information.
Similar to file access, the decoupled call initially gives you the freedom to use different technologies in the background. The class should start a workflow, set a task to the next status, and end workflows; the technology in the background should not play a role.
Interfaces
Things get a bit more complicated, however, with interfaces for data, especially when modeling in RAP objects. If you're creating current apps that rely on associations with the standard, or even rely on the entire application's Core Data Services, then migrating to the BTP won't be quite as easy. Currently, the only solution is to use a custom entity, but this would require redesigning the application.
If the integrated Core Data Services are primarily planned as value helps, they can also be mapped using a custom entity, and the conversion effort isn't quite as great. This particularly applies to applications that have their own data model.
Accessing data in the standard is quite easy to implement in the same system, but this is where the greatest challenges arise when moving to side-by-side. External entities can certainly simplify access and avoid conversions in the future, but in the current state, you can't use them for this purpose.
Conclusion
In principle, you can already implement your extensions in the system with ABAP Cloud today and don't need a BTP for it. This currently saves a lot of costs, but you won't be able to enjoy the full freedom to consume the various cloud services. However, you also need a current release to get started with Clean Core.
Further inspiration:
Michael Keller Blog (SAP, Well Organized, etc.)
