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: 


Cloud Integration capability of SAP Integration Suite ensures that only authorized client is able to call integration flow endpoint (see Setting Up Inbound HTTP Connections (Integration Flow Processing)). However, if you have multiple parties (could be both internal and external) that need to consume your integration flows, it can be tricky to make sure that integration flows which are intended for one party cannot be called by another party. What you would probably end up doing is creating multiple Process Integration Runtime instances with custom roles and somehow distributing client credentials/certificates among your consumers.

So, is there a more straightforward and secure way of managing this? Maybe even the one where the consumers can subscribe to the endpoints intended for them on-demand? And what if we want to add additional layer of security, traffic management and even monetization? Can this be done?

The answer to all these questions is resounding Yes! And in this blog I will outline how to achieve this by leveraging API Management capability of SAP Integration Suite.

The Approach

Let’s start with stating the fact that the integration flows (or API-Based Integration Artifacts) that were deployed on Cloud Integration and have publicly accessible endpoints are essentially APIs. So, I will refer to these artefacts as ‘APIs deployed on Cloud Integration’ further in this blog.

The end goal is to publish APIs on an omni-channel platform which can be used by authorized developers to:

  • explore all the APIs they are authorized to invoke;

  • obtain individual set of credentials they need to use to call these APIs.

To achieve this goal, we would need to perform 3 major steps:

  1. Create API Proxies for the APIs deployed on Cloud Integration and (optionally) apply Policies to secure the APIs, manage traffic to them, control access, etc.

  2. Bundle API Proxies to API Products, configure Permissions and publish API Products to API Business Hub Enterprise (a.k.a. Developer Portal).

  3. Onboard internal and/or external developers so they can subscribe to and consume the APIs centrally.



Create an API Provider

First, we need to configure Cloud Integration as an API Provider so that we can easily discover all APIs deployed on Cloud Integration when creating an API Proxy.

Following the procedure described in Create an API Provider | SAP Help Portal to configure your Cloud Integration as an API Provider.

Note that you should retrieve all the necessary connection details by following the procedure described in Setting Up OAuth for Cloud Integration in Cloud Foundry | SAP Help Portal.

Create API Proxies

Create API proxies for the APIs deployed on Cloud Integration by following the guide: Creating an API from SAP Cloud Integration API Provider | SAP Help Portal.

For our demo use case let’s create API Proxy for just one integration flow that returns product details of ESPM Webshop. The detailed instructions on how to configure and deploy such an integration flow can be found in this tutorial.

Add Policies to API Proxies

One of the most essential and widely used Policies of API Management is Verify API Key policy. This Policy ensures that only authorized and subscribed consumers (applications) can invoke the APIs by verifying the validity of API Key (that can only be obtained by subscribing to the relevant API Product in API Business Hub Enterprise). The Verify API Key By Header Policy Template is supplied as part of SAP API Management Security Best Practices API Package. Learn how to Discover API Packages and Apply a Policy Template to apply this policy to your API Proxies.

You may also want to apply URL Masking API Policy Template to mask the underlying Cloud Integration endpoint from your consumers and add and configure other Policies, as per your use case. Please see Create a Policy | SAP Help Portal and SAP API Management Policies blog for full list of Policies available with API Management. Please also see the API Recipes page on GitHub for samples of API Proxies, Policy Templates and more.

Create API Product

An API Product represents a collection of API Proxies which can be bundled together logically (e.g., “SAP SuccessFactors Integration”) or by consumer (e.g., “APIs for XYZ Company”). Follow the procedure described in Create a Product | SAP Help Portal to create and publish API Product to API Business Hub Enterprise.

For the demo use case I’ve created an API Product ‘ESPM_Webshop_Integration’ and added only 1 API Proxy to it. In the real world scenario, you would probably want to bundle multiple API Proxies into one API Product.

Assign Permission to API Product

We need to assign permissions on the API Product level to manage and control what consumers can view and/or consume APIs of this API Product. For detailed instructions on how to configure Permissions please see blog API Management – API Product Permissions.

For our demo use case let’s assign ‘Webshop_Developers’ role to restrict Discovery and Subscription operations only to the authenticated users of our API Business Hub Enterprise platform that are assigned to this role.

That way we can ensure that only developers with the role ‘Webshop_Developer’ can view and subscribe to API Product ‘ESPM_Webshop_Integration’ in API Business Hub Enterprise.

Onboard Developers to API Business Hub Enterprise

As an Administrator you can onboard multiple users via API Business Hub Enterprise UI or ask your API consumers to go through self-registration process. There is also an option to automate user onboarding process by utilizing API Business Hub Enterprise - Registering Users(CF) API. For more information on the topic please see Register on API business hub enterprise | SAP Help Portal.

By default, developers would need to authenticate to API Business Hub Enterprise via SAP ID Service. That means that you would need to add them as users of your BTP subaccount and assign roles to them directly via SAP BTP Cockpit. However, many of our customers are using SAP Identity Authentication service (SAP IAS) as their corporate user store or as a proxy to their actual corporate user stores.

For instructions on how to configure IAS as an identity provider for your SAP BTP subaccount please follow the blog: Setup an Identity Authentication service (IAS) as an Identity Provider for the Integration Suite or Single Sign On to SAP Integration Suite / SAP API Business Hub Enterprise via Open ID Connect (OIDC)....

In the end, your API consumers would login to API Business Hub Enterprise with available identity provider and discover, subscribe and invoke the APIs for which they have necessary permissions.

For our use case, let’s assume we have 2 users ‘integrationuser01’ and ‘integrationuser02’. We will assign the role ‘Webshop_Developers’ only to user ‘integrationuser01’. That means that when user ‘integrationuser01’ logins to API Business Hub Enterprise, he can find and explore ESPM Webshop API Product as well as obtain Application Key which is required for calling our API.

However, when ‘integrationuser02’ logins to the same site, there is no API Products available for him.

This way we can successfully manage and control which parties are authorized to discover and/or obtain valid credentials for calling our APIs (integration flows).

Closing Remarks

Managing connections to APIs deployed on Cloud Integration through API Management helps you streamline your own operations but also provide much better experience to the consumers of your APIs – with API Business Hub Enterprise they have a central space where they can discover, consume, test, monitor health and usage of the APIs.

Creating API Proxies for APIs deployed on Cloud Integration is especially critical when you need to expose these endpoints to external parties. For such use cases you might want to mask the underlying Cloud Integration URL in the response body, restrict access only to certain IPs, add validation/threat protection policies – all this is possible with API Management.

The approach described in the blog can also be applicable when you want to configure certificate-based authentication to APIs deployed on Cloud Integration and use the certificate which is associated with a concrete user and not clientId of Process Integration Runtime service instance. See SAP Cloud API Management – Enable Client Certificate Authentication on API Proxies.

It is worth mentioning that for every call to Cloud Integration endpoint that is routed through API Management proxy 1 additional message will get consumed, as per 2942344 - SAP Integration Suite - Message Metric Definition. However, here I would like to point out that the prices for additional messages of SAP Integration Suite have been lowered, making additional messages consumption more affordable at every volume level. I welcome you to review the prices for Messages on SAP Discovery Center – SAP Integration Suite – Pricing.

Questions? Please use the blog comment feature or reach out to me.