Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
Showing results for 
Search instead for 
Did you mean: 
Former Member
Cloud Foundry (CF) has been a global cloud-native application development standard for a while now and by announcing the general availability of the CF environment for the SAP Cloud Platform (SCP) in May 2017, SAP opened the gates to a whole new realm of applications.


Cloud Foundry helps developers focus more on the development tasks and eases the process of deploying and managing applications.
To gain a much broader perspective on how CF brings a new and innovative direction to SCP, please refer the below-specified blogs.

SAP Cloud Platform – A positive-sum game
SAP Cloud Platform – The next level


The main focus of this blog is to assist developers in getting started with application development and then deploy those apps on the SCP CF environment.
In order to know the steps to creating an account in the regions supporting CF environment and getting started with using the CF command line interface (CF CLI), please have a look at the detailed tutorial: Getting Started with Cloud Foundry scripted by Jonathan Baker.

This blog is mainly targeted for developers, having a background in developing apps for SAP on-premise solutions using ABAP, XSJS, SAPUI5, SQL scripting, etc., looking forward to getting started with application development on SCP CF environment.

As part of this blog, we would be creating a simple Java-based REST API (using Spring Framework) and deploying the same on the SCP CF runtime.

Cloud Foundry: Brief Introduction

Before we dive into the actual app development, here's a brief introduction about Cloud Foundry.

As quoted at the official CF website -

Cloud Foundry is an open-source platform as a service (PaaS) that provides you with a choice of clouds, developer frameworks, and application services.

CF allows you to run your apps on your own computing infrastructure (as done in the case of the XS Advanced runtime), or deploy on an IaaS like AWS, Azure, GCP, vSphere, or OpenStack.
In reference to SCP, the IaaS providers available are - Azure, AWS and GCP.

Apart from this, it also brings with itself the freedom of scripting applications using frameworks and programming languages of our choosing and binding them with various other backing services (Rabbit MQ, Mongo DB, Redis, etc.) made available as part of the platform.

[graphic source:]

The CF runtime entirely manages the infrastructure and the deployed apps and services, thus not only reducing the costs but also significantly lowering the time to develop and deploy applications in the cloud.

The best part of it is that it allows the developer to focus more on the task which is most dearer to him, Application Development, rather than on deploying and managing these apps thus making the life of the developer easy and improving productivity.

There is a plethora of documentation content available at, it is recommended to go through it once just to get a basic overview of CF.
Getting to know the Cloud Foundry Concepts is the best way to start off.

Multi-Target Applications

A full-fledged application deployed in the cloud might consist of multiple components such as the front-end, application logic or db modules. Now, when deployed in the cloud, these modules are deployed separately in their specific runtime containers (web, application or db servers to be more general) and are inter-dependent on each other for operating as part of one single application in whole.
Even though these components or modules are parts of the same single application, they have their own separate development lifecycle and managing them could be difficult and challenging at times.
Thus enters the concept of multi-target applications.

Multi-Target Application or MTA is essentially an application consisting of multiple parts or modules which, even though created with different technologies and deployed to multiple targets, still share a common lifecycle and can be managed as one single logical unit and as a coherent application.

The core of an MTA is the application descriptor or the application manifest.
The app manifest contains in itself details of the multiple modules of the application and their dependency on other modules and services. MTA-aware frameworks (CF in this case) take care of validating and individually deploying these apps to their specific targets thus freeing the developer from the burden of managing and deploying the application modules to their target containers.

To gain a much broader perspective on MTAs, please refer the documentation for the same.

Development Environment

Before starting with the application development, let's have a look at the development environments that can be utilized for developing apps for the CF runtime.

SAP introduced the WebIDE Multi-Cloud Version to help develop MTA applications for the CF runtime with support for developing Java and HDB modules added lately.

But apart from using the webIDE, any of your favorite IDE (such as Eclipse, Sublime Text, Visual Studio Code, Atom, IntelliJ IDEA, etc) can also be used to develop and deploy applications to the CF runtime.

The approach described as part of this blog is independent of the development environment used.

Application Development

Getting to the core of this post, let's start with the actual app development.

As specified earlier, we would be developing a simple Java-based REST API using Spring Framework and deploying it to the CF runtime.
The REST API would accept a parameter named 'name' and when queried would return back a response message saying - 'Hello, <parameter_name_value>. Ready to develop and deploy apps on the CF runtime ?'.

For example, the query - '<rest_api_url>?name=John Smith' would return back the response message - 'Hello, John Smith. Ready to develop and deploy apps on the CF runtime ?'

Before starting off, it is better to have a basic understanding of Java and the Spring Framework but it is not necessary. Not only java but also web, node.js and hdb modules can be deployed to CF using the same approach.
The main purpose of this app development exercise is to help developers gain perspective on deploying apps to the CF runtime, period.

So, let's get started.

  1. Bootstrap the Application
    We would be building a Spring Boot application using Maven (used to build the application and manage its dependencies). To bootstrap the Spring application and generate the Maven project, there's no better place to start with than
    Go to and generate the Maven project specifying the below-shown values.The dependency - Web is selected as we are developing a REST API.
    Generate, download and extract the project to a local directory on your machine. The generated project structure should look something like this.

  2. Developing the Spring Application Components
    Open the generated project in the IDE of your choosing and start creating the development artifacts that are to be discussed below.By default, a class with the annotation - @SpringBootApplication, denoting it to be the main application class, would be created inside the generated project with the name - DemoGreetingSpringApiApplication.Rename the said class to GreetingApplication for simplicity sake.The application class should now look something like this.
    package com.demo.demogreetingspringapi;

    import org.springframework.boot.SpringApplication;
    import org.springframework.boot.autoconfigure.SpringBootApplication;

    public class GreetingApplication {

    public static void main(String[] args) {, args);

    Next, to creating the Greeting class which would serve as the class representing the greeting string the REST API should be returning. This class would contain members - greetingID (containing a unique ID for the greeting) and greetingContent (the greeting string).
    package com.demo.demogreetingspringapi;

    public class Greeting{
    private final long greetingID;
    private final String greetingContent;

    public Greeting( long greetingID, String greetingContent){
    this.greetingID = greetingID;
    this.greetingContent = greetingContent;

    public long getGreetingID(){ return this.greetingID; }
    public String getGreetingContent(){ return this.greetingContent; }

    Once done with the Greeting class, next is to create and setup the REST controller class naming it GreetingController.
    package com.demo.demogreetingspringapi;

    import java.util.concurrent.atomic.AtomicLong;

    import org.springframework.web.bind.annotation.RequestMapping;
    import org.springframework.web.bind.annotation.RequestParam;
    import org.springframework.web.bind.annotation.RestController;

    public class GreetingController{

    private static final String greetingTemplate = "Hello, %s. Ready to develop and deploy apps on the CF runtime ?";
    private final AtomicLong counter = new AtomicLong();

    public Greeting greet(@RequestParam(name = "name", defaultValue = "World") String name){
    return new Greeting(counter.incrementAndGet(), String.format( greetingTemplate, name));

    Now, there is a lot going on in this GreetingController class.

    Annotating it with @RestController denotes it to be a controller and would enable it to format the Greeting object content in the response body to JSON, by default.
    Using the annotation - @RequestMapping would enable all the GET HTTP requests to /greet to be mapped to the greet() method.

    We are now done with developing the application components of the Spring application.
    The package - com.demo.demogreetingspringapi should now contain 3 java files as shown below.

  3. Testing the application locally
    Navigate to the project root directory, using either command prompt or powershell in Windows or a terminal in a UNIX / LINUX based machine, and execute the command
    ./mvnw spring-boot:run​

    This command would compile the application and start it.
    If the application is compiled successfully, you should be able to see a message saying - Started GreetingApplication.

    In the logs generated, lookout for the statement stating the port on which the Tomcat server is initialized.

    The application can now be tested by querying the URL - localhost:<port>/greet and it should return a JSONified content of the Greeting object.

    If the output that you get is as shown above, it means that you have successfully developed the REST API.
    Next Step is to package and deploy the application on the CF runtime.

  4. Packaging the application
    Before we can deploy the application on CF we need to package it.
    Execute the command from the project root directory to do the same.
    ./mvnw clean package

    This command would generate all the required artifacts, compile the application and generate a JAR file.

  5. Application Manifest
    Create a new file in the project root directory and name it manifest.yml.
    The project root directory would now look as below.Populate the content in the file as shown below.
    - name: demo-greeting-spring-api
    instances: 1
    disk_quota: 256M
    memory: 256M
    # routes:
    # - route: <host>
    random-route: true
    path: target\demo-greeting-spring-api-0.0.1-SNAPSHOT.jar
    buildpack: java_buildpack

    In order to get detailed information on the attributes used in the app manifest, please have a look at the documentation for the same.

    The random-route attribute has been set to true to avoid URL collisions. But a definite route can also be specified for the app by using the attribute - routes>route (the same can be seen as commented in the above-shown app manifest content) and the CF runtime would successfully map the specified route to the application in case it hasn't already been taken up.


  6. Deploying the app to the SCP Cloud Foundry Runtime
    Assuming that the CF command line interface has already been installed, login to the CF environment as specified in this tutorial and navigate to the required org and space.
    In order to deploy the application to the CF runtime, execute the below-specified command from the project root directory.
    cf push​

    This command would look for the app manifest (named manifest.yml) in the current directory, push the application (packaged as a JAR and pointed to in the app manifest by using the attribute - path) to the CF runtime and deploy and configure the app to be fully operational.

    If the app has been pushed and deployed to the CF runtime successfully, the final output of the command would be as shown below representing that the app is now operational.

    After being deployed successfully, the app can be accessed by the route(s) mapped to the application. Details of the mapped routes can be found by executing the below-shown command.
    cf app <APP_NAME>​

    The application logs can also be accessed by using the command.
    cf logs <APP_NAME>​


  7. Testing the deployed application
    The deployed application can be accessed via the route(s) mapped to the app and the JSONified content of the Greeting object can be generated by accessing the URI - /greet.The REST API can also be queried by passing the parameter - name.

This concludes the application development part.
As specified earlier, this development exercise is just to gain some perspective on deploying applications to the CF runtime. Applications created in other languages and frameworks of your choosing can also be deployed to CF in a similar manner.


Congratulations, you have successfully developed and deployed a Java-based REST API on the SCP CF runtime.

This application has also been made available on Github. Go ahead, clone it, deploy it and let Me know your feedback.

If looking for a node.js implementation of the same REST API, it can be found here.

1 Comment
Labels in this area