Skip to content

Configuring Destinations

In several situations, generated OData services may need to access databases or back-end systems identified by a destination name.

Destinations for Cloud Foundry

For SAP Business Technology Platform (Cloud Foundry environments), use the -dest option in build-cloud.options to specify the name of your SAP Business Technology Platform Destination Service Instance. Then, use the SAP Business Technology Platform Cockpit to configure destinations as needed.

  • HTTP destinations let users access remote REST systems or remote HANA systems.

    • Set the destination property PROPAGATE_AUTHORIZATION to false to prevent client credentials from being forwarded to the backend. This ensures that technical credentials are always used. This setting also applies to Destinations for Local Servers.

  • RFC destinations let users access remote SAP systems through the SAP Java Connector.

  • For access to on-premise SQL databases, refer to the topic "Using the TCP Protocol for Cloud Applications" in the SAP Business Technology Platform Connectivity documentation. This approach works only for database products that support JDBC via a SOCKS5 proxy, such as SAP HANA. If this limitation hinders connectivity to the back-end databases, a recommended solution is to deploy the generated OData services to an on-premise Apache Tomcat environment. You can then use SAP Cloud Connector to access the on-premise Tomcat from SAP Mobile Services.

Destinations for Local Servers

For local or on-premise servers, place a destination properties file in the appropriate conf subfolder of the Tomcat server. If this subfolder doesn't exist, you'll need to create it manually. Define each property on a separate line using the format propertyName=propertyValue.

  • To configure an HTTP destination, edit the <tomcat-home>/conf/http/<destination-name>.properties file. Include an url property with the back-end system URL. Optionally, add username and password properties for HTTP Basic authentication.

    If you provide the username or password properties for preemptive basic authentication, you can use client registration bindings. These bindings help you obtain the necessary credentials from a property of the ClientCredentials entity.

    You can enable Client Certificate Authentication for the back-end system by configuring the following properties: * KeyStoreLocation: Specify the location of a Key Store file. It supports files in the following formats: pem, jks, p12, and pfx. * KeyStorePassword: Specify the password for the Key Store file. You need this password when you provide the KeyStoreLocation. * TrustStoreLocation: Specify the location of a Trust Store file. It supports files in pem, jks, p12, and pfx formats. If you don't provide a location, the JDK Trust Store is used. * TrustStorePassword: Specify the password for the Trust Store file. You need this password when you provide the TrustStoreLocation.

    To address more complex HTTP back-end authentication needs, customize the generated HeaderProvider class.

  • To configure an RFC destination, edit the <tomcat-home>/conf/jco/<destination-name>.properties file. Include properties such as jco.client.ashost etc. Make sure the sapjco3.* files from the SAP Java Connector are installed in the Tomcat server's lib directory.

  • To configure an SQL destination, edit the <tomcat-home>/conf/jdbc/<data-source-name>.properties file. This file contains data source configuration parameters as defined by Apache Commons DBCP. For production systems, it's recommended to include the testOnBorrow and validationQuery properties. These help the OData service recover gracefully from broken database connections. Additionally, use the maxTotal property to set the maximum number of concurrent connections to the database.

Local Password Obfuscation

For local or on-premise servers, properties files containing destination properties may include password (for HTTP or JDBC) or jco.*.passwd properties (for RFC). These passwords can be expressed as plain text. It's preferable to obfuscate these passwords, using a form of reversible encryption, to reduce the risk of accidental disclosure.

Find the hide-password script in the same folder as the csdl-to-war script. Use it to generate an obfuscated password. You can then replace the plain text password in the destination properties file with this obfuscated version.

Caution

The server runtime needs to unobfuscate passwords in-memory to present them to the back-end systems for authentication. Obfuscation is a type of reversible encryption, meaning that anyone with access to the obfuscation mechanism or memory contents could potentially recover the original credentials. Therefore, the folder containing the local Tomcat installation should have permissions that allow access only to the user who owns the Tomcat server, minimizing the risk of exploitation by malicious insiders or compromised local accounts attempting to extract sensitive data.

Last update: November 20, 2025