Leveraging Open Service Broker to connect SAP Cloud Platform with Azure Services
Published Jun 11 2019 01:00 PM 13.8K Views
Brass Contributor

SAP Cloud Platform and Open Service Broker

A few weeks ago, Harini Gunabalan from the SAP Cloud Platform Product Management published a blog on how to use the Open Service Broker with Azure. Within a few weeks the blog attracted quite a few thousands views and was followed by a series of related blogs by Marius Obert on what you can actually do when combining SAP Cloud Platform, Open Service Broker and Azure.


In this blog I want to outline a few basic things and also get you started.


When I tweeted about Harini's blog there were quite a few questions why this approach should actually be used. From my point of view it addresses one major concern that companies have that want to leverage SAP Cloud Platform. SAP Cloud Platform offers a great platform for SAP customers not only to integrate in existing SAP services, but also build new ones that leverage (business) services that are exposed via this platform. The SAP Cloud Platform is probably SAPs best manifestation of the new "multi-cloud" approach which allows customers to leverage hyperscalers like Microsoft with Azure to "host" SAP services anywhere in the world, really leveraging the infrastructure that Azure provides. With this approach SAP is able to concentrate on three key pillars of SAP Cloud Platform: Extend (existing SAP Fiori services for example exposed via SAP S/4HANA), Integrate and Innovate using new business services (like Master Data or Taxation services).

That is where the real value from my point of view lies when looking at SAP Cloud Platform. (SAP) developers wanting to integrate in existing SAP services or want to leverage business services have a perfect home in the SAP Cloud Platform.


However, when comparing technical services offered by the SAP Cloud Platform with services from Azure, SAP Cloud Platform is does not always offer the same functionalities. That is exactly where the Open Service Broker for Azure (OSBA) comes in. Leveraging OSBA SAP developers can easily consume these services directly from SAP Cloud Platform. They would not even need to know who their Azure admin-colleague is, how to connect to an Azure subscription, evaluate which services are useful, how to connect / authenticate to these services, …

After an admin has setup OSBA once and connected it to Azure, these services are available for any developer using the SAP Cloud Platform. A SAP developer would not even need to know that these services are coming from Azure. 



So what exactly is this Open Service Broker and why should you use it?

First of all, when you are one developer looking for combining services from SAP Cloud Platform and Azure, you probably don't need it. You can develop your application anywhere and just select the services that you are interested in (if you have access to Azure). However, when you want to provide a platform for the developers in your company, which might not know where and what services are available from Azure as well, OSBA can be a perfect start. You can provide these services to your fellow developers without having them to figure out how to get access to Azure, how to authentication, …

The Open Service Broker API (https://www.openservicebrokerapi.org) defines the interactions between (in this case) the SAP Cloud Platform and the services offered on Azure.

Actually Open Service Broker is not limited to Cloud Foundry, you can also use it for Kubernetes and other open platforms.


In order to get you started with Azure, Microsoft has released the implementation of Open Service Broker for Azure on GitHub (https://github.com/Azure/open-service-broker-azure, https://osba.sh). As of today there are a bunch of stable Azure services available (like PostgreSQL, CosmosDB, …) and lots more currently being evaluated.


Getting started is quite easy (and I will guide your through the SAP steps as well). The steps below are based on the instruction mentioned https://osba.sh/


Sign-up to SAP Cloud Platform

At first you need an account for the SAP Cloud Platform. You can easily sign up at https://account.hanatrial.ondemand.com/cockpit/#/home/trialhome


Once you have your user you can access the two environments of SAP Cloud Platform. We will skip the older one (Neo) and focus on the Cloud Foundry Trial. Click on this tile and make sure to select Europe (Netherlands) to get SAP Cloud Platform running on Azure.01-SCP.png

Initial setup only takes a few seconds and then you are ready to go:02 - CFTrial.png


From here we can go the Cloud Foundry Space and from Services -> Service Marketplace we can see a list of default services which are available in SAP Cloud Platform.03- SCP Cockpit.png

All these services can be used by developers in your company to create business applications. In order to give them choice and even more options the Open Service Broker for Azure will list even more services.


Leverage Azure Cloud Shell to setup OSBA

The OSBA uses Redis as a backing service. So the first thing we need to do is setup this Redis Cache. The easiest way to do this is using the Azure Cloud Shell, which can be accessed from https://shell.azure.com


A good starting point is always to check the Subscription ID which you are currently running in. Just run

az account show --query id

04 - AZ Show.png


And note down the ID, because we will need it later on when updating the manifest.yml file from the OSBA project.


This is the ID of your subscription that you can also see when you go to the Azure Portal (http://portal.azure.com) and select Subscriptions:05 - Portal Subcription.png


Now you can verify if you have already a Redis cache created by issuing


az provider show -n Microsoft.Cache -o table

If you get a NotRegistered

06 - AZ Provider.png


You need to register and create it first.


az provider register --namespace Microsoft.Cache


This might take some time and you can check the process by running the provider show command.

After a few minutes the status should chance from Registering to Registered

07 - AZ Registered.png


In Azure you group resources in so called Resource Group. So the first thing to do is to create a Resource Group. We will call the Group osbaRG and locate it in West Europe


az group create -l westeurope -n osbaRG

08 - AZ Group Create.png
Now we can create the cache in this resource group using


az redis create -n osba-cache -g osbaRG -l WestEurope --sku Standard --vm-size C1


09 - AZ redis create.png

Note down the hostname which will be used later. 

If you want, you can also verify this in the Azure Portal, where you can find the resource group and the cache:10 - Portal Redis.png


To retrieve the Primary Key you could do this again either via the portal (Settings -> Access keys) or you can simply run the command:


az redis list-keys -n osba-cache -g osbaRG


11 - AZ redist list.png

The Open Service Broker uses a service principal to provision resources in Azure. So we need to create this SP via


az ad sp create-for-rbac


12 - AZ sp create.png


This now creates a new service principal that we will used in the follow steps. Make sure to note down this information.


Clone the Open Service Broker for Azure from GitHub

Now we have all the information to get the Open Service Broker. For this clone the repo via

git clone https://github.com/Azure/open-service-broker-azure.git

13 - git clone.png


Once that is done you can use Code to edit the manifest.yml file located in the contrib/cf folder and update the variables with the information we retrieved so far. Keep in mind that you have to select a different name / route than the one I have specified since it has to be unique. In the Azure Cloud Shell, just type Code!


You can also update the buildpack to the latest, e.g.



Update 2019-10-06: Thanks to feedback to the blog, please update to the latest buildpack when encountering issues with cflinuxfs2 not being supported anymorehttps://github.com/cloudfoundry/go-buildpack/releases/download/v1.9.0/go-buildpack-cflinuxfs3-v1.9.0... -- THANKS ravipati9

14 - VS Code.png


Hint: since you need to copy and paste the Redit host and password twice, make use of Codes Strg-D and Paste feature.

Once done, use Strg-S and Strg-Q to Save and exit the file.


Connect to SAP Cloud Platform

We are now ready to push the Open Service Broker for Azure to Cloud Foundry. For this we need to connect to the Cloud Foundry environment on the SAP Cloud Platform.


At first we need to set the right API URL for the SAP Cloud Platform. In my case I use


cf api https://api.cf.eu20.hana.ondemand.com

to set the Cloud Foundry environment on Azure in Europe (you can find additional regions and endpoints here)

15 - cf api.png



after that you can login via


cf login

and the email and password that you used for your SAP Cloud Platform account.

16 - cf login.png

With this you can issue a cf push command. Make sure that you do this from the root where you have downloaded the Git repo:


cf push -f contrib/cf/manifest.yml


17 - CF push.png


After a few minutes you should get a result that the app is now running:


18 - cf waiting start.png


If you log on to the SAP Cloud Platform, go to your space -> Application you can also see the App there:

19 - SCP app starting.png


Register the Service in Cloud Foundry

With that the last step is to register the service in Cloud Foundry so that it can be used. For this issue


cf create-service-broker osba-service username password https://osba-service.cfapps.eu20.hana.ondemand.com --space-scoped

Where osba-service is the name of the Open Service Broker app that we deployed, username and password are the actual username and password that we specified in the manifest.yml and the URL is the routes that we got back when pushing the service to Cloud Foundry.20 - cf create-service-broker.png


when that is done you can check the SAP Cloud Platform Service Marketplace again where you will see several Azure services ready to be consumed by your developers!21 - SCP marketplace.png

From now on developers using the SAP Cloud Platform cannot only use the services provided by SAP to create applications, but can easily enrich applications using Azure services.


Use Mongo DB APIs in SAP Cloud Platform

Lets say you want to use a Cosmos DB in your SAP application. Then issuing from CF


cf create-service azure-cosmosdb-mongo-account account mongo-db-hbr -c '{"resourceGroup":"osbarg", "location":"westeurope"}'


would create a Cosmos DB (with MongoDB API) in Azure and make it available in SAP Cloud Platform. There is no need for the SAP developer to reach out and interact with the Azure admin to go back and forth to discuss details. It's just there and ready to use!


As a result you can see the service in CF:

cf service mongo-db-hbr


22 - cf service mongo.png


and of course also in the Azure Portal in the related Resource Group:


23 - portal rg.png



Now you are ready to go and develop new applications not only leveraging SAP, but also backing services from Azure!




June 20th, 2019: Small updates / corrections. Thanks, Max for the feedback!



Version history
Last update:
‎Oct 06 2019 08:55 AM
Updated by: