SAP BTP Development Environments and Deployment Options Explained

SAP BTP gives developers several environments to build and run applications in, and each one handles deployment a little differently. In this post, we'll look at how SAP BTP is structured into global accounts, subaccounts, and spaces, and then cover how deployment works in Kyma, Cloud Foundry, Neo, and the ABAP environment, along with SAP's low-code option, SAP Build.

SAP BTP is organized into a global account, subaccounts, and spaces. Most configuration, such as connections to a specific on-premise system or your security setup, lives at the subaccount level.

So, if you’re deploying an application which is, say specific to finance, then it’s better to have a separate subaccount for finance only. If the same subaccount is used for all areas, there is a chance of configurations getting overwritten or conflicts and confusion arising.

For every environment (development, test, and production), you need a separate subaccount. Each subaccount is typically linked to a corresponding instance of the underlying transactional system, such as an on-premise SAP S/4HANA system. Ideally, you'll have a one-to-one link between each SAP S/4HANA environment and its subaccount, so that backend testing and security stay in sync and deployments carry less risk.

Within a subaccount, you can further divide your work into spaces, a concept inherited from Cloud Foundry. Spaces are also useful for grouping related developments logically.

Kyma Runtime and Kubernetes

SAP initiated the development of an open-stack project called Kyma, which uses Kubernetes clusters for container deployment, along with a set of other related activities for maintaining and scaling applications. These additional activities are now transparent to users using Kyma-managed services in the SAP BTP platform. With SAP BTP, Kyma runtime, you can create your own applications or extend SAP’s cloud applications.

Both Kyma and Kubernetes are operated by SAP, and thus, all patches and software upgrades are handled by SAP and are supported according to SAP BTP service level agreements (SLAs).

Serverless Development with SAP BTP, Kyma Runtime

The serverless option is primarily used for doing short proof of concept kinds of development, which can then be scaled down to zero when not in use or scaled up, as required. This option is supported by SAP BTP, Kyma runtime.

Deployment on Kyma Runtime

After the application, whether a microservice or a function is created, it is containerized using Docker containers and exposed as standard in the Kubernetes framework, and it is possible to make these scalable. For complex requirements, this is the option to be chosen. Then, the Docker image can be deployed to SAP BTP, Kyma runtime, using the Kyma dashboard. After deployment, you can check the status in the Kyma dashboard through the log output. Logs are available for each namespace and for individual Functions.

Microservices can be deployed through the deployments as YAML Ain’t Markup Language (YAML) or JavaScript Object Notation (JSON) files. Continuous integration/continuous deployment (CI/CD) pipelines use kubectl.

Cloud Foundry Environment

Cloud Foundry has become the industry-standard, open-source, cloud-based platform that can be deployed on any infrastructure, owned in-house or hosted on the cloud, called infrastructure as a service. Commercial providers offer Cloud Foundry as a platform as a service (PaaS), and SAP BTP is one of them. Since 2014, SAP has partnered with other infrastructure providers that have joined the Cloud Foundry Foundation (https://www.cloudfoundry.org/foundation/) so that these providers can deploy Cloud Foundry for any compliant infrastructure.

SAP's Cloud Foundry environment has been available since May 2017. In simple terms, Cloud Foundry can be described as an operating system for a cloud platform that provides a standardization layer.

The Cloud Foundry platform enables you to deploy any app or service within minutes and makes these apps or services scalable, depending on their usage. Its layer of standardization has in fact become the de facto standard for cloud platforms. The Cloud Foundry architecture offers container-based isolation between the various parts of your application, including, for instance, SAP HANA deployment infrastructure containers or an app container in the application layer. Multiple app containers can separate microservices, for instance, in different languages.

Deployment on Cloud Foundry

When an application is deployed on Cloud Foundry from the developer workspace to SAP BTP, Cloud Foundry uses different containers, for instance, various app containers and database containers. Since the architecture using Cloud Foundry is completely different from using Neo, these applications are deployed and executed differently as well.

Runtimes available in Cloud Foundry include Java, HTML5, Node.js for backend applications, and machine learning algorithms in Python. SAP Business Application Studio is the development and deployment environment for cloud-native applications on Cloud Foundry (ABAP development uses Eclipse instead, as covered below). It replaced SAP Web IDE, which is now available only for the Neo environment.

In Cloud Foundry, MTA deployment is possible. Let’s look at an example of creating an application using the Cloud Foundry architecture and then using MTA to deploy the application. In our example, we’ll consider a simple cloud-native application with a frontend and a schema in the SAP HANA database with some calculation views, consuming some services from other systems, perhaps SAP S/4HANA through a CDS view. How the deployment architecture should look is shown in this figure.

The AppRouter is the first point of entry when a user calls your application through a web browser. The AppRouter also handles security considerations and authenticates the user. The call goes from this application to the microservice, over an HTTP service or a REST service.

The application can be deployed into different app containers, depending on the microservices used. Cloud Foundry has container services and backing services. With each container, core parts of the application server are deployed too. For instance, a microservice may use different languages. This multilingual operation is supported by backing services, which contain every attached resource for your application, for example, persistence objects or job schedulers.

While typical artifacts are created in SAP Business Application Studio, if you use a language it doesn't yet support, you can connect an external development tool for any language through Git. All the code for all your applications can be stored in a Git repository. The deploy services available in Cloud Foundry can act as the central component for managing the lifecycle of the application. These services enable MTAs, which will package up all the different parts of the application in a single .yaml file, to be transported across different landscapes.

The MTA will split up the application into modules: For instance, one module may be for the SAP HANA database for database content (CDS views, calculation views), while another module may contain Java/Node.js for backend code. A third module may be an HTML5 module for the HTML frontend content. The deployment functionality also contains configuration information for security and other dependencies like services the application needs. It will take care of getting the code from the developer workspace into the relevant parts of Cloud Foundry (e.g., HDI containers into the table/views/databases, frontend/backend into app containers, etc.).

Once the development is built, you generate the .yaml file through the graphical menu or using the CLI in SAP Business Application Studio. You’ll also need to input some details into the descriptor files for an SAP Cloud Application Programming Model-based application. Then, this application will be built, which generates the .mtar file in the .mta archive folder. The advantage of this build and deployment approach is that it knows all the dependencies and sequences and takes care of the generation of the different code in different languages. Once the .mtar file is generated, you can deploy this application, which you will then see in your dev space (assuming you first deploy to a dev environment before moving to other environments), including logs for the deployment of each module (e.g., .srv for the web services or .ui for the UI module).

Note: Detailed guidance for Cloud Foundry deployments can be found at http://s-prs.co/v550429.

As you can see, Cloud Foundry makes the SAP BTP architecture quite open.

Neo Environment

Note: SAP will sunset the Neo environment on December 31, 2028. After that date, Neo applications and services will no longer be accessible, and SAP is releasing new features only for the multi-cloud environments (Cloud Foundry, Kyma, and ABAP). If you're starting a new project, use one of those instead. If you're running apps on Neo today, start planning your migration now.

For applications developed in the legacy SAP BTP, Neo environment, the first point of entry into the deployment architecture is often through SAP Web Dispatcher.

SAP BTP, Neo environment, also supports multitarget application (MTA) deployment, though Neo MTAs use their own format and can't be deployed to Cloud Foundry as-is.

Deployment on SAP BTP, Neo Environment

When an application is created in SAP BTP, Neo environment, you’ll create a project in SAP Web IDE, push the code to GitHub, and then have three options for saving the application: saving locally, committing changes to GitHub, or pushing the application to the SAP BTP instance. The main runtimes available in SAP BTP, Neo environment, support development using Java, JavaScript, SAP HANA, and HTML5/SAPUI5. Developer environments are available on Eclipse and on SAP Web IDE. For XS-JS development, you can use Eclipse plugins or the SAP HANA Web-Based Development Workbench. An application can be run locally for unit testing but, in this state, is not available for other users. Only when published to SAP BTP and activated will the application be ready to run on the cloud. As shown in the figure below, some services are available in the SAP BTP cockpit, while the deployment and versioning functionalities are available via SAP Web IDE for Neo.

SAP Business Application Studio doesn't support the Neo environment, so Neo development still relies on SAP Web IDE Full-Stack, which retires along with Neo at the end of 2028.

The next figure shows versioning capabilities within SAP BTP, Neo environment.

ABAP Environment on SAP BTP

SAP BTP, ABAP environment, supports the latest version of ABAP. While the development must be performed using the ABAP perspective in the Eclipse IDE currently, the deployment of the application occurs in the ABAP server on SAP BTP. A set of development toolsets are part of the Eclipse IDE. SAP operates this ABAP platform as a service.

Deployment on ABAP Environment

ABAP developments are created as software components under “packages” in ABAP. When you release the code, the packages are stored in the Git repository, which handles the deployment as a whole. The entire code is deployed.

In ADT, you record your changes in transport requests using the Transport Organizer. When you release a transport request, the changes are pushed to the software component's Git repository. You then import that software component into your test and production systems with the Manage Software Components app, which uses Git-based CTS (gCTS) behind the scenes. SAP Cloud ALM can orchestrate these imports across systems. OData services are created and deployed to the ABAP application server in the cloud in the same way.

The ABAP code can also be placed in the abapGit repository, from which the deployment can be handled it. However, abapGit is currently available only as a plugin to ADT.

ABAP cloud development comes in two forms: SAP BTP, ABAP environment, for standalone apps and side-by-side extensions that run on SAP BTP, and embedded Steampunk, which runs directly on the SAP S/4HANA stack.

For some scenarios that are tightly coupled to an existing SAP S/4HANA model, the extension becomes difficult since it is not loosely coupled. For these scenarios, SAP introduced embedded Steampunk (also called developer extensibility), covered below.

The architecture shows how the ABAP instance is running on a space connected to an SAP HANA database. Using the SAP Connectivity service, you can connect with other cloud systems like SAP S/4HANA Cloud, SAP Ariba, or any cloud APIs. Leveraging a cloud connector, you can connect any system in your business network including those behind a corporate firewall, whichever is supported by the cloud connector.

Eclipse IDE and ABAP Development Tools

Also, an ABAP application can use any SAP BTP service. Within the SAP BTP cockpit, you can configure the launchpad for system admin activities using SAP Fiori apps. SAP Business Application Studio can be used to build SAP Fiori apps as well. The development is performed through ABAP Development Tools available on the Eclipse IDE, and developments can be stored in Git repositories. Different use cases would leverage different parts of this architecture. This figure shows the Eclipse IDE for developing custom code.

Embedded Steampunk for SAP S/4HANA

Embedded Steampunk lets you build tightly coupled extensions directly on the SAP S/4HANA stack for scenarios that side-by-side extensions can't handle. It has been available in SAP S/4HANA Cloud Public Edition since the 2208 release, and in SAP S/4HANA Cloud Private Edition and on-premise since the SAP S/4HANA 2022 release.

SAP Build for Low-Code/No-Code Development

SAP acquired AppGyver and used it as the foundation for SAP Build Apps, part of the SAP Build family of low-code and no-code tools. SAP Build Apps is typically used for quick development and prototyping, especially for mobile apps that can be deployed to any platform and device. For workflows and automation, SAP Build Process Automation (which combines the former SAP Workflow Management and SAP Intelligent Robotic Process Automation) takes the same low-code/no-code approach.

SAP Build Apps includes several features that speed up development:

• Visual UI Builder: This UI helps you generate the code by simply selecting from a large library of UI components that can then be modified without any coding. Themes are available to help you build UIs even more quickly.

• Visual Logic: Business logic also can be built up through visual aids, leveraging 400+ formula functions, simply by dragging and dropping logical components, without any coding.

• Integrations: This environment provides the ability to integrate APIs in no time and even to integrate with REST APIs through the REST Integration wizard. From a UI perspective, SAP Fiori-based themes are available to help you create SAP Fiori-like UIs, although without SAPUI5 controls. You can even extend SAP’s functionalities like SAP Sales Cloud or SAP Service Cloud through a UI built in SAP Build.

Conclusion

Picking an SAP BTP environment comes down to what you're building and what it has to connect to. ABAP teams extending SAP S/4HANA will feel at home in the ABAP environment, while teams working in Java, Node.js, or Python will likely end up on Cloud Foundry or Kyma. If you still have apps running on Neo, start planning the move now, since that environment shuts down at the end of 2028. For quick prototypes or apps built by business users, SAP Build is worth a look before anyone writes code. 

Dive into SAP BTP with this learning journey.

Learn SAP BTP in Our Rheinwerk Course!

What is SAP Business Technology Platform and what can it do? Get all the information you need in this course. Take a tour of the platform’s tools and services for development, integration, analytics, data management, and more. Learn directly from the experts and see SAP BTP in action with practical demos! Get access to course recordings by clicking the banner below.