In SAP S/4HANA Cloud, private edition and SAP S/4HANA on-premise we recommend to follow the ABAP Cloud development guidelines as much as possible and reduce the amount of classic ABAP developments to enforce upgrade stability and clean core for your systems.
The 3-tier extensibility model described in the ABAP Extensibility guide provides you a blueprint how you should setup the new development model in your landscape.
Figure 1: 3-tier extensibility model for SAP S/4HANA Cloud, private edition and SAP S/4HANA on-premise
The most important rule is that the default for all kinds of new developments is Tier 1, where ABAP Cloud including the usage of released SAP APIs is set up by switching the ABAP language version to ABAP for Cloud Development and strictly controlled via the ABAP syntax check. In case of missing released APIs the idea of providing custom wrappers in Tier 2 development overcomes this gap. But there are still quite some use cases where this strict development model controlled via the ABAP language version cannot be applied. Therefore Tier 3 for classic ABAP extensions is there in place. Examples are the extensions of SAP GUI based Dynpro applications or the need to extend an application via a classic extension technique like User Exits or not released BAdIs. Tier 3 is also the place for all kinds of legacy code where an adjustment towards ABAP Cloud is not feasible from the ROI perspective.
As the ABAP for Cloud Development language version cannot be used for Tier 2 and Tier 3 developments we recommend to control the usage of ABAP Cloud via the ABAP test cockpit (ATC) and minimize the usage of classic ABAP code. The basic idea is to check all developments (even the legacy development) with the same ATC variant and use the ATC exemptions to control the usage of ABAP Cloud within your developments.
Technical Setup
Use the remote ATC and set up a central ATC system connected against all development related systems (DEV, Q). Setup the ATC blocking mode in DEV systems for all Priority 1 and Priority 2 findings for transport tasks and transport requests.
Recommendation for the ATC check variant
You should create your own ATC standard variant as a copy of the default ATC variant ABAP_CLOUD_DEVELOPMENT_DEFAULT in ABAP development tools for Eclipse and add the following checks from the ATC category Cloud Readiness to your variant to enforce the cloud-like development:
Figure 2: Custom ATC check variant to enforce development with ABAP cloud development model
Please note: The SAP note 3397285 must be implemented to set the correct default value of the “Usage of Released APIs” check.
Remark: In case you have not licensed the CVA security checks you have to remove them from your check variant.
Use ATC exemptions to control new classic ABAP developments
As already mentioned we recommend to use ATC exemptions to control the rules of ABAP Cloud for developments within Tier 2 and Tier 3. ATC exemptions can be applied individually for every check message and on the following granularity levels:
| Exemption scope | Description |
| Finding | Exemption is valid for a single finding |
| Package | Exemption is valid for all objects of a package |
| Object | Exemption is valid for a single object |
Let’s go through the following use cases to explain the usage of ATC exemptions in more detail:
Use Case 1: Implement a custom wrapper for a missing released API (Tier 2 development)
The recommendation is to use language version “Standard ABAP” for the wrapper object and use the ATC check to apply the syntax of ABAP Cloud (no exemption) and control the usage of not-released APIs via fine granular ATC exemptions for the check “Usage of Released APIs” on a finding level.
Figure 3: Example for implementing a custom wrapper for a missing released API (Tier 2 development)
Use Case 2: Extend an SAP GUI based Dynpro application
The usage of the ABAP for Cloud Development language version is not possible here, so you have to apply for an exemption on object level for the check ABAP Language Version (Syntax) but you can control the usage of released APIs on a fine granular level for the check Usage of released APIs on finding level.
Figure 4: Example for extending an SAP GUI based Dynpro application
Use Case 3: Implement a non-released BAdI
The usage of released APIs is not possible here so you have to apply an exemption on object level for the check Usage of released APIs. But the syntax of the BAdI implementation should be compliant to the rules of ABAP Cloud and therefore no exemption should be applied for the check ABAP Language Version (Syntax) in this case.
Figure 5: Example for implementing a non-released BAdI
Use ATC Exemption Browser to monitor the usage of standard ABAP
The ATC Exemption Browser (in the SAP GUI transaction ATC) will provide you an overview about the state of your system with regards to clean core. You will get an overview about all exemptions that were created in your system to allow the usage of standard ABAP and not released APIs.
The following ATC Exemption Browser screenshot demonstrates the overview of the exemptions with regard to the exemption use cases described above:
Figure 6: ATC Exemption Browser
The first exemption relates to the Use Case 1: Implement a custom wrapper for a missing released API, the second and third exemptions are valid for the Use Case 2: Extend an SAP GUI based Dynpro application and finally the fourth and fifth exemptions are relevant for the Use Case 3: Implement a non-released BAdI.
The icons in the Object Scope column represent the scope of the exemption respectively:
| Icon | Exemption Scope | Description |
 | Finding | Exemption is valid for a single finding |
 | Package | Exemption is valid for all objects of a package |
 | Object | Exemption is valid for a single object |
Use ATC baseline for legacy code
In case you do not start with a greenfield SAP S/4HANA system and you have legacy custom code in place the usage of ATC exemptions is not the best choice to setup the ABAP Cloud development model for your legacy code. We recommend setting up an ATC baseline for all findings in legacy code right before you start with new developments. Just execute an ATC mass run over your legacy code with the ATC checks variant ABAP_CLOUD_READINESS and create a baseline out of the findings of the run. If necessary the findings in the baseline can be anytime displayed and analyzed. For more details about ATC baseline see also the blog Remote Code Analysis in ATC – Working with Baseline to suppress findings in old legacy code. The benefit of creating a baseline is that initially developers are not blocked because all initial findings on legacy objects are exempted via the baseline. Your new developments are controlled from the beginning via ATC and the above-mentioned ATC exemptions handling.
- SAP Managed Tags:
18 Comments
| User | Count |
|---|---|
| 13 | |
| 10 | |
| 7 | |
| 6 | |
| 6 | |
| 6 | |
| 6 | |
| 6 | |
| 6 | |
| 5 |
