Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 
Product and Topic Expert
Product and Topic Expert
General prerequisites for following the blog series can be found here.




Getting Started with SAP Cloud Platform

Getting started with SAP Cloud Platform, Cloud Foundry Environment, is well described in the SAP Help Portal

You need to access to the SAP Cloud Platform, so apply for an account

You need the Cloud Foundry Command Line Interface (CLI), a command line tool, for deploy, etc


How to create a destination in SAP Cloud Platform, Cloud Foundry Environment


What is a destination?

A destination is used to avoid hard-coding URLs in the application code, e.g. in a String-variable in Java.
Furthermore, if the consumed URL requires user-authentication, a destination helps avoid hard-coding the user and password in the application.
Similar with other authentication methods.

Instead, from the application code, a destination is referred, which encapsulates the target URL.
A destination comprises more information apart from the target URL. There can be authentication methods and additional parameters.

Altogether can be exported to a file and re-used on different landscapes.

More info can be found in the SAP Help Portal

Why do we need it?

In some tutorials of the series, we learn how to fetch data from an existing OData service.
In order to call that service, we need a destination.


As long as you’re creating an OData service which doesn’t require authentication itself, make sure to set the environment variable ALLOW_MOCKED_AUTH_HEADER with value true
cf set-env <appNAme> ALLOW_MOCKED_AUTH_HEADER true


The following section describes the 3 required steps:

  1. Create instance of xsuaa service.
    This is required for destination service

  2. Create instance of destination service.
    This is required to make use of destination configurations

  3. Create the destination configuration itself.
    This is the destination which contains the info about target URL

If these 3 requirements are fulfilled, an application can be deployed to Cloud Foundry, can be bound to the 2 service instances and can make use of the destination configuration


Find Service Marketplace

Go to SAP Cloud Platform landing page: and log in.
If you're not yet registered, then NOW would be a good moment to do it.


Choose "Cloud Foundray Trial"
Go to "Subaccount" (in my case, the name of the subaccount is “trial”).
Click on “trial”


Choose “Spaces” on the navigation pane



Click on the space name for navigating to the Space


Now that you’ve accessed your Space, you can proceed creating the service instances which are required for using destinations

Click on Service Marketplace on the navigation pane


In our case, we need 2 services: xsuaa and destination.
Proceed as follows to create the respective instances


1) Create xsuaa service instance


Find the xsuaa-service called  “Authorization&Trust Management” (you can use the search box on the upper right side)

On the navigation pane, click “Instances”


Then click on the button “New Instance” and go through the wizard.
On the first wizard page, choose “application” as Service Plan
On the second and third pages no entries are required
On the fourth page, enter a name for your instance, e.g. demoxsuaa and press “Finish”



2) create destination service instance

Next step is to create an instance of the service “destination”.
You can either go back to the Service Marketplace, but a shorter way is this one:
On the bread-crumb menu, an arrow next to the “Authorization…” service indicates that from here you can select a different service
Click on the arrow, then on the entry “destination”

Afterwards, you can proceed creation an instance of destination service
The procedure is similar like above.
In this case, the Service Plan to be used is called “lite”
the name for the service can be e.g. “demodestination”
After pressing “Finish”, you can see your newly created destination service instance.



In both cases, you’ve created instances of services, but you haven’t used them yet.
They need to be “bound” to your application, once you’ve created your app.
If your app is already deployed, you can do the binding right from the wizard.
Or from the UI, by navigating into the details of the service instance
Alternatively, and probably the usual use case, is to declare the application binding in the yml file of the application, before deploying it.


3) create destination configuration


After having created an instance of the Destination service, you need to create a destination configuration.
That configuration can then be accessed from your java coding.
There are 2 possible levels: either you create a destination configuration  on subaccount level, or on instance level.
On subaccount level means, the destination configuration can be used by all apps, whereas instance level means, it can be used only by that app
This description shows how to create a destination configuration on subaccount level.
On the bread-crumb menu, click on your subaccount:, e.g. “trial”



On the navigation pane, expand the entry “Connetivity”, then click on “Destinations”



Then you can click on “New Destination”



and enter the details for a new Destination configuration



After pressing Save, you can try the Check Connection button



After going through this prerequisite-section, you’re ready to use a destination from your application.
You’ve created:
XSUAA service instance
Destination service instance
Destination Configuration

Make sure to note down the names of the 2 service instances and of the Destination-Configuration-name
After you’ve created your application, you have to bind it to the 2 service instances (can be done in the manifest).
The name of the Destination Configuration is used in the Java code (required by the S/4HANA SDK or the Data Source for OData V2 consumption)




Using empty JWT token

The OData service which we create, exposes data which in turn is fetched from a different target service.
That target service my require authentication, which is stored in a destination (a so-called technical user)
Our service which we create, doesn’t require authentication, during the prototyping phase.
As such, there’s no security mechanism in place.
However, when connecting to an OData V2 service, the framework requires a JWT-token, otherwise it refuses to connect, for security reasons.
But during prototyping phase, this can be workarounded.
We can set the environment variable ALLOW_MOCKED_AUTH_HEADER with value true
In that case, the framework will generate an empty JWT token

The environment variable can be set via command line using the CloudFoundry Client tool:
cf set-env <appNAme> ALLOW_MOCKED_AUTH_HEADER true

Make sure to replace the placeholder <appName> with the name of your application which you’ve deployed to CloudFoundry
After executing this command, you’ll need to restage or restart your application


Alternatively, you can specify the env in your manifest, such that you don’t need to execute that command each time.

Your manifest.yml  will then contain these lines:
- name: demoapp
path: ...
- demoxsuaa
- demodestination


While using your OData service, the framework will print a warning to the log, indicating that the described workaround is used and that it isn’t recommended.