When it comes to IT Solutions, it is sometimes difficult to understand what exactly they do. Marketing material may be way to high-level and the documentation too technical. At SAP we have so called “Feature Scope Description” documents, which are nice, but do not articulate the business value behind the features.

Long story short: in this blog series, I will explain what you can do with SAP Cloud Platform API Management, and how this will benefit your business.

Note that these are my views on the product based on my experience, and reflect what I usually present in my customer interactions.

The situation

More and more companies are facing the need to open up their data to end customers, business partners and technology partners. This need emanates from business requirements such as apps for employees, apps for customers, simplified integration with SaaS applications or business partners.

Over the last 10 years, REST APIs have emerged as the de facto standard for communication of apps, web applications and integration scenarios: APIs are present everywhere, and should be managed just as any other asset, ideally centrally and through a single pane of glass.

Using an API Management layer will allow companies to:

• create an Omni-channel experience for customers and employees (mobile, web, devices)
• implement simplified Integration with various ecosystems (partners, suppliers, marketplaces etc.)
• expose data with external ecosystems to generate new revenue streams (Data-as-a-Service)

SAP API Management allows to efficiently address the requirements of the above mentioned challenges through the following key features:

• Configuration instead of coding: managing APIs consists of applying standard features in the areas of security, traffic management and mediation. All these features are pre-defined within SAP API Management, and simply need to be adapted to your needs.
  This allows to centrally simplify and streamline the management of APIs, in order to increase agility and to enforce central governance easily.
• Efficient API Publishing: one of the most important aspects of API Management, is to simplify API consumption for the Application Developer. Hence API Management provides a self-service and integrated Developer Portal, featuring self-service capabilities, searching, documentation, testing and subscription capabilities.
  This allows to reduce the time and effort of onboarding Developers, allowing for better time-to-market and reduced costs.
• Broad analytics: API usage is not limited to internal consumption, hence monitoring and analytics are even more relevant than before. API Management provides central, technical and business-driven analytic capabilities.
  This allows to quickly solve issues for increased user satisfaction and to steer your API program for an optimal return on investment of your digitalization projects.

The concepts of SAP API Management

High-level architecture

From a high-level perspective, SAP API Management is divided in 2 main areas: designing APIs through the API Portal, and providing APIs through the Developer Portal.

Within the API Portal, the API Builder can abstract an existing API or SOAP WebService (through the façade pattern) using so called “API proxies”. The API proxy should be the only access point to the actual API implementation, hiding internal information and providing specific behaviours that would otherwise be coded in the API itself, such as Security, Traffic Management or Data Transformation.
Having these features deported in an API Management layer will free up valuable development time for the API developers focusing on business features more than technical features.

Within the self-service Developer Portal, Developers can discover APIs, see their documentation, test them and eventually subscribe to them as needed. The Developer Portal is tightly integrated with the API Portal providing a streamlined process to publish APIs.
Having a self-service Developer Portal for App or Integration Developers will simplify usage of APIs and increase Developer Experience.

Once the APIs are being used by applications, apps, systems or by partners, they can be analysed from a technical and from a business perspective.

Configure your APIs: API Portal

When working with SAP API Management, customers are not changing the actual API implementation. They are defining API proxies, ie. facades, to existing APIs. Hence API developers can continue to focus on great business APIs, while security, traffic management and consumption of these APIs are taken care centrally by SAP API Management. The following chapter will focus on how these API proxies are configured in SAP API Management.

The API proxy as a starting point

Any REST API or SOAP Web Service can be handled by SAP API Management, but customers can work more efficiently when using specifications or standards described below. If no metadata or descriptive information is available, an API proxy can still be defined manually.

OpenAPI

APIs may have been modelled first, or can be modelled in SAP API Management, using the OpenAPI (fka. Swagger) specification. In this case, SAP API Management allows to design or import the API description through the “API Designer”. The OpenAPI description is then analysed and interpreted when generating the API Proxy in SAP API Management. Note that the import of RAML is also supported.

This allows for the quick creation of the API façade, including all necessary artefacts such as resources and documentation.

ODATA

Another widely used standards, is the OData standard. This standard is also used in SAP Gateway Hub and SAP S/4HANA, providing an easy way to generate OData APIs out of an SAP system.
One of the compelling aspects of OData is that it provides metadata for the OData REST API: resources, documentation, access properties …. Whenever an API proxy is created within SAP API Management, the OData metadata is interpreted and used for the generation of resources, documentation, etc..

… leads to…

Same as with OpenAPI APIs, the support of ODATA within SAP API Management allows for the quick creation of the API façade, including all necessary artefacts such as resources and documentation.

In the next blog entry, I’ll cover the API Proxies themselves and what added-value they bring to the table!