Skip to Content

The following steps will explain how to use the SAP S/4HANA Cloud SDK’s Virtual Data Model (VDM) to call OData services of an SAP S/4HANA system.

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

In this tutorial, we will do the following:

  1. Explain the SAP S/4HANA Virtual Data Model provided as part of the SAP S/4HANA Cloud SDK
  2. Enhance the HelloWorld project stub to call an existing OData service via the VDM.
  3. Deploy the project on
    1. SAP Cloud Platform Neo
    2. SAP Cloud Platform Cloud Foundry
  4. Write an integration test

If you want to follow this tutorial, we highly recommend checking out Step 1 (Setup) and Step 2 (HelloWorld on SAP Cloud Platform Neo) or Step 3 (HelloWorld on SAP Cloud Platform CloudFoundry), respectively, depending on your choice of platform. You will not need any additional software besides the setup explained in the first part of the series. The application will run on your local machine and can be deployed to Cloud Platform.

If you would like to know more about communication management and identity & access management artifacts in S/4HANA Cloud, please follow the Deep Dive on this topic. We also highly recommend as further reading the deep dive on the OData Virtual Data Model used in this blog post. The VDM provides very easy access to OData endpoints of an SAP S/4HANA system for services published in the SAP API Business Hub.

Note: This tutorial requires access to an SAP S/4HANA system (see prerequisites below).


In order to execute this tutorial successfully, we assume a working and reachable system of SAP S/4HANA on-premise or S/4HANA Cloud. You may substitute the presented business partner service by any other API published on the SAP API BusinessHub.

If you do not have an S/4HANA system at hand, you may be interested to study the mocking capabilities provided by the VDM as explained in the corresponding blog post.

Please note that depending on the platform (Neo or CloudFoundry) you are using, the configuration to the respective S/4HANA system might be different. In the following, we list the methods by which you can access your system.

SAP Cloud Platform, Neo SAP Cloud Platform, Cloud Foundry
S/4HANA on-premise SAP Cloud Connector required with HTTP Destination SAP Cloud Platform Connectivity and Cloud Connector
S/4HANA Cloud

Direct Connection with BASIC Auth (technical user)

Direct Connection with SAMLOAuthBearer (PrincipalPropagation with BusinessUser)

Direct Connection with BASIC Auth (technical user, used  below)

Note that your application code is not dependent on your choice. Using the S/4HANA Cloud SDK, you can write your code once and it is capable of dealing with all different authentication and connectivity options.

Virtual Data Model

This section explains the concepts of the S/4HANA Virtual Data Model. If you would like to first implement the S/4HANA integration, jump ahead to the next section and revisit the content of this section later.

The data stored in an S/4HANA system is inherently complexly structured and therefore difficult to query manually. Therefore, HANA introduced a Virtual Data Model (VDM) that aims to abstract from this complexity and provide data in a semantically meaningful and easy to consume way. The preferred way to consume data from an S/4HANA system is via the OData protocol. While BAPIs are also supported for compatibility reasons, OData should always be your first choice. You can find a list of all the available OData endpoints for S/4HANA Cloud systems in SAP’s API Business Hub.

The S/4HANA Cloud SDK now brings the VDM for OData to the Java world to make the type-safe consumption of OData endpoints even more simple! The VDM is generated using the information from SAP’s API Business Hub. This means that it’s compatible with every API offered in the API Business Hub and therefore also compatible with every S/4HANA Cloud system.

The manual way to OData

Let’s take a look at typical code we could write to access any OData service using the SAP Cloud Platform SDK for service development. Here, we retrieve a list of business partners from an S/4HANA system:

final ErpEndpoint endpoint = new ErpEndpoint();
final List<MyBusinessPartnerType> businessPartners = ODataQueryBuilder

The ODataQueryBuilder represents a simple and generic approach to consuming OData services in your application and is well suited to support arbitrary services. It is a big step forward from manually building up an HTTP request to an OData service and processing the results in your code, and is used internally by the S/4HANA Cloud SDK. In turn, the ODataQueryBuilder also uses concepts of the SAP S/4HANA Cloud SDK to simplify communication with systems such as the ErpEndpoint.

Nevertheless, there are quite a few pitfalls you can fall into when using the plain ODataQueryBuilder approach to call OData services:

  • For .withEntity("/sap/opu/odata/sap/API_BUSINESS_PARTNER", "A_BusinessPartner") you already need to know three things: the OData endpoints service path (/sap/opu/odata/sap), the endpoints name (API_BUSINESS_PARTNER) and the name of the entity collection (A_BusinessPartner) as defined in the metadata of the endpoint.
  • Then, when you want to select specific attributes from the BusinessPartner entity type with the select() function, you need to know how these fields are named. But since they are only represented as strings in this code, you need to look at the metadata to find out how they’re called. The same also applies for functions like order() and filter(). And of course using strings as parameters is prone to spelling errors that your IDE most likely won’t be able to catch for you.
  • Finally, you need to define a class such as MyBusinessPartnerType with specific annotations that represents the properties and their types of the result. For this you again need to know a lot of details about the OData service.

Virtual Data Model: The new way to OData

Now that we have explained the possible pitfalls of the current aproach, let’s take a look at how the OData VDM of the S/4HANA Cloud SDK simplifies the same task, as the SDK is able to incorporate more knowledge about the system that is being called.

final List<BusinessPartner> businessPartners =
        new DefaultBusinessPartnerService()

Using the OData VDM we now have access to an object representation of a specific OData service, in this case the DefaultBusinessPartnerService (default implementation of the interface BusinessPartnerService). So now there’s no more need to know the endpoint’s service path, service name or entity collection name. We can call this service’s getAllBusinessPartner() function to retrieve a list of all the business partners from the system.

Now take a look at the select() function. Instead of passing strings that represent the field of the entity, we can simply use the static fields provided by the BusinessPartner class. So not only have we eliminated the risk of spelling errors, we also made it type-safe! Again, the same applies for filter() and orderBy(). For example, filtering to male business partners becomes as easy as .filter(BusinessPartner.IS_MALE.eq(true))– note the type-safe comparison.

An additional benefit of this approach is discoverability. Since everything is represented as code, you can simply use your IDE’s autocompletion features to see which functions a service supports and which fields an entity consists of: start by looking at the different services that are available in the package, instantiate the default implementation of the service you need (class name prefixed with Default), and then look for the methods of the service class that represent the different available operations. Based on this, you can choose the fields to select and filters to apply using the fields of the return type.

Each service is described by a Java interface, for example, BusinessPartnerService. The SDK provides a default, complete implementation of each service interface. The corresponding implementation is available in a class whose name is the name of the interface prefixed with Default, for example, DefaultBusinessPartnerService. You can either simply instantiate that class, or use dependency injection with a corresponding Java framework (covered in Step 22 of our tutorial series). The benefit of the interfaces is better testing and extensibility support.

To sum up the advantages of the OData VDM:

  • No more hardcoded strings
  • No more spelling errors
  • Type safety for functions like filter, select and orderBy
  • Java data types for the result provided out of the box, including appropriate conversions
  • Discoverability by autocompletion
  • SAP S/4HANA services can be easily mocked during testing based on the service interface in Java (see tutorial Step 19: Mocking S/4HANA calls)

The VDM supports retrieving entities by key and retrieving lists of entities alongwith filter()select()orderBy()top() and skip(). You can also resolve navigation properties on demand or eagerly (expand, see Step 22). The VDM also gives easy access to create (see Step 20), update, and delete operations as well as function imports.

For any OData service not part of SAP’s API Business Hub, the ODataQueryBuilder still is the goto approach for consumption.

Write the BusinessPartnerServlet

The SAP S/4HANA Cloud SDK provides simple and convenient ways to access your ERP systems out of the box. In this example we will implement an endpoint that performs an OData query to SAP S/4HANA in order to retrieve a list of business partners from our ERP system. More specifically, we want to retrieve all persons (a specific kind of business partner) with their name and a few additional properties.

To get started open your previously created Hello World project (in our case this is called firstapp) and create a new file called in the following location:



import org.slf4j.Logger;

import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.util.List;



public class BusinessPartnerServlet extends HttpServlet {

    private static final long serialVersionUID = 1L;
    private static final Logger logger = CloudLoggerFactory.getLogger(BusinessPartnerServlet.class);

    private static final String CATEGORY_PERSON = "1";

    protected void doGet(final HttpServletRequest request, final HttpServletResponse response)
            throws ServletException, IOException {
        try {
            final List<BusinessPartner> businessPartners =
                    new DefaultBusinessPartnerService()
                            .orderBy(BusinessPartner.LAST_NAME, Order.ASC)

            response.getWriter().write(new Gson().toJson(businessPartners));

        } catch (final ODataException e) {
            logger.error(e.getMessage(), e);

The code is fairly simple. In the servlet GET method, we initialize an instance of the BusinessPartnerService to prepare the query to S/4HANA with the help of the SDK’s Virtual Data Model. We call the method getAllBusinessPartners, which represents the operation of the OData service that we want to call. WIth the fluent query helper returned by this method, we can gradually build up the query:

  • we select the fields of the BusinessPartner that we want to retrieve (if we leave out this part, all fields will be returned),
  • filter for business partners of category Person (code "1"), and
  • order by the last name of the business partner.

Finally, having prepared the query, we call the execute method. This method does a lot of the heavy lifting necessary to connect to an S/4HANA system and relieves us as developers from dealing with complex aspects such as:

  • the configuration which system to connect to (in a multi-tenant environment) – by transparently accessing the destination service of SAP Cloud Platform,
  • the connectivity to this system, which may reside on-premise behind a corporate firewall, – by means of the connectivity service and the optional Cloud Connector, and
  • the authentication to this system using potentially vastly different authentication flows (basic authentication, principal propagation, OAuth2).

The SAP S/4HANA Cloud SDK provides all of these capabilities with a simple interface and allows customers (tenants) of your application to configure the connection to their system. We will discuss the configuration below when deploying the project.

The execute method of the VDM returns the query result as a navigatable list of type BusinessPartner, which represents the entity type of the response in a type-safe manner. We declare the servlet’s response as JSON content and transform the result into a JSON response.

Any ODataException thrown by the OData call is caught and logged, before returning an error response.

Deploying the Project

Depending on your chosen archetype and SAP Cloud Platform setup you can deploy the project on either SAP Cloud Platform Neo or SAP Cloud Platform Cloud Foundry. If you face any problem with connecting to OData please find the troubleshooting paragraph at the end.

On SAP Cloud Platform Neo

If you have started your project on SAP Cloud Platform Neo (step 2), you can now deploy your application to your local Neo platform using the following maven goals:

cd /path/to/firstapp
mvn clean install
mvn scp:clean scp:push -pl application -Derp.url=https://URL

Replace URL with the URL to your SAP ERP system (host and, if necessary, port).
Note: the -pl argument defines the location in which the Maven goals will be executed.

Maven will then prompt you for your username and password that is going to be used to connect to SAP S/4HANA. Alternatively, you can also set these values as command parameters: -Derp.username=USER -Derp.password=PASSWORD

If you now deploy the project with the Maven command and visit the page http://localhost:8080/businesspartners you should be seeing a list of business partners that was retrieved from the ERP system. Note: Please login with test / test).

On SAP Cloud Platform Cloud Foundry

If you have started your project on SAP Cloud Platform Cloud Foundry (step 3), you need to supply the destination of your SAP S/4HANA system before you deploy the new version to Cloud Foundry or run the application on the local server.

Run on a Local Server

As mentioned in Step 3 of this tutorial series, you can run the project on a local TomEE server. Here, you need to supply the destinations as an environment variable on your local machine (replace set with the corresponding commands to define environment variables on your command shell).

set destinations=[{name: "ErpQueryEndpoint", url: "https://URL", username: "USER", password: "PASSWORD"}]

Please change the values URL, USER and PASSWORD accordingly.

Afterwards, re-build and start the server as follows:

cd /path/to/firstapp
mvn clean install
mvn tomee:run -pl application

Visit http://localhost:8080/businesspartners to see your new feature in action.

Note: You can also add more ERP endpoints to this JSON representation, following the same schema. However, please note that “ErpQueryEndpoint” corresponds to the destination used by default by the execute method of the VDM.

Connecting to SAP S/4HANA from SAP Cloud Platform Cloud Foundry

In order to perform queries against your ERP system when the application is deployed on Cloud Foundry, you have to inform Cloud Foundry about the location of your ERP endpoint.

To do this, you can either supply the same environment variable destinations that we used for the local deployment above to the Cloud Foundry application, or use the destination service (beta) of SAP Cloud Platform Cloud Foundry. Using the destination service is the recommended approach, because it already handles important aspects related to multi-tenancy, connectivity and security and is transparently integrated into the SAP S/4HANA Cloud SDK.Therefore, we explain how to use the destination service in detail below.

Nevertheless, there may be circumstances that make the approach via the environment variable easier to use or otherwise preferable for initial testing, for example, because the destination service is still in beta and only available for Cloud Foundry trial accounts. To set the environment variable using the Cloud Foundry command line interface (CLI), execute the following command:

 cf set-env firstapp destinations '[{name: "ErpQueryEndpoint", url: "https://URL", username: "USER", password: "PASSWORD"}]'

Again, supply the correct values for your S/4HANA system. Afterwards, rebuild and deploy the application to Cloud Foundry (see below). Depending on your command line interface (for example, on Windows), you may need to use double quotes instead of single quotes and escape the double quotes:

cf set-env firstapp destinations "[{name: \"ErpQueryEndpoint\", url: \"https://URL\", username: \"USER\", password: \"PASSWORD\"}]"

Whenever this environment variable is set, the SAP S/4HANA Cloud SDK will use it to determine destinations. Make sure to delete it with cf unset-env firstapp destinations as soon as you are done with the initial testing and when you want to use the real destination service.

Using the Destination Service (Beta) on SAP Cloud Platform Cloud Foundry

For the recommended approach of using the destination service to configure the connection to your SAP S/4HANA system, proceed as follows. Note that this requires version 1.6.0 or higher of the SAP S/4HANA Cloud SDK.

Subscribe to Services

The destination handling is available as a beta service on Cloud Foundry (trial accounts). You need to create an instance of that service and bind it to your application in order to use the destination service. Additionally, you need an instance of the Authorization and Trust Management (xsuaa) service.

Use the Cloud Foundry CLI to create the two required service instances:

cf create-service xsuaa application my-xsuaa
cf create-service destination lite my-destination

This creates two service instances in your space: one instance named my-xsuaa for the xsuaa service with service plan application, and a second instance named my-destination for the destination service (plan lite).

To bind the two newly created service instances to your application when it is deployed, adapt the manifest.yml file by adding the two instances to the services section at the end. The remainder of the file remains as before:


- name: firstapp
  memory: 768M
  host: firstapp-D123456
  path: application/target/firstapp-application.war
  buildpack: sap_java_buildpack
    JBP_CONFIG_SAPJVM_MEMORY_SIZES: 'metaspace:96m..'
  - my-destination
  - my-xsuaa

Please make sure to have the host property declared with a unique name of your choice. The recommended way is to include the username as suffix. The hostname will later be used as subdomain of a publicly reachable route. Since this is a setup with multiple, dedicated instances, a random-route should be omitted.

With this, the setup is complete and we can re-deploy the application. However, we still need to configure the destination to our SAP S/4HANA system. We will do this in the next section and then deploy the application to Cloud Foundry.

Configure Destinations

Customers of our application can use the Cloud Platform cockpit to configure destinations. We will use the cockpit to define our destination as well.

  1. Navigate to the Cloud Foundry subaccount within your global account that you have used before to deploy the application (see Step 3). In case of a trial account, the subaccount will be called trial by default.
  2. In the menu on the left, expand Connectivity and select Destinations (Beta).
  3. Click on New Destination and enter the following values into the input fields:
    • Name: ErpQueryEndpoint (this is the destination accessed by default by the SAP S/4HANA Cloud SDK)
    • URL: https://URL (URL to your SAP S/4HANA system)
    • Authentication: choose BasicAuthentication
    • Provide credentials of your technical user in the User and Password fields.
    • Leave the other fields unchanged.
  4. Click on Save.

Afterwards, the destination should look as follows.

Please note that the above settings represent the setup for a connection to SAP S/4HANA Cloud via a technical user (communication user). Depending on your setup and requirements, you may want to use a different ProxyType (OnPremise when using the Cloud Connector) or a different means of authentication.

Deploy to Cloud Foundry

Now you can deploy your application to Cloud Foundry using the Cloud Foundry CLI (command line interface):

cd /path/to/firstapp
mvn clean install
cf push

Access the new servlet at https://YOUR-ROUTE/businesspartners.

If you change the destinations afterwards, you need to at least restart (or restage) your application to make sure that the changes become effective due to caching:

cf restart firstapp

Integration Test for BusinessPartnerServlet

To construct an extensible integration test for the newly created BusinessPartnerServlet, the following items will be prepared:

  • Adjustment: Maven pom file
  • New: test class
  • New: JSON Schema for servlet response validation
  • New: systems.json and credentials

Adjustment: Maven pom file

First, let’s adjust the Maven pom file of the integrations-tests sub module, by adding a dependency for JSON schema validation:



New: test class

Navigate to the integration-tests project and create a new class:



import com.jayway.restassured.RestAssured;
import com.jayway.restassured.http.ContentType;
import io.restassured.module.jsv.JsonSchemaValidator;
import org.jboss.arquillian.container.test.api.Deployment;
import org.jboss.arquillian.junit.Arquillian;
import org.jboss.arquillian.test.api.ArquillianResource;
import org.jboss.shrinkwrap.api.spec.WebArchive;
import org.junit.Before;
import org.junit.BeforeClass;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.slf4j.Logger;



import static com.jayway.restassured.RestAssured.when;

public class BusinessPartnerServletTest {
    private static final MockUtil mockUtil = new MockUtil();
    private static final Logger logger = CloudLoggerFactory.getLogger(BusinessPartnerServletTest.class);

    private URL baseUrl;

    public static WebArchive createDeployment() {
        return TestUtil.createDeployment(BusinessPartnerServlet.class);

    public static void beforeClass() {

    public void before() {
        RestAssured.baseURI = baseUrl.toExternalForm();

    public void testService() {
        // JSON schema validation from resource definition
        final JsonSchemaValidator jsonValidator = JsonSchemaValidator

        // HTTP GET response OK, JSON header and valid schema

What you see here in the test method testService , is the usage of RestAssured on a JSON service backend. The HTTP GET request is run on the local route /businesspartners, the result is validated on multiple assertions:

  • HTTP response status code: 200 (OK)
  • HTTP ContentType: application/json
  • HTTP body is valid JSON code, checked with a businesspartners-schema.json definition

New: JSON Schema for servlet response validation

Inside the integration-tests project, create a new resource file


  "$schema": "",
  "title": "Business Partner List",
  "type": "array",
  "items": {
    "title": "Business Partner",
    "type": "object",
    "required": ["BusinessPartner", "LastName"]
  "minItems": 1

As you can see, the properties BusinessPartner and LastName will be marked as requirement for every entry of the expected business partner list. The JSON validator would break the test if any of the items was missing a required value.

New: systems.json and credentials

If you run your application on SAP Cloud Platform, the SDK can simply read the ERP destinations from the destination service. However, since the tests should run locally, we need a way to supply our tests with an ERP destination.

Luckily, the SDK provides a utility class for such purposes – MockUtil. This class allows us to mock the ERP destinations we’d typically find on CloudFoundry. To provide MockUtil with the necessary information, you’ll need to add a systems.json or systems.yml file to your test resources directory. MockUtil will read these files and provide your tests with the ERP destinations accordingly. Adapt the URL as before.


  "erp": {
    "default": "ERP_TEST_SYSTEM",
    "systems": [
        "alias": "ERP_TEST_SYSTEM",
        "uri": "https://URL"

That’s it! You can now start all tests with the default Maven command:

mvn test -Derp.username=USER -Derp.password=PASSWORD

Please change the values USER and PASSWORD accordingly. If you do not want to pass the erp username and password, checkout the appendix below for an alternative.

If you want to run the tests without Maven, please remember to also use include the command line parameters.

In this blog post, we have explained the virtues of the Virtual Data Model and demonstrated how easy it is to connect to SAP S/4HANA using the SAP S/4HANA Cloud SDK, how to deploy the application including destination configuration, and how to create integration tests.

See the next tutorial in the series here: Step 5 with SAP S/4HANA Cloud SDK: Resilience with Hystrix.


Supplying credentials as a file: credentials.yml

Hint: How to remember ERP username and password

If you do not want to pass the erp username and password all the time when executing tests or want to execute tests on a continuous delivery pipeline where more people could see the password in log outputs, you can also provide credentials in a credentials.yml file that the SDK understands.

To do this, create the following credentials.yml file in a save location (e.g., like storing your ssh keys in ~/.ssh), i.e., not in the source code repository.


- alias: "ERP_TEST_SYSTEM"
  username: "user"
  password: "pass"

Afterwards you may pass the credentials file as follows when running tests. Make sure to use the absolute path to the file:

mvn test -Dtest.credentials=/secure/local/path/credentials.yml


In case you are trying to connect to an OData service endpoint on a server without verifiable SSL certificate, you might see the following error message due to an untrustworthy signature:

Failed to execute GET https://<URL>/$metadata
  • To manually override the chain of trust, you can set a special flag on the destination configuration. To avoid any further issues with untrusted certificates in your local Neo deployment environment, please change the TrustAll flag in your destinations configuration file ./config_master/service.destinations/destinations/ErpQueryEndpoint
  • If you are running into the same problem in a Cloud Foundry deployment environment and you are using the environment variable approach, please adapt the destinations environment variable to additionally include the properties map:
    [{name: "ErpQueryEndpoint", url: "https://URL", username: "USER", password: "PASSWORD", properties: [{key: "TrustAll", value: "true"}]}]
  • If you are using the destination service on Cloud Foundry, add a new additional property to your destination in the Cloud Platform cockpit. Enter TrustAll into the first input (dropdown) field and TRUE into the second field.

If you are still facing problems when connecting to the OData service, try the following to get more insights into what is happening and what can be logged:

  • Add a logger implementation to the test artifact’s dependencies in order to get more detailed log output during tests: expand the dependencies section of integration-tests/pom.xml with:

If you are behind a proxy and want to connect your app running locally with the Cloud Foundry archetype to an SAP S/4HANA system in your network, you can supply your proxy information as part of the destinations environment variable (see Javadoc):

[{name: "ErpQueryEndpoint", url: "https://URL", username: "USER", password: "PASSWORD", properties: [{key: "TrustAll", value: "true"},{key: "proxyHost", value: ""},{key: "proxyPort", value: "8080"}]}]
To report this post you need to login first.


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

  1. Julian Frank

    Hey Alexander,

    first of all: great example on how to use the SDK.

    One question from my side: is there anything more to do to establish the ERP connection when deploying to CloudFoundry? I always receive an UnknownHostException that the name or service is not known.

    Thanks and best regards


    1. Philipp Herzig

      Hi Julian,

      this depends a little bit on the setup you intent to use. We have added a small little prerequisite section that explains which configurations are currently available. To which system do you try to talk to? Is it an S/4HANA Cloud system? Or do you try against an S/4HANA on-prem system. Also it matters whether you try to do it from Neo or CloudFoundry (but see yourself in the updated prerequisite section).

      Don’t mind to drop us additional questions.

      Best regards



      1. Thomas Nitschke

        Did you already manage to run the example on Cloud Foundry with the new destination service  against an onPremise system? Any specific troubleshooting hints in that case?

        I get the service running, the integration test executes fine in a local environment but despite a destination service and cloud connector setup that does not show obvious issues I end up with an exception.

        1. Sander Wozniak

          Hi Thomas,

          could you please share some more details on the exception?

          It would be great if you could find the time to also post the issue on StackOverflow using the tag “s4sdk” so that others who might have a similar issue can also benefit from your question!

          Thank you!



        2. Marco Dahms

          Hi Thomas,


          can you pls share all the relevant details with us, for instance, which exception and what is the stack trace, the message etc.?




          1. Philipp Herzig

            Hi Thomas,

            just fyi: Have you tried Katja’s deep dive on how to use connectivity service with onprem here: ?

            Please also bear in mind that at this time, the connectivity service is still in beta despite being already supported by the SDK.

            Best regards


  2. Yangyang Chen

    Hey Alexander,


    Very good tutorial, give us many valuable information. We have a similar scenario that we need to call an Odata service provided by S4/HANA cloud from our Application which is deployed on SCP CF. I have two questions related to this scenario,


    1.How can we adapt this tutorial to support multi-tenant?

    2.If we want to query the Odata service directly from UI, are we able to do that? We are thinking about directly consuming Destination service provided by SCP CF, user can configure tenant-level destinations through Cockpit, but it looks like Destination service is still at Beat version on SCP CF.


    Could you kindly share us some ideas? Thank you in advance.





    1. Sander Wozniak

      Hi Yangyang,

      regarding the secure setup of a multi-tenant application on CF, please have a look at our tutorial on this topic:

      You are right, at the moment, the destination service on CF is still in Beta. As long as this is the case, you could rely on the Neo environment to consume a multi-tenant destination. In addition, please consider the option to also expose an OData V4 service using the SAP Cloud Platform SDK for service development. A tutorial on this topic can be found here:

      Best regards


  3. Bastian Schiele

    Hi Alexander,

    thank you for the great blog.

    We had some problems with calling the OData Service. We wanted to call the cost centers service from our local S/4 HANA and got the following error:

    Failed to execute GET https://<URL>/$metadata

    As the service-side certificate is not signed from any root CA, hence, is not trusted (if you call the service in browser you get a warning).

    To avoid any issues with untrusted certificates you may set the property TrustAll=TRUE in the created destination property in following location of your project:


    With that configuration it works fine for us in Neo.

    Best regards,




    1. Alexander Duemont Post author

      Hey Bastian,

      thank you very much for your feedback. Finding out about the TrustAll flag was a good catch! I changed the blog post to also include your solution, see Troubleshooting.

      Best regards,


  4. Sankeerth Narsina

    Hi Alexander,

    Thanks for such a great blog.  I tried the steps mentioned here – deploying the app locally and accessing the data at localhost:8080. I am able to see the expected JSON data. But when I am trying to access the endpoint to display the JSON data after deploying the app to Neo environment, it gives me following error.

    HTTP Status 500 - Destination "ErpQueryEndpoint" not found.

    Could you please help me fixing this issue.




    1. Philipp Herzig

      Hi Sankeerth,

      you need to configure the ErpQueryEndpoint destination in Neo using the destination tab of your application. It has to look similar to what Tri has posted below.

      Best regards


      1. Sankeerth Narsina

        Thanks for the response. I see the result in the webpage like as below.

        Failed to read metadata for "TimeEntryCollection".

        I also added the destination along with the property TrustAll as TRUE. But it didn’t help.

        I am facing this issue only in neo environment but not in cloud foundry. Can you help me with this?

        1. Alexander Duemont Post author

          Hi Sankeerth,

          In case a metadata file is either too big (thus taking long to load) or non-existing, then please consider disabling the look up altogether:

            .withEntity("/some/path/to/endpoint", "SomeEntity")
            .select("Some", "Fields")

          By using the “withoutMetadata()” modifier, the meta information about data types will not be loaded. As consequence some special (de)serialization of unusual attribute types may not work as expected.

          Best regards


    1. Philipp Herzig

      Hi Tre,

      as written in the blog, please try setting the TrustAll property to TRUE. In the destination service this can be done via additional properties you see in your screenshot.

      Best regards


          1. Tri Minh Le

            Hi Philipp,

            Thanks for your effort.

            This is error when i check connection.

            Even though I can save it successfully, the result is

            Failed to execute GET$

            I’ve checked the log:

            Caused by: connect timed out (local port 34229 to address (, remote port 443 to address (

            Have you tried this successfully on Neo, Philipp?

            Thanks in advance.


            1. Francesco Spina


              I have the same problem. I configured a S/4Hana Cloud destination but I have the “Failed to execute GET $metadata” error. The same application running locally is instead able to call the destination. Furthermore I can run a simple Fiori app that can communicate with this destination.

              I have tried both the .withoutMetadata() on ODataQueryBuilder than the TrustAll option.


              Any suggestion?

              1. Henning Heitkoetter

                Hello Francesco,

                are you running this in the Neo environment in a trial account? (URL contains hanatrial)

                If yes, you may need to manually configure a proxy (this is not necessary elsewhere, only do this for the trial region of Neo)

                Add the following Additional Properties to your destination (click New Property and type this into the field – do not use the dropdown options):

                1. proxyHost =
                2. proxyPort = 8080



  5. Henning Heitkoetter

    Change log (December 22, 2017):

    • Explain benefits of the Virtual Data Model provided by the SAP S/4HANA Cloud SDK
    • Use Virtual Data Model throughout the code (instead of manual approach via ODataQueryBuilder)
    • Introduce a new example: the application is now using the business partner API to retrieve a list of business partners (instead of cost centers)
    • Use systems.json to define ERP systems used during testing
  6. Henning Heitkoetter

    Change log (January 04, 2018):

    • Use destination service (beta) on SAP Cloud Platform Cloud Foundry
    • Reference later tutorial steps on the Virtual Data Model
    • Explain proxy support in local deployment (Cloud Foundry archetype)
    • JSON schema validation: verify that response contains at least one item
  7. Robert Eijpe

    Hi Hennig

    Can you also provide an example for filtering the manual way to OData. We need a ComplexFilterExpression to filter on 3 fields.

    Please explain also the OR and AND example.




    1. Henning Heitkoetter

      Hello Robert,

      with the manual way, the filter would look similar to the following:


      AND would simply work by calling the same method multiple times.

      We plan to describe more complex filter expressions in the future. If you need it now: they are available for the manual approach if you manage the dependency of to version 1.11.4 (add this as first dependency into the dependency management section of the pom.xml in the root folder).

      Best regards,


  8. Venu Ravipati

    Hi Alexander,

    This blog is awesome :). Thank you.

    Just have one question. The name for backend Destination is mentioned as “ErpQueryEndpoint”. is this mandatory that the destination name has to be always this name?

    Thank you and Best Regards,


    1. Alexander Duemont Post author

      Dear Venu,

      You cannot change the default destination name. But you can use your very own:

      ErpEndpoint endpoint = new ErpEndpoint(new ErpConfigContext("YourCustomEndpoint"));

      Please keep in mind, to update your local / SCP destination configuration accordingly.

      Best regards


    1. Sander Wozniak

      Hi Martin,

      it might be that you are using a system which is not reachable from the landscape that you are using.

      Could you please share some more details on the exception in the log file that you get when running the application?

      In case you find the time, it would also be great if you could post your question to StackOverflow using the tag “s4sdk” so that others who might have the same or a similar issue may benefit from it as well in the future!

      Thank you!




Leave a Reply