How to transport API assets between instances

In our series SAP API Management – Overview & Getting started we have tried to provide understanding of what API Management is, and many of its basic functionalities. But we have yet to touch on one small, but important item, landscape transport. This will be a short blog, about the current method to transport API assets between instances of API Management (for example, between Dev -> Test -> Prod).

PRE-REQUISITE TO THIS BLOG

To understand API Proxies, and Transport it is expected that you will have already read and understood the introductory Blog How to use SAP API Management on HCP Trial , describing the creation of API Providers, and API Proxies. Other blogs in the SAP API Management – Overview & Getting started will help as well.

Understanding the Process

Currently the mechanism for transport is the Export / Import function. Once an API Proxy is developed enough on one landscape, to be moved, the Administrator will simply export that proxy, which will create a downloadable .ZIP XML bundle, which can then be imported into the next landscape, containing all the same settings, policies, etc. except now exposed via the new landscapes FQDN.

The essential process looks like follows, using “Dev -> Test” as an example, exports an API Proxy from Dev, and Imports it into Test:

In this example, API Management on a completely isolated Development Landscape, connects to a Backend in the same landscape, has an API Proxy exported by the Administrator, and then imported into another isolated Test landscape, which also contains a Backend which should contain a similar endpoint as before.

There are many other scenarios that could occur, for example Test and Prod could be on the same landscape connecting to the same backend, but only Prod is accessible externally, e.g.

or the Backend could be in another cloud, etc. but the basic premise is the same.

Making it happen

So now, let’s look at how it actually works in practice. As expected it is fairly easy. If you know another person with a trial account, you can export / import between trial accounts, or as a customer if you have provisioned separate landscapes within HCP, you can follow the same process. In this example, I will be demonstrating by exporting an API Proxy I created on Trial, and importing it into a productive landscape I have access to on US1, simulating Test -> Prod.

I begin by logging into my Trial Tenant of SAP HCP, API Management

The keen observer will notice that the GoogleMaps API Proxy has been giving me a lot of errors, so it’s good that I tested it a lot on Trial first, as that’s the one I will be moving.

As usual, I open the “Manage” area of API Management, to get access to my API Proxy list.

I want to export the GoogleMaps API I have created, which currently resides on the Trial endpoint as you can see below.

To do so, simply click the “Action” arrow for GoogleMaps and select Export, as below:

And as mentioned earlier, this will generate a .ZIP file to be downloaded

Now I switch landscapes to my “Prod” instance on US1

Still have some errors, but I’m trying to keep it a little bit cleaner! Ok, again to Manage APIs as above, and now I import the API Proxy I just downloaded (don’t fret about the API screen looking different, this is proof it’s somewhere different!) by clicking the “Import API” button.

This pops up the Import Wizard, and I click Browse to find the .ZIP just downloaded

Now the bundle should import and automatically populate all the information as before, only now being called from the “Prod” Proxy Endpoint URL on US:

With this simple process, the Proxy has been transported from Test (Trial) to Prod (US1).

Advanced Notes

As mentioned above, if you have read the Blog How to use SAP API Management on HCP Trial you may remember that when you create an API Proxy, you are given the option of selecting an “API Provider” as well as the option of “Link API Provider” to API Proxy. This becomes much more relevant when we talk about the process of API Proxy Transport.

Note at the creation time of the API, if an API Provider is selected, and Link API Provider is checked, that the URL path to the API is now a relative URL, instead of an absolute URL. This is useful in the case of the first example shown, where you have 2 isolated landscapes, where the Backend for the 1st landscape may not be accessible from the 2nd landscape. If the URL were absolute, it would require manually editing where the API Proxy points to get its data each time. However with the relative URL, the API Proxy simply needs to be pointed to the name of the API Provider (which can be named the same on both landscapes) and then find the same relative path to the data.

This helps to simplify the transport process between isolated environments, without having to reconfigure multiple API Proxies to point to the correct Backend URL.

Hope this helps, and happy transporting!