In this phase we are going to cover below areas:

  1. What is API proxy and API Provider?
  2. Creating API Proxy with OpenAPI Specification
  3. Creating API Provider
  4. Creating API Proxy with API Provider
  5. Creating API proxy with Open Connector
  6. Publish the API Proxy to API Portal

Table of Contents

  1. Table of Contents
  2. Development in Context of API Management
  3. API Blueprint and Terminology
  4. Creating an API Provider
  5. Creating an API Proxy
  6. Testing API Proxies
  7. Publish your API Proxy
  8. Conclusion
  9. What is next?

Development in Context of API Management

Despite what lot of literature says or covers about this phase of API lifecycle. API development end to end is about two things:

  1. Building API Provider - This again has two phases
    • Building core API which directly interfaces with data sources- This step will generally be done by an API Developer with capability to create and work with CDS views, SAP Gateway, ABAP and in case of non-SAP data sources, it would be someone with expertise in Node.js, Express.js, Python, Java/Spring etc. Generally this Developer will take the API specifications built in design phase and work with it to match actual API to this spoecification.
    • Creating API Provider object - This step involves all the steps required for API Management server to be able to point and connect to API service built in previous step. This object pointing to actual API host and service collection also called “Target Endpoint”.
  2. Building API Proxy - An API proxy is also an API, which wraps an actual API i.e. target endpoint, into another endpoint called "Proxy Endpoint". It protects API provider from unwanted direct exposure and lays the foundation for next phases of API Lifecycle.

These two steps are what comprise “Develop” phase of lifecycle.

As “Building API Provider” is a very large topic and is beyond the scope here, given the pre-requisite requires you to learn numerous other technologies, we will cover here “Creating API Provider object” and “Building API Proxy”.

API Blueprint and Terminology

An API is made up of two parts

  1. Host: The host is the main domain or server where the API resides, defining the network location for accessing its endpoints, such as api.example.com or example.com/api.
  2. Path Prefix: Optionally placed after the host and before specific endpoint paths, the path prefix organizes related endpoints under a common path. For instance, endpoints related to user management might be grouped under the prefix /users, resulting in URLs like api.example.com/users.

Additional Glossary

Service Collection URL: This URL grants access to the API’s range of services. It typically serves as the root URL or a designated endpoint for listing available services. In RESTful APIs, it could be a resource like /services or /endpoints. For example, api.example.com/services might showcase services like user management, product catalog, and order processing.

Creating an API Provider

Navigate to “Configure -> API Providers -> Create”

API Provider is placeholder inside Management Console which points to actual “service collection URL” which we want to use. In this example, we will use Northwind Services (https://services.odata.org/V3/(S(gdl1ocjuhe2irgfcw3xfilzy))/OData/OData.svc/). It is an open source OData API and will be used in our blog series for all intents and purposes.

Once you hit “Create” we need to provide basic details.

Move on to “Connection” settings, here we need to provide type of API Provider, Host, Port and SSL usage.

Type: An API provider’s type is basically the category of “how do you plan to connect to the service”. It can have following values:

  1. Internet - If available openly on internet(where our NorthWind service is hosted)
  2. On-premise - If it its hosted within your company’s landscape and you need to set up connection to your backend system in Cloud Connector first.
  3. Open Connector - Select this option if it can reached through “Open Connector” capability of Integration Suite.
  4. Cloud Integration - Select this if you want to consume the service through a service collection exposed by SAP Cloud Integration capability.

API Provider for our demo is simplest part, as they just service providers which need to be accessible through one of the four choices listed above. In API management, you will focus mostly on “Manage and Engage” phases.

We will select “Internet” for our openly available NorthWind Services. Host as seen from URL earlier is “services.odata.org”, port is default https port 443 and we will use SSL for it being HTTPS service, we do not need to provide Cert Store setting details though. API management trusts all TLS certificates by default, for others you will need to configure trust store setting.

Lets goto catalog service settings, here you need to configure path prefix and service collection URL.

Path prefix and the service Collection URL, we can leave these blank here, as it is applicable to SAP Gateway-enabled SAP NetWeaver systems, so you can leave it blank here.

It can be a bug, or a missing feature for the lack of detailed backend documentation, the way the tool parses path prefix and service collection URL, it doesn’t translate well with non-SAP API Providers. Feel free to give it a try and share you experiences in comments.

Authentication is “none” as this service doesnt require any. It supports basic Auth too. Check “Trust All” to automatically accept SSL certificates to this service.

Hit the “Save” on top right, which enables the option to “Test Connection”. Hit the Test Connection, this is what you should get:

And we have successfully connected to our API Provider. Now if you navigate to “Configure -> API Providers”, you can see it listed there.

The steps are similar for other “types” of providers, setting and configurations for those will be on case to case basis. But this should give you the idea, how to employ other types of data sources aka API providers in your Management Console.

Okay, now that we have an API Provider, assume instead of an openly available service, you have a service within your landscape. Now, you have a few things to consider of which common concerns are below:

  1. You dont want to your host directly to external applications.
  2. You do not want to overload your backend system with configuration and settings to control access to it.
  3. You do not want to touch upon backend system for implementing security measure for each new cusumer.

To Address all these concerns, we will wrap this API provider inside something called API Proxy, which will facilitate the flexibility on all three accounts, as we will see in upcoming blogs.

For now, lets create an API Proxy.

Creating an API Proxy

You can create API proxy from three types of sources:

  1. API Provider
  2. API Proxy
  3. URL

I explain each of them below.

To create an API proxy navigate as shown below:

As discussed earlier, here you have three options to create API proxy, we will go over each one of them in next steps.

Creating from an API Provider

We have already created API Provider so lets see the setting to use it. Below are the step/click ordering in which you configure the interface.

This Wizard has two parts:

API Provider Details

  1. Select: Select “what exactly you proxy is wrapping”. In this case we are using an API provider we created previous step.
  2. Dropdown: To select the API provider from list of providers.
  3. Discover: Discover button links, populates the API proxy data based on the type of API provider. e.g. service type options and documentation (if available).
  4. URL: Fill in the path which will be suffixed to your API provider to point to catalog of services.

API Proxy Details

  1. Name of API: Give name of API which will appear in Dashboards
  2. Title: Title which will appear in your API specifications
  3. API State: It can have one of three values depending on the stage of proxy lifecycle. Alpha if it is with developer for intial development and local testing. Beta if it has been handed over to select users for testing it out to seek feedback. Active if it has been rolled out for productive use.
  4. Host Alias: It is the host server where you will be hosting this proxy. For SAP trial you will have only one tenant to host, so default is used.
  5. API Base Path: Think of it as an identifier which can used to single out one proxy among many hosted on same “host alias” or server.
  6. Service Type: This allows the Developer to decide how the consumer should be consuming proxy. Depending on which service you are wrapping, the options change accordingly. You can choose where the proxy should be consumed as ODATA (if avaiable), plain REST or SOAP service.

Hit Create and it should create a proxy, it will create and open up the newly created API proxy for you if you want to make any changes to it. If you are satisfied, hit “save”.

Notice, in "Resource" pane, you have all the services displayed as UI Document for Open API specification for this proxy.

You can not test this API yet though, as you need to deploy it first. You can click “three dots” on top right if on smaller screens, else the option to “deploy” is directly visible. Click it and note the change in status.

This API proxy is now available to us for internal usage/testing. Without directly calling NorthWind services.

Creating from an API Proxy

Self explanatory, it just wraps an existing API proxy inside new API proxy which we create. There can be mulitple reasons for it. e.g. Providing a partner/user access to existing proxy without sharing the same details/credentials. Or sharing one API proxies over different hosts for different landscapes where you just change host alias while still pointing to same API proxy.

Here is how you create the API proxy from another API proxy. Here we will use the same API proxy which we just created in previous step.

Here you Select “API Proxy” option.

Disover the already avaiable proxy which you want to wrap.

API Details block details follow the same logic as mentioned in previous step for “Creating from API Provider”.

Hit Create, Save, Deploy and you are set with another type of proxy.

Creating from direct URL

As the name suggests, in this case the “to be” created API proxy will wrap an API URL for which details are provided in the wizard directly. This mode of creating API proxy makes sense if you are trying to expose just one API service to the consumers, instead of a catalog of services for which API provider option is better choice.

Below is the setting you can go for this case.

All the field details are already explained. So we can move on to next special way of creating API proxy.

Creating from the Open API Specification

As we saw in previous blog about “API Designing” where we created an Open API specification for “Greeting and Feedback API”. We can create API proxy directly from OpenAPI Specification.

In design step we only left out one step, hitting “Save” button, once you do that you create an API proxy in advance for an API which will adhere to Open API standard.

You will deploy the proxy as we done in similar excercises earlier, and you are set.

Before I wrap up “Creating API proxy” section, I want to just touch upon “Generate Server Stub” option, as seen above. This option is used to create pre-built projects in a .zip file, for Spring or Node.js based server side development, which then can be used by an “API Developer” to implement business logic to add real world functionality to the actual API, which our API proxy will be pointing to.

To summarize at this point we have below four API proxies as seen in “Configure-> APIs” Dashboard:

We will now learn how to test your API proxy.

Testing API Proxies

Before we close upon the Develop Phase, it is essential that we know how to test our API Proxies. This ensures we can connect to backend services, also known as API Providers, in the expected manner. Additionally, we must ensure that we can fetch responses that are inline with what an API developer would find useful.

While you can use Postman to test APIs, which has an ample documentation available, also if you have any previous experience with working APIs in general. You might already be familar with Postman. I will not go into “Testing with Postman” here.

Here we will go over an option available in API management console as well to test your APIs (API Proxy), it is called “Test Console”

Once you are on the testing tool pane, you can see the list of proxies available for you to test. You can:

  1. Select the proxy you want to test.
  2. Add authentication method and details to call the proxy endpoint.
  3. Add custom headers and their values you want to send in request.
  4. Add custom parameters and their values you can send in request.
  5. Setting debug mode
  6. Executing the request
  7. Exploring the debug mode

Adding authentication

Adding headers and parameters

Setting “debug” mode for detailed information on API flows

Once click “Debug” button at bottom right corner, below view opens. Just click “Start Debug”

It enable default “Debug” Session for 10 minutes, after which it will disable it to save on storage. you can see the counter in the same window.

Please note that this step is optional and should be used only for troubleshooting purposes.

Executing the request

Go back from “Debug” window and hit “Send” as seen below. It will execute the request and show you reponse.

You can also see the “Status Code” at the botton there.

Exploring “debug” mode

As we had enabled debug mode, it will show microscopic details about everthing from the point you click send to the point you receive back the response.

Once you no longer need the debugging trace, you can click “Stop Debug” at the bottom right corner.

For most part this is what you will need to test a proxy, but a few new details may emerge as you progress and do more testing case to case basis.

Publish your API Proxy

Path to publish the API Proxy

Publishing your API proxy involves making your API accessible to developers and users outside your organization, while still maintaining control over its usage and security.

It is essential that you take care of below steps before you publish your API:

  1. Security Configuration: Implement security measures such as OAuth, API keys, or JWT tokens to authenticate and authorize API requests. This ensures that only authorized users can access your API resources.
  2. Endpoint Configuration: Define and configure endpoints for your API proxy, specifying routing rules, transformations, and any necessary policies like caching or traffic management.
  3. Documentation: Document your API thoroughly, providing clear instructions on how to use each endpoint, sample requests/responses, and any specific requirements or limitations.
  4. Testing: Test your API proxy rigorously to ensure it behaves as expected under various conditions, and that security measures are effectively enforced.

Ideally, my next blog should be about publishing API proxy. However, due to certain security policy (in the Manage phase) which can be applied only after you publish APIs on API Business Hub Enterprise, I will cover the “publish” part together with the Engage and Monetize phases in blog 5. It will become clear in time it belongs together with those phases, because Engage, Meter, and Monetize are bundled together with how you publish your APIs. We will discover this in blog 5.

Conclusion

The develop phase is where your API design comes to life. Here’s the breakdown:

  • API Provider/Backend: This is the existing system or data your API will expose. It houses the core functionality.
  • API Proxy: A security and management layer between your API and its users. It handles tasks like authentication, rate limiting, data transformation, and gathering analytics.

Key Actions:

  • Coding: Developers build the API’s logic to interact with the backend.
  • Mocking: Simulate the API for early testing and feedback, before the backend is fully complete.
  • Documentation: Write clear instructions for developers who will use your API.

Remember: Test the API rigorously during this phase to ensure it functions as designed, adheres to security standards, and performs well.

What is next?

Now that you’ve secured good understanding of creating and testing an API proxy, it’s time to delve into the world of API management! This means taking control of your API by learning how to manage traffic, transform data, and implement robust security measures. All this is done to get your API ready for consumers.

The key to unlocking these powerful controls is the “Policy Editor”. This powerful tool will be the focus of our next blog, where we’ll explore how to use it effectively!

I will see you in next one.