Introduction
Extensibility is a key capability of SAP ECC and SAP S/4HANA. It enables customers to create a competitive advantage by customizing their business processes and allows partners to enrich core ECC or S/4HANA with tailor-made solutions
During the last decades SAP’s on-premise customers and partners have mainly used classic ABAP extensibility to extend their ERP solution. Classic extensibility allows ABAP developers to use and even to modify all SAP objects. Although, classic extensibility is very powerful and flexible, it is no longer a good option in today’s cloud world.
In-lined with cloud strategy, SAP S/4HANA provides a new upgrade-stable cloud extensibility model that clearly separates SAP code and extensions via public SAP APIs and SAP extension points.
In this blog we will understand:
- What is S/4HANA Extensions and why do we need them?
- How Classic Extensions has been working for traditional SAP ECC system?
- Why Classic Extensions are no longer a good choice in cloud world?
- What is Clean Core Paradigm?
- What are new extensibility options in SAP S/4HANA?
- As an SAP partner or customer how should you choose the right extensibility option?
- How should SAP S/4HANA On-Premise and Private Cloud customers should switch to new extensibility model?
Target Readers
SAP partners and customers who are either building a new extension on SAP S/4HANA or migrating existing extensions from traditional SAP ECC to SAP S/4HANA.
SAP consultant/architects who need a holistic understanding of SAP S/4HANA extensibility model.
Note: Since I have covered all the major concepts related to SAP S/4HANA Extensibility, this blog is slightly lengthy. But I am sure that once you finish this blog, you will have a crystal clear understanding of the SAP S/4HANA Extensibility.
Let’s get started!
What is an extension in S/4HANA and why do we need them?
We all know that standard SAP software doesn’t cover the scope of all the company business processes. There is always a need for a new app, a new report, or a new functionality. SAP partners and customers have been traditionally building extensions on SAP ECC system using ABAP code. However, with SAP S/4HANA and customer’s digital transformation journey towards cloud, we need a more robust yet loosely coupled extensibility model.
What is Classic Extensibility?
Traditionally, SAP partners and customers have been using classic ABAP extensibility to extend their ERP solution.
Classic Extensibility (aka classic ABAP custom development) in SAP S/4HANA (or in SAP ECC):
- Allows you to use classic development tools and techniques (e.g. transaction SE80, Eclipse IDE, BAdIs etc.)
- Very rich of features and functions.
- Extremely flexible and even allows you to modify SAP code itself.
Drawbacks of Classic Extensibility?
Although, being very powerful, flexible, and popular, classic extensibility has some major drawbacks.
One of them is High Upgrade Efforts!
The missing clear interface between SAP code and extensions might lead to issues in the extensions during upgrades. As a result, upgrades require high planning, regression test, and adaption efforts, which is one of the reasons why customers delay upgrades.
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.
Classic Extension is no longer a good option specially in Cloud World.
Is Classic Extensibility Still Available?
In S/4HANA Cloud automated software updates run for all customers in parallel. Hence classic extensibility is not available there.
In S/4HANA Private Cloud Edition and On-Premise –Classical extensibility is available but not recommended.
What is Clean Core Paradigm?
Clean core is an extension methodology in which
- Extensions are kept strictly separate from the SAP application.
- Extensions access SAP business objects only through well defined, upgrade-stable interfaces
By following clean core paradigm, you make sure that
- Extensions do not break an upgrade and upgrades do not break an extension.
- Extensions do not create a problem when you migrate from SAP S/4HANA on-Premise to SAP S/4HANA Cloud
SAP’s rationale behind the “clean core” paradigm is simple – Allow customers to extend their SAP S/4HANA software while making the software updates eventually non-events.
Benefits of Clean Core Paradigm
Clean core paradigm is the back-bone of S/4HANA new extensibility model. It provides following benefits
Reduce TCO
- Make upgrades non-events from a custom code point of view
- Reduce test efforts for business users
- Reduce adaption efforts for developers
- IT service providers can offer upgrade projects at a fixed price
Speed and Innovation
- Absorb innovation delivered by SAP at a faster rate
- React fast on changing business requirements
Be cloud ready
- Lay the foundation today to move to the cloud from a custom extension perspective
Before we proceed further, let’s quickly revisit some important terminologies that we need to know before understanding the S/4HANA extensibility model.
SAP BTP ABAP Environment (aka Steampunk)
In 2018, SAP added ABAP Environment to the SAP BTP, called SAP BTP ABAP Environment or Steampunk.
Steampunk was actually the internal project name but got quite popular externally.
Steampunk comes with
- Eclipse-based ABAP Developer Tools
- And the ABAP language version ABAP for Cloud Development.
Important points regarding Steampunk:
- The SAP BTP ABAP Environment provides ABAP Platform as a service on SAP BTP.
- ABAP-minded customers and partners can reuse their ABAP skillset to
- Build new cloud solutions
- Transform already existing on-premise ABAP assets to the cloud
- Build new cloud solutions
SAP S/4HANA Cloud ABAP Environment (aka Embedded Steampunk)
The ABAP development environment of SAP S/4HANA is now available for developers to build extensions and known as Embedded Steampunk.
Important points regarding Embedded Steampunk:
- It enables developers to develop and run S/4HANA extension on same software stack as the underlying SAP S/4HANA system.
- It allows extensions to access SAP S/4HANA logic and data via SAP extension points, local SAP APIs or via SQL queries.
- It is based on the same language version (ABAP for Cloud Development) as Steampunk, but in the embedded option.
Since the SAP S/4HANA 2022 release, Embedded Steampunk is also available in SAP S/4HANA Cloud, private edition and on-premise.
SAP S/4HANA Cloud (aka public cloud offering)
SAP S/4HANA Cloud public edition allows customers and partners to use S/4HANA without the need to take responsibility for the cloud infrastructure and operations.
SAP manages all operation and lifecycle management tasks such as continuous feature delivery or providing hotfixes and regular upgrades to new software versions.
Important points regarding SAP S/4HANA Cloud (public offering):
- Runs on SAP Data Center
- Governed and operated by SAP
- 100% managed by SAP as the “cloud provider” with updates automatically pushed to the systems on a timeline defined by SAP
- This is the default public cloud offering
SAP S/4HANA Cloud is a SaaS product from SAP.
SAP S/4HANA Cloud, Private Edition
The major difference between S/4HANA Cloud, Private Edition and S/4HANA Cloud is the ownership of operating the solution.
- With S/4HANA Cloud (public cloud), SAP takes care of operating the solution including the quarterly upgrades.
- With S/4HANA Cloud, Private Edition, the operation of the solution is governed by customer (but can of course be handed over or supported by 3rd party (including SAP)).
Important points regarding SAP S/4HANA Cloud, Private Edition is:
- Single tenant S/4HANA solution
- Preferably for customers who want to do conversion (Brownfield) of their existing SAP ERP System to Cloud-based architecture.
- Customers can choose their infrastructure provider.
SAP S/4HANA Cloud, Private Edition is NOT a SaaS product from SAP.
Now that we have got the important jargons covered. Let’s come to the main topic – What are different extensibility options in SAP S/4HANA?
Extensibility Model in SAP S/4HANA
SAP S/4HANA provides a new upgrade-stable cloud extensibility model that clearly separates SAP code and extensions via mandatory public SAP APIs and SAP extension points.
This cloud extensibility model consists of:
- Key-user extensibility
- Developer Extensibility (Embedded Steampunk)
- Side-by-side extensions on SAP BTP
All these extensibility options use only SAP APIs and SAP extension points that have been released and are stable.
What is Key user (in-app) extensibility?
Key user extensibility empowers business experts to build extensions to SAP S/4HANA Cloud mostly without a single line of code.
Target Persona – Key Users
Key users typically have deep knowledge of SAP business and process but no or only limited coding skills.
Why/Where Key user extensibility is beneficial?
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.
The main argument for using key user extensibility is that simple extensions can be realized quicker than with developer extensibility, because the communication overhead between the business expert (responsible for specification of the extension, and later for testing and approval) and the developer (responsible for development and developer test) is avoided.
Key user (in-app) Extensibility – Use Case Example
With the provided key user tools the key user can achieve the following use-cases:
Adapt the screen layout such as moving fields and field groups, hiding fields, changing labels etc.
Add custom fields to business objects. The custom field is then available in the entire application stack (from the UI to the database tables or for developer extensibility).
Add custom business objects to handle custom data with very little coding efforts.
Add custom logic to validate the custom fields using cloud BAdIs.
Add custom Core Data Service (CDS) views and create new analytical applications (reports, KPIs, …).
What is Developer (on-stack) extensibility?
Some business requirements lead to extensions that are
- Too complex to be built with the in-app extensibility
- Too tightly connected to core S/4HANA data/apps to be built with side-by-side extensibility
That’s where developer extensibility come in. Developer Extensibility is intended for those extensions,
- which requires proximity to or coupling with SAP S/4HANA data, transactions, or apps
- Which require full access to development capabilities like debugging, refactoring support, version control etc., thus cannot be built using key user extensibility
On-stack extensions are developed and run on the same software stack as the underlying SAP S/4HANA Cloud system. This allows extensions to access SAP S/4HANA logic and data via SAP extension points, local SAP APIs or via SQL queries.
Developer (on-stack) extensibility – Programming Paradigm
On-stack developer extensibility allows ABAP developers to connect to an SAP S/4HANA system using the ABAP Development Tools. This feels almost like developing custom ABAP code on an SAP S/4HANA on-premise system.
On-stack developer extensibility offers the standard ADT tool support like ABAP Unit, ABAP Test Cockpit, ABAP profiler, ABAP debugger and the well-known SAP lifecycle management (change and transport system).
However, the extensions are developed using the new ABAP RESTful Application Programming model (RAP), which ensures that no SAP object is modified and that only local public SAP APIs and public SAP extension points are used in the extensions.
Developer (on-stack) extensibility – Use Cases
Typical on-stack scenarios are
- Extensions with frequent or complex SQL access to SAP data (e.g., SQL queries that join customer and SAP data), which cannot be realized easily by remote data access or data replication.
- Extensions that store custom data in the same logical unit of work as the extended SAP S/4HANA app
Example
A customer simplifies the process for recurring employee purchases below a certain amount.
He uses the ABAP RESTful application programming model and SAP Fiori elements to implement an employee self-service app on SAP S/4HANA Cloud ABAP environment.
The app uses local public procurement APIs and extension points to validate, create and release the purchase orders automatically
What is Side-By-Side Extensibility?
Side-by-Side Extensibility allows you to build extensions on SAP BTP. True decoupling between your extensions and SAP S/4HANA enables an independent lifecycle and allows you to build and evolve applications much faster.
SAP BTP offers a wide range of capabilities and services tailored to the needs of enterprise applications.
Major difference compared to the on-stack extensibility model is that – In side-by-side extension, accessing SAP S/4HANA Cloud data is only possible using remote APIs which are published in the SAP API Hub (https://api.sap.com/).
Why to Choose SAP BTP for building Side-By-Side Extension?
SAP BTP has been designed to make it much easier to build and integrate side-by-side extensions for SAP products compared to other generic platforms.
- It is one platform for extending both cloud and on-premise solutions from SAP.
- It provides integration for your extensions on the UX, process, and data levels.
- It offers comprehensive security from the UI to the back end.
- It enables smooth connectivity to SAP solutions and easier discovery and consumption of APIs and events across applications.
- It is integrated into the lifecycle management of hybrid landscapes.
Side-By-Side Extensibility – Use Cases
Scenario 1 – Integration Hub:
A typical side-by-side use case is the hub scenario. A hub solution integrates with several ERP systems and cloud services. partners want to provide a SaaS solution
Example:
A customer uses multiple SAP S/4HANA systems in several of their subsidiaries to manage his purchasing processes. To improve the purchasing process, he develops a central purchasing approver determination application on SAP BTP.
Based on a set of business rules, the application identifies the allowed approvers for specific purchasing documents and provides the information as a central remote OData API to the distributed purchasing processes.
Scenario 2 – SaaS Solution:
A partners want to provide a SaaS solution to many customers.
Example:
A partner has figured out a use-case which is a strategic gap in SAP S/4HANA. He wants to provide the solution as a SaaS solution and cater to multiple customers.
SAP BTP is specially optimized for large SAP or partner SaaS solutions which benefit from the multitenancy offerings and services for partners to run and operate the solution.
Side-By-Side Extensibility – SAP BTP Programming Models
There are three options for building side-by-side extensions on SAP BTP
- Leverage default application programming models
- SAP Cloud Application Programming Model (CAP)
- ABAP RESTful Application Programming Model (RAP)
- SAP Cloud Application Programming Model (CAP)
- Use low-code and no-code tools (for example, SAP Fiori elements, workflow, business rules)
- Use open-source components or external frameworks or any other language of your choice
What is SAP Cloud Application Programming Model (CAP)?
CAP is not a specific product but a framework, a set of tools, languages, and libraries that:
- Brings together SAP’s own technologies like SAP Business Application Studio, Core Data Services (CDS), SAP HANA and open source technologies like Node.js or Java
- Let’s you efficiently and rapidly build enterprise services and business applications in a full-stack development approach
- Allows you to focus on your business domain while relieving you from the tedious tasks which are necessary for all the cloud applications.
What is ABAP RESTful application programming model (RAP)?
RAP is a set of concepts, tools, languages, frameworks, and best practices provided on the ABAP Platform.
Important points regarding RAP:
- It is the recommended programming model for customers and partners to build ABAP based S/4HANA extensions.
- RAP is available for
- SAP BTP ABAP environment (aka Steampunk)
- SAP S/4HANA ABAP Environment (aka Embedded Steampunk)
- SAP BTP ABAP environment (aka Steampunk)
- It supports the development of all types of Fiori applications as well as publishing Web APIs.
Decision matrix – When to use which extensibility option?
Here comes the most important part – how to decide which extensibility is the right choice for you?
To decide right extensibility option for your use-case, you should consider following aspects.
Extension use case:
Is the extension a new application, or an extension to an SAP app?
Extension architecture:
Is the extension loosely or tightly coupled to SAP S/4HANA?
Extension scope & size:
Who provides the extension for which purpose?
For example,
- Is the extension a small extension that is provided by key user
- Or a custom development project that is provided by a development organization
- Or a partner SaaS application that is provided to many customers
The following Figure provides a decision tree to select the right extensibility option.
1st Scenario
External target group or consumption via mobile and consumer-grade UIs – YES
This includes
- native mobile apps
- apps that need freestyle UI development for consumer-grade UIs
- apps for persons without a named user in SAP S/4HANA.
Decision: Side-by-side extension
2nd Scenario
Partner SaaS solution – YES
Solution shall be provided as a cloud service operated by a partner.
This use case can only be realized separated from the SAP S/4HANA Cloud operation model.
Decision: Side-by-side extension
3rd Scenario
Independent infrastructure and operation – YES
Customers need to be flexible in terms of
- choosing data center
- scaling the solution without impacting S/4HANA system
- scheduling downtime independently of S/4HANA Cloud
Decision: Side-by-side extension
4th Scenario
Does extension need proximity to and coupling with SAP S/4HANA Cloud data/transactions/apps – NO
Loosely-coupled extensions:
- Data is replicated to SAP BTP or read via remote API calls
- Data hubs or integration hubs that integrate, collect, or distribute data from many systems across company
Decision: Side-by-side extension
5th Scenario
Does extension need proximity to and coupling with SAP S/4HANA Cloud data/transactions/apps – YES
Tightly-coupled extensions:
- Frequent read-access or changes to SAP data
- Reading of customer data and SAP data in complex SQL queries and with high data volume
- Extends the UI of an SAP app, extends the SAP data model, implements the extension point of an SAP app.
- Uses local SAP APIs to build an own tailored remote service for a side-by-side SAP BTP solution
Decision: Either Key User or On-Stack Extension
6th Scenario
Does extension have limited scope and can be built by key users without coding and full development project?
YES
Decision: Key User Extension
NO
Decision: On-Stack Extension
Additional aspects to consider
Consider the knowledge and experience of your development teams
For SAP Partners and customers having ABAP skillset, building extensions with Embedded Steampunk and side-by-side extensibility with Steampunk can be an easy task. For new age developers, who are more comfortable with languages like Node.js, Java, Python etc., side-by-side extension on BTP cloud foundry environment might seems an easy pick.
Balance between homogenous versus hybrid extensions
Customers and partners must find the right balance between homogenous (only on-stack or only side-by-side) versus hybrid (mixture of on-stack and side-by-side) extensions.
Homogenous extensions should be preferred for simpler lifecycles, but in some cases, hybrid extensions are the best solution.
Layering of key user and developer extensibility
On-stack extensions are often a mixture of key user extensions and developer extensibility. For these scenarios customers must consider that these extension types are layered (key user extensions on top of developer extensions). Objects built with
It’s Not Always Either/Or Decision
Key user Extensibility, Developer Extensibility and Side-by-side Extensibility may also be used in combination.
For Example:
We may use Uses Key user Extensibility to build local tailored remote service for a side-by-side SAP BTP solution.
Extensibility Options in SAP S/4HANA Cloud, Private Edition and On-Premise
With the SAP S/4HANA 2022 release Embedded Steampunk (and hence on-stack extensibility) is available in SAP S/4HANA Cloud, private edition and on-premise.
With this, we have all the 3 extensibility options available in SAP S/4HANA Cloud, Private Edition and On-Premise.
At the same time, classic extensibility is also available there.
Classic Extensions endangers smooth upgrades and makes further cloud transformation steps more difficult. Hence, reusing the SAP S/4HANA Cloud extensibility model also in private cloud or on-premise deployments is beneficial and recommended.
Can S/4HANA Private Cloud/OP customers switch to pure cloud extensibility model overnight?
Although all 3 cloud extensibility options are available in S/4HANA Private Cloud and On-Premise, it cannot be expected that these customers switch completely to the pure cloud extensibility model overnight
The main reasons are:
- Existing classic custom ABAP code must be handled
- Broader functional scope of SAP S/4HANA Cloud private edition is not covered by public SAP APIs. The public SAP APIs and extension points focus on the public edition scope.
S/4HANA Private Cloud/OP – Gradual Transition from Classic to Cloud Extensibility Model
Because of the reasons mentioned above, we need a feasible compromise for S/4HANA Private Cloud and On-Premise. The fundamental principle is that ABAP cloud and ABAP classic code can coexist since the ABAP language version is defined on ABAP object level.
This offers a gradual transition from the classic to the cloud extensibility model.
To manage the coexistence of these different extensibility models, SAP recommends a three-tier extensibility model for for S/4HANA Private Cloud and On-Premise.
What is Three-Tier Extensibility Model for S/4HANA Private Cloud/OP?
As shown in figure below, three-tier extensibility model helps us to manage the coexistence of classic extension along with new extensibility model.
Tier 1 – Cloud development
Default choice for all new extensions following the SAP S/4HANA Cloud extensibility model.
Tier 2 – Cloud API enablement
Mitigation of missing local public APIs or extension points. Here, custom wrappers for non-released SAP objects are built and released for cloud development so that they can be used in tier 1.
Once SAP provides a public local API, the custom wrapper 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 that is not supported in the ABAP cloud development model. The goal is to avoid and reduce developments in this tier to minimize the risk of upgrade issues. Guidance on how to achieve this for transformed legacy code is given in the next chapter.
