Skip to Content

The following steps will explain how to create the very first HelloWorld example on SCP Neo using the SAP S/4HANA Cloud SDK. If you want to follow this tutorial, we highly recommend checking out the first part of this blog series.

Note: This post is part of a series. For a complete overview visit the SAP S/4HANA Cloud SDK Overview.


Goal of this blog post

This tutorial will cover your first steps when developing applications for SCP CloudFoundry using the SAP S/4HANA Cloud SDK. More specifically, we will cover the following steps:

  1. Create an account for SCP CloudFoundry and setup the CloudFoundry command line interface for deploying and managing CloudFoundry applications.
  2. Generate your first project using the SAP S/4HANA Cloud SDK Maven archetype and understand its structure.
  3. Deploy your first application to SCP CloudFoundry.

The screenshot below shows the final result of this tutorial.


Setup for CloudFoundry

In order to deploy applications to SCP CloudFoundry, you need to create a free trial account. You can create your account by visiting

After creating your account and activating it via email, you can log in to your personal cloud cockpit. For your first visit, it should look like this:

Now click the “Home” button in the upper navigation bar and then click “Start Cloud Foundry Trial”.

After selecting your region, your account will be automatically setup for development with CloudFoundry.

Now that your account is activated and configured, you will need the CloudFoundry command line interface (cf CLI) to deploy and manage your CloudFoundry applications.

To install cf CLI, you can either grab the latest release on the official release page or use your favorite package manager.

In order to deploy applications on SAP CloudFoundry we need to provide cf CLI with an API endpoint. The API endpoint depends on the region you chose for your account:

  • for EU:
  • for US EAST:
  • for US WEST (beta):

Now enter the following commands (in this case for the EU region):

cf api
cf login

The cf CLI will ask you for your mail and your password. After entering these, you should be successfully logged in!

Generate Project from Archetype

To generate your first project from the Maven archetype, run the following command:

mvn archetype:generate -DarchetypeArtifactId=scp-cf-tomee -DarchetypeVersion=1.0.0-SNAPSHOT

During the generation process, Maven will require additional parameters to form your project:

groupId An identifier representing your group, company or organization (e.g.
artifactId An identifier for your application (e.g. firstapp)
version The version of your application (e.g. 1.0-SNAPSHOT)
package The name of the top-level package your source code will reside in (typically equal to your groupId, e.g.
uniqueHostname An unique identifier to determine your initial project URL on CloudFoundry. This value must be across your CloudFoundry region, but it can easily be changed later on. We recommend Application Name + some random number, e.g.: firstapp-D123456

After providing these values, Maven will generate your project from the archetype.

Note: We have created here an application which is based on the TomEE runtime which is Java EE 6 compliant OpenSource runtime that is available in the Cloud Foundry platform if you aim at a Java EE application. You may also initialize the project with SpringBoot (artifactId: scp-cf-spring) or on a pure Tomcat container (artifactId: scp-cf-tomcat). Our tutorial series will be primarily based on the TomEE runtime, we may cover flavors in SpringBoot or Tomcat later in this blog. Nonetheless, the SAP S/4HANA Cloud SDK is compatible with these popular runtimes too.

Now you can open your favorite IDE and import the project as ‘Maven Project’. After importing the project into your IDE, the project structure should look like this:

The project consists of two directories, application and integration-tests.

  • application contains the source code and configuration files of your actual application.
    src/main/java Here goes your production code, nothing else. As you can see, there’s already the HelloWorldServlet, which we will look at in more detail soon.
    src/main/resources Anything that you require in your production code but is no code goes here (typically things like API definition files for RAML or OpenAPI, Database Migration Files for Flyway or Liquibase)
    src/main/webapp It contains the deployment descriptor for your web application – the infamous web.xm
    src/test/java This is the place for your automated tests.
    src/test/resources Tests may also require additional resources to work properly such as configuration files. This is their place.
    pom.xml  This is your project management file for Maven where you can maintain other open source dependencies or use plugins that ease your build environment.
    manifest.yml  This is the deployment descriptor for CloudFoundry (we will take a closer look at this file when we deploy the application)
  • integration-tests contains the integration tests for your application. Its structure is similar to application.
    src/test/java Here you can put all your integration tests. As you can see, there’s already the HelloWorldServiceTest corresponding to the HelloWorldServlet.
    src/test/resources Here go all the resources needed for the integration tests to run.

This separation of test modules makes it possible to just run integrations test without deploying, as well as deploying the application without running time consuming integration tests. Unit tests will be kept publicly inside the application module. For that topic we highly recommend the articles and educational videos from Martin Fowler. For a start we advice reading his post about Unit Tests.

Integration tests

During development it becomes important to test newly implemented code to external services, i.e. logic running in a distributed environment. This is where integration tests are an important tool to ensure correctness and stability over the whole internal and external deployment. Since these integration tests may contain confidential information, like business logic and test access tokens, it can be helpful to maintain its operation inside a dedicated Maven sub module. That way the application can be shipped without integration tests and their dependency.



Now that you understand the structure of the project, let’s take a closer look at the HelloWorldServlet.

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class HelloWorldServlet extends HttpServlet
    private static final long serialVersionUID = 1L;
    private static final Logger logger = LoggerFactory.getLogger(HelloWorldServlet.class);
    protected void doGet( final HttpServletRequest request, final HttpServletResponse response )
        throws ServletException, IOException
    {"I am running!");
        response.getWriter().write("Hello World!");

The HelloWorldServlet extends HttpServlet, so this will be a HTTP endpoint that we can visit. We map this endpoint to the /hello-servlet route using @WebServlet("/hello-servlet"). By overriding the function doGet, we define what happens when a client performs an HTTP GET request on the /hello-servlet route. in this case we simply write a response containing “Hello World!”.

Note: The application code runs seamlessly in SAP Cloud Platform, Neo as well as SAP Cloud Platform, Cloud Foundry. The SAP S/4HANA Cloud SDK is compatible with both versions and provides mechanisms to seamlessly transfer code between both environments.


In order to deploy the application, we first need to assemble our project into a deployable artifact – a .war file. Open your command line and change into the firstapp directory, the root directory of your project and run the following command:

cd /path/to/firstapp
mvn clean package

This tells maven to remove any files from previous assemblies (clean) and to assemble our project (package). The project is setup so that Maven automatically runs our unit and integration tests for us. After running the command there should be a directory target inside of the applicationdirectory, containing a file called firstapp-application-1.0-SNAPSHOT.war. This is the file that we will deploy to CloudFoundry.

Now the previously mentioned manifest.yml comes into play – it’s the deployment descriptor used by CloudFoundry.

- name: firstapp
  host: firstapp-D123456
  path: application/target/firstapp-application-1.0-SNAPSHOT.war
  buildpack: sap_java_buildpack
    destinations: '[{name: "ErpQueryEndpoint", url: "", username: "user", password: "password"}]'

The manifest contains a list of applications that will be deployed to CloudFoundry. In this example we only have one application, firstapp, with the following parameters:

name This is the identifier of your application within your organization and your space in SCP CloudFoundry.
memory The amount of memory allocated for your application.
host Determines the URL of your application after deploying it (this is where the uniqueHostname from the generation process is being used).
path The relative path to the artifact to be deployed.
buildpack A buildpack is what CloudFoundry uses to build and deploy your application. Since this is a Java application, we use the sap_java_buildpack.
env Here we can provide additional application specific environment variables. For example we specify that we want to use a TomEE container as our target runtime.

Now you can deploy the application by entering the following command:

cf push

cf push is the command used to deploy applications. The -f flag provides cf CLI with the deployment descriptor.

Hint: If you omit the -f flag,  cf CLI will check whether there is a file named manifest.yml in the current directory. If so,  cf CLI will use this file as deployment descriptor. Else, it will fail.

After the deployment is finished, cf CLI’s output should look like this:

Now we can visit the application under its corresponding URL:

Hello world!

That’s it.

Now you have a strong basis for developing your own cloud application for SCP CloudFoundry using the SAP S/4HANA Cloud SDK. Stay tuned for upcoming blog posts about more advanced usages of the SAP S/4HANA Cloud SDK.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply