Product Information
SAP Cloud Integration – Step towards Building API Based Integrations
Update
The below described API artifacts availability depends on your tenant licensing model, more information at https://help.sap.com/viewer/368c481cd6954bdfa5d0435479fd4eaf/Cloud/en-US/997501da152d419d96c92f7bfbd7b6f3.html
Update
Due to unavoidable reasons, the release of below mentioned feature is postponed to next release cycle. Hence, the below mentioned feature will be available with SAP Cloud Integration version 3.34.*/5.18.*/6.10.* . Updated the blog post’s introduction part accordingly. Initially it was planned to release as part of version 3.33.*/5.17.*/6.9.*.Only renamed type OData API from OData Service will reflect in 3.33.*/5.17.*/6.9.*.
Introduction
SAP Cloud Integration, one of the capabilities of SAP Integration Suite, brings a new feature from version 3.34.*/ 5.18.*/ 6.10.* which takes a step towards strengthening design of API based integration scenarios. In this blog post, information about this new feature will be provided.
REST API, SOAP API and OData API
Users can now create a new integration artifacts of type REST API, SOAP API and OData APIs. OData APIs are the rename of previous OData Services artifacts. These artifacts generate a default integration template which can be further extended to meet API based integration needs.
API Artifacts Menu
Note: We are fixing the sorting of these menu entries 🙂
Once you select the menu entry, creation dialog will popup
REST API
Select REST API to create an REST API based integration scenario.
Create REST API Artifact
Once you create REST API integration scenario gets created
Clicking on the artifact, integration with basic template is displayed. For REST API, HTTPs sender adapter is added in the template.
REST API Integration Template
Add the required endpoint address name fo the HTTP sender adapter. The template can be further extended to fit your API integration scenario
REST API with HTTP Sender Adapter
SOAP API
Select SOAP API to create an SOAP API based integration scenario.
Create SOAP API Artifact
Once you create, SOAP API integration scenario gets created
Clicking on the artifact, integration with basic template is displayed. For SOAP API, SOAP 1.x sender adapter is added in the template.
SOAP API Integration Template
SOAP API with SOAP Sender Adapter
OData API
Note: OData API is the renamed type of previous OData Service
Select OData API to create an OData API based integration scenario.
Create OData API Artifact
Once you create, OData API integration scenario gets created
Clicking on the artifact, integration with basic template is displayed. For OData API, OData V2 sender adapter is added in the template.
For OData API artifact, a default method and a sample EDMX file is generated in the template
Monitoring
Once you extend the API templates and complete the integration scenario, you can save and deploy them.
Deployment View
To view the deployed artifacts, as of now, monitoring doesn’t provide a default tile to view the deployed artifacts, you need to create a tile to view them.
Add a tile under Manage Integration Content
Add new tile in Manage Integration Content section
Select API type for tile
Clicking on the tile displays the details
Message Processing view
To view the message processing status for APIs, you need to add the tile under Monitor Message Processing section
New tile under Monitoring Message Processing section
If user invokes API endpoint, e.g., a REST endpoint from POSTMAN application, then message processing status will appear in this new tile
Invoke REST API endpoint
Details of the message processing details
Note:
- If you have already deployed the previous OData Service artifacts and created a tile for it, then such previously created tile will be appear as OData APIs.
- You can repeat the same process to get a tile for SOAP API artifacts by choosing SOAP API type for new tile
Next Steps
As mentioned, this feature is a step towards building API based integration scenarios. And there are more supporting enhancements coming.
Considering API Definition
As of now, you might have noticed, in REST API and SOAP API based integration scenarios doesn’t take API definition (e.g., Open API Spec/Swagger JSON for REST API) as source. In the next upcoming increment, implementing an integration considering API definition file shall be supported.
Enhancing the templates
For API based artifacts, the sender adapter selection and validation will be enhanced to match the type of artifact, e.g., only HTTPs adapter as sender for REST API artifact.
Summary
This is an initial step towards strengthening SAP Cloud Integration capability to support building API based integration scenarios. As of now, they are integration artifacts with basic templates, but going forwards, more and more API related capabilities shall be added.
Thanks for your blog,
But I don't see the value added of creating an artefact type "API" instead of creating an Iflow starting with a sender "API" (rest,soap...) ?
Because the predefined template of this flow is not really a value added. it's only few click to get the same result starting from Iflow artifact...
Is it a way to better onboard the API management APIs for the future ?
Hi Aurelien,
Thanks for the feedback. As I have mentioned, these are the initial steps for us in SAP Cloud Platform Integration to create a technical baseline on the API based integration.
And yes, in upcoming releases, we have the plans to bring SAP API Management closer to SAP Cloud Platform Integration.
Thanks
Deepak
Hi Deepak,
These are not any new capabilities right? Except the options to create templates for Rest, SOAP and additional tiles in monitoring, these still creates integration flows even though the type changed.
Swagger documentation based API generation is cool but this is already a feature available in API Management and generating APIs based on that code. When clients asked for a Rest API, we use HTTP sender adapter and create an iFlow.
Further more enhancements like supporting multiple HTTP operations similar to OData service under a single API would be helpful. Thanks for the effort on writing this blog.
Hi Anil,
Thanks for the feedback. As I have mentioned, these are the initial steps for us in SAP Cloud Platform Integration to create a technical baseline on the API based integration.
And yes, going forward, supporting multiple HTTP operations as similar to OData API (the renamed OData Service artifact) under a single API is in our plan and once available, I will share the updates via blog.
Thanks
Deepak.
It's a good starting point, looking forward to seeing how it evolves 🙂
Hi Maximiliano,
Thanks for the inputs. Yes, it is the starting point and more support and enhancements for 'API based integration scenario development' will be provided going forward.
Thanks
Deepak
Hi Deepak,
Is there any plan to add a capability to import the API specifications from SAP API Management and keek it in sync?.
Kind Regards.
Max.
Hi Max,
Yes, it is in our plans.
Thanks
Deepak
Thanks for sharing the new features in advance.
Is this baseline features releasing soon or it will release later with more capabilities?
Regards,
Souvik
Hi Souvik,
Yes, this baseline feature will be released first and then in subsequent releases, enhancements shall be added.
Thanks
Deepak
Hi,
I see that once you have defined a type of e.g. Integration Flow you cannot change into REST API anymore. I have approx. 20 Integration Flow I want to redefine as REST APIs.
Best regards,
Marco Verhoef
Hi Marco,
As of now, there is no option to convert Integration Flow to REST APIs, but this is something that we are working on to enable to support.
Once such a feature is enabled, you will be notified via release notes, documentation and I will update/create a relevant blog.
Thanks
Deepak
I don´t fully get the idea. At the end it looks like an overlapping feature with SAP API Mgmt. service.
Why would I create APIs in CPI, when API mgmt. service can do that for me easily, meaning exposing backend services or CPI iFlows as API end points. could you please shed some light here?
Hi Jitendra,
In API Management, you don't 'implement' the API, but you only 'manage' them. So, this is the first step from CPI side to come up with REST/SOAP API Artifacts, such that, you can implement an API.
As of now, with this first step and via Integration Flow, e.g. with HTTP sender, you will define the integration scenario which can be equated to the API implementation, but with the "API definition" file.
Going forward, our next step is, we will allow you upload/create API definition file/Swagger file in SAP Cloud Integration REST API artifact, and you would then be able to use that definition file to implement the scenario with supported back-end services
I hope this clarifies
Thanks
Deepak
Hello Deepak,
Currently we are implementing IBP with Ci-DS (2111). From the available options, when we choose REST web service it expects a WADL path. Our provider only supports RAML or Swagger. How can we proceed from here?
Tom
Nice blog. good step towards making CPI more user friendly.
Hi,
can this API be then deployed on PO Cloud Integration Content( CPI Runtime), like rest of the IFLOWS can ?
ifnyes then can it be independently hosted from PO runtime as full fledged API ?
Hi,
No, these API artifacts cannot be deployed/consumed in PO.
Thanks
Deepak
Hello Deepak,
Why I can't see the "REST API" and "SOAP API" in our tenant integration, we only have the OData API, is it the old release of integration? how to upgrade to the latest version?
Thanks for your sharing!
Hi
you need CPI license standard or premium edition to have REST API and SOAP API
Thanks Dalius~ Found the related notes.
Hi,
As mentioned by Dalius in his comment, you need to have relevant license type, for more information, please check out the documentation at https://help.sap.com/viewer/368c481cd6954bdfa5d0435479fd4eaf/Cloud/en-US/997501da152d419d96c92f7bfbd7b6f3.html
Thanks
Deepak
Thanks Deepak~It's helpful information