Skip to Content

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:

TransportOverview.png

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.

TransportOverview_2.png

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

Trial_Home.png

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.

Manage_Trial_API.png

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

GMaps_Trial.png

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

Export_Trial_with_description.png

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

DownloadExport.png

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

Prod_Home.png

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.

Import_Prod.png

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

Import_Proxy.png

Select_Proxy_Bundle.png

Import_Proxy_2.png

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:

GMaps_Prod.png

Prod_Final.png

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.

Link_Provider.png

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!

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Murali Shanmugham

    Thanks for posting on the transport process. I am assuming we need to create an API Provider (pointing to TEST/PROD) manually in the next landscape before importing the transport file from DEV ?

    (0) 
    1. Elijah Martinez Post author

      Hi Murali,

      Good question, it depends on the way in which the API Proxy is structured, which is why I tried to keep it generic here, but yes in the case that you originally had an API Provider, you would need to have a corresponding API Provider in the destination landscape, which you would create separately (manually)..

      NOTE: Only the Name of the API Provider needs to be the same, the system details can change if needed.

      (0) 

Leave a Reply