SAP BTP Development Environments and Deployment Options Explained

The structure of the SAP BTP provisioning in terms of global account, subaccounts, and spaces—any configuration like connecting to a specific on-premise system or security setup, is specific in a subaccount instance of the platform.

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 like development, test, and production, you need separate subaccounts. In fact, since each subaccount would be linked to the core instance of the underlying transactional system, which may be on-premise SAP S/4HANA, for example. Ideally, you have one-to-one linkages between the environments of this SAP S/4HANA instance and the corresponding subaccount. This approach ensures testing with the backend systems and security, all in sync, with no deployment risks.

Further classification under the subaccount is provided spaces, which is a concept inherited from Cloud Foundry. But this concept can also be used for logical groupings of developments.

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 console. After deployment to SAP BTP, Kyma runtime, the status can be checked in the Kyma dashboard through the log output. Logs are available for each namespace and for also for particular lambda 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 Cloud Foundry providers can provide PaaSs like SAP BTP or IBM Cloud Foundry, among others. 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.

Available since May 2017, Cloud Foundry in simple terms 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. While SAP Web IDE still supports full stack development, including frontend development capabilities, database models, and business logic built into backend capabilities, the newer IDE called SAP Business Application Studio is now the preferred development and deployment environment for the cloud-native applications (unless using ABAP).

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.

2

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 through the SAP Business Application Studio (or SAP Web IDE full-stack), if you use a language not yet supported by the SAP Business Application Studio/SAP Web IDE, 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 shown, note how Cloud Foundry has made the SAP BTP architecture quite open.

Neo Environment

For applications developed in 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 but not in the cloud environment.

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.

Unlike other environments, SAP Business Application Studio has no roadmap to support Neo environments so far.

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. This ABAP code as a service, is operated by SAP.

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.

Transport organizers in ADT in Eclipse are used for deploying ABAP programs to application servers configured in SAP Business Application Studio. OData services are created and then deployed to the application server in the cloud. The transports are handled using SAP Cloud ALM or Git-based CTS (gCTS).

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.

Thus, SAP BTP, ABAP environment, has two components.

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 this scenario, the embedded Steampunk solution and developer extensibility have been introduced. This option is currently available in SAP S4HANA Cloud and is planned for SAP S/4HANA.

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

As of late 2022, developer extensibility on SAP S/4HANA Cloud for scenarios that cannot be achieved using side-by-side extensions is possible with the embedded Steampunk on the stack.

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).

SAP Build for Low-Code/No-Code Development

SAP acquired the company AppGyver as an environment for low-code and no-code development, using it as the base of their new solution SAP Build, and this solution is typically used for quick development and prototyping, especially for mobile applications that can then be deployed on any platform for any device. Other tools that enable low-code and no-code approaches for the SAP Process Automation suite include SAP Workflow Management and SAP Intelligent Robotic Process Automation.

SAP Build offers some powerful features that enable development, such as the following.

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.

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

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

With SAP BTP, developers can choose from a range of environments to suit their project needs—whether it’s serverless functions on Kyma, full-stack applications on Cloud Foundry, ABAP-based extensions, or low-code/no-code apps with SAP Build. Each environment comes with its own deployment model, toolset, and best practices, from provisioning subaccounts to handling transports and MTAs.

By understanding both the capabilities of these environments and how applications are deployed in each, you can select the right option for your use case while ensuring scalability, security, and maintainability. As SAP continues to evolve BTP, expect ongoing improvements across these runtimes—especially in areas like Kyma-managed services, SAP Build extensibility, and integration with SAP S/4HANA.

Whether you’re building proof-of-concept apps, extending core SAP systems, or rolling out enterprise-grade cloud solutions, SAP BTP provides the flexibility and foundation to support modern development and deployment.

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.