第３回 Web API を利用するには？ ～ノンコーディング編：Microsoft Flow, Azure Logic Apps～

#はじめに
[前回](http://qiita.com/yugoes1021/items/d8defc41d1bcd04674fe)は「第２回 Web API を利用するには？ ～ノンコーディング編：IFTTT～」を書かせていただきました。

ノンコーディングでも IFTTT を利用すると、こんなに簡単に Web API が利用できちゃうというお話でした。

さて、どんなに簡単に使えると言っても、やはりエンタープライズ向けのシステムで IFTTT のような無料の外部サービスを利用するのは、なかなか難しいですよね。

上司の承認をゲットしようにも、自分たちの管理下にないものを使用するのは…という方も多いですよね(´・ω・`)

そんな方へ向けて、IFTTT のように手軽に使えて、かつエンタープライズ向けにも使用可能というサービスを紹介するのが、この第３回です。

#Microsoft Flow
[IT media ニュース]
Microsoft、企業向けIFTTT的サービス「Microsoft Flow」を正式公開
http://www.itmedia.co.jp/news/articles/1611/01/news066.html

この2016年11月01日の IT media のニュースにあるように、Microsoft の IFTTT 的サービスとして、Microsoft Flow が紹介されています。
まずは記事を読んでいただければ、と思います。

![MSFlow_Top.PNG](https://qiita-image-store.s3.amazonaws.com/0/152946/0b27ca95-6fce-9bf6-81f8-ba2df9917a7f.png)
[Microsoft Flow]
https://flow.microsoft.com/ja-jp/

**Microsoft Flow** は、Microsoft アカウント、組織アカウントのいずれでも無料で使い始めることが可能です。
会社や所属組織で Office 365 や Dynamics 365 を既にお使いの場合は、Flow for Office 365 and Flow for Dynamics 365 というプランが用意されており、追加の課金なしに使用することができます。
価格については、こちらを参照してください。

[プラン | Microsoft Flow]
https://flow.microsoft.com/ja-jp/pricing/
#Microsoft Flow の使い方
現在のところ、まずは登録したアカウントで個人がフローを作成して、決まった処理を自動化させることができます。
IFTTT と同様、トリガーを作成して、そのトリガーが動作した際のアクションを、ドラッグ＆ドロップで繋いでいくことになります。

IFTTT と異なるのは、下記2点です。
1. MS 製のサービス、製品へのトリガーやアクションが用意されている
2. 複数のアクションを接続することができる

さすが MS 製だけあって、MS の各種サービス（Office 365、Dynamics 365、OneDrive、SharePoint、Power BI、 SQL Database、Azure のサービス等々）に接続するための、トリガーやアクションは一通り揃っています。また、MS 製のサービスだけではなく、Twitter や Facebook、Dropbox、WordPress などサードパーティー製のサービスに接続することも可能です。

また、**IFTTT** はトリガー（This）ひとつに対して、アクション（That）がひとつですが、**Microsoft Flow** は、ひとつのトリガーに複数のアクションを直列に繋いでいくことが可能です。さらには、プログラミングで言うところの 条件分岐（If）や 一定の条件に従うループ処理（Do...Until...）も可能です。

![logicappcapture2.png](https://qiita-image-store.s3.amazonaws.com/0/152946/ab80b460-e5f5-5192-303b-31317c16588c.png)

#Microsoft Flow の中身は Logic Apps
**Microsoft Flow** は、後述する **Microsoft Azure** の **Logic Apps** と中身は全く同じものです。**Logic Apps** は **Microsoft Azure** の **Azure App Service** に含まれる PaaS になります。

Logic Apps の場合は、Azure のアカウントで App Service を作成後、Logic Apps のフローを作成することになりますが、App Service 自体を作成する際に、どこのリージョン（データセンター）にデプロイするかを選択したり、サーバーのスペックを選択することが可能です。

一方、Microsoft Flow はそういった「**どこのデータセンターを使用するか**」や「**処理スペックを詳細に指定する**」といったことができません。その代わりに**アカウントさえ登録すれば、簡単に使い始めることが可能**となっています。

既に Office 365 アカウントを持っているユーザーや Dynamics 365 アカウントを使用しているユーザー向けの **Flow for Office 365 and Flow for Dynamics 365** というプランの場合、Office 365 や Dynamics 365 と同じリージョンにフローが作成されるようです。つまり、**Office 365 が日本の東日本リージョンを使用しているのであれば、そこに属するアカウントで Microsoft Flow でフローを作成すると、東日本にデプロイされることになります。**

Logic Apps の詳細は以下をご覧ください。

[Logic Apps とは]
https://docs.microsoft.com/ja-jp/azure/app-service-logic/app-service-logic-what-are-logic-apps

#使いどころ
**IFTTT** も同様ですが、ノンコーディングで Web API を使用するにはうってつけのサービスになっています。一般的に Web API を使用するには以下の手順通りに実装することが多いでしょう。

**＜Web API の一般的な呼び方＞**
1. 認証・認可
2. 欲しいデータをリクエスト or 登録したいデータを送信
3. 結果を受け取って、呼び出し側のプログラムで後述処理を判断

複数のサービスと連携するにしても、基本的には上記の組み合わせになるはずです。
どうでしょう？これを毎回実装したいですか？

SNS、業務用 SaaS、クラウドのサービス、自社の独自サービス…

どれであっても、基本的には上記１～３の手順になるでしょう。フロントのアプリはともかく、ビジネスロジック以降で何らかの Web API を呼び出すのであれば、経験上 80% 程度は Microsoft Flow や Logic Apps でカバーできるのではないかと思います。もちろん、繋ぎたいサービスへのコネクタ（トリガー、アクション）が存在すれば、の話ですが。

注：Logic Apps は、.NET Framework 等で開発したコネクタをホストすることができます。

#昨今のトレンド
「サーバーレス」という言葉が、昨年くらいからにわかに注目を浴びてきて、開発する場合であっても利用する場合であっても、本当の意味で「サービス」に注力できるようなプラットフォームが各クラウドで出てきております。

これらの背景にあるのは、明らかに**開発スピードの高速化**です。
**もはや「あのサービスにつないだぜ、ﾄﾞﾔｧ٩( 'ω' )و」と自慢する時代ではありません。**
（もっと言うと、**いかに素早く自分たちのサービスを実現するか**、が求められているはずです。）

というか、そんなことが自慢になるようなサービスは、誰も求めてないですよね。
なぜなら、それは**開発コストが高い Web API だということになってしまうから**です。

時代は言わずもがな、そうではなく、**繋ぎたい時に、適切なセキュリティを保持して、欲しいデータをリクエストすることができる、またはデータを送信することができる**、そういうものを求めているはずです。

**Microsoft Flow** や **Logic Apps** はこういった背景に対応するひとつの解としてリリースされました。

#フローの作成例
例えば、以下は私が Twitter で集めたいハッシュタグを指定して、Azure 上の SQL Database に保存するフローです。
![HashTagMSIgniteToSQLDatabase.PNG](https://qiita-image-store.s3.amazonaws.com/0/152946/0989cf75-9ffd-3e28-a2eb-e8b090c37e59.png)

画像には二つの箱があり、一つ目が Twitter に指定したハッシュタグ（上記は #MSIgnite、#AzureStack、#PowerBI の３つを指定）が投稿されたら動き出すトリガーです。二つ目は SQL Database にツイートの内容を登録するためのアクションです。基本的にすべてドラッグ＆ドロップで設定が可能です。

たったこれだけで、**自分が指定したハッシュタグを含んだ世界中のツイートが SQL Database に保存されます**。作成には数分です。Database を作る時間、動作テストをする時間を鑑みても、小1時間でできてしまいます。明らかに実装するより早いです。

#おわりに
いかがでしょうか。第２回と今回で、ノンコーディングで Web API を使用する手段を３つご紹介させていただきました。
言葉で説明するとややこしく聞こえるかもしれませんが、ご興味ある方はぜひ試してみてください。

**実装するのが無駄に感じるかもしれませんよ！**

#次回は第４回 12月16日（金）
さて、次回は「第４回 Web API を利用するには？ ～EAIツール編：DataSpider, ASTERIA～」と題してお送りいたします。
いわゆる EAI ツールと呼ばれる、ノンコーディング分野のエンタープライズ向け製品を二つご紹介いたします。

これらも、ノンコーディングで Web API を使用することになりますが、タイトルはあえて「ノンコーディング編」としていません。
IFTTT や Microsoft Flow、Logic Apps よりも複雑な処理を作成することが可能です。

それでは次回 12月16日(金) をお楽しみに！！