IBM API Connect 環境依存の値をコントロールする

はじめに

API Connectを利用したAPIのシステムアーキテクチャーでは、API Connectがリソースサーバーの役割を担うことは稀で、大抵のケースにおいて他のリソースサーバー(バックエンドサーバー)へAPIを中継することになります。

そこでよくある問題が、テスト環境ごとに異なるバックエンドサーバーのURLをどのように保持するか？というものです。

ここでは、API定義のプロパティーにカタログごとの値を設定する方法をご紹介します。
なお、APIC v2018では、より良い方法が採用できるので、最後にご紹介します。

前提条件

2019/12時点のIBM Cloud API Connectサービスを利用します。
IBM CloudのAPI Connectは v5ベースになります。

なお、本記事で作成するAPI定義は、ここからダウンロード可能です。

試すこと

API Connectサービスに、2つのカタログを用意します。
カタログ名は、env1、env2とします。
env1、env2に同じAPIを公開し、カタログごとに異なるバックエンドサーバーのAPIを呼び出してみます。

バックエンドサーバーのAPI

バックエンドサーバーのAPIは、同じIBM Cloud上のSandBoxカタログ上に作成します。
このAPIは2つ作成し、それぞれ以下のJSONをレスポンスします。

backend_api_response-env1用

{"message" : "stub1だよ" }

backend_api_response-env２用

{"message" : "stub2だよ" }

API定義(アセンブル)

env1、env2カタログに公開するAPIの処理内容(アセンブル)は下図の通りです。
invokeポリシーで、バックエンドサーバーのAPIにアクセスします。
ここで、バックエンドサーバーのAPI URLは、$(backend_url_root)/stubとしています。
URLの前半部分は、「backend_url_root」としてプロパティー化します。

API定義(プロパティー)

プロパティー登録内容は、下図の通りです。
backend_url_rootプロパティーに対して、env1、env2カタログで異なる値を設定しています(赤枠部分)。

バックエンドサーバーのAPI URLは、invokeポリシーの設定値を踏まえると、以下のようになります。

env1用

https://api.us-south.apiconnect.appdomain.cloud/xxx/sb/env-api-stub1/stub

env2用

https://api.us-south.apiconnect.appdomain.cloud/xxx/sb/env-api-stub2/stub

※host名は、API Connectサービスをデプロイしたリージョンに依存します
※xxxは、本来サービスごと（オンプレ版だとプロバイダー組織ごと）に設定されますが、ここではマスクしています

API実行

先ほど記載したAPI定義を、env1/env2カタログに公開し、実行します。
以下は、curlコマンドでAPIを呼び出した結果です。
記載の通り、レスポンス内容からバックエンドサーバーのAPIを呼び分けていることが分かります。
なお、カタログへの公開方法は、本記事の主題から逸れるので省略します。

env1カタログ

curl https://api.us-south.apiconnect.appdomain.cloud/xxx/env1/env-api/go
'{"message" : "stub1だよ" }'

env2カタログ

 curl https://api.us-south.apiconnect.appdomain.cloud/xxx/env2/env-api/go
'{"message" : "stub2だよ" }'

※URLにはカタログ名が含まれており、URLからカタログが推察できます
　(https://ホスト名/プロバイダー組織名/カタログ名(env1 or env2)/APIごとのURL)

APIC v2018では

APIC v2018からは、カタログにプロパティーを設定することができ、環境変数のような扱いが可能になります。

これにより、API定義に設定を保持する必要がなく、より環境間のポータビリティーが増します。
なお、API定義からカタログのプロパティーを参照する方法は、API定義のプロパティーと同じです -> $(プロパティー名)

下図は、v2018のカタログ-プロパティー設定画面例です。

まとめ

本記事では、バックエンドサーバーのAPI URLを題材に、環境間で異なる値をプロパティーで解決する方法をご紹介しました。

注意点としては、今回の手法は、あくまでカタログ名が異なる前提ということです。
例えば、本番とテスト環境で、アカウントを分けてカタログ名を同じにするケースでは適用できません。

逆に、テスト環境が複数あって、カタログで論理分割する際には有効な手段になります。