ABAP Cloud - Clean Core Level Concept
The new Clean Core Level Concept for ABAP Cloud is here, replacing the 3-TIER model. In this article, we take a detailed look at the changes and adjustments.
Table of contents
In this article, we'll explore the various details and layers of the Level Concept and how it can help you achieve Clean Core much more easily. We'll address the various aspects and look at a possible implementation.
Introduction
About three years ago, the 3-TIER Model for the path to Clean Core was introduced. How can you achieve Clean Core, and how are the different layers divided? Such questions should be clarified in the concept. However, most companies that don't use Greenfield found this too difficult, as their entire source code was classified as Classic ABAP, making Clean Core measurable. Accordingly, the new "Clean Core Level Concept" was introduced in August. presented, which should provide more clarity in the future.
Concept
In this chapter we will look at the new concept in detail and go into the various new points.
General
The new level concept provides for four levels, from A - D. Level A is the best you can achieve and D is currently the worst, which also does not mean Clean Core. As you can see from the following overview, Level C is only Clean Core unless otherwise defined (with conditions).
Level
Let's take a look at the different levels, what properties they have, and how we can achieve them. We'll start with Clean Core and Cloud Ready in the first step:
- Level A - The objects correspond to the ABAP Cloud standards; this is the old TIER-1 layer. We only use released APIs in the system and are therefore Clean Core and Cloud Ready.
The other three levels primarily refer to the Private Edition and on-premise systems, since we are in the area of Classic ABAP development here. Therefore, these levels are directly related to "Classic ABAP."
- Level B - The object only uses APIs marked "Classic API" in the Cloudification Repository. These APIs are stable, documented, and released for use.
- Level C - These are unclassified APIs from SAP. They are neither "Classic API" nor "noAPI." This level can change from release to release. You should consult with SAP and consult the changelog.
- Level D - APIs marked "noAPI" in the Cloudification Repository are used. Classic extensions, such as modifications to the system, are used. This level is not Clean Core and should be revised first.
If we now take the different levels, along with the recommendations and definitions, we get the following overall picture of the different levels.
Technology
In principle, one can now say that classic ALV-based applications are also Clean Core. This is because ALV is marked as a Classic API. This applies primarily to existing applications from the standard area and the associated extensions. However, there are also things you should not use, such as RFC_READ_TABLE, which is marked as noAPI. In addition to not being approved, this also has security concerns and should therefore no longer be used anyway. The list also includes things like BAPI_COSTCENTER_GETDETAIL, but only because there are already good successor solutions for this.
Governance
An important step is the topic of governance. How far is the system on the path to Clean Core? The ABAP Test Cockpit (ATC) will play a key role in determining the metrics. If you already use the ATC in the ABAP environment, the latest test is already available, and you can use it to test against your on-premise system. Important checks in the ATC variant are therefore:
- Allowed Enhancements Technologies - Check whether the permitted enhancement scenarios are being used; currently, these are only BADIs.
- Usage of APIs - Classification of the Classic API and noAPI via the Cloudification Repository.
- Search customer modifications - Modifications are not Clean Core and are determined via this check.
- Critical Statements - Critical statements that should no longer be used in ABAP developments.
Here you will find a comparison of the new levels with the ATC findings and their degree as an initial overview.
Hint: Working with the exemption process within the ATC facilitates documentation and sustainability when monitoring Clean Core. The check upon release also blocks potential violations of the Clean Core strategy.
Upgrades
For upgrades, SAP will provide a changelog for the Classic APIs (Levels B and C) in the future. This gives us the opportunity to check our developments against the changelog to find changes and errors more quickly. The list of changed objects should be particularly helpful when it comes to testing effort. This is intended to keep the testing effort to a minimum when changing releases. If there have been no changes to a component, then custom developments that use this component do not need to be tested.
An ATC check is provided for this purpose, which you can use to check your existing custom developments before an upgrade and react before an upgrade.
API Enablement
The topic of API enablement, formerly Tier 2, remains a concern. Due to the discontinuation of Tier 2, there is currently no process for where the APIs should be created or for governance and retrieval. Therefore, you need to consider how you want to handle this issue within your company, as the current Level Concept no longer provides recommendations or guidance.
A suggestion from our side would therefore be:
- Component - Create a suitable structure in the system where developers can create their released objects. As a repository, new developers can get an overview of the APIs already available in the system. The main goal here is to avoid constantly rebuilding existing APIs, but rather to provide and use central APIs wherever possible. A separate SWC is optional here; a suitable structure would be paramount.
- Monitoring - Which APIs and functions are released for Level A? Here, it should continue to be checked centrally which functions are wrapped (continue to observe best practices). Generally, APIs are noticed when they fall into Levels C and D.
Modernization
In principle, you can now achieve Clean Core without migrating your entire system to ABAP Cloud. You should first start with Level D developments with the help of the ATC, testing them, and adapting them. If the ATC check then only returns warnings or all errors have been documented, you have essentially already completed the journey towards a Clean Core.
In the next step, you should look at modernization. The new ABAP Cloud APIs continue to be an important component, and standardization makes sense. This is especially true with regard to technology, such as Fiori Apps, Application Jobs, Business Configuration, and the new Mail Framework, in order to harmonize all areas. Generally, it makes sense to start new developments at Level A, unless the technology of the business application does not allow it. If it's a pure GUI application, no RAP object is available, and extensions are implemented using traditional methods, then you should do so. If the extension is Level C or even Level B, you're initially on the Clean Core side.
Summary
Basically, a tip from us: First, think about what strategy you're follow for a system. If you want to be cloud-ready, then Level A is the goal, and you want to replace as much Classic ABAP as possible. If Clean Core is sufficient for you, then you just need to move away from Level D, which is now easier to achieve. If your company doesn't want or can't move to the cloud, Clean Core is certainly sufficient. However, since Level C is currently undefined, you should also think about these objects in the future, as these objects will either become Level B (Good) or Level D (Bad). We still recommend implementing many applications with ABAP Cloud to ensure a future-proof investment in the applications.
Here are the most important points:
- 3-TIER model (TIER 1-3) becomes Clean Core Level Concept (Level A-D)
- Clean Core easier to achieve
- Goal remains ABAP Cloud for new developments
- ATC for more governance
Conclusion
The Clean Core Level Concept should now make it easier for customers to achieve Clean Core. However, consideration must also be given to measurability and governance to avoid a renewed chaos of various APIs in the system. The path (Clean Core and/or Cloud Ready) should also be coordinated and kept in mind.
Source:
ABAP Cloud
Clean Core Extensibility (White Paper)
Extensibility Guide (Current Version)
SAP Community - ATC recommendations for Governance
