It is a common scenario that cloud applications need to connect to remote systems to fulfil the business goals of their creators. This is essential for enterprise applications, which are generally complex and consume or push data from variety of sources or destinations. Latter includes systems hosted in public or private cloud, or such that are hosted in the customer premises. This use case is called hybrid connectivity.

Sounds complex, right?! With this blog post, I show you that it has never been easier to solve this problem. Let’s get started and see how SAP BTP Connectivity can help with this challenge.

Prerequisites

Well, complex things cannot be made simple without proper prep work. Therefore, I need to setup the environment. For the purposes of this blog post, I don’t get into details on how each step is done, if interested, you can follow the links:

1. Setup the cloud environment:
   1. Create a SAP BTP subaccount – the PaaS context in the domain of SAP BTP
   2. Enable Kyma environment – the cloud native application hosting environment
      1. Enable Connectivity Proxy for cloud to premise technical connectivity, an integrated component in Kyma environment
      2. Enable Transparent Proxy for unified, virtually transparent technical connectivity to any destination or data source, an integrated module in Kyma environment
2. Setup the local environment
   1. Install Kubectl – the command line interface for connecting to and interacting with the Kyma instance
   2. Install Cloud Connector for controlled and secure exposure concrete systems or resources, hosted in a VPC on Hyperscalers or on-premises – in my case, on my PC.

Overview of the scenario

In this blog, I showcase how I can connect my cloud application to the following target systems. I start with trivial ones and continue with the more advanced use cases:

1. Google – direct connectivity without using any of the SAP BTP Connectivity software and services
2. Google via destination – direct connectivity with usage of SAP BTP Connectivity software and services
3. Google via destination and Cloud Connector – indirect cloud to premise connectivity – in my setup Google is directly accessible via my local Cloud Connector
   • Note: this is done only for the showcase, not expected to be done in production
4. SAP Authorization and Trust Management Service (XSUAA) via destination – OAuth based REST API
5. An HTTP system hosted on-premises – indirect cloud to premise connectivity
6. An HTTPS system hosted on-premises – indirect cloud to premise connectivity with Principal Propagation enabled, i.e., end-to-end secure user context propagation, a.k.a Single Sign On (SSO).

I pick those systems to showcase what I claimed in the begging of this blog – It has never been easier!

Note: For the creation of the destination pointing to XSUAA in step 4 of the scenario, I followed these two simple steps in BTP cockpit:

1. Create a service instance of service “xsuaa“, plan “apiaccess“
2. Create a destination pointing to the service instance via destinations UI – just a few clicks job!

Configure the scenario

To get the scenario in action, at first I need to configure the target systems as technical connection configurations, a.k.a. destinations. This way I control to which systems the application has access to, and can switch the used technical authentication and authorisation mechanisms on the fly – changing the destination attributes without affecting the experience of the consumer.

Expose the on-premises system to the cloud

For the destinations pointing to systems hosted in the customer premises (points 5 and 6 of the scenario overview), I need to securely expose those to the cloud.

You guessed it, for this I configure the respective Access Controls in my SAP Cloud Connector:

Image: Access Control entries in Cloud Connector

In this example, the two systems hosted in the on-premises are simple HTTP and HTTPS servers:

• System #1: localhost:8000 – serves HTTP, returns status code: 200 with the received HTTP request line as a message.

• System #2: localhost:9000 – serves HTTPS, returns status code: 200 with the received HTTP request line as a message, and the subject common name (CN) of the received X.509 client certificate as part of the HTTP request – the user context propagated from the cloud, achieving Single Sign-On (SSO).

Manage the technical connection configurations

One of the best practice for cloud native applications is to externalise any configuration and avoid coupling it with the lifecycle of the application, e.g. via hard coding it. I use Destination service for managing the technical connection configurations (a.k.a. destinations), as guided by the golden path defined in Cloud Application Programming model of SAP BTP.

In the context of my SAP BTP subaccount, I create the following destinations, pointing to the variety of systems I’ll connect my cloud app workload running in my Kyma instance.

Image: Destinations in BTP cockpit

Expose the destinations in the Kyma instance

To allow an application to consume the defined destinations, I declaratively expose only those I’m interested in, and are specific for this particular use case. For this, I create specific Destination Custom Resources, a common practice for cloud native applications based on Kubernetes. In Kyma environment, I can do this either via Kyma Dashboard, or via command line using Kubectl.

Image: Creation of a Destination CR in Kyma Dashboard

Shortly after the Destination CR is created, Transparent Proxy process it and updates the status of the Destination CR with a message that the technical connectivity is successfully configured and this destination is ready to be consumed.

Image: Status of a Destination CR in Kyma Dashboard

Using the same approach, I expose all the destinations required specifically for this use case.

Image: Destination CRs in Kyma Dashboard

It’s all set now, let’s play with the application.

Scenario in action: Connect the application to the remote systems

As described in the status message of the Destination CR, the Transparent Proxy exposed the referenced destination via the specified name in the form of locally accessible host, leveraging the concept of Kubernetes Service.

As result, it’s trivial for the application to connect to those local hosts, and this is the only needed step to be performed. It’s that easy!

For simplicity and versatility reasons, my application is represented by local terminal attached to a container running in a Kubernetes Pod in the Kyma Instance. Then I use cURL command line tool for executing HTTP requests towards the target systems.

How it’s done? Once connected to the Kyma instance via Kubectl, I run a sample cURL image as a Kuberenetes Pod and open a terminal session via the following command:

kubectl run mycurlpod -n sap-transp-proxy-system --image=curlimages/curl -i --tty -- sh

Executing request to Google:

This is a trivial direct invocation of the public web page of Google:

~ $ curl www.google.com -v
*   Trying 142.250.179.164:80...
* Connected to www.google.com (142.250.179.164) port 80
> GET / HTTP/1.1
> Host: www.google.com
> User-Agent: curl/8.4.0
> Accept: */*
> 
< HTTP/1.1 200 OK
...
< 
<!doctype html><html...<title>Google</title><script...

Executing request to Google via destination:

This is an example reaching the same public web page of Google, but this time via destination, locally exposed and served by Transparent Proxy, and centrally managed via Destination service:

~ $ curl google -v
*   Trying 10.111.255.220:80...
* Connected to google (10.111.255.220) port 80
> GET / HTTP/1.1
> Host: google
> User-Agent: curl/8.4.0
> Accept: */*
> 
< HTTP/1.1 200 OK
...
< 
<!doctype html><html...<title>Google</title><script...

Executing request to Google via destination via Cloud Connector:

This is an example reaching the same public web page of Google via destination, locally exposed and served by Transparent Proxy, Connectivity Proxy, and centrally managed via Destination service. The destination is configured to point to an on-premises system, exposed to the cloud via Cloud Connector:

~ $ curl mypremisegoogle -v
*   Trying 10.111.159.5:80...
* Connected to mypremisegoogle (10.111.159.5) port 80
> GET / HTTP/1.1
> Host: mypremisegoogle
> User-Agent: curl/8.4.0
> Accept: */*
> 
< HTTP/1.1 200 OK
...
< 
<!doctype html><html...<title>Google</title><script...

Executing request to XSUAA API via destination:

This is an example for getting the registered service instances of the current subaccount via destination, locally exposed and served by Transparent Proxy, and centrally managed via Destination service.

~ $ curl xsuaa-api/sap/rest/authorization/v2/apps -v
*   Trying 10.106.192.162:80...
* Connected to xsuaa-api (10.106.192.162) port 80
> GET /sap/rest/authorization/v2/apps HTTP/1.1
> Host: xsuaa-api
> User-Agent: curl/8.4.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< cache-control: no-cache, no-store, max-age=0, must-revalidate
< content-length: 10621
...
< 
[{"appid":"app123!b13","serviceinstanceid":"15442f82-7d82-11ee-b26d-ab53f17d39a5","planId":"HWEgt9/213f90b0+/7d82-11ee=","planName":"broker"...

Executing request to an on-premises HTTP server via destination via Cloud Connector:

This is an example of connecting to a simple on-premises HTTP server via destination, locally exposed and served by Transparent Proxy, Connectivity Proxy, and centrally managed via Destination service. The destination is configured to point to an on-premises system, exposed to the cloud via Cloud Connector:

~ $ curl mypremserver/test-path -v
*   Trying 10.110.23.19:80...
* Connected to mypremserver (10.110.23.19) port 80
> GET /test-path HTTP/1.1
> Host: mypremserver
> User-Agent: curl/8.4.0
> Accept: */*
> 
< HTTP/1.1 200 OK
...
< 
Response generated by HTTP server: 
GET /test-path HTTP/1.1

Executing request to an on-premises HTTPS server via destination via Cloud Connector with Single Sign-On enabled:

This is an example of connecting to an on-premises HTTPS server via destination, locally exposed and served by Transparent Proxy, Connectivity Proxy, and centrally managed via Destination service. The HTTPS server requires the cloud user identity to be propagated. The destination is configured with PrincipalPropagation as authentication type, and to point to an on-premises system, exposed to the cloud via Cloud Connector:

~ $ curl myppserver -H 'Authorization: Bearer eyJhbGciOiJSUzI1Ni...bwKMpAGKbhECqvkyibC7Q' -v
*   Trying 10.105.101.106:80...
* Connected to myppserver (10.105.101.106) port 80
> GET / HTTP/1.1
> Host: myppserver
> User-Agent: curl/8.4.0
> Accept: */*
> Authorization: Bearer yJhbGciOiJSUzI1Ni...bwKMpAGKbhECqvkyibC7Q
> 
< HTTP/1.1 200 OK
< server: envoy
< date: Tue, 07 Nov 2023 15:17:47 GMT
< content-type: text/plain; charset=utf-8
< content-length: 1956
< x-envoy-upstream-service-time: 657
< 
>>>>>>>>>
Response generated by HTTPS server: 
GET / HTTP/1.1
=========
Received X.509 client certificate with Subject: <Name([email protected])>

Summary

As you can see, it’s that simple! No matter of the type and hosting location of the target system, from the application development perspective the user experience is the same – simple, unified, virtually transparent, and the technical complexity is handled by the usage of software components and services part of SAP BTP Connectivity product portfolio:

• Destination service for managing the technical connection configurations (a.k.a. destinations)
• Transparent Proxy for unified, virtually transparent technical connectivity to any destination or data source, an integrated module in Kyma environment, also available in Docker Hub.
• Connectivity Proxy for cloud to premise technical connectivity, an integrated component in Kyma environment, also available in Docker Hub.
• Cloud Connector for controlled and secure exposure concrete systems or resources, hosted in a VPC on Hyperscalers or on-premises.

Тhis simple yet powerful approach enables application developers to focus more on their business goals and delegate the technical complexity to SAP BTP Connectivity, and at the same time the application administrators can manage the outbound technical connections (via destinations) without affecting the lifecycle and availability of the application itself.

Stay tuned and subscribe to What’s New for SAP BTP Connectivity page.