Experts, before getting into the topic, let’s understand the motivation and purpose of the new modern extensibility options defined by the SAP for SAP S/4HANA Public, On-premise, and PCE editions.

Motivation

SAP S/4HANA extensibility strategy update comes with lots of benefits for traditional ABAPers and overall benefits for operating in a cloud-first environment. There is a lot of confusion on embedded ABAP, BTP ABAP, ABAP Cloud, Standard ABAP, and everything in between. It’s important to convey and understand how SAP is moving away from a monolithic way of developing (SAP ECC era) to a nimble one that is modular and agile.

Extensibility is a key capability of Enterprise Resource Planning (ERP) solutions that enable customers to create a competitive advantage by customizing their business processes and allows partners to enrich ERP with tailor-made solutions. The importance of extensibility has been confirmed by the legacy ERP flagship product SAP ECC and will remain valid for the current and future cloud ERP transformation.

SAP S/4HANA is a front-runner product providing intelligent ERP in the cloud and on-premise. This
blog helps you to provide guidance and advice to choose, implement and use the modern extensibility options correctly for various customer environments (public cloud, private cloud, or on-premise).

The goal is to shift from the classic ABAP extensibility model to an SAP S/4HANA modern extensibility model that allows customers to consume SAP innovations, building future-proof extensions that are ready for the cloud ERP. How do we connect the dots for customers that are on traditional ABAP so they can take advantage of modern innovations? What are S4CORE Extensions? What is Embedded Steampunk, and BTP ABAP environment? How it is different from standard ABAP?  Where can we use SAP Build Apps with ERP? What is Side-by-side BTP Extension? and more questions. This place will help you to understand the purpose, guide you to select, and make you comfortable and ready for the journey from the current state to the future state ERP.

Contents

1. Current customer situation
2. Challenges with the classic extensibility model
3. What are the extensions?
4. Why does SAP S/4HANA need extensibility?
5. What and why about the clean core concept?
6. What is the new extensibility model?
7. SAP S/4HANA Extensibility Options
   1. Key User (In-app) Extensibility
   2. On-stack Developer Extensibility
   3. Side-by-side Extensibility
   4. Classic Extensibility
8. 3-tier extensibility model for SAP S/4HANA On-premise and PCE editions
9. How to handle Classic Custom Code Migration?
   • Classic RICEFW Vs Modern Extensibility With BTP
10. Decision Matrix for Extensibility Options

Current customer situation

Our business is doing fine with the classic ABAP extensions and customizations. We have spent a huge amount of effort in building the custom processes as per the business demands. Our system has become complex over time due to customizations and enhancements. Classic extensibility is extremely powerful and flexible to meet every single requirement of the business and keep them happy regardless of the system that has become over time inefficacious and substandard performance. We are facing challenges in terms of high maintenance IT cost and lack of innovation. Our goal is to become Intelligent Enterprise with digital ERP transformation. Reduce the costs, modernize to keep up with the competition, and bring value from our operational data.

Challenges with the classic extensibility model

1. High TCO for system maintenance and software upgrades.
   • Extensive planning and regression testing. Making sure the upgrade does not break the system.
   • Software changes lead to high adoption efforts and high upgrade efforts
   • SAP Standard code and Customization are not clearly separated, there is no interface.
   • Classic extensibility adds complexity to the SAP Core and averts from adopting agile practices and standardized business processes.
   • Redundant data and unused custom code living within the core ERP system.
   • Example: You have used an SAP object that is not whitelisted by SAP in your extension. After an upgrade, the used SAP object has been changed or deleted. Now you will have to adjust the extension thus upgrade is delayed and the speed of innovation is decreased.
2. The slow rate of innovation speed as the system has been modified via standard and custom codes.
3. Limitations and struggle to reach the fast-changing business needs to compete and lead.

What are the extensions?

• Software engineering principle that allows for enhancements without impairing existing system functions.
• Extensions can be the addition of new functionality or through modification of existing functionality.
• Extensibility is a measure of the ability to extend and the effort required to implement an extension.

Why does SAP S/4HANA ERP need extensibility?

• Extend user experience of existing processes and provide controlled access for additional user groups
• Extend business process for business process optimization or innovation
• Extend data insights by consolidating and combining data in one central place
• Extend the ecosystem by creating and operating a Software as a Service (SaaS) application and selling it to multiple customers

ERP Extensibility

What and why about the clean core concept?

Let’s understand the meaning behind the Clean + Core.

Clean… up-to-date, transparent, unmodified, consistent, efficient, and cloud compliant.
Core… the main aspects of an ERP system are extensibility, processes, data, and integration.

The clean core is an extension methodology concept with the basic goal i.e.  Extensions should not break an upgrade and upgrades should not break an extension. Follow the rules:

1. Fit-to-Standard: Leverage SAP standard processes where possible.
2. Apply a zero-modification policy from the project’s first day.
3. Leverage the full potential of new extension options (In-App, Developer, or Side-by-Side ) which fit your needs best.​Use whitelisted and released APIs.​
4. Eliminate enhancements that are redundant to standard code and functionality, as well as “clones” of standard code.​
5. Think and act like moving SAP S/4HANA on-Premise to SAP S/4HANA Cloud by
   engaging the capabilities and services offered by SAP BTP Extension & Integration Suites for application development and integration.

Some principles when building extensions to keep the core clean.

How to plan and adopt a clean core strategy for an SAP S/4HANA ERP transformation project?

• Greenfield project: Start with the stay clean strategy to bring system the system closer to standard processes, and keep the system up-to-date, including modern extensibility and integration options as well as data governance.
• Brownfield project: Start with the get and keep clean strategy to bring system the system closer to standard processes, including the transformation from traditional custom code to modern extensibility, integration capabilities, and duplicate data cleansing.

Understood! Tell me the benefits of it:

1. Reduce TCO (Time, Effort & Cost)
   • Faster deployment and Ready for a smooth upgrade.
   • Reduce test efforts for business users and Adoption efforts for developers.​
   • IT service providers can offer upgrade projects at a fixed price.
   • No costly maintenance for unused artifacts and data.​
2. Innovation at Market Speed.
   • Captivate innovation delivered by SAP.
   • React fast to changing business requirements.
3. Data to value.
   • Consistent data allows for reliable forecasting and predictions for confident decisions.
4. Become cloud-ready and Competitive at any point in time.
   • like moving SAP S/4HANA on-Premise to SAP S/4HANA Cloud.

Above IT and business benefits of keeping SAP core clean, makes you accelerate innovation, optimize and automate the process, be agile for rapid changes, be in the driver’s seat, and lead the competition. Let’s get into the main topic now.

Learn more, Get your organization in shape: Keep a Clean Core with SAP Business Technology Platform.

What is the new extensibility model?

This new SAP S/4HANA Cloud extensibility model, first introduced in SAP S/4HANA Cloud public edition, is now available and recommended in all SAP S/4HANA editions, to achieve the following:

• Smoother upgrades everywhere.
• Diminutive to no extending testing efforts.
• Simplified adoption and LOBs drive innovation timelines.
• Standardized and optimized business processes.
• Pave the way to the cloud.

Let’s understand the various options/tools available to create stable extensions in the SAP S/4HANA ERP system by following the clean core principle, even when the classic extensibility model is still available for the on-premise and private editions and recommendations are NOT to adopt it.

SAP S/4HANA Extensibility Model Options

SAP S/4HANA New Extensibility Model Options

The new extensibility model in SAP S/4HANA can be divided into three parts:

1. Key User Extensibility in the SAP S/4HANA Core
2. Developer Extensibility in the SAP S/4HANA Stack
3. Side-By-Side Extensibility on the SAP Business Technology Platform

1. Key User (In-app) Extensibility

SAP Fiori extensibility apps(tools) help you to customize simple application changes with a no-code/low-code paradigm. The key user extensibility is designed mainly for key users or citizen developers (typically a user from the business department). Key users typically have no or only limited coding skills and therefore do not need a fully integrated development environment, with capabilities such as versioning, dependency handling, refactoring, or debugging. Development skills are recommended for developing custom business objects and adding business logic using the cloud ABAP web editor.

The main argument for using key user extensibility is that simple extensions can be realized quicker than with developer extensibility because of the communication overhead between the business expert (responsible for the specification of the extension, and later for testing and approval) and the developer (responsible for development and developer test) is avoided.

How to enable Key User Extensibility apps?

• S/4HANA: The Key User Extensibility apps are provided as part of the business catalog SAP_BASIS_BC_EXT, this catalog needs to be assigned to a role in PFCG.
• S/4HANA Cloud: The Key User Extensibility apps are provided as part of the business role SAP_BR_ADMINISTRATOR.

Find other Key User Extensibility apps:

1. Go to the SAP Fiori apps reference library
2. Search for the title of the app you want to configure
3. Choose your product (S/HANA Cloud or S/4HANA)
4. Change to the tab Implementation

Key user Extensibility Pattern Architecture

Key User Extensibility Tools

2. On-stack Developer Extensibility

This option bridges the gap between the key user and side-by-side extensibility options. On-stack developer extensibility is intended for development projects requiring proximity to or coupling with SAP S/4HANA data, transactions, or apps using a restricted ABAP version. The requirements of the extension project go beyond the scope of key user extensions and therefore require full access to development capabilities like debugging, refactoring support, version control, etc.

• ABAP RESTful Application Programming model (RAP) to build.
• Eclipse-based IDE (ABAP Development Tools) with a debugger, troubleshooting, and testing tool support
• A cloud-optimized subset of ABAP language.

In contrast to side-by-side extensions, on-stack developer, and key user extensions are developed and run on the same software stack as the underlying SAP S/4HANA system. This allows extensions to direct access SAP S/4HANA logic and data via SAP extension points(BAdis), local public CDS views, SAP-released APIs, or SQL queries.

On-stack means you are using the new ABAP Cloud syntax to build upgrade-safe extensions inside your core ERP system. So ABAP RAP model fits perfectly here. You must only use released APIs and the stricter syntax check of ABAP Cloud. (Note that to fully utilize this you need to be on a recent version of S/4HANA >= 2022 though it’s still possible to follow this system with older releases.) Note that ABAP Cloud just means a “cloud-ready syntax for ABAP”. You will see it is also called “Embedded Steampunk”. It is different from the ABAP environment on BTP (which also uses ABAP Cloud as the ABAP syntax).

Developer Extensibility Pattern Architecture

ABAP for Cloud Development

Developer Adaptation Project

Adaptation projects are currently only supported on the S/4 HANA on-premise ABAP system or the Cloud Foundry environment, for the S/4HANA cloud it may be supported in the future, refer to the product roadmap for more details. SAP S/4HANA cloud extensibility explorer.

3. Side-by-side Extensibility

Extensions running on the separated (side-by-side) SAP Business Technology Platform (SAP BTP) for all other loosely-coupled extension scenarios integrating with the extended SAP S/4HANA system. This model is the preferred option for scenarios that are loosely coupled to SAP S/4HANA data, transactions, or apps. Explore how you can develop and integrate side-by-side extensions to enhance applications, processes, and experiences.

Develop custom code side-by-side extension and SaaS solutions using ABAP RESTful Application Programming Model (RAP) and SAP Cloud Application Programming Model using Java, or Node.js. Use no-code/low-code applications like SAP Build Apps, Process Automation, and Build Workzone to build custom applications, process automation, and workflow management. One main difference compared to the on-stack extensibility model is that accessing business objects of SAP S/4HANA Cloud is only possible using remote APIs which are published in the SAP API Hub.

Side-by-side Extensibility Pattern Architecture

3.1 PRO-CODE

ABAP RESTful Application Programming Model (RAP)

New ABAP programming model for efficiently building cloud-ready enterprise apps and upgrade-stable extensions on SAP BTP ABAP environment, SAP S/4HANA Cloud, SAP S/4HANA Cloud ABAP environment, and SAP S/4HANA 1909 and higher.

• RAP is a powerful framework consisting of a set of concepts, tools, and languages.
• A strategic long-term solution for the ABAP developments.
• Help developers to build innovative, cloud-ready, enterprise applications of different domains, such as transactional and analytical applications.
• RAP offers a standardized development flow based on Core Data Services (CDS), the ABAP language, and business services in the modern, Eclipse-based ABAP Development Tools (ADT).
• RAP is available on
  • SAP BTP ABAP Environment (Steampunk), provides the ABAP platform as a service (PaaS) on SAP BTP. ABAP-minded customers and partners can reuse their ABAP skillset to build new cloud solutions, or to transform already existing on-premise ABAP assets to the cloud.
  • SAP S/4HANA ABAP Environment (Embedded Steampunk)

High-level RAP Programming Model

SAP Cloud Application Programming Model(CAP)

An open and opinionated framework of languages, libraries, and tools for building enterprise-grade services and applications. The CAP framework features a mix of broadly adopted open-source and SAP technologies

• CDS is the backbone of the SAP Cloud Application Programming Model (CAP) to build data models, defining the UI layer with those definitions (annotations)  and service definitions on a conceptual level.
• CAP-based projects benefit from a primary focus on the domain rather than delving into overly technical disciplines.
• SAP programming model is compatible with any development environment, but recommend using the SAP Business Application Studio.

High-level CAP Programming Model

SAP CAP Vs RAP model, which one to choose? The choice of the programming language for your extension – ABAP, Java, or JavaScript is decisive.

3.2 LOW-CODE

SAP Build Apps

Evolution of SAP AppGyver is a professional application development solution designed for anyone to quickly create apps without code regardless of role or skill level.

• Build Full-Stack Enterprise-Apps in Minutes – Absolutely Zero Coding Required
• Drag-and-drop the user interface and Create any logic without code.
• With SAP Build Apps everyone can become a full-stack cloud developer.
• Easily add your own data integrations or get started with some of ours.
• Users can design both mobile and web applications with a pixel-perfect design using the drag-and-drop functionality and a rich component library.

Note: SAP Build Apps is still evolving and due to limitations on the availability of different hyper scalers, other low code and pro code solutions become equally important.

SAP Build Process Automation

• Users can create forms, manage decision logic, and build, adapt, and organize process flows with drag-and-drop simplicity.
• Automate repetitive manual tasks – such as copy-and-paste operations, data extraction, data entry, and data creation – using no-code and low-code capabilities or the built-in automation recorder.
• Built-in AI capabilities enable intelligent document processing –like extracting data from structured or unstructured documents to transfer it to your enterprise systems for processing – without needing data scientist support.
• Simplifies process and task automation so business users can unleash their process expertise without writing code.
• Adapt, improve, and innovate business processes with no-code workflow management and robotic process automation capabilities.

SAP Build Work Zone

• Users can create beautiful, custom business sites for themselves, colleagues, suppliers, customers, partners, etc., without writing any code.
• Business sites created with SAP Build Work Zone provide central access to relevant applications, processes, and information.
• Maximize productivity by enabling guided experiences and knowledge sharing.

4. Classic Extensibility (Not available in SAP S/4HANA public edition)

This is the traditional way of the SAP ECC or S/4HANA on-prem enhancement for RICEFW ABAP custom object development like user-exits, customer-exits, classic BAdis, implicit/explicit enhancements, BTE, module-pool, etc using transaction code SE38, SE80, SE11 (SAP GUI, Eclipse ADT).

Basically using non-released objects from S/4HANA and an ABAP standard version (non-restricted). No restriction on the extension, it even allows you to modify the standard SAP code itself. Hence, upgrade effort increases and agility/innovation speed decreases.

Classic Extensibility Pattern Architecture

In S/4HANA On-Premise –The classical extensibility option is available but not recommended.

Available extensibility options for SAP S/4HANA editions

Key user, developer, and side-by-side extensibility are available for public and on-premise editions while the classic extensibility model is available only for an on-premise edition.

3-tier extensibility model for SAP S/4HANA On-premise and PCE editions

3-tier extensibility model

As shown in the above diagram, SAP extensions belonging to 3 different tiers (or levels) as follows to keep the core clean:

TIER 1:

The default choice for all new extensions following the SAP S/4HANA  extensibility model.

• ON-STACK Extensibility( Key user and Developer): ABAP for cloud development and Key user tools
• SIDE-BY-SIDE Extensibility: Cloud development on SAP BTP

TIER 2:

Cloud API enablement: mitigation of missing local public APIs or extension points. What happens when you need an API or extension point that is NOT released by SAP?

Well, that is where TIER 2 comes as an option. You can create custom APIs here and use some more “classic” code like un-released function modules etc. Kind of custom wrappers for non-released SAP objects that are built and released for cloud development so that they can be used in TIER 1.

You can develop here in such a way that you can swap TIER 2 code whenever SAP provides a public local API, and the custom wrapper API(TIER 2 code) can be removed.

In this sense, TIER 2 serves as an extension to TIER 1 which will follow the same ABAP cloud development model besides the usage of the wrapped non-released SAP object.

TIER 3:

Legacy Development: classic extensibility based on classic ABAP custom code used from ECC’s old days that is not supported in the ABAP cloud development model. The goal and recommendation are to avoid and reduce developments in this tier to minimize the risk of upgrade issues.

Now obviously it would be first-choice to have everything in TIER 1, yet it’s also not entirely practical in today’s complex business environment. The go-forward approach you must follow is to try and complete everything with TIER 1 and use TIER 2 to handle missing APIs etc. While for TIER 3 legacy code – look to retire unused code or lift it up the tiers( Classic ABAP to ABAP Cloud).

Guidance on how to reduce the impact of such extensions.

1. Using classic structure extensions are extensions of the data model of database tables, structures, CDS views, and services (OData, SOAP). A general thumb rule is no modifications to the corresponding SAP objects.
   • Data dictionary (DDIC)
     • Append fields to non-released structures and database tables using existing customer includes (CI includes) or extension includes (EEW includes).
     • Use domain value appends, search help appends, and search help exits.
   • CDS Views: Use CDS extends and metadata extension
   • OData Services: Use redefinition of OData services. More information.
2. Using classical business logic extension techniques, follow the below recommendations.
   • BAdIs: even if a BAdI is not released for usage in cloud development it is a good choice for customers to extend the application. Most likely the BAdI will be released with an upcoming release or will be replaced with a released BAdI as a successor.
   • User exits (VOFM, SAPMV45A): user exits are coding parts from SAP that are stable and typically do not lead to issues after an upgrade. Technically the custom code here is treated as a modification. It is planned that BAdIs will replace these extensions over time.
   • Customer exits (SMOD/CMOD): customer exits are the predecessor technology of BAdIs and will be replaced. Anyhow you can still use them in exceptional cases where no BAdIs exist yet in the application.
   • Explicit enhancement spots: these are extension points that were mainly created by SAP to enable industry-specific adaptations to the core ERP applications. We recommend using them only in exceptional cases to include custom-defined BAdIs into the SAP core. You should not directly include the extension code in the enhancement spot.
   • Implicit enhancement spots: this extension technique is very similar to modifications and should therefore not be used to extend the core applications.
   • Clones are copies of SAP standard objects. Now the original objects continue receiving code corrections and additional functionality with system updates, while clones don’t. Unlike modifications and enhancements, clones are not detected during upgrades or system conversion. This is why they generally represent a risk to system stability and should be avoided.
3. Modifications of SAP core objects should be avoided completely.
   • If they cannot be prevented, we strongly recommend using the modification assistant. This makes the adjustment of the modifications after an upgrade manageable in contrast to free-style modifications. Moreover, the ATC check Search for customer modifications allows one to establish governance for this purpose.

An overview of setup, tools, and rules in the three tiers represented by software components is given in the table below.

How to handle Classic Custom Code migration?

• Analyze the classic ABAP custom code with the Custom Code Migration App to estimate the impact. For step-by-step guidance, read the blog “Custom Code Analysis for SAP S/4HANA
  with SAP Fiori App Custom Code Migration”
• Detect unused classic ABAP custom code based on usage analysis and retire it during the conversion. Removing obsolete code significantly reduces the effort for custom code adaptation. At the same time, this is certainly a first step toward a clean digital core.
• Adapt the classic ABAP custom code by using ABAP Test Cockpit and automate the adaptation with quick fixes.

• Adapt usage of SAP objects based on SAP S/4HANA readiness ATC checks, the Simplification Database, and the Quick fixes in ADT Eclipse IDE.
• Usage of SQL Monitor to detect performance optimization candidates.

Classic RICEFW Vs Modern Extensibility With BTP

Decision Matrix for Extensibility Options

*X – Not applicable for S/4HANA Public Cloud

The clean core is a journey to be better, more reliable, and more efficient. You can not just switch it on overnight. 😉

Summary

• SAP S/4HANA provides tailor-made modern extensibility options for all editions.
• Staying close to the Clean Core Index is the extensibility strategy all customers should aim for.
• Key-user tools allow the creation of tightly coupled extensions and adapt the SAP S/4HANA applications with no or low-code skills.
• Side-by-Side is an extensibility model that supports a clean core index while adding multiple additional values.
• Establish a common development model for custom ABAP code deployments.
• An embedded ABAP environment offers values for both greenfield and brownfield projects.
• Retire unused code, Custom code migration and developments with modern cloud ABAP is a go-forward strategy to become cloud competent, modularized, and agile for business needs.

References:

1. https://www.sap.com/documents/2018/08/7a62516c-157d-0010-87a3-c30de2ffd8ff.html
2. https://www.sap.com/documents/2022/10/52e0cd9b-497e-0010-bca6-c68f7e60039b.html
3. https://extensibilityexplorer.cfapps.eu10.hana.ondemand.com/ExtensibilityExplorer/
4. Custom Extensions in SAP S/4HANA Implementations – A Practical Guide for Senior IT Leadership