MoreBeerMorePower

Power Platform中心だけど、ノーコード/ローコード系を書いてます。

ローコード開発から見たAzure API Managementの役割

すこし広いタイトルですが、今回はWeb API Advent Calendar 参加の投稿なので、ローコードとそれを支えるWeb APIという観点で書いていきます。

結論としては、 『バックエンドサービスをローコードで作るユーザー、クライアントをローコードで作るユーザー、その間を交通整理してくれるのがAzure API Management 』 ということなのですが、ここではローコード開発でのAPIの役割やiPaaSの話なども書いていこうとおもいます。

ローコード開発とWeb API

ローコード開発を行う上で、Web APIの利用はなくてはならないものです。 通常のコードを書いて開発するアプリと同様に、外部サービスの情報を取得する・更新するためのWeb APIはもちろんですが、データ加工、何らかのメディアの加工、またはマイクロサービスの利用もコードを書かずに必要なアプリケーションの機能を実現するために重要な要素になります。 (コードを書く代わりにそれらの機能をWeb APIで補完しているようなイメージです)

f:id:mofumofu_dance:20201127233356p:plain

このブログでメインに取り上げている Power Platformもローコードでアプリケーションやワークフローを作成するサービス群ですが、Microsoft サービス/3rd Party サービス/オンプレミス資産 へのアクセスを容易にするコネクターの豊富さが大きな特徴の1つです。

Power Platformで実現されるアプリケーション、ワークフロー、あるいはデータ分析の多様性は、豊富なコネクターにより支えられているといっても過言ではありません。 さらにMicrosoft に認定されたコネクターのほかにも、開発者自らがAPIを実行するためのコネクターを作成することもできます。これにより提供されていないサービスのAPIも活用して、サービスのマッシュアップができます。

f:id:mofumofu_dance:20201127233702p:plain

iPaaS と API

少し話題が変わりますが、iPaaS (Integration Platform as a Service) のうち、HTTPの入り口・出口をインターフェースに持っているサービスではHTTPリクエストを起点にしてワークフローを開始し、データ収集や加工をした結果をレスポンスとして返却することで簡易的なWeb APIを開発することができます。

このようにiPaaSで作成したWeb API をローコードのアプリケーションや、ワークフロー から呼び出す - iPaaS と iPaaSをつなげる - ことにより規模の大きな、多様なサービスを作成することも可能です。

Power Platformの中では、Power Automate (またはAzure の Logic Apps) がこの役割を担うことができます。HTTPリクエストの受信をトリガーとして、ワークフローを実行、最後にHTTPのレスポンスを返すことで簡易的なWeb APIが作成できます。

Power Automate/Logic Appsで簡易APIを作成する場合には、基本は1フローで1操作 ("AAAAというリソースを取得する", "AAAAにBBBBを登録する"はそれぞれ別フロー) です。 送るデータを変えて処理を分岐させることはできますが、それはそれで簡易APIを担うiPaaS側の処理が複雑になりすぎるので避けたほうがよいでしょう。

さて、このように作られた簡易APIですが、Power Automate/Logic Apps の場合、APIのURLは以下のようになります。

[フロー1]

https://prod-77.westus.logic.azure.com:443/workflows/58b6309f36944cccbc5a0f1801d7b488/triggers/manual/paths/invoke?api-version=2016-06-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=ZnTJGR5cOfNxSjDf3PBTPF0xxxxxxxxxxxxxxx

[フロー2]

https://prod-28.westus.logic.azure.com:443/workflows/30310da426b6434e9beef758f4110506/triggers/manual/paths/invoke?api-version=2016-06-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=AaKH0cUB4RUONb-iXWCl8-Axxxxxxxxxxxxxxx

サーバーURLから違ってユーザーから見ると完全に別のAPIですね。せっかく簡易APIを作ったはいいものの、APIユーザーからみるとかなり煩雑な状況になってしまいました。

f:id:mofumofu_dance:20201125173309p:plain
様々な簡易APIをバラバラに利用するのは大変。同じリソースでも別APIにも。

API Management

ここまでを振り返ると、

  1. ローコード開発ではAPIの活用がカギ
  2. iPaaSを利用した簡易的なAPI作成も可能。これをローコードアプリから呼び出せる
  3. 簡易APIをたくさん作ってもAPIを使う側からは非常にわかりにくい

という状況になっています。

そこで登場するのが、複数の簡易APIをユーザー側から隠ぺいするためのレイヤーで、Microsoftのサービスの中では Azure API Managementがこの役割を担うことができます。

Azure API Managementは、Azure が提供するAPI ゲートウェイのサービスで、バックエンドにあるサービスを提供する API を一括で管理して様々な処理 (セキュリティ、レート制限、データ変換、監視、など) を仲介するものです。

このAPIゲートウェイが間に入ることで、APIを利用する側からは統一されたインターフェースで、必要なリソースをバックエンドのサービスを意識することなく利用できるようになります。

f:id:mofumofu_dance:20201124223649p:plain
APIを利用するアプリ/フローとAPI Managementの関係図

この効能は、何もローコードのAPI利用側にだけうれしいわけではありません。コードをガリガリ書くような開発でもこういったAPI Gatewayがあることは非常にありがたいです。

本題、ローコードから見たAzure API Management

ローコードなiPaaSもアプリも作る私の見解です。

Azure API Managementは先ほど書いた以下の状況を解消してくれる点がとてもうれしいです。

f:id:mofumofu_dance:20201125214442p:plain

つまり、

バックエンドサービスを(ローコードで)作るユーザー、クライアントを(ローコードで)作るユーザー、その間を交通整理してくれるのがAPI Management の役割

と考えています。

なお、最近の発表でうれしい点は、Dataverse for Teams の環境では、Azure API Management経由で作成したカスタムコネクターが、標準的なPower Apps/Automateのライセンスで利用できるということです。

Azure API Management で Project Oakdale 環境にカスタムコネクターを追加する - MoreBeerMorePower

これまでプレミアムだからと使えなかった外部サービス・登録されていない3rd PartyのAPI、Logic Appsで作ったワークフロー、またAzure Functionsで作ったAPI、これらを丸ごとAPI Management経由で利用できるようになるのは本当に有益だと思います。

ぜひ、ローコードに必要不可欠なAPIを、ローコードに作成して、Azure API Managementで分かりやすくユーザーに使ってもらってください。