Designing and Running your Application in SAP BTP, Cloud Foundry Runtime

The SAP BTP, Cloud Foundry runtime offers a robust platform-as-a-service (PaaS) solution tailored for cloud-native application development and orchestration. Leveraging open standards, developers can build, deploy, and scale applications efficiently in a polyglot environment.

The Cloud Foundry runtime provides developers with flexibility in choosing their development path. Whether leveraging SAP's recommended approach based on the SAP Cloud Application Programming Model (CAP) or opting for custom solutions, developers can select from a range of programming languages and development tools.

In the polyglot nature of the Cloud Foundry runtime, developers are not limited to specific programming languages or tools. They have the flexibility to choose their preferred development and deployment tools. The three languages supported by SAP are Java, Node.js, and Python. However, there are buildpacks available for many other programming languages, including Golang, ASP.NET, PHP, and more. Choose appropriate buildpacks based on the requirements of your application.

Find more information on the three languages supported by SAP using the following links:

• Developing Java in the Cloud Foundry Runtime
• Developing Node.js in the Cloud Foundry Runtime
• Developing Python in the Cloud Foundry Runtime

SAP recommends following a structured development approach based on the SAP Cloud Application Programming Model (CAP). By utilizing Java and Node.js, developers can benefit from extensive tooling support and best practices tailored for cloud-native application development. However, the order of development steps is flexible, allowing adaptation to specific use cases.

Multitenancy allows application providers to own, deploy, and operate tenant-aware applications for multiple consumers, reducing costs by sharing resources and updating applications in a single step. In Cloud Foundry, the favored multitenancy concept leverages that each consumer accesses the application via a dedicated URL, ensuring data separation and security. You can find detailed information on Multitenancy, Roles and how it works in the SAP documentation here.

When developing tenant-aware applications, follow these guidelines:

• Avoid shared in-memory data (for example, Java static fields).
• Prevent users from executing custom code or accessing the file system.
• Implement Subscription callbacks for tenant onboarding with SAP SaaS Provisioning service (saas-registry).

You can find detailed implementation procedures in the SAP documentation here.

• Multitenant SaaS applications on SAP BTP using CAP? Tried-and-True!
• Develop multitenant applications in CF runtime [SAP Help Portal]

• MTA Descriptor (mta.yaml)

  A YAML file that lists all components of the MTA, such as modules, resources, properties, and their interdependencies. This file is central to defining how the MTA is structured and deployed. An example of an MTA descriptor is provided here

• Module

  Each self-contained part of an MTA, like a Java or HTML5 module, representing different tiers or components of the application.

• Resource

  External services or properties required by a module at runtime, which are not part of the module itself.

• Property

  Key-value pairs used during deployment or runtime to configure modules or resources.

• Dependency

  Links between modules and resources, crucial for resolving runtime and deployment dependencies.

You can create and deploy a multitarget application in the Cloud Foundry runtime by selecting from several outlined approaches below, each capable of achieving the same result:

• Using SAP Web IDE Full-Stack as described in Developing Multitarget Applications – both the development descriptor mta.yaml and the deployment descriptor mtad.yaml are created automatically. The mta.yaml is generated when you create the application project, and the mtad.yaml file is created when you build the project.

  Note

  It might be required to edit the development descriptor.

  Development descriptors are used to generate MTA deployment descriptors, which define the required deployment data. That is, the MTA development descriptor data specifies what you want to build and how to build it, while the deployment descriptor data specifies as what and how to deploy it.

• Using SAP Business Application Studio – the flow is similar to WebIDE but the development is done from SAP Business Application Studio, as described here.

• Using the Cloud MTA Build Tool. Afterward, you deploy the MTA using the Cloud Foundry Command Line Interface.

  Note

  An MTA development descriptor mta.yaml is required. You have to create it manually.

• Manually – Create the required files manually, and deploy them using the Cloud Foundry Command Line Interface.

  Note

  An MTA development descriptor mta.yaml is not explicitly required. In this case, a deployment descriptor is maintained instead.

  1. Create the required files using an IDE of your choice.
  2. To produce your custom artifacts, use a build technology of your choice.
  3. Maintain your deployment descriptor document (mtad.yaml).
     1. (Optional) If you want to have an MTA archive package, use the mbt assemble. Otherwise, deploy the mtad.yaml directly by pushing your files individually.
     2. Otherwise, deploy the mtad.yaml directly by pushing your files individually.

Cloud Foundry only supports cloud native applications. Best principles for building cloud native applications are outlined in the 12 Factor App methodology. Developers are encouraged to consult these principles for guidance on developing robust and scalable applications in the Cloud Foundry runtime.

Apps running on Cloud Foundry must avoid writing files to the local file system due to its short-lived and nonpersistent nature and lack of file sharing among instances. Instead, utilize cloud storage services such as SAP HANA Cloud, or other relational databases, or hyperscaler solutions for persistent data storage.

In environments with shared domains, cookies may be accessible across apps. Developers must decide whether to set cookies at the highest available domain to ensure consistent behavior across applications.

Clients connect to Cloud Foundry apps via URLs associated with the app. HTTP requests are allowed on ports 80 and 443, with support for WebSocket connections.

To avoid temporary unavailability, you have to run multiple instances of the app. Cloud Foundry uses a process called evacuation to relocate app instances, which frequently happens and is a common internal system operation.

It recreates instances on another virtual machine (VM) and then shuts down the old ones. Singleton app instances might be temporarily unavailable if the new instance doesn't become healthy within the evacuation timeout (default is 12 minutes). Additionally, for a short period, your singleton may have two instances, which can lead to issues if not properly managed.

To minimize downtime, running multiple instances of your app is essential. Select here to find more information about: High availability at platform and application level and The application container life cycle on the Diego architecture.

By default, all files in an app's project directory are uploaded to Cloud Foundry during deployment. Exclude unnecessary files using a .cfignore file to improve deployment efficiency.

In SAP BTP, Cloud Foundry, your app must adhere to strict time limits:

• Upload: Complete within 15 minutes.
• Staging: Must finish in 15 minutes.
• Start: The app must start within 60 minutes (configurable).

When an app receives a shutdown signal (SIGTERM), it has 60 seconds to close gracefully before being forcibly terminated by SIGKILL. Failure to shut down properly can lead to data corruption or other issues, especially with persistence. It's crucial to ensure that your app can handle this within the 60-second window.

Set up the SAP BTP, Cloud Foundry runtime App Autoscaler service, which lets you automatically increase or decrease the number of your application instances based on the policies you have defined. The service will then automatically adjust the number of app instances based on the current load, ensuring more resilient and scalable applications.

Utilize SAP BTP's logging capabilities for better observability. Use centralized logging services like Cloud Logging and Application Loggingto monitor and analyze app performance and behavior.

Set up the SAP BTP, Cloud Foundry runtime Alert Notification Service to receive real-time notifications about critical events, improving the ability to respond to issues promptly.