By the end of this blog, you will understand how to make your APIs available to the outside world. In the “Engage” phase of the API lifecycle, we will publish our well-prepared API proxies to the API Business Hub Enterprise (ABHE). ABHE is a central place for APIs, templates, and best practices. It’s where the things created by API Developers are discovered and explored by Application Developers for business use cases. We will also see how to monetize you product usage.

Table of Contents

  1. Table of Contents
  2. What we have done previous phases so far?
  3. Engage Phase of API lifecycle
  4. Meet API Business Accelerator Hub
  5. Create a product
  6. Assign permission to a Product
  7. Monetize: Creating a Rate Plan
  8. Exploring the published product as an Application Developer
  9. Onboard an application developer
  10. Using a product as an application Developer
  11. What did we learn so far?
  12. What is next?

What we have done previous phases so far?

In the previous phase we fine-tuned our APIs through various policy injections to our APIs to make sure they can withstand heavy traffic, we massaged its data to make sure the API provider is getting it in the correct format and responding with the required information, we also saw how we can secure our APIs using API key and OAuth policies.

We learned how to think about API usage holistically and how to make sure it runs smoothely.

Now its time to publish our APIs.

Engage Phase of API lifecycle

As the name suggests, in this phase, the Application Developer, who builds the actual application to provide a business view and data to make informed decisions, engages with our API Proxies. Their applications will consume these API proxies by putting them to actual usage in their application and workflows.

The key steps of engage phase are broadly below three:

  1. Bundling similar APIs together in a Product and publishing it.
  2. Onboard Application Developer to allow them to use our product.
  3. Manage Consumer access to our products.

We will go over each step.

Meet API Business Accelerator Hub

Also known as API Business Hub Enterprise (ABHE), this is a central hub where you can explore and test new products across different categories of processes, domains, and industries. You can also search for API Products here. In the Engage phase, our goal is to ensure that our APIs can be explored and used from here by packaging them inside a Product. Since we are in a trial account, we will publish our products in our own test environment for ABHE, which is currently empty.

The production environment is central across customers. All customer and partners can explore various products and artifacts and subscribe to them.

Lets move on to creating a product now.

Create a product

The first thing to do is to group together the proxies that serve similar purposes and that we will include in a product. Once you have done that, go to the “Engage” option in your navigation pane and click on “Navigation Pane-> Engage-> Products-> Create”.

Give basic details about the product:

Add APIs which you want to add to this product, we will use the one we have used so far. Go to “APIs->Add”. Make the selection. You can choose specific services you want to publish as well. Here I am publishing only Categories and Product services of NorthWind Catalog.

Hit ‘OK’. Before we publish our Product lets go over a few other options.

Assign permission to a Product

The specific relevant content for this request, if necessary, delimited with characters: You can configure new roles in BTP cockpit for new/existing users who can view your products and add it to "Permissions" tab to manage the access to your products. Being in trial account we don’t have that access so we will do away with this part.

Monetize: Creating a Rate Plan

A rate plan helps you monetize your API Product usage by charging a consumer based on certain rate plan. The usage then can be used to bill a consumer to create a revenue.

Lets see how to configure this. Go to “Monetize”

Provide relevant details and rate per tier if applicable. Hit “Save”

Now go back to “Engage-> Rate Plans-> Add”

Select the plan and hit “OK”.

We can customize a bit more. This should be enough for beginners to understand how to publish APIs through Product. Now, we can publish our Product by clicking on the “Publish” button on the top right.

Once you do that you can see the status of proudct change to “Published”

We can see our product in ABHE now.

Exploring the published product as an Application Developer

Lets say you are an application developer, who came across our API in ABHE and want to explore it.

In ABHE, if you open the product, you can see the overview and the API Proxy and underlying services we published.

Also the rate plan for the usage of APIs.

Now, if a cusumer or application developer finds our Product with possible value, lets see how to onboard them.

Onboard an application developer

Onboarding an application developer (consumer) means facilitating them to use our APIs.

They can “Subscribe” to our Product. They can create a new application or if they have an application created already, they add this product to that as well. Here we will start from scratch and “use"Create a new application”

Fill the basic details and hit “Create”

Clicking “Create” button will take you to your application where you will see more details which will pave the way for you to use our recently published product.

The Application secret, Application Key and callback URL, are what you will need to be able to use our product.

Using a product as an application Developer

Keep the Application secret, Application Key and callback URL handy, we will need it.

Now if you go to your “My Workspace => Select Application => Products tab => Select Product => APIs tab => Select the API Proxy”, you will see below page.

That is the host you will use for your application.

In the API Reference tab, you can then see the paths that you can suffix to the host you saw earlier to consume the proxy. In the same tab, you will have the option to explore the details of each path and also to “Try out” the API proxy.

Once you click “Try out” you will option to execute a call as shown below and you will see the response.

You may have noticed the error:

Failed to resolve API Key variable request.header.APIKey

This is because in our API Proxy we have enforced security policy “Verify API Key”. In the absence of an API key, it will not allow unauthorized applications to consume the API.

Let’s tackle this. Remember the Application key we got earlier when we created our application, we need to pass that in the header, as seen below. Remember that ideally this specification should be enforced at the design phase to ensure it can be done from the ABHE portal itself without manually adding the header. For now, we will make a manual entry and execute the request again.``

Notice the successful response.

Also as the developer keeps using the API, he can check the usage and billing details as well.

What did we learn so far?

If you have been with me so far, you may have noticed the importance of Design Specification, how it can make your product engaging to an end user as he goes through API reference.

Also, you can now appreciate the importance of policy in securing your APIs. Without the correct API key, an application cannot consume your APIs. Not just that, with other authentication methods, you can even enforce OAuth2 authentication.

And finally, you may now have a better understanding of how “Products” are what make your API proxies presentable to application developers, and how to monetize your API usage through rate plans.

What is next?

In the next blog, we will touch upon Analytics and API Deprecation. We will also touch upon a few miscellaneous topics. Also, we will wrap up this blog series in the next blog.

I will see you in next one.