SAP API Management: Discover Integration Flows from CPI tenants and auto-generate APIs
Update from Jan 2021:
It is now possible to also discover OData, SOAP & REST API artifacts from Cloud Integration using the below mechanism. See this blog for information.
SAP Cloud Platform API Management can be used to create connected omni-channel experiences for your consumers, partners and employees. And in many cases, building integrations to link processes and data across applications or across businesses form an intrinsic part of this exercise. Cloud Platform Integration can help you implement these integration scenarios. For more information about Cloud Platform Integration (CPI) refer to this link. Once you have the integrations in place API Management will help you bring in additional security compliance, traffic management, implement Usage reporting, monetization etc.
A typical solution pattern where API Management and Cloud Platform Integration services are used in conjunction is depicted in the figure below. You can build enterprise integration scenarios using CPI and the pre-packaged content from SAP API Business Hub. You can build low-code APIs using SAP API Management. Connectivity with SAP Cloud Integrations will be achieved via API Providers. Security risks can be minimized by applying security best practices from SAP API Management. You can also gain insights on API usage and traffic with the inbuilt Analytics dashboard.
In order to achieve the above solution architecture, you should be able to discover the Integration Flows from CPI and create corresponding APIs in API Management to further strengthen it with security or traffic management policies.
In this blog, I write about how easily you can discover the Integrations Flows deployed in your CPI tenant from your API Portal and generate an API for the same with minimal steps.
- You already have a CPI tenant and have atleast one OData type Integration Flow deployed on it for your integration scenario.
- You already have setup API Management and have access to API Portal as an Administrator.
Create an API Provider
To begin with, you need to create an abstraction to your CPI tenant where all your Integration Flows are hosted. In order to do so, create an API Provider of type ‘Cloud Platform Integration’ with all the necessary details.
Note: You need to enter the co-ordinates and the credentials to connect to your CPI Web UI tenant.
Once the API Provider is saved, you can also check your details by clicking on the ‘Test Connection’ action. If everything looks fine, you are ready to use this API Provider to browse through the Integration Flows and generate an API for any chosen Integration Flow.
Generate an API
Start creating the API from the Develop tab.
Choose the API Provider that you just created and click on ‘Discover’.
A dialog displays all the OData Integration Flows from the tenant. Choose the one for which you need to generate an API and click on ‘Next’.
Enter the credentials to connect to the Integration Flow and click on ‘Done’.
Now the details of the Integration Flow will be used to populate the API details. You can edit basic details like name, title, description, base path etc. tailored to your needs.
You will then be taken to the API details page where you can decide to browse through the created resources.
Add Policies to manage traffic
Click on ‘Policies’ to enter the Policy Designer page. Select ‘PreFlow’ under ‘ProxyEndpoint’ and add a ‘Quota’ policy on the incoming request stream. Let’s leave the default policy snippet as is, which allows a maximum of 2 calls on the API within a minute. Deploy the API with the changes.
Test your API
A quick verification of the API can be done by invoking the API Proxy URL in either the Test console or any other client like a Web browser or Postman. If you make more than 2 calls within a minute, the API responds with a failure message since the allowed quota is exceeded.
As you can see, in less than a few minutes you could discover the Integration Flows in your CPI system, create an API for a selected Integration Flow and add policies to bring in the necessary behaviors on the API. This empowers you to easily implement best practice solution architectures in your enterprise integration projects. Give this feature a try and let us know what you think.
Question for you. Can we discover other iflows with http as REST service in API? Your blog talks about ODATA iflows only.
Yes, this is something that we intend to do in future.
do you know when this can be available?
if it is not available in near future then can we manually add HTTPS CPI end point against CPI API. PROVIDER ?
we tried that but getting 404 HTTP error even if API provider connection is tested okay
also if not available through CPI API provider , we were planning to use “Internet” as API Provider to use CPI end point but not able to find a way to get CPI SSL certificate pair to load into API management for SSL to work
Appreciate your response
We intend to enable this by end of this year. Yes, you can manually choose the Internet provider type , skip the discover URL but configure directly the Integration flow REST service URL.
thank you for sharing this opportunities! That's really great.
I'm looking forward to have that in place for CPI on Cloud Foundry, as we have our CPI on CF setup to have a painless orchestration with all the other services (e.g. Enterprise Messaging Service, Business Rules, ...).
Is there already some timeline for this Service-Catalog feature for CPI at Cloud Foundry ?
Thx and Regards, Cedric
Yes, this support should be made available in the next months
Do you have any information or a new timeline when the Service-Catalog feature for CPI is enabled for Tenants on Cloud Foundry?
This should be available now
I tried configuring API provider for CPI tenant and tried discovering ODATA APIs but below error
Error: Service URL not found. Try again with a valid URL.
API Provider Configuration:
Are you using the type 'Cloud Platform Integration' when creating the provider? Could you cross check?
Thanks, I was using type 'Internet' as I did few months back and was not aware of type 'Cloud Platform Integration'
thanks a lot for your blog.
I just have a question confuse me, I can found the successfactors API also existing in CPI API area, so what is the difference that I consume the API from successfactors API directly or consume from CPI?
Hello Ren Sui
More often, you may want to perform an integration with another system before consuming a service. This is where CPI can help you. You can integrate the successfactor API with lets say ERP and then call the integration flow endpoint to invoke the integration. Now if you want to further expose this integration flow endpoint securely or manage traffic on this endpoint, you can make use of API Management. This adds an additional protective layer on your integration flow endpoint and also can provide a simplified API URL for it. Hope this clarifies
Thanks a lot for this blog, it looks it could help with my problem.
We have third party system we communicate with. Their outbound services does not allow any type of authorization, basic, certificate, nothing, so they are not able to call the SCPI iflow directly.
Is it possible solution to create API , whitelisted the allowed addresses for access this API and call it without any authorization? Of course the API would be further connected to existing integration iflow as described in this blog with basic authorization access to SCPI.
Thanks a lot for your opinion or any other suggestion
APIM does not mandate any specific auth type. It is left to you to choose what authentication mechanism you would like to use for the API or use none at all. So your approach is okay.
Thanks for the blog. It is very helpful.
My question relates to setting up OAuth. For the initial provider setup, I am using an OAuth client ID/secret from the BTP platform. This works well and allows me to discover the available APIs from the SAP Cloud Integration when creating a new API.
When creating a new API, a new API Provider is created for the flow specifically, which now uses another OAuth client ID/secret combination that is connected to running flows, rather than discovery.
This scenario works fine when we want to use the OAuth client to connect API Management to CPI to run flows. I tested and works well.
When switching to principal propagation (e.g. SAML bearer flow : https://api.sap.com/policytemplate/Principal_Propagation_via_SAML), we have one flow requesting the token (locally within API management) and another one using the token and connecting to the Cloud Integration flow. This last request now is conflicting between the provided Authorization header and whatever the background is doing with the flow specific API provider. (OAuth client credentials)
Is the suggested approach to remove the flow specific provider and replace with a URL? Wondering if there is another approach or future roadmap item to support principal propagation?