Evaluating Special Considerations for SAP S/4HANA Cloud Private Edition and SAP S/4HANA Flashcards
How do software updates differ between SAP S/4HANA Cloud Public Edition and Private Edition?
In SAP S/4HANA Cloud Public Edition, updates run automatically and simultaneously for all customers, while in SAP S/4HANA Cloud Private Edition, updates are customer-specific and not automatic.
What are the main rules for extensibility in SAP S/4HANA Cloud Public Edition?
Modifications of SAP objects are not permitted.
Extensions must be separated from SAP code.
Only released APIs (local or remote) and extension points are permitted.
Why is it recommended for customers to use the ABAP Cloud development model even in SAP S/4HANA Cloud Private Edition or on-premise installations?
Using the ABAP Cloud development model facilitates smoother migrations to SAP S/4HANA Cloud Public Edition and minimizes disruption during upgrades.
What happens if the ABAP Cloud development model cannot be used?
Classic extensibility is still available and supported, but it can lead to difficulties and higher costs in future migrations and potentially more disruptive upgrade projects.
Are the considerations for extensibility the same for both SAP S/4HANA Cloud Private Edition and on-premise installations?
Yes, the considerations apply equally to both, and distinctions will be explicitly stated if necessary.
What are the three tiers in the SAP S/4HANA Cloud extensibility model?
Tier 1: Cloud Extensibility Model
Tier 2: Cloud API Enablement
Tier 3: Classic ABAP Extensions
What does Tier 1 include and who can use it?
Tier 1 includes:
Only approved ABAP Cloud object types
ABAP Cloud language enforced via syntax checks
Usage of released APIs enforced via syntax checks
Development using ABAP tools for Eclipse
This tier is available to both SAP S/4HANA Cloud Public Edition and Private Edition customers.
What is unique about Tier 2 and who can use it?
Tier 2 is only available for SAP S/4HANA Cloud Private Edition. It allows the use of non-released APIs through custom wrappers while adhering to ABAP Cloud development rules. ABAP test cockpit checks ensure compliance, and customers can request new APIs via the Customer Influence Channel.
Why should Tier 3 be avoided if possible?
Tier 3 allows classic ABAP extensions with no restrictions on language or object types, but it carries a high risk of software upgrade disruptions. SAP recommends using Tiers 1 or 2 to minimize these risks.
Can you provide examples of use cases for each tier?
Tier 1: Adding a custom field on a database table, implementing a released SAP BAdI, creating a custom ABAP RESTful application programming model-based SAP Fiori app.
Tier 2: Creating a wrapper class around non-released SAP objects (e.g., BAPI), creating a wrapper CDS view for non-released SAP tables or CDS views.
Tier 3: Implementing a non-released BAdI, extending SAP Fiori apps based on legacy UI technology, modifying SAP objects.
What should customers do after software upgrades?
After upgrades, customers should reevaluate all developments. If any development is no longer necessary due to new releases or standard functionality, it should be refactored or retired.
What is the first step in setting up for tier-based development?
The initial setup includes configuring software components, creating ABAP packages, and setting up user authorizations.
How are software components set up for tier-based development?
Using the report RSMAINTAIN_SWCOMPONENTS, administrators create and configure software components classified as either “ABAP Cloud” or “ABAP Classic”. ABAP Cloud components follow the cloud development model, while ABAP Classic components can include any type of object.
What is a structure package and why is it important?
A structure package is created for each software component to facilitate the organization of customer software projects. Development packages are created under these structure packages to hold all needed development artifacts.
What authorization objects are important for tier-based development?
The key authorization objects are S_CTS_ADMI for administrators and S_ABPLNGVS for controlling developer permissions. These are managed using transactions SACF and PFCG.