GA された LogicApps では、新規作成時に適用されるプランは Consumption となり、実行されたアクション数によって金額が計算されるプランとなっています。数百回程度では 1 円にも満たないので、開発中であってもそれほど問題はないのですが、明示的に開発中は Free プランで進めることで精神的に安心したいという気持ちもありましたので、切り替え方法を試してみました。

基本の流れとしては MSDNに記載されているように行えば AppService Plan を利用するよう変更が可能です。

最初に Add-AzureRmAccount コマンドレットを実行し、Azure にログインを行います。コマンド実行時にサインイン用ダイアログが表示されるので、アカウントとパスワードを入力します。

続いて Set-AzureRmContext コマンドレットで利用するサブスクリプション情報を設定します。-SubscriptionID に続けて自身のサブスクリプション ID を記載してください。

その状態で Set-AzureRmLogicApp コマンドレットを実行します。

必要となるパラメータは 3 つで、-ResourceGroupName で「利用しているリソースグループ名」、-Name で「LogicApps 名」、そして最後に –AppServicePlan で「設定する AppService Plan 名」をつけて実行すると、上記のように LogicApps が利用する AppServicePlan が設定されます。

注意する必要があるのは、この際に指定する AppServicePlan です。これは ResourceGroupName で指定するリソースグループに属している必要があります。

このようにすることで、Consumption プランとなっている LogicApps をこれまでのように AppService Plan を利用するように変更が可能です。

※なお、今の時点で AppServicePlan から Consumption へ戻すのが成功していません……。

もともと初期のスキーマより提供されている並列動作ですが、現在のスキーマ形式に切り替わってからはデザイナで対応されていないのもあり、あまり触れることがなかったのですが、気が付いたらデザイナ上でも並列動作を表示できるようになっていたので確認してみました。

「表示できるように」と書いたように、現時点ではデザイナ上から並列動作を指定することはできません。利用するには CodeView 上で JSON を直接編集する必要があります。

サンプルとしてこのような LogicFlow を作成します。これを CodeView で見ると次のようになります。

{
    "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
    "actions": {
        "応答": {
            "inputs": {
                "body": "TEST",
                "statusCode": 200
            },
            "runAfter": {},
            "type": "Response"
        }
    },
    "contentVersion": "1.0.0.0",
    "outputs": {},
    "parameters": {},
    "triggers": {
        "manual": {
            "inputs": {
                "schema": {}
            },
            "kind": "Http",
            "type": "Request"
        }
    }
}

この json 定義を次のように書き換えます。

{
    "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
    "actions": {
        "応答": {
            "inputs": {
                "body": "TEST",
                "statusCode": 200
            },
            "runAfter": {},
            "type": "Response"
        },
        "応答_2": {
            "inputs": {
                "body": "TEST",
                "statusCode": 200
            },
            "runAfter": {},
            "type": "Response"
        }
    },
    "contentVersion": "1.0.0.0",
    "outputs": {},
    "parameters": {},
    "triggers": {
        "manual": {
            "inputs": {
                "schema": {}
            },
            "kind": "Http",
            "type": "Request"
        }
    }
}

応答_2 というアクションを追加したものです。単純に追加しただけですが、この状態でデザイナを表示すると次のようになります。

このように単純に追加しただけでも並列動作となりますが、これは先程の JSON 定義にて、各コネクタの値に runAfterという箇所が影響しています。この値は「直前に実行されるコネクタ」についての情報を設定するもので、ここが同一の値のコネクタは並列に実行されることとなります。今回のサンプルでいえば、runAfter が未指定のもの同士（トリガ後すぐに実行するもの）が並列に並べられることとなります。

なお、現時点の制限かどうかは不明ですが、片方の並列動作アクションにだけ後続のアクションを定義して言った場合、デザイナ上で新規アクション追加を行うと想定している動きと違う動きとなります。

このようにどちらかのアクションに対しての後続アクション追加となるのですが、並列動作するアクションが同一数の場合はこのようになります。

試しに Compose コネクタを導入すると、JSON 定義は以下のように記載されます。

{
    "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
    "actions": {
        "作成": {
            "inputs": "",
            "runAfter": {
                "応答": [
                    "Succeeded"
                ],
                "応答_2": [
                    "Succeeded"
                ]
            },
            "type": "Compose"
        },
        "応答": {
            "inputs": {
                "body": "TEST",
                "statusCode": 200
            },
            "runAfter": {},
            "type": "Response"
        },
        "応答_2": {
            "inputs": {
                "body": "TEST",
                "statusCode": 200
            },
            "runAfter": {},
            "type": "Response"
        }
    },
    "contentVersion": "1.0.0.0",
    "outputs": {},
    "parameters": {},
    "triggers": {
        "manual": {
            "inputs": {
                "schema": {}
            },
            "kind": "Http",
            "type": "Request"
        }
    }
}

Compose コネクタの runAfter 値に二つのアクションが成功したら、という感じに設定されているのがわかると思います。このように記載して、並列動作するアクションが同一数である場合は、先ほどのようにデザイナ上でも正しく線が引かれますが、同一数ではない場合はデザイナ上でアクション追加を行った場合と同様、どちらか片方のアクションに対してのみつながった状態となり、意図した動きと異なる結果となりますので注意が必要です。

LogicApps や Flow など、LogicFlow にはセキュリティの仕組みがないのは周知のとおりですが、これは API Management を利用することで対応可能、というかこうするのが本筋のような気もしますのでメモ書きとして残しておきます。

まずは呼び出される側の LogicFlow を作成します。今回は手っ取り早く Flow で作成。

サンプルですので、呼び出されるとすぐに結果を返却するものです。この際、HTTP Request コネクタでは、呼び出すための URL が生成されています。これはこの URL を POST で呼び出せばそのまま LogicFlow が実行されるのはこれまでに扱った通りです。

次に API Management を用意して、LogicFlow を呼び出すためのプロキシを作成します。

残念ながら、現在のポータルからはまだ利用できないので旧ポータルから・・・。

新規に作成しようとすると、上記のようなダイアログが表示されます。ここで設定するのは、呼び出しベースとなる URL と、構築対象となる Azure サブスクリプション、そして構築場所のリージョンです。API Management でプロキシを挟んだ環境の場合、［プロキシの URL］/［API］のような形でアクセスが可能になります。

同時に開発者向けポータル、が作成されるのですがその際に表示する組織名と、問い合わせ先となるメールアドレスです。

作成にはおおよそ 30 分ほどかかります。これで API Management な環境が構築されましたので、続けて API の定義を行います。

先程のダッシュボードに「発行者ポータル」と書かれていたところがあったので、それをクリックすると上記のようなサイトが開かれます。ここから、利用する API の設定を行います。

左のメニューから「APIs」をクリックすると上記のように表示されます。ここで新たに API を追加するか、既存の API を変更するかを行います。今回は新規に登録しますので［ADD API］を、もし利用する API に Swagger な JSON ファイルがあるのでしたら［IMPORT API］をクリックします。

ADD API 選択時は、このように WebAPI の名前、Web サービスの URL（今回でいえば LogicFlow の URL）、URL サフィックス（API Management 経由で呼び出す際に URL に付与するアドレス）を指定します。この時点では Web サービスの URL として、LogicFlow で生成された URL をそのまま張り付けておきますが、後でここは修正する必要があります。

IMPORT API の場合は、生成されている Swagger の JSON ファイルを指定することになります。WADL にも対応しているので、利用できる方を利用してください。

設定が行われると、先程の一覧に API が追加されますのでそれをクリックすると、このように詳細が表示されます。ここから実際に呼び出すことができるよう、設定を追加します。

まずは Setting タブで表示される部分です。ここで変更が必要なのは［Web service URL］に表示されている、呼び出される Web サービスのアドレスです。ここは先程、LogicFlow で生成された URL をそのまま張り付けていたので、api-version に始まる各種パラメータが付随するアドレスになっています。これを除去します。上の例では「～ triggers/manual 」まで削ったものとなります。

次は API Management を経由して呼び出す際の、呼び出し方を定義します。Operation タブで設定を行います。上の例ではすでに一つ登録した後ですが、新規時は何もない状態ですので［ADD OPERATION］をクリックします。

LogicFlow の呼び出し方をここで定義します。LogicFlow は基本 POST でなくてはならないので、API Management 側も同じく POST に合わせます。そして URL template には / だけとしていますが、これは https;//[API Management のプロキシアドレス]/[API のサフィックス]/ というパラメータもない状態で呼び出し可能としたかったから、/ 以外は何も記載していません。

そして Rewrite URL Template のところで、実際の呼び出しで必要なパラメータ、api-version や sig などを記載します。こうしないで、Web サービスの呼び出し URL にすべてを含めた形にしていても行けそうに思えますが、実際には呼び出そうとした際にパラメータがすべてクリアされてしまいますので、この部分でパラメータを付与するように指定する必要がありました。

ここまで設定すると、API を呼び出す下準備は整ったことになります。後必要なのは、API Management 経由の場合、API Management を利用するユーザーの情報が必要になります。

これは API の設定で上記のように「セキュリティ：何もなし」にしていても必要です。

そして実際に必要となる値は、左のメニューから Users を選択し、対象ユーザーの詳細を表示した際に確認可能です。この値を、呼び出し時のヘッダ情報に含ませる必要があります。

実際に呼び出しを行っています。私の場合は Advanced REST Client が気に入っているのでこれを利用しています。

上記のように、ヘッダ情報に Ocp-Apim-Subscription-Key というキーを追加し、値としてユーザーに振られているキー情報を記載します。こうすることで API Management を経由して LogicFlow を呼び出すことが可能になります。

API Management を利用する利点は、セキュリティの設定や課金の設定、利用量の測定などがまとめて行えて、呼び出し先の API 自体になんら影響を与えない点です。今回のように LogicFlow だけではセキュリティもなく問題がある場合でも、API Management 側で認証を行うなどを実施することが可能になりますので、非常に使い出のあるサービスなのではないでしょうか。

LogicApps を利用している方々のところには、MS からメールが届いているかと思いますが、2016/11/01 より AppServicePlan を利用した LogicApps の利用が行えなくなる模様です。

エンタープライズアグリーメント（EA）利用者はこれまで通り可能とのことですが、一般利用者にとっては従量課金的な Consumption のみになるということで、わかりやすくなるとは思います。

実際に MS から送付されたメールがこれ。

11/1 とありますが、MS の LogicApps 料金計算ページからは AppServicePlan の表示はなくなっています。MSDN 内ではまだ表記が残っており、「過去に App Service プランで作成したロジック アプリは、引き続き以前と同様に動作します」との記載もまだありますが、7月時点での記述というのもあり、これが 11/01 を迎えたときにどのようになっているかは、注意しておく必要がありそうです。

Ignite で流れている情報をちらちら見ていたので、大体は把握しているのですが、今後の事も踏まえてメモ書きを残しておきます。

全体の予定としては、上記のスライドにまとめられています。Q4 には GA するとのことなので、もう数カ月以内には GA されるようです。

GA 後には Azure Functions への対応が Flow にも来るのと、Flow から LogicApps へのアップグレード的な仕組みも用意される模様。元々が同じ基盤を利用しているからこそできることですね。

そして気になる料金体系は以下の予定。

個人向けで使ってなんぼ、と思っていたので無償プランが残るのは非常にありがたいところです。月に 750 回の実行まで、となっていますが、これが LogicApps でいうアクション数なのか、LogicFlow 自体の実行回数なのかは配布されているスライドを見てもちょっとはっきりしませんでした。

※スライド上は「 Flow の実行回数 」と読み取れるのですが・・・

PowerApps と一緒に利用している場合と、Flow を単独で利用している場合とでは、各種設定方法が異なる画面遷移になっているものがあります。細かいアップデートが実施されたこともあり、現時点では Flow 単独でも色々できるようになりましたので、今時点での操作方法をまとめておきます。

これが Flow の基本画面（デザイン中）です。

まずは右上のアカウント（人型アイコン、または自分のアカウントに設定した画像）をクリックすると、設定用メニューが表示されます。

• 自分のフロー：このアカウントで作成した LogicFlow の一覧を表示
• 自分の接続：コネクタで利用している接続の一覧を表示
• ゲートウェイ：オンプレミスとの接続を行うゲートウェイの一覧を表示
• カスタム API：LogicFlow から呼び出せるよう登録した API の一覧を表示

また、コネクタにおいても設定用メニューが追加されています。

コネクタの名前（見出し）変更やコメントの追加、削除はこれまでもありましたが、接続先についてのメニューが追加されています。このコネクタで利用している接続が表示されるのと、新しく接続を作成するためのショートカットが表示されるようになっています。

自分のフローをクリックした場合の一覧は、このような感じです。ここから LogicFlow に対しての修正や、新規作成、または無効化や削除を行います。

自分の接続をクリックするとこうなります。LogicFlow は各種サービスと連携するのがウリの一つでもありますので、ここにはたくさんの接続が表示されることになります。連携用のアカウントで、パスワード変更などを行って接続できなくなった場合はこの一覧上から設定を行うことができます。

これがゲートウェイの一覧ですが、Flow のみを利用している場合、現在オンプレミスのデータゲートウェイを利用できない制約があります（利用するためには PowerApps が利用できるアカウントでなくてはならない）。

ここで、ゲートウェイの作成をクリックすると、インストーラーが DL できるので、利用可能な方はここから作業を行うのが楽そうです（今までは PowerBI のサイトに行かないとなかった）

カスタム API の登録がこちら。JSON 定義を「ダウンロードしておいて」それを取り込ませる形になります。コネクタから Swagger を利用する場合のような、URL 指定はできないので注意です。

このような形で、随時細かいアップデートを適用し操作性を改善していってます。そのため、次に見たときには、ここで紹介したものと異なることがありえるのは、クラウドサービスとしてよくある事態なのをご注意ください。

LogicApps 界隈はアップデートを木曜日に行うのが定例となっています。コネクタの追加は随時行われており、それとは別にリリースされているのですが、LogicApps 自体のアップデートは木曜日が多い模様です。今回のアップデートでも機能改善が行われています。

公式サイトでの発表では以下の点が改善されたとのことです。

Release Notes:

• Resubmit button added to the run view to resubmit a run
• Ability to regenerate callback URLs for request triggers
• Added chart and metrics for billable actions by logic app (below list of runs)
• Performance improvements for designer load time and run view load time
• New output picker experience (Add Dynamic Values) with search for outputs
• ForEach allows multiple actions
• Cognitive Services Text Analytics connector
• Will always show delete and rename but give info when actions cannot be performed
• @base64 can now encode JSON objects

Bug Fixes:

• Drag and drop bugs
• Unsubscribe from webhook should be optional

また、久々となる LogicApps Liveも行われていて、そこでは上記の内容以外にも現在進行形の話など色々と新しい話題が飛び出していました。

まずは ForEach コネクタでの複数アクション指定が可能になりました。これ結構うれしいんですよね。今までだと別の LogicFlow 呼び出すしかループ内部で複数アクション実施する方法がなかったのですが、これで少しシンプルに書くことができるようになります。

コネクタで利用する値の指定ダイアログも変更になりました。利用するコネクタによっては、提供される値がべらぼうに多く、その場合は画面上に表示される値の数も非常に多くなり見にくかったところだったのですが、別ダイアログとすることで非常にすっきりと。

新しいコネクタ周りでは Cognitive Service 対応の一つとして Text Analytics が利用できるようになりました。旧コネクタはこれで廃止されていく方向かな？

そして「後で読む」でおなじみのサービス、Instapaper へのコネクタも追加。

また、開発中バージョンの紹介として Azure DocumentDB コネクタが紹介されていました。なのでこれは近日中にリリースされるのではないでしょうか。

現時点での LogicApps チームの作業内容はこちら。以前アナウンスされていた GMail と OneNote がいなくなったのが気になりますが、ホワイトリスト対応など気になるものが含まれています。

AppService から外れた位置づけに LogicApps が変わったこともあり、LogicApps 単体で色々できるようにする方向にシフトしているのかもしれません。

他にもメトリック対応されたので、LogicApps に関連したアラートルールが作成できるようになりました。基本プランが従量課金（Consumption）なので、課金に絡む成功・失敗なども監視対象になったのはありがたいところです。

2016-10-20 のアップデートで対応されたメトリクス（監視項目）への追加対応で、請求に関連する項目でのアラートが作成できるようになりました。

アラートの設定は以下の通りです。

LogicApps のブレードを開き、一番下に表示されている「Billable executions in the past month」をクリック。

上記のようにメトリックが表示されるので、「アラートの追加」をクリック。

ここで選択できるメトリックに追加されたのが以下の物です。

• Billable Action Executions
• Billable Trigger Executions
• Total Billable Executions

それぞれ請求対象となるものについての監視ルールで、Action Executions では「請求対象となるアクション実行数」で、Trigger Executions では「請求対象となるトリガ実行数」を意味します。

LogicApps の仕組みとして、Request コネクタ以外ではまずトリガが起動しますので、Trigger Executions は定期的にカウントが上がっていくものになります。そこで実行条件を満たした場合に、後続のアクションが実施されますので、Actin Executions では実際に実行されたアクション数がカウントされていくものとなります。

それら二つを合算したものが、Total Billable Executions となりますので、基本はここを監視していることで請求額が一定ライン以下となっているか、などを監視できますし、予定している限度額に近づいた際には、アラートを発生させて管理者にメールを飛ばす、Webhook として何かしらの API を呼び出すといったことが可能です。

LogicFlow の仕組みとして、直前のアクション結果に基づいた処理分岐が用意されています。これを利用すると、あるアクションが成功した場合と失敗した場合とで処理を分岐させることができ、一般的なエラー対応を行えるようになります。

これまでの投稿の中で、LogicFlow をコードビューで見た際にだけ記述できる runAfter という値を扱ったことがあります。エラー処理を行う場合にも、runAfter の値を用いで行います。

まず簡単な例として、呼び出された際に適当な HTTP ステータスを返却する Azure Function App を用意します。このような検証ですと、速攻で用意できる Azure Function App は本当に便利ですが、VB 使いとしては（

例えば正常な結果を返すテスト用にはこのような形で用意します。

失敗した結果を返すテスト用ですと、次のような感じになります。

見てもらうとわかるように、何もせずに HTTP ステータスを返却しているだけです。次はこれを用いる LogicFlow を作成します。

まずはデザイナー上で、HTTP Request コネクタ、HTTP コネクタ（本当なら Function App の検索で呼び出せればよかったのですが、なぜか今回は一覧に表示されず……）、そして正常時の応答を返す HTTP Response コネクタと、異常時の応答を返す HTTP Response コネクタを用意します。

そして Code View で直接 JSON 定義を編集します。上記の状態では以下のような定義になります。

{
    "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
    "actions": {
        "HTTP": {
            "inputs": {
                "method": "GET",
                "uri": "https://kumafunc.azurewebsites.net/api/FromLogicFlowHTTP"
            },
            "runAfter": {},
            "type": "Http"
        },
        "応答": {
            "inputs": {
                "body": "Called OK",
                "statusCode": 200
            },
            "runAfter": {
                "HTTP": [
                    "Succeeded"
                ]
            },
            "type": "Response"
        },
        "応答_2": {
            "inputs": {
                "body": "Called Bad Request",
                "statusCode": 400
            },
            "runAfter": {
                "応答": [
                    "Succeeded"
                ]
            },
            "type": "Response"
        }
    },
    "contentVersion": "1.0.0.0",
    "outputs": {},
    "parameters": {},
    "triggers": {
        "manual": {
            "inputs": {
                "schema": {}
            },
            "kind": "Http",
            "type": "Request"
        }
    }
}

応答 と 応答_2 のコネクタ設定で、どちらも runAfter の値は「直近のコネクタが正常終了した」という条件を表しているのがわかるかと思います。エラー処理を行う場合、ここの条件を調整することで、対応が行えるようになります。

先程の JSON 定義を、下記のように書き換えます。

"応答": {
    "inputs": {
        "body": "Called OK",
        "statusCode": 200
    },
    "runAfter": {
        "HTTP": [
            "Succeeded"
        ]
    },
    "type": "Response"
},
"応答_2": {
    "inputs": {
        "body": "Called Bad Request",
        "statusCode": 400
    },
   "runAfter": {
        "HTTP": [
            "Failed"
        ]
    },
    "type": "Response"
}

応答 と 応答_2 のコネクタ設定のうち、応答_2 の方を「HTTP コネクタが失敗した」という条件になるよう runAfter の箇所のみ書き換えたものです。なお、ここで指定できる値ですが、

• Succeeded：成功
• Failed：失敗
• Skipped：スキップ

の 3 種類が利用できます。MSDN ではまだドキュメントの更新が追い付いていないようで、Aboted と書かれていますが、これは現在のスキーマでは利用できずにエラーとなりますので気を付けてください。

この状態に書き換えた後で、デザインビューへと戻ります。

すると、上記のように並列動作を定義したかのようなフローへと書き換わります。

このようにコネクタの runAfter 値を設定することで、直前のコネクタがエラーになった場合の処理を設定することができるようになります。

なお、上記の状態で、新しいステップを追加するとどうなるかというと。

このような状態となります。ここで Code VIew を見てもらうとわかりますが、並列に並んでいる二つのコネクタがどちらも正常終了した場合に、次のステップが実行されるように設定されています。今回のようなエラー処理の場合、何かしらのエラー処理を行った後に通常の流れと合流する、ということになりますので、このあたりの制御は注意してください。

またあまりにエラー処理を利用すると、LogicFlow が非常に複雑になりがちです。Scope を利用してある程度の処理をグループ化する、別の LogicFlow に分けるなどといった対応も必要に応じて行うと良いのではないでしょうか。

最後に、実際に LogicFlow を呼び出して、想定した値が返却されているかのスクショを張り付けておきます。

LogicApps や Flow では、処理の実行タイミングを制御する仕組みとして何種類かの方法があります。トリガに対して開始日時を設定する方法、延長期間（Delay）コネクタを利用する方法、延長期限（Delay-Until）コネクタを利用する方法がそれにあたりますが、それぞれに違いがあるのでまとめてみました。

まずはトリガに対して直接開始日時を設定する方法です。

繰り返し（Recurrence）コネクタではデザイナ上で指定できますが、そのほかのコネクタにおいても Code View 上で starttime の値を設定することで同様のことが行えます。

この場合は、設定した時刻になるまでトリガが呼び出されません。

延長系のコネクタを利用する場合は、デザイナ上で上記のように「いつまで待機するか」（Delay-Until）「どれだけ待機するか」（Delay）の設定を行うことができます。

これらの方法の違いは、トリガの呼び出しが発生するかどうか、になります。

最初の starttime を指定する方法では、設定日時になるまではトリガが呼び出されたことにはならず、請求対象となる実行は発生しません。

対して延長系のコネクタを利用する方法では、トリガが呼び出されそのあとにこれら延長系コネクタが実行されて待機状態になりますので、呼び出し自体はあくまでも指定した通りに発生します。ですので、請求対象となるトリガの実行は発生しますし、延長系コネクタより先になにがしかの処理を定義してあれば、そこまでのアクション実施数も請求対象となります。

上記は延長系コネクタを利用した場合の実行履歴ですが、延長コネクタにより実行を待機している状態のまま、次の LogicFlow が呼び出されているのがわかります。そしてあるタイミングを迎えると、一斉に処理が実行再開されることになります。

トリガの呼び出される有無もあるので、直接請求に関連する部分になりますが、同じ実行日時を指定するものであっても、利用シーンはかなり明確に分かれます。

starttime 指定では、LogicFlow 自体の実行を行わないので、ｘ月ｙ日からサービス開始、というタイプに用いるのがよさそうです。

反面、延長系コネクタを利用するシーンは、LogicFlow の処理を途中までは進めておきたい場合、に利用するのが適しているかもしれません（実際問題としてそういうケースがどれほどあるか、というのはありますが）

アメリカ時間の 11/1（日本時間だと恐らく明日 11/2） をもって、ついに PowerAppsと Flowが正式リリースになるとのことです。それに合わせて各種料金プランやこれまで利用していた人たちがどうなるかについての発表もありましたのでメモ書きします。

まずは Flow。

個人向けもうたっていますので、無償プランは継続して残ります。また Dynamics 365 や Office 365 のユーザーについては、特定プランであれば追加費用無しで Flow が利用できるようになっています。これは PowerApps にも同様で、上記ユーザーであれば PowerApps も無償で利用が可能です。

Plan 1 は個人ユーザー、Plan 2 は組織向けという区分けの要で、Plan 2 でのみ、同一組織内における共有が可能になっています。また最近追加された Environment を複数作成し、ユーザーによって利用できる接続を変更するなどといったことも Plan 2 のみとなります。

LogicApps と異なり、課金単位は「フローの実行数」です。アクション数ではないので、ここは混同しないように注意が必要です。また、規定回数フローを実行してしまった場合に、追加実行回数を別途購入できるようになっています。

いきなり 50000 回実行できるようになりますが・・・、これはもう少し細かい単位で用意した方が使う側にとって使いやすいサービスになる気もします。

続いて PowerApps。こちらはもともと組織ユーザー向けというのもあり、無償プランは用意されません。ただし、現在開発者向けプランを検討中となっているので、近日中にアナウンスがある模様です。Common Data Modle の容量の違いなどが、Plan による差異となっています。

PowerApps ライセンスには Flow のライセンス料も込みとなっていますので、LogicFlow だけ使いたいのか、アプリケーションも使いたいのかによってどちらかを選択することができます。

GA タイミングに近い形で Flow や PowerApps では色々と機能追加が行われました。その中に管理センターというものがあるとのことでしたので、色々とみてみました。

まずは Flow の管理センターです。アカウントのアイコンをクリックすると、メニューに管理センターというのがあるのでそれをクリックします（PowerApps 利用時も同等の画面が表示されます）。

なお、この管理センターを利用するためには条件があります。

それは PowerApps を利用できるアカウントであること、という条件で PowerApps を利用できない場合はエラー画面が表示されてしまいます。これは、管理センター上で利用する機能が、Flow の無償プランでは利用できない機能だからだと思われますが、ちょっとなんだかなぁ、と思えますね。

管理センターで提供される機能は二つあります。一つは先のように「環境設定」。デプロイする環境を定義するものです。もう一つは上記の「データ損失防止ポリシー（DLP）」です。

環境設定ではデプロイする環境を設定できます。

環境名と利用するリージョンを選択するだけで、現在利用できるリージョンから選択を行います。プランによって差があるのかまではわかりませんでしたが、11/02 時点では以下のリージョンが選択できました。

LogicApps など Azure で提供されているサービスを利用する際にも、同じようにリージョン選択がありますので、意味合いは理解できるかと思います。作成した LogicFlow や、API 定義、オンプレミスとのゲートウェイ設定などが同一のリージョンに展開されます。

作成した環境については、以下のように表示されます。

ロールに対して、メールアドレスを基にしたユーザー設定を行えますが、恐らく Azure AD を参照しているので、Azure AD 上に登録されているアカウントでなければ追加できない様子です。

そしてユーザーロールとアクセス許可セットですが、これらはデータベース（Common Data Model）に対して利用するものとなります。新規に環境を作成した直後は、CDM のデータベースが作成されておらず、ロールやアクセス許可の設定が行えない状態ですので、データベースを作成した後に行います。

なお、プレビュー時から利用している場合、Default という名前の環境設定が作成されていますが、そこに対してはロールや DB の作成などは行えないようになっています。

ロールに対してユーザーの追加が行えるのですが、制限として同一組織（ドメイン）である必要があります。これはおそらく Azure AD に登録されていることが条件、なのだと思いますが、Flow / PowerApps のみ利用しているユーザーの場合、どのようにしてそれを行えばよいかはまだ方法がアナウンスされておりません。

もう一つの機能である、データ損失防止ポリシー（DLP）ですが、これは利用している環境の中で、サービス群に対してくくりを設けることで、そのくくりを超えた連携を行えなくするというものです。例えば、AというグループにOneDriveに対しての接続を作成し、BというグループにOffice365 の接続を用意したとします。この場合、A と B の間ではデータ連携を行うことができなくなります。そうすることで、不要なデータ漏れを防ぐ意味合いがあります。

主な使い道としては、初期設定にもあるように「保護が必要なビジネス向けデータ」とそれ以外を区分けし、安易に連携させないようにすることになるかな、と思われます。

このような機能が GA と同時に追加されているのですが、ここまで読んでいただいてわかるように基本的には組織ユーザー向けの機能です。個人向けではないので、お世話になる人は結構限られるかな、という印象です。

今まで LogicApps ではセキュリティ的要素を持っておらず、Azure ApiManagement を利用するか、API 内部で実施するかなど別の手段に頼らざるを得ませんでしたが、今回 IP アドレスによるアクセス制限が追加されました。

設定に Access control configuration という項目が増えているので、これをクリックすると IP 制限をかける画面が表示されます。

ここで設定できるのは、LogicApps の呼び出しに対する IP 制限と、履歴情報の取得に対する IP 制限となる模様です。IPv4 または IPv6 による設定が可能になっているので、これで呼び出し元を制限させることが可能になります。

また、同時期に SAS アドレスを生成するためのアクセスキー設定機能が追加されました。

こちらでプライマリキーかセカンダリキーかを指定すると、HTTP Request コネクタなどで生成されるアクセス可能な SAS アドレスにて利用されるようになります。注意点としては、Warning が書いてあるように、すでに存在している SAS アドレスも変更されるので、一度 LogicFlow にアクセスしなおして再保存する必要があるとのことです。

大体月に一度のペースで行われている LogicApps チームの Webcast があるのですが、今回もここまでにリリースされた新機能や、現在作業中のものについての話がありました。

現在までにリリースされている新機能の説明です。つい最近に提供開始された IP アドレス制限や、OMS で LogicApps のログを参照できるようになった件、実行履歴から IN/OUT の生データを確認できるようになった件などがあります。

そしてここまでにリリースを開始している新規コネクタ。昨日利用可能になった File コネクタなどもここに含まれています。

現在作業中のタスクについて。Azure サブスクリプションとの接続生成がありますが、これは Microsoft Flow に先行リリースされていた Azure Resource Manager 用コネクタの件でしょう。ほかにもいろいろな点について作業中だそうです。

DocuSign って電子署名のサービスでしょうか。Mediumは Twitter の創設者が作った Blog 記事などの作成、公開などいっしょくたにひっくるめた総合サービスのやつでしょうか。

しかし GMail と OneNote はどこへ（

LogicApps では XML を扱うのも、繰り返し処理を行うのも微妙にクセがありつかみづらいところでしたので、試したことをメモ書きしておきます。

お題として、11/24 に CLR/H カフェと称した集まりがあり、そこでさかもとさんから頂いたものがあったのでそれを利用しています。

処理対象となる XML データはこれを利用しています。ブラウザで開くと以下のような形で表示されています。

ListBucketResult を親要素とした XML データで、Contents エレメントで各モジュールの情報を保有している形式です。HTTP コネクタで取得すると、上記の XML データが扱えるようになりますが、実行履歴では次のように表示されます。

これは HTTP コネクタで取得した結果を BASE64 エンコーディングし、ほかのコネクタへと渡しています。Content-Type と Body に分けて値をやりとりしているのですが、他のコネクタで値を利用する際に、BASE64 からのデコードは不要です。MSDN に記載があるのですが、いまいちつかみづらい・・・

次に取得した XML データにおいて、Contents エレメントの数だけ繰り返し処理を行う場合の記載についてです。こちら ForEach コネクタを利用するのはすぐに思いつくことと思います。実際に利用する際は以下のように記載します。

LogicApps の関数で用意されている json 関数は、文字列または XML データを JSON として変換します。body(’HTTP') というのは、先程の HTTP コネクタで取得した結果の BODY 部を意味します。これは XML データ全体を表しているので、ルート要素から目的の値を配列として保持している Contents までを ForEach コネクタの対象として記載します。こうすることで、Contents 要素で記載されているすべての要素に対し、繰り返し処理が行われます。

繰り返し処理内部での記載は上記のようになります。@item() 関数を利用すると、繰り返し要素を参照できますので、今回は Contents 要素が持つ Key 要素の値を BLOB のファイル名へと利用しています。Replace 関数は文字通り、文字列の置換を行っていて、ここでは /（バックスラッシュ）を _ （アンダースコア）に変換させています。

このような記載を行うことで、XML を取得し、その要素数分繰り返しを行う処理が LogicFlow で実施できます。

以前にカスタム ApiApps を LogicApps から利用したことがあるのですが、そこから大幅に構造が変わったこともあり、最近になってようやくあらためてやってみようと思った次第です。

通常の流れでは Azure ApiApps を作成して、それを LogicApps から呼び出すだけなのですが、表題にもある通り VB.NET でそれをやってみたものとなります。わざわざこう書いているので、なんとなくわかった方もいるでしょうが、VB.NET 用の ApiApps テンプレートはいまだに提供されていません。

（VS2015）

（VS2017)

実際のところ、WebApps も ApiApps もほぼほぼ同じものですので、技術的には可能というか、なぜできないようにしているのかがわからないレベルの話なのですが、現時点の仕様として VB を選択した場合に、ApiApps は新規作成できません。しかしデプロイすることはできたりしますので、今回は VB.NET 製の ApiApps を LogicApps から認識させてみようと思います。

まずは ApiApps を作成するためのテンプレートですが、以前に書いたエントリにて公開している VB.NET 向け ApiApps のテンプレートを利用することにします。これは既存の C# 用 ApiApps テンプレートを VB 向けにいろいろ書き直したものとなっています。なお、以前はこのテンプレートからデプロイすることで ApiApps の新規作成も行えていたのですが、現在ではそれもままならず、新規作成できるのは WebApps のみとなっています。

実際のトリガのソースとしては、MSDNにも記載があるように Githubでサンプルが公開されています。しかしこれは当然 C# のみですので、これを VB 用に書き換えを行います。

書き換えたものは上記のようになります。ここまでできると、次はデプロイ先を用意することになります。

先程書いたように、VB.NET の場合は、ApiApps の新規作成が行えません。どうするかというと、あらかじめポータル上で ApiApps を作成しておき、そこに対してデプロイする形を採ることになります。こうしないと、LogicApps 側で ApiApps と認識されないため、LogicFlow 上で呼び出すことができません。

ポータル上で新規作成した後に、デプロイ先として選択します。ここで表示されているアイコンが ApiApps となっているのが確認できるかと思います。この状態であれば、ApiApps として VB なアプリをデプロイすることが可能です。

無事にデプロイできたら、次に LogicApps から ApiApps へとアクセス可能にする設定を行います。具体的には Swagger で作成されている API 定義アドレスの設定と、CORS の設定です。

API 定義は https://hogehoge.azurewebsites.net:443/swagger/docs/v1 の形で指定します。ここでは HTTP ではなく HTTP/S である必要があります。

CORS については、LogicApps のデザイナーなアドレスを指定するのですが、以前設定した ema ～なアドレスでは現在アクセスできないのが確認できています。残念ながら * を指定し、どこからでもアクセス可能とすることになります。

このように設定を行うことで、LogicApps 側から ApiApps が認識され、上記のように一覧から選択が可能になります。

選択すると、API として提供されているものの一覧が表示されますが、注意が必要なのはトリガとアクションの区別が行われていないので、トリガとして利用できないものや、アクションとして利用できないものも一覧上に表示されます。

一覧から選択するとこのように表示され、自分で実装した APIApps が利用できているのがわかると思います。このデザイナー上の表示についても、少しはカスタマイズができるとのことなので、次はそのあたりを挑戦してみようと思います。

定期的に行われている LogicApps チームによる Youtube 放送。今回は今年最後ということでサンタ帽をかぶっての登場となっていました。公式 Blog でなぜか発表しない内容が多いのはさておきｗ

今回の更新情報としては、Cloud Exproler での LogicApps 対応、HTTP 認証の追加、IP 制限の追加、Log 検索対応、Alert 対応、といったところです。

追加コネクタとして、プライベートプレビューだった SAP や、Google Contract、Harvest、Buffer、Typeform、Medium、MSN Weather、SparkPost、Chatter が登場。SurveyMonkey はアナウンスがあったものの、自分の環境ではどのリージョンにおいても見当たらず・・・。

そして Enterprise Integration Pack も GA を迎えました。BizTalk の仕組みを利用したものですが、VS 上でスキーマやマップを定義し、ポータルからアップロードすると、データ変換などが行いやすくなるものです。個人的にはもう GA していたものだと思っていました（

SAP コネクタはオンプレミスデータゲートウェイを利用して接続するもので、まだまだ改良中だからどんどんフィードバックしてほしいとのこと。

現在作業中のものとしてはいろいろありますが、OneNote コネクタが作業中に帰ってきましたw 他にも Outlook Tasks が追加されていたりと、何気に嬉しい対応サービス追加となりそうです。

また、一部で熱烈に希望されていた Switch 式も現在作業中なのと、JSON 周りが改良中なのも嬉しいところですね。やはり現時点だとどうしても使いにくいところが多い（配列の配列がうまく扱えないなど）ので、このあたりさらに利用しやすくなってほしいものです。

明日の CLR/H にでかい影響はなかったので一安心（

2016/12/17 に行った CLR/H #103でLogicApps や Flow について話してきました。毎年年末恒例行事なのですが、ここ数年は札幌にいなかったのもあり久々の参加に。

スライドはこちらです。

今回はコードを書いたら負け、というテーマで LogicFlow のみで色々できることを中心にお話しさせてもらいました。今話題になっている LINE BOT や、GPS を絡めた処理など、思っているよりもいろいろなことが LogicFlow のみでできることが伝わっていれば幸いです。

実際、ここ最近は WebAPI として HTTP でアクセスできる形での機能提供が多いです。それは言い換えると、コードを書かなくても連携が可能、とも言えます。セッション中に話しましたが、これからは単純に連携するならば LogicFlow などで省力化し、込み入った処理が必要な個所だけコードで API 化するのが時間効率的にも優れた手法と言えるのではないでしょうか。

12/17 の CLR/H で話させてもらったネタのまとめです。単純に受け答えするだけなら、もうコードを書く必要がない時代になっているというのがわかると思います。

アカウントの作成については色々なところで記載されているので割愛。LINE BUSINESS CENTERでアカウントを作成し、Messagin API の有効化と Webhook の有効化を事前に行います。

実際に BOT としてある程度の機能を持たせるためにはいくつかの処理が必要となります。

• Webhook を受け取り発生したイベントに対応させる
• 何かしらのメッセージを返却する

メッセージを返却する方法は Reply と Push の二つが用意されています。Reply は受け取ったメッセージに対する返答で、Push は自発的にこちらからメッセージを送付する方法です。

LINE 上でメッセージを受け取る、友達登録されるなどのイベントが発生した場合には、Webhook で特定の URL へ呼び出しを行ってもらうことができます。その際の設定は、

アカウントリストの上記から、Messaging API 欄の横にある LINE Developers をクリック。

表示されるアカウント情報の下部に、Webhook URL という項目があります。上記のスクリーンショットはすでに設定済みの状態ですが、ここに対して呼び出してほしい URL を設定します。

LogicFlow で呼び出してもらう URL は 要求：HTTP Request コネクタで生成されます。

HTTP Request コネクタは一度保存しなければ URL が生成されませんので、トリガを置いた状態で一度保存します。そしてコネクタ下部には、受け取る JSON データのスキーマを定義することができます。これは LINE Messageing API Refernece に記載されているサンプルデータから、スキーマを生成して貼り付けます。スキーマ生成には Jsonschema.netなどが便利です。

こうすることで、トリガの後の処理で受け取ったデータを指定しやすくなります。

スキーマを指定しなかった場合は、受け取ったヘッダーかボディを指定することしかできないので、ここから値を取得するには関数を利用するなどのひと手間が必要になります。こういう違いがありますので、受け取るデータスキーマが明確な場合は、必ず設定しておくといいでしょう。

Webhook でメッセージを受け取った場合、その文章は  events という配列の中に設定されています。一度の Webhook 受信で複数メッセージを受け取ったり、複数のイベントを受け取ることがあるためです。LogicFlow 上では、そのような配列内部の値を利用しようとした場合、自動的に ForEach コネクタが設定されます。

上記の場面では、配列内部の text の値をセットすると、自動的に ForEach コンテナが配置され、その内部の子コネクタとして構造が調整されています。現在の LogicFlow の仕様制限として、一次元の配列は問題ありませんが、二次元以上の配列を扱おうとした場合には簡単にできないというものがあります。

ForEach コネクタのネストが行えないので、もう一つのループ処理である DoUntil コネクタを利用したり、別の LogicFlow に配列処理部分を切り出すなどの工夫が必要です。

今回は受け取ったメッセージをそのままオウム返しするよう、Push Messageの仕組みを利用します。返答先となる userId や、受け取ったメッセージの text の指定が、最初に設定したスキーマにより簡略化されているのがわかると思います。

ヘッダー部では、Messaging API へ渡す認証情報の設定が必要です。API Reference にもありますが、Channel Access Token として LINE Developers に記載されていますので、それをまるまるコピーします。Content-Type については application/json である必要があるので、その通りに記載します。

ここまでの LogicFlow で、受け取ったメッセージをそのままオウム返しする BOT が作成できてしまいます。まったく一行もコードを書いていないので、今まで難しそうだと思った人でもできるのではないでしょうか。また今回の LogicFlow 作成は Microsoft Flowの無償プランにて実施しています。メールアドレスの登録だけで、どなたでも利用可能です。

また、受け取ったメッセージの文言により、返す文言を変更するといった判定も行うのは簡単です。

ForEach コネクタの下部に「条件の追加」というリンクがあるので、それをクリックすると上図のように判断を行うコネクタが利用できます。今回は、受け取った文言に「てすとぶろぐ」というのが含まれているかどうか、で処理を分岐させています。

判断結果の「はい」「いいえ」でそれぞれ返答するメッセージを HTTP コネクタを利用して POST します。

そうすることで、このように簡単に反応を調整することも可能です。複雑な判定を行いたい場合は、別の LogicFlow に切り分けるのが、処理全体で大きくならないでよいのですが、Flow の課金は「LogicFlow の実行回数」に基づきますので、そのあたりはさじ加減とも言えます。

Azure LogicApps や Microsoft Flow の登場で、コードを書く開発者以外でも、API を連携して利用したりする仕組みを作ることが、非常に容易になったと思います。今まで「プログラム書けないから」と断念していたことも、これら LogicFlow を利用することでできるようになることが出てくると思います。何より、無償で試せるしな！

LogicFlow の基本機能の中に、作成：Compose と フィルタ：Filter という特殊なコネクタが用意されています。

Compose の基本機能としては、「変数への値設定」となります。といっても、プログラミングで出てくる変数とは少々異なり、保持している値へさらに追加という使い方はできず、一回のみ設定可能な挙動となります。

例えば上記のように JSON 値を渡して LogicFlow を呼び出すとします。

要求：HTTP Request コネクタではスキーマを定義しておき、このような形で受けっとた値の name だけ指定しておきます。

この場合は、Compose コネクタで指定した name な値だけが設定されているのがわかります。

次に、JSON 値の中で配列と定義してある languages を指定してみます。

その場合の実行履歴を確認してみると、これまでと違い作成のコネクタがなぜか薄く表示されており、1 回目や 2 回目という回数を指定できるようになっています。ここから 1 回目の処理結果、2 回目の処理結果を個別に確認できる……だとよかったのですが、現時点でここは何の役にも立ちません……

左上にある「実行の詳細」をクリックすることで、全体の処理履歴を確認できるのでこちらからの確認になります。

今回は作成：Compose コネクタしかないのでそれを選択すると、「ロジックアプリのアクション」が表示され、コネクタへの入力値と出力値が確認できます。

ところが入出力それぞれを見てみると、どちらも同じ値、Compose コネクタに設定した languages 配列そのものが入力も出力もされているのがわかります。これは、デザイナー上で指定した値のみに限定されたものがコネクタに渡される LogicFlow の仕様みたいなもののためです。今回で言えば、スキーマ上で languages の値が配列として定義してありますので、その部分だけが Compose コネクタへと渡されたことになります。

それでは、配列の中身を直接指定した場合はどのようになるのでしょう。

配列の内部値を利用する場合に、デザイナー側で自動的に ForEach コネクタが導入されます。ForEach コネクタに対して、まず languages 配列が渡されます。

続いて ForEach コネクタ内部の Compose コネクタに対して、値が一つずつ受け渡されています。この時は「ロジックアプリの実行」画面からそれを確認が可能です。

結果として出力されている値を見ると、先程のように language 配列を指定した場合とは違い、langname 値と、それ以外にもいろいろな値が付与された形で、配列として返却されているのが見えます。これはコネクタが実行された際に毎回 Azure LogicApps が生成している値で、LogicFlow の追跡に必要なものなどが含まれています。今回のケースでは、Compose コネクタは ForEach コネクタ内部で「2 度」実行されているので、それぞれの値にシステムから自動で付与されたものと考えることができます。

また、Compose コネクタを利用すると配列内部の特定要素に限定した配列に、再編成のようなことも行えます。

呼出時に渡す値を、上記のように language 配列内部に lang 配列を持つ形に変更してみます。

LogicFlow 側では、lang 配列内部の langname 値を Compose コネクタに指定します。なお、デザイナ上で設定したように見えますが、現時点ではデザイナ上で上記のように設定は行えず、CodeView を利用するか、デザイナ上で @item().lang[0].langnameのように直接指定する必要があります。この書き方で行くと、ForEach コネクタで指定されたものの要素（→ item）にある、lang 配列の先頭要素（→ lang[0]）にある langname 値、という意味になります。

このように指定すると、特定要素に限った形で値を扱うことが可能になります。ここより以降のコネクタでは、デザイナ上で「作成」を選択すると、この配列が扱えるようになります。

このように Compose コネクタは使い方が理解しにくいところはありますが、LogicFlow 上で必要な値をあらかじめ抽出しておくなど、LogicFlow を見やすくするためにも利用することが可能です。