- SAP Managed Tags:
What are the different tiers for Clean Core development
The basis of Clean Core development for S/4HANA private Cloud customers is the S/4HANA extensibility guide and the 3-Tier model:
- Tier-1: Cloud Extensibility Model. This model comprises custom development objects strictly following ABAP Cloud rules. Besides objects in their own software component, they can only access released objects. It can be either on Stack ABAP Cloud development, or side-by-side extensions on SAP BTP.
- Tier-2: Cloud API Enablement. This is the custom SAP interface developed in classic ABAP, that mitigates missing public SAP APIs. ABAP Cloud rules are enforced by the ATC (ABAP Test Cockpit) both for the development of wrapper objects, as well as the access to non-released SAP development objects.
- Tier-3: Classic ABAP Extensions. We distinguish between new and old objects created here. For new objects in tier-3, ABAP Cloud rules shall be enforced by ATC. Existing objects in tier-3 may not follow the ABAP Cloud rules and can be exempted using a base line approach in ATC.
Picture source: SAP learning hub
Where are we in the concept of Clean Core for EWM in general?
For Tier-1 on-stack development, it is required to use only C1 released SAP APIs and extension points. For Tier-1 side-by-side Cloud development, C2 released SAP APIs are needed. Refer to the further linked document at the end of this blog for definition and differences between C1 and C2 release contracts.
For example, in EWM PCE, the following Odata V4 APIs are already available:
- Warehouse Storage Bin – read
- Warehouse Fixed Bin Assignment
- Handling Unit
- ..etc. Full list please refer to the SAP Business Accelerator Hub
Admittedly, there are not enough C1 released APIs in EWM PCE for on-stack custom extensions. We are aware of that, and we are working on it in our future roadmap.
Alternatively, in cases where such a C1 API does not exist for Tier-1 on-stack development, customers/partners can still create their own wrapper APIs in Tier-2 based on classic ABAP APIs. These wrapper APIs can be released and used in Tier-1 on-stack developments. We have also talked with our customers regarding this Tier-2 approach, and we know there is project effort to enable such, as all standard DDIC objects used in the /SCWM/IF_API* interfaces will also need to be copied, etc.
In future, we will be working on more guidelines to provide our customers and partners with a list of classic stable EWM APIs in the cloudification repository, where content from other SAP application is already available. This will be published in the Business Accelerator Hub, and then can be used as reference for Tier-2 development in the future. This hopefully can be achieved later this year.
In general, Tier-3, classical custom development shall be used only in a controlled way to minimize the risk of potential upgrade issues. SAP note 2782080 provides a PDF document with several extensibility guides for specific areas of EWM. All these specific EWM extensibility guides offer upgrade safe extensibility methodologies, which have been proved in EWM on-premises since 10+ years and are also valid for S/4HANA private cloud edition. In addition, the above mentioned cloudification repository with EWM content that mentioned previously, will serve the same purpose to provide guidance for future Tier-3 custom development, as like the guidance for Tier-2 developments.
Again, our major goal for clean core concept from EWM PCE product perspective, is to ensure the future upgrade stability for our customers, by using stable standard APIs for on-stack developments.
What about custom development in RF framework?
EWM PCE customers can still implement classic ABAP in custom development in the RF framework, provided that the coding is according to the technical ABAP code guidelines. This would ensure upgradeability in the future. Refer to the previously mentioned SAP note for the detailed guidelines.
It is possible that when you run ATC checks, you can make sure that you use the check for “classic ABAP, ABAP Cloud rules not enforced”. This is because the variant “ABAP Cloud rules” in ATC checks, does not support SAPGUI screens, and SAPGUI technology framework is used in EWM RF framework.
Are there any other custom developments still allowed in EWM PCE?
This is a very good question. We do have some additional use cases where traditional custom developments are applied. One example is around the Warehouse Monitor, or our monitoring framework. We will not forbid 100% custom development in such areas, as long as there is sufficient business reason behind it, and the custom development is in accordance with the ABAP coding guidelines.
What about classic BADI implementation in EWM PCE?
In short, EWM PCE customers are still allowed to use classic BADI implementation, provided that the custom codes are in accordance with the ABAP code guidelines. Our main goal is to ensure upgrade stability and avoid potential issues. EWM is using this methodology since many years by providing the guidance of SAP note 2782080 and providing more than 700 BADIs as the upgrade safe “APIs”, for on-stack developments.
There are many new Cloud BADIs released in Public Cloud, why can we not reuse them in private Cloud?
This is because technically, the public cloud C1 released BADIs (in /SCWM/ES4_CORE_PTS) are different from the “Classic BADIs” (in /SCWM/ES_CORE_PTS) that we define in EWM PCE/OP. The set of new cloud BADIs has a new design in the BADI interfaces, the C1 released CDS views, and the remote APIs speak the same ‘language’ which is the new type system of GFNs(global field names).
What do we do in future in order to keep a close alignment of SAP’s Clean Core strategy as an EWM customer?
First of all, we would recommend our EWM customers to get a clearer picture on what we aim for clean core and make sure that we all understand the specialties in the EWM case. Of course, we encourage our customers to try out our available APIs from SAP Business Accelerator Hub and provide us with feedback on the potential gaps that are identified in your projects. We are keen to improve them, and we are working on it. Secondly, for custom developments, please check in the future (when available) the cloud repository for stable standard APIs and only use them for custom developments if possible. Finally, carefully think about the business necessity of having certain custom processes and keep in mind on the future efforts that it might introduce in the upgrades, such as regression tests, redesign efforts, and etc.
FURTHER LINKS TO READ:
ABAP Language Versions, Release Contracts and Released APIs
Launching the RISE with SAP Methodology Dashboard for Your SAP Transformation Journey
2 Comments
| User | Count |
|---|---|
| 10 | |
| 8 | |
| 6 | |
| 5 | |
| 4 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 |
