In May 2023 we released the last major update regarding ABAP Cloud and SAP S/4HANA Extensibility. One important part of these updates are the Cloud API Enablement guidelines. Meanwhile we also have a tutorial for Cloud API Enablement.
In this blog post I will summarize frequently asked questions regarding the Cloud API Enablement guidelines that we received in the last months. I will update this post over time to reflect incoming Q&A.
Questions
Answers
How can I enable existing SM30 customizing in Tier 1 coding?
Create a CDS view wrapper on top of the customizing table. General guidance regarding the development of business configurations in the context of ABAP Cloud is provided in the Extensibility Guide in chapter 4.6.
Can I enable DDIC search helps for the usage in ABAP Cloud?
DDIC search helps are not and will not be part of ABAP Cloud. DDIC search helps are tightly integrated into Dynpro programming and SAP Gui UIs. With the change towards CDS, RAP and Fiori in ABAP Cloud these search helps cannot be used out of the box anymore. Instead, DDIC search helps shall be replaced by CDS based search helps. If a coding-based search help shall be reused, the coding needs to be encapsulated and can be wrapped. Summary:
- Table/View based DDIC search help: wrap the table with a CDS view, build the search help CDS view in tier 1 based on the wrapper CDS.
- code-based search help: wrap the function module executing the search help by a wrapper class, build a custom entity as search help in tier 1.
Can I use tier 2 also to mitigate missing remote APIs?
Tier 2 is suited for local API enablement. Custom remote APIs shall be developed in tier 1 using ABAP Cloud. In case a local SAP API is missing for your implementation, you can mitigate this using tier 2.
I get error TR461 ("Package must be assigned to the software component HOME") when trying to create Z-packages in a software component for tier 2. What’s wrong?
Caused by a bug, solution in SAP Note 3319469
What shall I do if a released CDS view does not contain all fields that I need?
General guidance is given in the blog post Custom Fields in S/4HANA: Key User versus Developer Extensibility. If the field is required in existing SAP applications and processes, use key-user extensibility. If the field is required in developer extensions (custom apps, services, etc.):
- If the CDS view is enabled for extensibility (C0 release): Create an extension in tier 1.
- If it is not enabled for extensibility: Create a wrapper CDS view in tier 2 over the required table. Create a custom CDS view in tier 1 that joins the released view with the wrapper view to combine fields of both views.
Please also have a look at this tutorial: Extend Released Data Sources...
Can I wrap a conversion exit to be used in ABAP Cloud?
No. In ABAP Cloud only ALPHA and ISOLA can be used. Conversion exits are problematic in general, more information is provided here.
Can I use a BAPI wrapper also for a new Fiori UI?
BAPIs with validation/simulation flavor can be used in Fiori UIs and Web APIs. The validate flavor shall be executed in the validation phase of the RAP BO, the productive flavor in the save. BAPIs without a validation/simulation flavor are not recommended to be used in Fiori UIs. Reason: The authorization checks and validations are only executed in the late save phase, where there is no possibility anymore for a controlled rollback to the UI. More information is given here.
Are wrappers in tier 2 considered Clean Core?
On-Stack extensions developed in tier 1 using ABAP Cloud follow Clean Core principles. Wrappers developed in tier 2 help you to do your development in tier 1 by leveraging existing classic APIs. Tier 2 is not an alternative development layer. Details of when a wrapper in tier 2 itself is considered Clean Core are currently under investigation. More information will be provided soon.
Can I combine several BAPIs (Create, Update, Delete) for the same business object in one wrapper?
Technically it is possible to combine multiple classic APIs within one wrapper. The challenge you face when combining multiple classic APIs in one wrapper is that if a released API is provided for only one of the classic APIs, you will not be able to retire the wrapper, since it still makes use of other classic APIs. Moreover, there is the danger to mix up different functionalities in your wrapper leading to loss of clarity. Hence, combining classic APIs in wrappers is not recommended in general and should be done with caution. For the special case of multiple BAPIs for different operations on the same business object (like create, update, delete), however, it is acceptable to combine them in a single wrapper to save multiple declarations of types and to reduce the pure number of wrapper objects.
Can I wrap non-released BAdIs in tier 2?
No, nothing to be done in tier 2 for BAdIs. Released BAdIs are implemented in tier 1 using ABAP Cloud, non-released BAdIs are implemented in tier 3 using classic ABAP.
Shall I wrap dictionary artefacts in tier 2?
No. For usage in ABAP Code use local type declarations in wrapper interfaces and classes to decouple from dictionary artefacts. For usage in custom dictionary artefacts in tier 1, use the released SAP artefacts or create own ones.
An SAP data element that I need for my development in ABAP Cloud is not released. What shall I do?
Guidelines regarding data elements are documented in SAP Note 3365744.
I declared a local type in my wrapper interface based on an SAP structure. When accessing components of this type in my ABAP Cloud code, I receive a syntax warning that the usage of this element is not permitted. What's wrong?
The warning is a false-positive. More information and correction in SAP Note 3362119.
When releasing my wrapper class I get the warning "Instance creation of class XYZ should be private". Why?
With this warning we want to enforce Clean ABAP development guidelines for instance creation of your wrapper classes/interfaces via factory methods or factory classes.
