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 ALLOW_MOCKED_AUTH_HEADER true
The following section describes the 3 required steps:
- Create instance of xsuaa service.
This is required for destination service
- Create instance of destination service.
This is required to make use of destination configurations
- 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: https://account.hanatrial.ondemand.com 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.
XSUAA service instance
Destination service instance
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 ALLOW_MOCKED_AUTH_HEADER true
Make sure to replace the placeholder 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:
applications: - name: demoapp ... path: ... env: ALLOW_MOCKED_AUTH_HEADER: 'true' services: - 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.