Describing Application Development and Automation Services

Objective

After completing this lesson, you will be able to describe application development and automation services.

Introduction to the Lesson: Describing Application Development and Automation Services

This lesson introduces the learner to application development and automation in the context of SAP BTP. It begins with a discussion of extensibility in general and some basic terms used. Next we cover the concepts of clean core and the SAP S/4HANA Cloud extensibility model. Finally we look at some of the specific SAP BTP services used for application development and automation.

This lesson contains the following topics:

Extending SAP Systems
Basic Terms Explained
Clean Core
SAP S/4HANA Cloud Extensibility Model
Three Tier Extensibility Model
SAP BTP Application Development and Automation Portfolio
SAP Build Apps
SAP Build Code
ABAP Development Tools for Eclipse (ADT)
SAP Build Process Automation

Application Development and Automation Services

The Problem Clean Core Solves: The "Technical Debt" Legacy

For decades, companies running SAP ERP systems (like ECC) customized them extensively to fit their unique business processes. This often involved:

Directly Modifying SAP Code: Changing the standard SAP source code.
Creating "Z-Code": Writing vast amounts of custom ABAP code (programs starting with 'Z' or 'Y') that was deeply intertwined with the core system.
Complex, Brittle Integrations: Building point-to-point connections that were hard to manage and often broke during updates.

This created a "Technical Debt" with significant drawbacks:

Upgrade Paralysis: Upgrades became massive, multi-year projects because all custom code had to be tested, remediated, and adapted. Many companies simply stopped upgrading.
High Total Cost of Ownership (TCO): Maintaining and supporting this complex, custom code is extremely expensive.
Inability to Innovate: Companies couldn't adopt new SAP innovations (like Fiori apps or AI features) quickly because their core was too fragile and outdated.
Technical Debt: The system became a tangled mess of dependencies, making any future change risky and slow.

Explaining Clean Core With An Analogy

Think of SAP Cloud ERP as the foundation and structural walls of a brand-new house. With a clean core, you don't knock down structural walls to add a new room. Instead, you build a well-designed, separate extension (like a sunroom or a detached office) that connects seamlessly to the main house through standard doorways (APIs). This way, when the city updates its building codes (SAP releases an update), your main house can be upgraded easily without having to rebuild your custom extension.

At its heart, SAP's clean core strategy is a modern approach to managing an SAP Cloud ERP system by keeping the central "core" of the software as close to the standard, out-of-the-box version as possible. Instead of heavily modifying the core system's code to meet business requirements (the old way), customizations, extensions, and integrations are built outside the core using modern, cloud-native tools and platforms.

Let's did a little deeper into how to approach extension and custom development in the context of SAP Cloud ERP. The options are organized around a "three options" concept. By doing so it makes it a little easier to analyze scenarios. Simply take each use case and decide which "bucket" it belongs in.

The first option is to develop "side-by-side". This means simply to build and run developments "outside" of the core and on SAP BTP. By doing so organizations can take advantage of all that SAP BTP has to offer. They can choose which environment to run their applications in. They have a wide range of SAP BTP services to utilize. If operations are needed on data in the core a deep repository of public remote APIs are available to utilize.

The second and third option are located "on-stack" (i.e., both take place and run on SAP Cloud ERP). This would be in cases where a tighter coupling between the extension and / or custom development is necessary. With "key user" extensions simple extensions that can be done by end users using specialized "low code / no code" tools are used. For extensions that require more of a "pro code" approach "developer extensibility" can be used.

The three options are consistent with a clean core approach. One of the goals of clean core in regards to extensibility is that "upgrades do not break an extension and extensions do not break an upgrade". Following the SAP S/4HANA Cloud Extensibility Model ensures that this is the case.

Clean Core Approaches

The clean core approach has been presented in two generations:

Three Tier Extensibility Model
Clean Core Level Concept

The Three Tier Extensibility Model (now to be considered as sunset) was the first generation approach. The Clean Core Level Concept is the second generation approach and represents the evolution of the first generation approach. Of key point to note is that both of these approaches detail the guidelines to be followed by all organizations whether they are using SAP Cloud ERP, SAP Cloud ERP private or on-premise ERP. While SAP Cloud ERP customers have a system that is clean by default (and thus the only need is to keep the system clean), SAP Cloud ERP private / on premise ERP customers are usually (although not always) long time customers and have a large number and variety of enhancements and modifications (built up over many years) based on traditional classical ABAP techniques. As they migrate to SAP Cloud ERP Private / on-premise ERP some additional options that fit their unique needs are necessary.

1st Generstion: 3-Tier Extensibility Model (Now Sunset)

Three Tier Extensibility Model

Tier 1 development is based off of the SAP S/4HANA Cloud Extensibility Model as explained in the previous section. Remember that based on this model, extensions and custom developments can be either on stack or side-by-side as appropriate. One requirement of Tier 1 is that all artifacts and their dependencies must be "public" (i.e., released). If an artifact is not released (e.g., a remote enabled function module that is not released but needed) then Tier 2 exists to "close the gap". Using Tier 2 development techniques a "wrapper" around the artifact is created (and subsequently released itself ) which allows usage of the artifact in Tier 1 development scenarios. Tier 3 is for developments that must be for the short and / or medium term based on classic ABAP techniques( both classic ABAP language and classic ABAP extension techniques). As a general rule architectural use cases should use Tier 1 development as much as possible, utilize Tier 2 to allow the usage of non released artifacts and utilize Tier 3 only when absolutely necessary.

2nd Generation: Clean Core Level Concept (To Be Followed)

Clean Core Level Concept

The clean core level concept is an evolution of the 3-tier model designed to make development approaches easier for customers by increasing the number available APIs available by usage and simultaneously decreasing the need for wrappers and also incorporating ABAP classic in more use cases. By evolving the previous 3-tier model, this new maturity model categorizes extensions into four distinct levels (A, B, C, and D) based on their architectural integrity, upgrade safety, and alignment with clean core principles. To wit:

Level A: The evolution of Tier 1. Extensions that solely use publicly released and stable interfaces backed by formal stability contracts. Based exclusively on ABAP Cloud. As always, the preferred approach.
Level B: Extensions that use an unreleased API (like a BAPI for example) that under the Tier 2 approach would have required a wrapper but under this approach do not. These APIs while officially unreleased are nevertheless deemed by SAP to be stable and upgrade safe and thus safe for customers to use. Along with Level A also to be considered as a preferred approach.
Level C: Extensions that rely on APIs that are not officially released but are nonetheless needed by customers for their legacy scenarios which they will need to continue to use. Because these APIs might change in a way that makes them less stable (and thus creates upgrade risk) SAP provides a changelog for customers to consult to help them identify upgrade risks and take action early. While not to be considered a preferred approach relative to the first two levels Level C nonetheless can be done if deemed necessary.
Level D: Extensions not considered "clean" because they use explicitly non-recommended objects or techniques. This approach represents the highest risk and is the most likely to result in technical debt.

For a more in depth discussion of clean core generally please see Managing Clean Core for SAP S/4HANA CloudFor a more in depth discussion of clean core as applied to extensibility please see Practicing Clean Core Extensibility For SAP S/4HANA Cloud

SAP BTP Application Development and Automation Portfolio

Lastly in this lesson let's look at the SAP BTP services available that can be used when doing extension and custom development. While in theory they could be presented in different ways the way we will present them will be based on the low code / no code / pro code paradigm. Using that as a guide the main SAP BTP services are:

Low Code: SAP Build Apps
Pro Code: SAP Build Code
Pro Code: ABAP Development Tools for Eclipse (ADT)

SAP Build Apps

Caution

As of March 23rd, 2026 as part of the continued evolution and simplification of the SAP Build portfolio, SAP Build Apps is being retired as a standalone product. Please note that there is no immediate impact on existing customers. Customers will continue to have full access to SAP Build Apps and in addition SAP will honor all existing commitments, including SLAs and maintenance through the duration of all existing contracts. For more information please see: SAP Build Apps Deprecation and The Path Forward

SAP Build Apps (formerly SAP AppGyver) operates in the low code / no code paradigm space of SAP BTP application development and automation services. It is a visual development solution to create enterprise apps without writing code. SAP Build Apps lets you:

- Create apps by dragging and dropping pre-built components and then configuring them to your needs.
- Connect to all types of back-end data, including SAP systems, using SAP BTP destinations.
- Create application logic, also by dragging and dropping flow functions and configuring them.

SAP Build Apps is primarily intended for line-of-business professionals who have a strong understanding of the business challenges that must be solved but are not experts at coding necessarily. Using SAP Build Apps nontechnical citizen developers can build enterprise-grade applications for mobile devices and Web browsers.

For information on using SAP Build Apps see Developing Apps with SAP Build Apps using Drag-and-Drop Simplicity

SAP Build Code

Moving into the pro code space they're several SAP BTP services available. First is SAP Build Code. As a pro code oriented solution SAP Build Code has everything needed to support developer efficiency:

Coding capabilities including generative AI based code development with natural language
Expedited access to APIs to support testing requirements
Integrated continuous integration / continuous deployment (CI / CD) functionality
Automation of software development and deployment
Collaborative capabilities

With SAP Build Code the full spectrum of application development is possible. SAP solutions can be extended and SAP Fiori UIs can built with SAPUI5 and SAP Fiori Elements. In addition cross platform apps can be developed to run on mobile devices and SAP HANA based applications are possible. For the most challenging use cases full fledged multitenant SaaS applications can be built using SAP Build Code.

While still available as a separate service SAP Build Application Studiois now also integrated and a part of the SAP Build suite accessible through SAP Build Code.

For more information on SAP Build Code see Creating Applications and Extensions using SAP Build Code/

ABAP Development Tools for Eclipse (ADT)

ABAP Development Tools in Eclipse (ADT)

As an additional option developers can use ABAP Development Tools for Eclipse (ADT). As with SAP Build Code the full spectrum of application development for all the same reasons are possible. The primary difference between the two is the programming model that each uses. In the case of SAP Build Code the programming model is the Cloud Application Programming Model whereas for ADT it is the ABAP RESTful Application Programming Model the programming model used by ABAP Cloud. We will explore these very important programming models in the next lesson.

You may recall we mentioned earlier in the lesson the three types of extensions that comprise the SAP S/4HANA Cloud Extensibility Model namely (1) side-by-side, (2) developer and (3) key user extensions. With SAP Build Code the focus of development is side-by-side. With ADT however both side-by-side and developer extensibility can be done (key user extensibility is done using a different toolset). This is accomplished via creating "projects" in ADT in which the target system of the project will be either an SAP S/4HANA instance (Cloud ERP, Cloud ERP Private or on-premise ERP) or an SAP BTP ABAP Environment. In the case of the former developer extensibility can then be implemented whereas with the latter side-by-side extensibility can be done.

SAP Build Process Automation

Moving from application development to automation we have the concept of Business Process Management (BPM). BPM is an approach used to identify, analyze, measure, and improve an organization’s processes across any and all areas (i.e., logistics, financial, HR). BPM software helps to achieve not just operational excellence but achieving it at the lowest cost possible. The SAP BTP solution for BPM is SAP Build Process Automation. SAP Build Process Automation is the evolution of the former SAP Workflow Management and SAP Intelligent Robotic Process Automation solutions into a unified solution based on a low code / no code design to put the enablement of process excellence in the hands of the citizen developer. SAP Build Process Automation enables users to quickly automate workflows and tasks to meet specific business requirements and represents a simpler, faster way to automate business processes. Some of the main features of SAP Build Process Automation are:

Digitalize, extend, or adapt existing processes and orchestrate new end-to-end processes.
Build RPA bots to handle repetitive tasks so users can focus on higher-value goals.
Accelerate document-heavy processes with intelligent document processing.
Connect process and task automations to any SAP or non-SAP application.

For more information on SAP Build Process Automation please see: Creating Processes and Automations with SAP Build Process Automation

SAP Build

Several time in this lesson SAP Build has been mentioned. That's not by happenstance. SAP Build is a unified solution bringing together tools that support low code / no code / pro code development across the entire application development and automation spectrum. As both a recap and preview of what SAP Build offers note the following:

SAP Build Apps: For building extensions without code
SAP Build Process Automation: For automating processes
SAP Build Work Zone (to be discussed in the next lesson): For setting up business sites
SAP Build Code: For building extensions with code

While AI will be explored in detail in Unit 6: Exploring AI Servicesit is worth noting now that SAP Build utilizes Joule for Developers. With Joule, developers can use integrated AI tools in SAP Build, powered by SAP-optimized models, to significantly improve productivity and efficiency in application development and automation without switching context. More specifically Joule capabilities integrated within SAP Build will allow users to generate code, automate processes, design intuitive UIs, and build custom agents using AI. Users will have easy access to a comprehensive range of large language models (LLMs) from which to choose from.

Unified Lobby

A solution as powerful and as diverse as SAP Build needs many different features. One of those features is "fusion team development" meaning the ability for multiple individuals on a team coming from a variety of backgounds (i.e., business, IT) collaborate together on projects. Hence creating a "project" is one of the core features of the SAP Build lobby. Once a project is created then "members" can be added it. This way project leads can control which specific members have access to which specific projects. In addition the unified lobby of SAP Build has the following features:

Store: Hundreds of pre-build content packages available containing forms, automations and apps.
Monitoring: Consolidated set of monitoring and configuration tools for users
Connectors: Create actions to communicate with external systems or leverage the automation SDK which provides different activities for an automation

How They Work Together: A Practical Example

Imagine a "New Vendor Onboarding" process.

Trigger: A business user fills out a simple form in a custom app built with SAP Build Apps.
Orchestration: Submitting the form triggers a workflow in SAP Build Process Automation.
Data Enrichment (Automation): The workflow starts an RPA bot that logs into a third-party credit-checking website, enters the vendor's details, and retrieves a credit score.
Custom Logic (App Dev): The workflow calls a custom microservice built with SAP Business Application Studioto perform complex validation logic that is too specific for the workflow itself.
Human Approval If the credit score is good and validation passes, the workflow creates an approval task in the manager's Task Center. The manager opens the task and sees a detailed SAP Fiori UI (built with SAP Business Application Studio) showing all the vendor details.
Final Update: Upon approval, the workflow makes a final API call to SAP Cloud ERP to create the new vendor master record.
Monitoring: Throughout the process, an administrator can monitor the status and performance of all onboardings using the Process Visibility dashboard of SAP Signavio.

Summary

In summary, SAP BTP is the foundation for the "Intelligent, Sustainable Enterprise." Its primary goal is to allow businesses to innovate and extend their core SAP systems (like SAP Cloud ERP) without disrupting them. This is achieved through the "Keep the Core Clean" strategy.

Instead of heavily customizing your core ERP system, you build new applications, extensions, and automations on SAP BTP. These "side-by-side extensions" connect to your core systems via stable, whitelisted APIs. This approach provides agility, simplifies upgrades, and leverages modern cloud-native technologies.

Next lesson