LogicFlow に最近追加された Typeformコネクタ。アンケート作成が主な機能の Typeformですが、イベント参加申し込みなどにも対応しており、アンケートなども含めユーザーに何かしら入力してもらうものについて色々できるサービスとなっています。

LogicFlow に対して提供されている Typeform コネクタの機能は、トリガが一つだけとなっています。

非常にすがすがしいほどシンプルで、「何かしらの反応を貰った時」というトリガになります。アンケートやイベント申し込みでいえば、参加登録されたとかアンケートに回答された、というタイミングです。

Typeform 上での作業は、受付サイトを作ることになります。日本語にも問題なく対応されているのと、設問への回答によって次の質問を分岐したり、回答された内容によって設問の文言を変えたりといった、なかなか面白いことが非常に簡単に行えるようになっています。

LogicFlow との接続には API Key が必要です。これは右上のメニューから、MyAccount を表示させると確認できます。

LogicFlow から利用する際には、最初に接続を作成するのは他のコネクタと同様です。接続名には適当な名称を（管理用に表示される名称となります）、API Key には先ほど確認したキー情報を貼り付け、作成をクリックします。

接続すると、作成済みとなっているフォームの一覧が表示されますので、LogicFlow で受け取りたいフォームを選択します。

コネクタから提供される値は上記の通りです。フォーム上に設定した各種質問の答えと、受付日時、登録日時が利用可能です。今回はフォーム上で、「何か質問がありますか」的なものを「その他に言い残しておきたいことはありますか」という設問を用意していますので、ここに何か入力された場合に限り、メールで通知を行います。

今回はこのような感じで、「その他に言い残しておきたいことはありますか」という設問に入力があった場合に限り、メール通知を行うようにします。その際に IF 文的な条件判断を行うコネクタで入力がありますが、「何か入力されていた場合」というものはそのままでは設定できません。LogicFlow 上で利用可能な関数を利用して判断を行いますが、未設定という判断を行うのが現時点では少々複雑になります。

条件判断を行わせている箇所の、一つ上に「作成」コネクタがあるのですが、ここで未設定を判断させるための下準備をしています。

条件判断で行っていることは以下のようにしています。

@not(equals(coalesce(triggerBody()?['その他に言い残しておきたいことはありますか？'], outputs('作成')),outputs('作成')))

単に「未設定かどうか」を判断させたいだけなのですが、このように面倒くさいことをしなくては、現時点での LogicFlow では判断できません。細かい処理としては次のように行っています。

1. coalesce 関数で「その他に～」が未設定だった場合は、作成コネクタの値を利用
2. equals 関数で上記の結果が、作成コネクタの値と同一かどうかを判断
3. not 関数で結果を反転

作成コネクタで設定している GUID は、ほぼほぼ重複することがないといえる値を生成してくれる関数です。また、triggerBody()?[‘その他に言い残しておきたいことはありますか？’] で利用している ? 演算子（triggerBody()? の ?）は、参照した際に Null （存在しない・未設定）の場合でもエラーとならずに Null を返すことができるものです。この挙動に、値が Null の場合に指定した値を返却する関数 coalesce を加えると、未入力だった場合に特定の値を設定することができます。

この場合の特定の値＝ GUID なので、高確率で未入力を判定できることになります。

早速受付サイト側で入力を行い、最後の設問に対して適当に文字を入力します。

すると、問い合わせがあったことを通知するメールを飛ばすことができます。

このような形で利用すると、イベント申し込みやアンケート回答の中で、特定のパターン（問い合わせがある、個別な意見があるなど）に限り、通知を行うことも可能です。

Microsoft が提供している Cognitive Services の一つに LUIS（Language Understanding Intelligent Service） があります。LUIS は与えられた文章を、機械学習を用いて解析し、指定したパターンに当てはまるかどうかを判定、不足している要素は何か、といったところを扱えるものです。今回は LUIS を用いて、自然な文章で問い合わせができる Bot を作成してみます。

まずは LUIS を利用できるようアカウントなどを登録します。今年いっぱいは Free プランがトライアル用として用意されているのですが、来年からはプランが廃止されますので注意が必要です。

1.LUIS の環境を作成する

LUISのサイトへ行き、「Sign in or create an account」をクリック。

サインインオプションとして、MS 社員かそうでないかを聞かれるので、most users をクリック。

利用するアカウントでサインインします。初めて LUIS にサインインする場合は、権限付与を求められるのでそれも許可します。

アカウントの国情報、組織名、どこで LUIS を知りましたか的な質問があるので、それらしいのを選択・入力し「I agree ・・・」にチェックをつけたうえで Continue をクリック。

これで LUIS にアカウントを登録できました。続いて、LUIS の機能を利用するアプリケーション情報を登録します。アプリケーション登録することで、HTTP による呼出も可能になります。

New App をクリックするとメニューが表示されるので、New Application をクリック。

このようなダイアログが表示され、アプリの名前や、使用用途、対象とするカテゴリ、アプリの説明、そして言語を選択します。現在 LUIS では言語によって利用できる機能が違っており、日本語環境ではまだ提供されていない機能も多いですが、とりあえず利用するには問題ありません。

なお、表示がいろいろ乱れていてアレなのは Chrome だから（

登録されるとこのような画面に切り替わります。

ここで行うことは、

1. 文章の要素（エンティティ）の設定
2. 文章の要素パターン（インテント）の設定
3. 解析サンプルとなる例文の投入

が主だった作業になります。エンティティとして必要な要素を登録し、それらを組み合わせて院展ととなるパターンを設定、その後に正しく解析できるかどうかサンプルをどんどん投入、という感じです。

左部にあるメニューで Entities をクリックすると、新しい要素の登録が行えます。

実際の登録はこのような形で行います。エンティティの名称と、もし子要素があるなら子要素の名称を登録します。子要素がない場合は、Include Children のチェックを外すことで単一の要素となります。また、Include children の下にある、Hierarchical と Composite ですが、Hierarchical だと新規に子要素も追加でき、Composite だと既存の子要素を指定できます。

ここで日本語環境以外であれば、このインテントに当てはまった場合に特定の動作を行うことができるよう、設定が行えるのですが・・・

日本語環境では残念ながら未対応で、Action の部分については何も設定できません。仕方がないので、Parameters に対して、どのエンティティを用いるかを指定します。この際に左端の Required にチェックをつけると、必須項目として扱われるようになります。解析した結果、恐らくこのインテントだと思われるけども項目が足りていない場合、LUIS は不足項目が何かというのを返答してくれます。Prompt で設定したものが、その際に利用される質問文となりますのでそれを用いて、確認メッセージを飛ばす、などと言った使い方ができると思います。

インテントを登録できれば、あとはサンプル文を投入し、その際にどう解析してほしいかを指定する作業になります。投入した文章で、エンティティとなる部分を反転させると、この部分はどのエンティティになるかを尋ねられるので、適切なエンティティを指定します。また、右側のリストボックスでは、どのインテントとするかを設定します。

設定後に Submit をクリックすると LUIS はそれをモデルとして把握するようになります。

サンプル文の解析を教え込んだ後は、画面左下にある Train をクリックします。こうすることで把握したモデル情報が LUIS に反映され、これより後に投入した文章に解析に用いられるようになります。

ここでどれだけ大量にサンプルを投入できるかが、意図した解析を行ってくれるかに影響しますので、できるだけ多くの文章を投入するのが良いと思います。

2.LUIS を使用できるよう設定する

続いて行うのは、実際に LUIS を利用するために必要なサブスクリプションを設定することです。これは Azure Portal から Cognitive Services を選択することで、新規に購入が可能です。

上記の一覧で追加をクリック。

このような画面が表示されるので、アカウント名（識別するための適当な名称）、サブスクリプション、API type（LUIS を選択）、価格レベル、リソースグループ、設置するリージョンを指定します。2016/12/27 時点では、利用可能なリージョンは米国西部のみ、となっています。

大体このような感じになるので、設定後に作成をクリックします。

作成できたら、一覧上でそのアカウントをクリックし、キー情報を取得します。キーは二つ用意されていますが、どちらか片方のみで大丈夫です。

キーを取得した次は、LUIS へそのキー情報を登録します。左側メニューより App Settings をクリックすると、このような画面が表示されるので、Endpoint Key Assigned to app な枠内にある、Save a new endpoint key 欄に、先程のキーを貼り付けし、Add New Key をクリックします。これで LUIS を利用できる状態になりました。

外部サービスなどから利用できるようにするには、LUIS のサービスを API としてデプロイしておく必要があります。左側メニューから Publish をクリック、初めてのデプロイ時は上記のように表示されるので、Publish web service をクリックします。

一度デプロイすると、このように HTTP で呼び出せる WebAPI となります。クエリパラメータとして解析した文言を渡す形式になりますので、アプリ側からはその形式で呼び出す必要があります。

3.LogicFlow から呼び出す

ここまでやると、ようやく LogicFlow から LUIS を呼び出して利用することが可能です。

今回はざっくりとこのような形の LogicFlow としています。Twitter で話しかけられたのをトリガとしたいのですが、今回は定期的に TL を取得し、その中に自分あてのツイートがあれば反応する、という方式です。

含まれていた場合には、まず LUIS を呼び出します。LUIS は先程もありましたように、HTTP の GET でアクセスする方式で、解析したい文言をクエリパラメータとしてアドレスに付与した形でアクセスするものとなります。

そこで解析された結果から、処理をどうこうさせるのですが、今回はその部分を別の LogicFlow に分けています。

それが上記のような LogicFlow です。こうすることで、LUIS からの戻り値である JSON の値を、HTTP Request コネクタにスキーマ定義しておくことで、デザイナ上で扱いやすくさせています。そして必要な値だけを戻すようにしています。

こちらがもともとの LogicFlow で、ここでいう HTTP2 となっているコネクタが、分けた LogicFlow を呼び出しているところになります。LogicApps の場合、HTTP コネクタでなくとも、直接同一リージョンの LogicFlow を呼び出すことは可能なのですが、今回のように受け取る値のスキーマを定義して利用したい場合、少々面倒なことになるので注意が必要です。

JSON スキーマで定義しているすべての値を求められるのは、悪くはないのですが結構な面倒ですので、今回のような場合はそのまま JSON を渡すことができる HTTP コネクタを利用する方が楽だと思います。

試しに LUIS を呼び出し、解析を行った場合はこのように実行されています。

戻された本文には、こちらから投げた文章となる query、解析結果で最もスコアが高かったものについての topScoringIntent などがあります。実際の解析結果は entities に設定され、不足があれば dialog に不足に対する質問内容が設定されてきます。実際に戻された JSON は以下のようになっていました。

このように、LUIS を利用することで、自然な文章に対して特定のパターンにあてはまるかどうか、あてはまる場合はどの要素にどの言葉があてはまるのかを判断できるようになります。今回の例では解析結果を特にどうこうしていませんが、「札幌の今日の天気は？」という質問に対して、いつ：今日、どこ：札幌、というのが抽出できています。

それらを利用することで、例えば特定の場所の天候を調べたり、特定の挙動を行わせることも十分に可能です。

何をやらせるか、何を解析させるか、というのを決めるのが今回一番悩みましたが、目的が決まれば LUIS を利用するのもそれほど難しくはありません。このあたりの技術を含めることで、コードを書かなくとも人間味のある BOT 開発が十分に可能です。

LogicFlow を作成するうえで、値を編集したり、部分的に使いたいなどといったことをやりたくなるのは結構あります。その際には各種関数を用いてやりくりするのですが、そこを含めて書き方についてあまりわかりやすい資料がみあたらなかったのもあり、自分用にまとめてみました。

1.式の書き方と演算子

LogicFlow で提供されている関数は @ を先頭につけることで呼び出されます。ただし、複数の関数をネストさせるような場合は、最初の関数にのみ @ をつけ内部に含まれる関数には @ をつけません。

ex) @string(@rand(0, 10))  → @string(rand(0,10))

また、関数の結果を文字列としたい場合、｛｝でくくることで string 関数を用いなくても文字列に変換できます。

ex) @string(rand(0, 10)) ＝ @{rand(0,10)}

またプロパティや子要素を参照する際には ． で結合した書き方を行いますが、その際に参照できる要素がない場合には、実行時例外となってしまい LogicFlow が終了してしまいます。それを回避するための演算子として ？ 演算子が用意されています。

ex) 値に subject 要素がない場合 @item().subject は実行時例外だが、@item()?.subject は OK

？演算子を用いた場合に、参照した要素がない場合は Null を返却します。そのためそのまま利用しようとした場合にはいろいろと問題があるケースが多いので、指定したものが Null だった場合に別の値を返却する coalesce 関数と合わせて使うことが多くなります。

ex) @coalesce(item()?.subject, ‘Nullの時の値’)

配列を扱う場合は［］で配列の要素を指定することができます。

ex) @triggerbody()[0].subject = トリガから渡された値の [0] 番目要素がもつ subject の値を参照する

JSON で配列を渡された場合などで、hogehoge[0] などと指定して利用することになると思います。また、この場合は ForEach コネクタを利用して、配列の要素すべてに対しての処理を行うことも可能です。その場合、ForEach コネクタ内部で @item()という関数を利用して、繰り返し対象となる要素を参照できます。

2.関数が返す値

LogicFlow で用意されている関数から戻される値は、大きく分けると

• 文字列
• 数値
• true / false
• 配列
• オブジェクト

になります。文字列や数値を戻すものは、そのものずばりですのであまり気にしないでしょう。配列についても同様です。true/false は、例えば empty 関数のように、「空かどうか」を true（空です）か false（空でない）を戻すものです。

上記は If コネクタによる条件判断を行った場合の結果です。equals 関数で、empty 関数の結果が「true」かどうかを判断しています。この場合、empty 関数は false を戻しており、equals 関数も true ではないということで、結果として false を戻しています。

次に配列やオブジェクトを返却する場合ですが、以下のようにしてみるとわかります。

最初に json 関数を用いて、文字列を JSON に変換しています。この部分を実行すると、次のように値が戻されます。

json 関数の結果として、JSON なオブジェクトが戻されているのがわかります。この場合は、JSON で配列という結果になっていますので、直接 val1 や val2 という値を利用することはできません。［］による何番目の値かを指定したうえで、val1 等の値を参照することができます。

ex) @json(～)[0].val1 = json 関数の結果から、最初の配列の値にある val1

配列を戻す関数の場合は、上記のような JSON ではなく、配列そのものが戻されてきます。

配列を作成する createarray 関数を利用してみた場合の結果が以下のようになります。

先ほどの JSON 値と異なり、配列として値が戻されているのがわかります。

もう一つの例として、XML を扱う場合を見てみます。

最初に xml 関数を用いて、文字列を xml オブジェクトに変換し、その結果から xpath 関数で条件に見合った要素の値を文字列として取得しています。

最初の 作成_3 コネクタでの結果は、JSON でも配列でもない xml オブジェクトなので、上記のように BASE64 エンコードされた状態で LogicFlow へと渡されます。LogicFlow 上で利用する場合には、自動でデコードされるので気にしなくてよいところですが、挙動としてこういうものになります。

次の 作成_4 コネクタでは xpath 関数を利用して、値を抽出しています。ここでの戻る値は次のようになっています。

xpath 関数で抽出した値を文字列としたため、このようにオブジェクトではなく、文字列での結果だけが戻されているのがわかります。ここで xpath に指定している string を外すと、結果は xml のオブジェクトになりますので、作成_3 の時のように BASE64 でエンコードされた値がここに表示されることになります。

このあたりを押さえておくことで、どういう風に書けばいいのかな、と悩むことも少しは減るのではないでしょうか。

LogicApps のアップデートがきていたのでどういった点が変わったりしたのか調べてみました。といっても、これを書き始めた時点ではまだ適用中なのか、コネクタを選ぶとエラーになったり・・・ｗ

下書きにしておいたのもあり、01/22 時点で利用可能になりました！

なお、今後は今回のように、事前にリリースアナウンスを公表して、影響をうけるかどうかチェックしてもらいたいとのこと。

アナウンスされたのは以下の点です。

• New connector search experience – select by service and see all triggers and actions
  
• New switch condition – use switch and cases to branch logic
  
• HTTP actions in designer have new authentication options
  
• Updated icons and brand color for many actions
  
• Designer now handles when you use dynamic outputs in dynamic fields

コネクタの検索が、最初はサービスの表示とトリガ・アクションの表示と同時に行うようになりました。

スクリーンショットは Microsoft Flow のものですが、LogicApps においても同様の画面が表示されたのを確認できています。先にサービスを選択して、そのあとにトリガかアクションを選択する方法が使えるようになるのは、結構便利だと思います。

次は個人的に最も大きいアップデート、条件判断で Switch が追加されました。

新しいステップで「さらに追加」を選択すると、「スイッチケースを追加する」というのが増えています。これが条件により分岐の数を多数に増やせる Switch コネクタになります。

今までの IF コネクタでは、条件に対して満たした場合のアクション、満たさなかった場合のアクションと、二系統にしか分岐することはできませんでしたが、スイッチケースを利用することで、分岐を複数用意することができます。

スイッチケースを選択すると、このように表示されます。最初の「オン」と書かれているところに、判定対象となる値をを設定します。そしてその値が～だったら、というのを各ケースにそれぞれ記載します。どのケースにも当てはまらないものは、規定となっているところに処理を記載することが可能です。もちろん、スイッチケースのネストも可能ですので、多数のパターンを効率よく扱うことができるようになります。

HTTP コネクタで利用できる認証については、ActiveDirectory やクライアント証明書が増えています。

あとは、アイコンの変更や、動的値のサポートが強化されたというあたりのようです。Stripe がコネクタに追加されたのは見つけたけど、Outlook Task が追加されたのは気づけなかった・・・ｗ

なお、Outlook Tasks は Outlook.com で提供されているタスク機能のことで、これで Google Tasks 以外にも誰でも利用できるタスク管理がまたひとつ LogicFlow で扱えるようになりました。

スクリーンショット上ではエラーになってますが、今では普通に呼び出せていますｗ

ちなみに上記スクリーンショットを Twitter に流したところ・・・

中の人 Kevin Lam さんよりリプをいただき、来週リリースするよ！、と教えてもらう事が出来ました！

まさか画像を張り付けただけの自分のツイートに反応してくれるとは、非常に驚きです・・・！

更新されているのに利用できない場合は、キャッシュのクリアを行ってブラウザを再起動し、再度ポータルに行くことで利用できることもありますので、試す場合には覚えておいてください。

最近のアップデートで、スマホアプリ版 Flow でよく利用する Flow ボタントリガで、何かしらの値や文字を入力させて、それを LogicFlow 上で利用できるようになりました。

ボタントリガを設定すると、入力させるための質問文と、その値を LogicFlow 上でなんという名前で利用するかを設定することができます。また、質問は複数個設定可能です。

このような LogicFlow を作成し、ボタンをタップすると次のように、質問文と答えの入力を求められます。

このように値を入力して、完了をタップするとその値が LogicFlow に渡されます。

今回は入力した内容を、そのままプッシュ通知させてみました。

このように、入力した内容がそのまま通知されているのがわかると思います。

LogicFlow もこの通り、非常にシンプルです。

ただし、現時点では注意事項が一つあります。ブラウザ上で新規作成しようとした場合、まだ対応されていないのか、入力項目の設定ができません。そのため新規作成だけは、モバイルアプリから行う必要があります。一度作成すれば、以後はブラウザ上からでも参照・編集可能です。

この仕組みを利用することで、定型的だった LogicFlow の処理に、自由度を持たせることが可能です。

一日間違えていた・・・。LogicApps チームによる WebCastが今月も放送されたので、内容をまとめておきます。今回は結構情報が多いなぁ。

今年になって初の LogicApps Live。

LogicApps チームのおなじみの三人。前回の放送は、音声の質がなんか悪くてごめんね的な話をして、今回からはあたらいいマイクを入手したからバッチリだぜ！ だそうですｗ

まずは新機能の紹介。この Blog でも適宜とりあげたり、Twitter 上で色々つぶやいていますが、知らない機能も何気に混ざっているのがすごいところです。

• コネクタ検索の改善
• JSON Parse アクションの追加
• Switch コネクタ
• Visual Studio でのパラメータ対応
• Azure Alert より LogciApps 呼出対応

コネクタ検索は、前回のアップデートアナウンスの際にも書かれていた、サービス検索が追加されたものです。JSON Parse は、Compose コネクタの新機能として、JSON 値とスキーマ定義を設定すると LogicFlow 上で扱えるようになる、というもので、JSON 関数を実行するのとその結果とスキーマを LogicFlow 上で適用するようなもののようです。今までだと JSON 関数で返還したものは、スキーマとマッピングできなかったため手入力で要素名を入力しないと値が利用できなかったのですが、これでかなり楽に指定できるようになります。

※いま探しているのですが、USA-WEST とかのアメリカ系リージョンでも見つからない・・・

Switch 式はここ最近のアップデートの中でも、非常にうれしいコネクタ追加でした。VS での対応については正直ノーマークでした。そして Azure Alert の対応ですが、これ存在を知ったのは昨日のことで、Twitter 上で公式アカウントが他の人にリプを飛ばしていたのをたまたま見つけたので知ることができたものです。

今までだと Webhook として Alert 発生時に LogicFlow を呼び出すことはできていましたが、今後は呼び出す LogicFlow をそのまま選択できるようになったとのことです。

新規コネクタと、新規アクションの追加。今まではコネクタ追加については取り扱っていましたけど、アクションの追加は扱われていなかったので見落としがちですが、既存コネクタへの機能追加も随時行っていました。File コネクタへのトリガ追加とか、Outlook コネクタでの「メールの移動」「メールへフラグを設定」、トリガとして「メールへフラグが設定されたとき」を追加などなど、使っている人でないとわからない情報です。

Twitter コネクタでタイムスタンプが編集されてわたってくるようになったというのは、結構ありがたいですね。今まで Twitter コネクタが取得していたタイムスタンプは Twitter 形式のもので、そのままだと気合入れて変換しないと利用することが難しいものでした。

LogicApps Live で個人的に一番楽しみにしているのが、現在作業中な情報です。

LogicFlow 内部での変数対応とか、実行履歴で IF コネクタなどでは「どういう値がきて、どういう処理をしたから True な方を実行した」というのが、正直追いかけにくかったのですが、そのあたりをもう少し情報を見やすくするというのもうれしいところです。

ポータルの管理ブレードの内容も更新中、配列や CSV データの取り扱いをするコネクタも作成中、サービスバスの名前空間取得する機能も開発中、EIP で提供する EDIFACT を利用したあたりの情報を OMS へ連携、そしてカナダリージョンが追加されたとのことです。

コネクタ開発情報としては、Oracle まわりに手を出し始めたのと、SQL Server/Database への機能追加、Azure Data Lake や Azure Automation などなど、データ回りが今のメインな開発内容のようです。

Azure Storage の Blob トリガとか LUIS コネクタなど、ほしがっている人が多いところも対応中なのがうれしいですね。

最後に、今後のイベントの予定を告知して今回の LogicApps Live は終わりです。

Ignite など海外イベントなのは当然ですが、いつか日本のイベントにも来てもらいたいなぁ・・・

先日の LogicApps Live で公開されたように、Azure Alert から LogicApps を簡易に呼び出すことができるようになりました。今までは Webhook の仕組みで呼び出してもらっていたのですが、より一層利用しやすくなったと思います。

設定を行うのは、アラートルール、またはメトリックの設定からとなります。

上記は Azure VM でのメトリック設定画面です。上部に「アラートの追加」があるので、これをクリックすると新規アラートの規則を作成する画面が表示されます。

表示された画面の、最も下部に LogicApps 呼出し設定はあります。

まだ日本語化されていませんが、「Run a logic app from this alert」をクリック。

するとこのように、アラート発生時に呼び出す LogicFlow を選択できます。表示されている一覧を見ると、特にアラート発生元と同一リージョンである必要はないようです。

また、注意書きとして表示されているように、現時点では Recurrence トリガ（定期実行トリガ）には対応していません。HTTP Request トリガのみとなっていますので、言ってしまうと Webhook で呼び出すのとなんら変わりはないとも言えます（

なお、アラート発生時に連携される値は、こちらにサンプル値があるので、これよりスキーマを作成することが可能です。

LogicFlow において HTTP コネクタはよく利用するものの一つですが、現在の仕様としてアクセスするとリダイレクトするものについては、実行時にエラーとなってしまいます。この場合の対応についてとある人から質問がきたので色々試してみました。

お題となったのは Google Action Script です。これは通常の API のように、POST でアクセスすることも可能ですが、その場合には色々とパラメータを設定したり、認証をどうこうする必要があります。そのため、別の手段として GET でアクセスする方法も用意されており、こちらを利用した場合はブラウザでみているように API を利用できるようになっています。

ただし、GET でアクセスした場合、結果は別のアドレスへとリダイレクトが行われます。

GAS の場合、このような形で Response Body にリダイレクト先の情報が設定されてきます。ブラウザで見ている場合は、自動でこのリンク先へとリダイレクトされますが、LogicFlow の HTTP コネクタではそれは手動で行う必要があります。

手動で行う場合は、上記のように HTTP コネクタが失敗した場合に、後続の処理を動かせるようにする必要があり、過去のエントリにもあったように runAfter 設定を用いて、「失敗した場合に実行する」という記述を行います。

runAfter の記述は CodeView でのみ行えます。CodeView 上で、runAfter の箇所に、条件として HTTP 呼出しを行ったコネクタ（上記例では HTTP という名前）が失敗（Failed）したら、という記述を行っておきます。こうすることで、HTTP コネクタが失敗（200 以外のステータスが戻された）場合に、処理を継続することができます。

そしてここからが力技ですｗ

戻されたリダイレクトの情報は、HTML で記述されておりそのままでは LogicFlow 上で扱うのが困難です。このような場合は、力づくで XML に変換します。LogicFlow の XML 関数は、渡された文字列や JSON 値を XML として変換しますが、その条件は XML として読める文字列であること、で具体的には先頭一行目に XML を表す

<?xml version=\"1.0\" encoding=\"utf-8\" ?>

という一行を加えます。文字列の結合は concat 関数で行えますので、次のように LogicFlow を記述します。

@xml(concat('<?xml version=\"1.0\" encoding=\"utf-8\" ?> ',body('HTTP')))

上記のように記述すると、HTTP コネクタの結果に、xml version ～なヘッダ情報を付与し、その結果を xml 関数で XML に変換します。こうすることで、戻された情報からリンク先の情報を取得するための下準備が行えたことになります。

次に、XML に変換した結果から、A タグで設定されているリダイレクト先の情報を抽出します。この場合では xpath 関数を利用して、特定の要素の特定の属性値を抽出させています。上記で言うと、BODY タグの中にある A 要素で指定されている HREF 属性、を文字列として取得させています。こうすることで取得できた結果が次のようなものです。

この結果がリダイレクト先の URL となっていますので、この値を用いて再度 HTTP コネクタでアクセスします。

ここでは URL に先ほど抽出した結果を設定しています。これで、リダイレクト先にアクセスして、結果を得ることができます。

このように、GET で GAS にアクセスし、リダイレクト先から結果の JSON を取得できました。

今回の場合、この取得した値に一癖あり、JSON の要素名に ： が使われているのですが、

LogicFlow では現状 ： が含まれた名前を扱えません。

そのため、この結果を JSON として扱う前に、名前から：を除去しておく必要がありました。具体的には、以下のように replace 関数を用いて、今回の名前で利用されている ga: という部分を ga に置き換える、ということを行っています。：だけ置き換えようとすると、JSON の名前と値を区切っている箇所の：も変換してしまうので、そこはちょっとだけ注意が必要です。

今回は取得した結果から、gadate という名前に設定されていた値を Slack に投稿させています。

このように、無事に結果から必要な値だけを連携することができました。

リダイレクトを含んでいる場合は、このような形で「HTTP 失敗時の処理」を記述することで対応が可能です。最後に今回作成した LogicFlow の JSON 定義を置いておきますので、似たようなことをやる人は参考にしてみて下さい。

LogicFlow の HTTP コネクタでは、? で接続されているクエリパラメータに対しても対応しています。これを利用すると、通常は JSON で値を渡さなくてはいけない API も、クエリパラメータを利用した値の利用が可能です。

本当は Flow だけで済まそうと思ったのですが、関数の記載が上手くいかなかったので、LogicApps → Flow と二段階で呼び出す形にて試してみました。

LogicApps 側では、HTTP Request を受けるトリガと、渡されたクエリパラメータを分解して Flow を呼び出す HTTP コネクタを設定します。

デザイナー上では、HTTP コネクタに謎の test1 という値が登場しています。これは CodeView で見てみると正体がわかります。

上記の赤枠で囲った部分が test1 の正体になります。

@triggerOutputs()['queries']['test1']

triggerOutputs 関数は、トリガから出力される値を取得する関数ですが、HTTP コネクタの場合は、呼び出された際に指定されたクエリパラメータが設定されてきます。その値は実行履歴で、トリガの未出力加工を参照すると確認できます。

queries という配列で、test1 と test2 の値が取得できているのがわかります。実際に呼び出した際には以下のようにしていました。

テストに用いたのは、Chrome アプリの Advanced Rest Client です。個人的には PostMan よりこっちの方が気に入っています（

上記のように、HTTP コネクタが生成した呼出し用の URL に、test1=aaaa&test2=bb というクエリパラメータを追加しているのがわかります。そしてそのパラメータから、test1 で指定された値を取得しているのが、先ほどの triggerOutputs 関数を用いた記述になります。

そしてその後に呼び出した Flow 側の LogicFlow は次のようにしています。

こちらも非常に簡潔に、HTTP Request トリガで受け取り、受け取った値をそのままプッシュ通知させています。スキーマについては、LogicApps 側で送る値を元に作成したものを張り付けているので、プッシュ通知コネクタでは値を選ぶだけで利用できています。

このようにすることで、クエリパラメータの値を抽出しプッシュ通知できたのが確認できました。

triggerOutputs 関数を用いてクエリパラメータを利用すると、JSON の値を使ってのやり取りが難しいケースでも、LogicFlow に値を受け渡すことが行いやすくなります。残念ながら Flow のデザイナ上では、記述しても上手く動いてもらえなかったので今回は LogicApps を起点としましたが、恐らくそのうち上手く動作するようになると思われます。

LogicApps と Flow では、オンプレミスデータゲートウェイを利用して、ローカル PC と接続しオンプレミスな SQL Server やファイルシステムを取り扱うことができるようになっています。しかし、このあたりの資料がほとんどないため、利用できるようになるまでも一苦労だったので、自分が試してできるようになったところをまとめておきます。

今回利用するオンプレミスデータゲートウェイは、PowerBI などでも利用することができるもので、Azure Service Bus 上にイベントをがしがし投げていって、定期的にポーリングを行い LogicFlow と連携させる仕組みのものです。リアルタイムではないので、随時監視としては不向きですが数分単位での連携ですので、ある程度は要望に適うものと思います。

インストールは Flow の上部メニューから行うことができます。Flow で利用するのも、PowerApps で利用するのも、LogicApps で利用するのも同一のものです。

ただし、ゲートウェイを利用するには組織アカウントが必要です。個人アカウントでパーソナルモードでのインストールはできるのですが、その場合は LogicFlow から利用することができません。

Office365 のアカウントを所有している人であれば、まだ試しやすいと思います。自分みたいに Azure を個人アカウントで利用している人にはちょっと面倒なところです・・・。

ゲートウェイをインストールし、Service Bus に接続できると、ポータル上の「ゲートウェイ」メニューから存在を確認できます。

上記のように、状態が Live となっていれば、ゲートウエイが Service Bus と接続できている状態となります。この次に LogicFlow 上で利用する接続を作成します。

File System の接続を作成を行おうとすると、上記のように接続情報を求められます。ここで作成しなくても、File コネクタを初めて利用するタイミングで同じ入力を求められることもあるのですが、求められないこともあるので、接続メニューから作成するのが確実です。

ここでの入力内容ですが、以下の通りにする必要があります。

• ルートフォルダ：接続先 PC でのローカルパス。共有はかけなくても大丈夫
• 認証タイプ：Windows 認証
• ユーザー名：（マシン名）￥（アカウント） を入力
• パスワード：パスワードを入力
• ゲートウェイ：インストールしたゲートウェイを選択

現在 Flow ポータルからの接続の作成画面は、少々動きがおかしく、認証方法は手打ち、ユーザー名はマスクがかかっています。まぁそのうち修正されるとは思います・・・

なお、PowerApps のポータルから接続を作成するときは、入力ダイアログもまともになっていますので、こちらから設定するのがおすすめです

接続を作成すると File コネクタから利用できるようになります。

ここで参照するフォルダを選択するピッカーが右横にあるので、ここから選択するか手入力で参照するフォルダ名を記載します。

もしこのピッカーで、フォルダが参照できていないような場合、先ほど作成した接続で入力した情報に何か間違いがあることになります。ユーザー名やパスワード、参照先のフォルダの記述ミスが殆どですので確認してみてください。

恐らくここで指定できるフォルダは、先ほどの接続で指定したルートフォルダ配下のフォルダとなると思われますが、まだそこは確認できていません。

無事に成功すると、上記のような実行結果となります。これでローカル PC やサーバと連携して何かを行う LogicFlow を作成することが可能になります。

ちなみに、今時点の状況として、ファイル名にマルチバイト文字を利用している場合はいつも通り文字化けしてきますので注意が必要です・・・。

以前に LogicApps 公式チームがツイートしていましたが、Parse JSON なコネクタに、新機能が追加されています。

It's a little thing, but this "generate schema" button rolling out this week should make designing and working with JSON a little easier pic.twitter.com/JTSdg115Ly

— Azure Logic Apps (@logicappsio) 2017年2月7日

利用できるかどうかは、上記のように デザイナ上で「Use sample payload to generate shcema」と下部に表示されているかどうかで判断できます。

クリックすると上記のように、スキーマ生成のもととなるデータを張り付ける欄が表示されます。ここに元となる JSON 値を張り付けます。

このような感じで貼付け後に、Done をクリック。

そうすると値を元にしたスキーマ情報が自動で作成されます。これは jsonshema.netでやっていたこととほぼ同等の結果が得られるので、いちいち jsonschema.net でスキーマを作ってコピペする手間が省けることになります。

細かい改善ですが、こういった機能改善が非常にありがたいですね。

LogicApps ではスケジュール実行の Reccurence トリガなど、定期的に実行するタイプのトリガには重複起動を抑止する設定が用意されています。前の LogicFlow が起動中に、後続処理が起動するのを防止するための設定です。

今時点では、CodeView 上で記載する必要があるので、Flow では利用できません。

挙動を確認するための、上記のようなただ待つだけの LogicFlow を作成してみます。実行されたら 5 分まつだけのものです。

CodeView を開き、シングルインスタンス設定を記載します。

これを実行すると以下のように履歴が記録されており、重複起動となった場合はトリガーがスキップされているのがわかります。

この設定を利用することで、1度の実行に時間がかかる LogicFlow においても、処理がバッティングしないように調整することが可能です。

なお、Reccurence トリガーをはじめとした定期実行系にのみ指定が可能で、ほかの種類（HTTP Request）などのトリガーで指定するとエラーとなり、LogicFlow を保存できませんので注意してください。

定期的に更新されている LogicApps のアップデート情報です。今回はやや小粒ですが、前に投稿した JSON Schema 作成機能のようにありがたいものが含まれています。雰囲気的には来週の Australis Ignite で何か言ってきそうにも思えるけど、どうなりますかね。

今回のアップデートは 3 つとバグフィックス少々です。

• JSON Schema generator in designer
• Support for multipart/formdata and application/x-www-url-formencoded
  • Can access in a run via @triggerFormDataValue(‘key’)
• HTTP Webhook can leverage query parameters on callback

JSON Schema は前のエントリの通り、デザイナ上でサンプルデータからスキーマを生成してくれる機能です。

HTTP 周りは上記の他にも手が入っていそうです。

HTTP コネクタでアクセスする際のヘッダ情報を指定できるようになっています。キーと値のペアを入力する方法と、JSON 値でまとめて設定する方法の二つが利用可能です。ヘッダの指定は HTTP 単体呼出しの際にのみ、上記のように拡張されていますが、Webhook 時などは文字列で直接入力しかまだ利用できないようです。

また、BODY に設定する multipart や formdata、application/x-www-url-formencoed 形式にも対応が行われ、これらの場合は新しく追加された triggerFormDataValue 関数を用いて渡された値にアクセスすることが可能になります。

さて Webhook ですが、クエリパラメータに対応しました。イベント発生時に呼び出してもらうコールバック URL に、パラメータを付与してアクセスしてきた場合にも利用可能になります。

そういえば今週末には Australia Ignite 特別篇 LogicApps Live が放送されるとのこと。こちらでも何か新しい情報が出てきそうで楽しみです。

オーストラリアで Ignite が行われていたのですが、そこに LogicApps チームが参加していたこともあり、特別篇的に LogicApps Liveが放送されました。その中で今回のアップデートについても色々話が出ていたので、今回は合わせてまとめておきます。

まずは今回のアップデートの話から。LogicApps 確認用に利用している米国中北部リージョンではすでにリリースされていたので、他リージョンも近々適用されると思われます。

Releae Update 2017-2-17 のアナウンスでも出ていた話題と、2017-2-10 で出ていた話題についてです。デザイナー上で HTTP ヘッダを入力できるようになったり、HTTP リクエストコネクタで POST 以外で呼び出せるようになったり、REST な API を作るときに必要な仮想パスでのクエリパラメータ対応（ /foo/{Id} とか）、新規に作成する際の表示が大幅リニューアルとか、ポータル上の表示もシンプルにまとめたとか、Azure Functions で js 利用するなら LogicApps デザイナー上だけでコードもかけるようになったとか、さっくり書かれている割に非常に大幅アップデートですｗ

細かい更新内容については、このエントリ最後の方にまとめます。

追加された新規コネクタと、機能拡張の件。Azure Automation や Data Lake がついに登場しています。

そして作業中情報。変数対応は多分ほしがっている人多数なので、リリースされるとうれしいですね。そして配列をテーブルか CSV に変換とか、EDIFACT を利用している際の情報を OMS に連携するようになったとか、B2B 方面もどんどん手が加わっています。

そして作成中コネクタですが、ここに並んでいるものが 2/18 時点ですでにリリース開始されてたりするので、In-Progress とは何なのかという気持ちに（

このあたりで、天候が良すぎたので室内へ退避ｗ

Service Bus を利用する際のパフォーマンス情報です。最短 30 秒間隔でのポーリング、最大 1 分間で 3000 件までのメッセージ処理、1 秒あたりだと 300 件（AutoComplete モード時）まで対応できるとのことです。

最後にイベント情報として、3/25 に 11 カ国で Global Integration Bootcamp が開催され、そこでは BizTalk や LogicApps、Flow など Integration に関わる話が盛りだくさんとのことです。日本は当然ながら含まれていないのが、非常に残念ですがこういった状況は変えていきたいですね・・・。

ここからがアップデート内容です。

LogicApps ポータルの構成が変わりました。今までは、トリガ履歴などは一覧として表示されていたのですが、条件でフィルタリングして表示させることができるようになりました。

そして新規作成しようとした場合の初期表示内容が大幅に変わり、LogicApps の紹介から、よく利用されそうなトリガーを選択できるようにしたり、これまでもあったテンプレート選択のところもフィルタリングして絞り込むことができるようになりました。

テンプレートの選択は、カテゴリと更新日時などでのソート指定が行えるので、初めての時にどういったものがあるのか見たい場合はいいのではないでしょうか。慣れた人には不要でも、最初のころはこういうのがあると、こういうこともできるのか、というのがわかるようになるのが良いと思います。

個人的に今回のアップデートで一番「グレイトだぜ！」と思っているのが、HTTP Request コネクタの更新です。ここにもサンプルデータからのスキーマ生成機能が追加されたのもありがたいですし、今まで POST で呼ぶしかできなかったのが、GET や PUT でも呼び出せるようになったのも非常に素晴らしいですね。そして相対パスに対応したので、上記のような実際にはないアドレスを設定して、呼び出し側から

（Request コネクタが生成した URL）/test/hogehoge

とアクセスできるようになります。もちろんここで指定した {account} というパラメータについてはデザイナー側でもちゃんと対応しているので、

このようにすぐに選択して利用することが可能です。これは非常に素晴らしく、今まで API Management を利用してあれこれやっていたものが、LogicApps のみで対応できてしまうことになります。もちろん生成される URL があれだから、というのは API Management で置き換える必要がありますが、それを気にせずに、REST API を作成したいということであれば、LogicApps だけで対応できるようになったということです。これは本当に素晴らしい・・・！

Azure Functions については、LogicApps デザイナー上だけで作成できるようになりました。今の時点では JavaScript のみの対応ですが、それでも Azure 上の各機能を行ったり来たりしなくても構築ができるのはすごいですね。

こんな感じでダイレクトに Azure Functions をいきなり作れます。一つ上の画像にあるように、Functions へ渡す値もデザイナー上でポチポチしていするだけでいいので、かなり楽です。

ここからは新規コネクタ情報です。

請求周りを行うことができる FreshBooks。以前追加された Stripe もそうですが、もう請求処理回りもこのようにサービスとして提供しているのを LogicFlow で組み合わせて利用できるようになってきているのは、非常にありがたいですね。

カンバン的なタスク表示も行えるプロジェクト管理 LeanKit。サイトを見ると、利用している企業なのか、ロゴとして Paypal や Adobe や vmware などがありますね。

ドキュメントのテンプレートを作成し、そこに好きに値をはめ込んで発行できる WebMerge。日本的な感覚だと、請求書のテンプレを用意して、そこに顧客ごとの値（顧客名とか、請求明細とか）を当て込んだ結果を出力するサービスですね。

今回のアップデート、個人的には非常に大きな更新だったと感じています。やっぱり HTTP Request コネクタの更新がすごくて、今まで ASP.NET WebApi とかで作成していた REST API なものも、LogicApps だけでできるようになった、ますますコードを書かなくても目的が達成できるようになったというのが、非常にうれしい限りです。

先日の Release Update 02-17 で更新された HTTP Request コネクタでは、POST だけでなく GET や PUT での呼出しに対応したのと、相対パスに対応したので RESTful API 的な呼び出し方（～/employee/2 とか /hogehoge/1 みたいなアクションとパラメータを URL に含む方式）を LogicFlow のみで構築することが可能になりました。

まずは HTTP Request コネクタをトリガとして設置します。その際、一度保存してアクセス先の URL を生成してもらうのですが、アドレスを生成した後でなくては、詳細オプションのメソッドや相対パスが反映しない事がありました。見分け方としては、生成されたアドレスに相対パスで指定したものが含まれているかどうかで判別できます。

https://prod-13.northcentralus.logic.azure.com/workflows/{workflow id}/triggers/manual/paths/invoke/{action}/{id}?api-version=2016-06-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=[signaature]

上記のように、生成されたアドレスに {action} とか {id} といった相対パスが含まれていれば大丈夫ですが、含まれていない場合は、再度 LogicFlow を保存して呼び出してみてください。

また、新しくなった LogicApps のブレードでも、トリガ履歴の欄に生成されたアドレスが表示されますので、ここから取得することも可能です。

サンプルとして上記のような LogicFlow を作成してみます。action としてメソッド名を渡してもらうイメージで、switch case でそれぞれの処理へ分岐するようなものです。

まずは GET で hisashi に 10 という値を設定し呼び出してみますと、上記のように正しく鰻を10匹奢ってもらうよう結果が返されています。

今度は hisashi から zaiba2 にアドレスを変えてアクセスしてみると、switch case で正しく分岐されて、戻されてきた結果が変わっているのがわかります。

最後に定義していない action を指定した場合も、switch case で「規定」のところへ処理が流れているのが、戻された結果からもわかります。

このように、強化された HTTP Request コネクタを利用すると、これまでコードを書くことでしか用意できなかった RESTful API 的なインターフェースも、コードレスで実現することが可能です。今まではクエリパラメータを利用する方法のみだったのが、相対アドレスを利用できることでより一層できることが広がってきたと思います。

Release Update 2017-03-03でアナウンスされていた、LogicApps のバージョン管理機能がリリースされていました。

バージョン管理と言っても、Git や VSTS でのそれとは異なり、過去に実行した情報を保持し、そのバージョンにいつでも戻せるようにする機能になります。

バージョン管理が利用できるようになっている場合、下記のように Versions という項目が表示されるようになります。

クリックするとこのような形で、これまでのバージョン変更（LogicFlow の変更履歴）が一覧表示されます。このそれぞれをクリックすると、その時点での LogicFlow が参照できます。

履歴ですので、ここを編集することはできないので ReadOnly となっているのが見えると思います。また、ここから最新バージョンへ戻す時には Promote ボタンをクリックします。

このようにデザイナー画面へと遷移しますが、この時点では旧バージョンへ復旧されているわけではありません。ここで保存することで初めて入れ替わりが行われますので、Promote したからといっても注意が必要です。

この機能を利用することで、何かしらの問題が発生した際に一つ前のバージョンに戻すことが可能です。バージョンアップ作業後に問題が発覚した場合など、即座に戻す必要がある場合も、別途バージョン管理システムを利用することなく対応が可能になります。

※ 一度公開したエントリですが、不注意により上書き削除してしまったので、新たに書き直しています

BizTalk Server などで提供されている機能を、LogicApps 向けに切り出したものが Enterprise Integration Pack となっています。機能としては非常に豊富で使い出のあるものですが、利用できるようになるまでが大変だというのもあり、色々とまとめてみました。

まず Enterprise Integration Pack ですが、これは Visual Studio 2015 のアドインとなっていますので、VIsual Studio がインストールされている環境が必要です。

インストールすると、LogicApps がプロジェクト種類にされています。

ここから新規にソリューションを作成します。

作成直後は、このように何もない状態で、ソリューションのみがある状態です。

プロジェクトへの新規追加を行うと、上記のようにフラットファイルスキーマ、ファイルスキーマ、マップ、が追加可能となっています。Enterprise Integration では、スキーマにて入出力するデータのレイアウトを定義し、マップで変換や演算処理を定義して利用します。

今回は CSV ファイルをもとに処理を行おうと思いますので、フラットファイルスキーマを選択します。選択すると、上記のようなダイアログが表示されます。以前はこれは BizTalk Server 2013 と思い切り表示されていましたが、いつのまにかちゃんと直っていました（

スキーマを作成する元となるファイルを指定する画面です。Enterprise Integration の仕組みでは、何かしらの入力を一度 XML に変換を行います。その際に利用するルート属性名や、名前空間（BizTalk の仕組みとして、スキーマごとに独立した名前空間にして他との衝突を防止します）、文字コードを指定します。

次に、スキーマ生成の基とするデータとして、どこまでを利用するかを指定します。上記のように、見出し付きなデータの場合は、見出しも含めた形でスキーマ定義することが可能ですので、見出し＋先頭データを選択します。

次はレコードやカラムを分ける方法を指定します。特定文字か、特定の文字数かを選択します。

特定文字を選択すると、このような分割する文字を指定する画面が表示されます。ここではレコードやカラムを分ける文字を指定するのですが、見出し付きデータを処理しようとした場合、ここでまずは「見出しとデータ」の分割を設定する必要があります。その場合は行端文字、大体は CRLF でしょうか、を設定します。

この画面ではほかにも「先頭にこの文字があった場合にのみレコードとみなす」という、タグ機能を利用する場合のタグを指定することも可能です。

見出しとレコードを分割する場合は、上記のように 2 行表示されていると思います。レコード中のカラムを分割する場合は、ここに分割されたカラム数ぶん一覧に表示されます。

ここでは分割された結果、それがどのようなものか、という詳細設定を行います。

見出し＋レコードの場合、上記のような形で設定を行うかと思います。ポイントとなるのはデータ側のほうで、Element Type に「Repeating record」を指定して、レコードが複数回繰り返されると指定します。ここを単に record として場合は、1 行しか発生しないとみなされますし、Element や Attribute を指定した場合は、XML の値や属性として扱われます。

ここまでが基本的な流れとなります。今回の例では、先ほど Repeating record を指定していますので、この次にその部分についての設定が繰り返されます。

今度はデータ部のみですので、見出しを含まないように選択します。

今回はカンマで区切られているレコードに対してスキーマを定義するので、特定文字、を選択します。

前回は、見出しとレコードを分割する指定だったので CRLF でしたが、今回はレコードのカラムを分割する指定ですので、分割文字には カンマ を指定します。

各項目の名称や Data Type を指定します。Data Type では文字型、数値型、日付型など多くの種類が利用可能です。日付型のように、この画面で指定しただけでは設定が足りない場合、上記のように　！　なアイコンが表示されますので、この場合は、スキーマ作成後にプロパティとして不足している情報を指定する必要があります。

ここまで行うことで、スキーマの定義が完了です。

このようにソリューションに作成したスキーマが追加されていれば、作業完了です。

ここで作成した xsd ファイルを、Azure ポータル上で統合アカウントに対してアップロードすることで、LogicApps から利用できるようになります。

次は、このスキーマを利用したマップの定義を行います。

1.スキーマの作成はこちら

LogicApps の Enterprise Integration Pack は BizTalk Server や BizTalk Service で提供されていた機能を利用できる、非常に強力な機能です。前回はデータのレイアウト定義を表すスキーマを作成しましたので、今回は変換処理にまつわるマップを作成します。

マップは、定義したスキーマ間でレイアウト、データの変換や色々な編集・演算を行うための設定です。前回作成した BizTalk 用のソリューションに追加することで、マップの設定を行うことができます。

追加直後はこのような表示になります。通常であれば、各種コントロールが表示されているツールボックスには、マップ上で利用できる機能 = Functoid が並んでいます。これを利用して、ある値を計算したり、結合したり、色々な事を行った結果を、別スキーマで定義されたデータに出力することができます。

マップは左側が入力で、右側が出力となります。それぞれのスキーマを選択します。

同じプロジェクトに含まれているスキーマが選択可能ですので、あらかじめスキーマは二つ用意しておきます。

マップ編集画面では、直感的な操作が可能です。まず値をそのまま出力する場合は、左側（または出力側の右側から）ドラッグして、出力先の項目でドロップすると、上記のように矢印がひかれ、左の項目から右の項目へと出力される設定が行われます。

Functoid を利用して計算を行う場合は、ツールボックスから利用したい Functoid をドラッグ＆ドロップします。上記の例は、加算（Addition）の Functoid で左から入力した値を合算し、右へ出力するものです。ここでは、単価と税額を合算させています。

各 Functoid の config 画面を出すと、上記のように細かい設定も可能です。マウスの場合は、Functoid 上で右クリックするとメニューから選択できます。

Functoid の結果は、さらに別の Functoid へと連携させることもできます。ここでは、合算した単価と税額に対して、数量を乗算するよう、乗算の Functoid へと接続させています。

このような感じで、入力側から出力側へと値を関連付けていきます。こうすることで、データの変換を行う設定をマップに設定していきます。

Functoid が BizTalk をはじめとした、マップ機能の主な機能で、非常に多彩な事が実行可能です。例えば Script という Functoid がありますが、これはマップ上で独自のスクリプトを実行するための物です。

このように C# や VB、XSLT スタイルシートなどに加えて、懐かしの JScript も利用可能です。

拡張機能には、単純ではない機能な Functoid が用意されています。

Conversion は変換機能。ASCII 変換や16進数変換などがあります。

Cumulative は集計関係で、合計や平均、最大最小などがあります。

Date/Time では日付計算ようのものが。

Logical では論理演算に用いるもの、LogicApps にも同様の関数があるのでイメージはつかみやすいものがあります。

Mathematical は算術演算。

Scientific は三角関数やべき乗といった、比較的複雑な演算。

String では文字列にまつわる Functoid が用意されています。

このように、BizTalk な機能である Enterprise Integration においても、ノンコーディングで多くのことを実現させる思想は共通しています。これら多くの Functoid を利用することで、単純なデータ変換だけでなく、集計レコードとして作成したり分析結果を算定させたりと、非常に多くのことが実現可能です。

このようにして作成したマップも、LogicApps で利用することができます。LogicApps だけでは比較的手間の多い処理を、マップ上で実現させることですっきりとした LogicFlow を作成することも可能です。

前回、今回で作成したものをベースに、次回は LogicApps 上で実際に利用するという事を行ってみます。

1.スキーマの作成はこちら
2.マップの作成はこちら

3 回にわたり続けてきた、LogicApps の Enterprise Integration Pack 利用法についてですが、いよいよ LogicApps からスキーマとマップを利用した変換を行います。

LogicApps で Enterprise Integration を行うには、統合アカウントが必要です。統合アカウントは二つのプランが用意されています。

無料プラント標準プランですが、標準プランは月額 10 万円超、と非常に危険なものとなっていますので、作成する際は注意してください。無料プランでも一定数のスキーマやマップは利用できますので、Enterprise Integration がどのようなものかというのは十分確認可能です。

統合アカウントを作成したら、これまでに作成したスキーマとマップをアップロードします。

スキーマもマップも、アップロードするファイルを指定した後に、画面下部にある OK ボタンをクリックしないとアップロードが完了しないので注意してください。

スキーマには作成した xsd ファイルを、マップにはビルドして生成された xslt ファイルをそれぞれにアップロードします。

そして統合アカウントを利用する LogicApps と、統合アカウント自身を関連付けます。

この際、統合アカウントと LogicApps のリージョンが同一でなくては関連づけられませんので注意してください。

関連付けが終了すると、このように LogicApps の統合アカウント欄に選択したアカウントが表示されます。これで LogicApps から Enterprise Integration を行う準備は完了です。

動作を確認するために、上記のような LogicFlow を作成しました。変換元となる csv ファイルは BLOB に前もってアップロードを行っておきます。言葉の使い方で少々戸惑うところがあるかもしれませんが、デコードは「元データをスキーマに沿って XML に変換する」という意味で、エンコードは「何かしらのデータをスキーマに則り出力する」という処理になります。スキーマ上では、カンマ区切りの CSV や、各項目についての定義が記載されているので、その定義に基づき CSV ファイルとして出力されていることになります。

マップについては、スキーマで定義された XML データ間での変換処理を実行しています。重要なのは XML でなくてはならない、というところで、そのためにデコードをあらかじめ行っておく必要があります。

LogicFlow を実行すると、上記のような結果が BLOB に格納されています。下が変換前の CSV でブラウザ内に表示されているのが変換後の CSV です。マップでは明細行の変換を行い、見出しについてはそのままでしたので、変換結果では見出しと出力されている内容が食い違っているのがわかると思います。

このように Enterprise Integration を利用すると、複雑な変換処理であっても LogicApps で十分に実行できます。しかもノンコーディングで実施可能ですので、

今回はアップデートの事前告知ではなく、事後告知として LogicApps の更新が行われていました。大きい変化はないですが、より利用しやすいような改善がメインです。

今回のアップデートは以下の改善が行われています。

• Azure Blob trigger added
• Open nested logic app from designer or run history
• Support for messages up to 100MB, and HTTP timeout max of 120 seconds
• Ability to set a timeout on HTTP Webhook or Async operation (e.g. on approval email – timeout after 1 day)
• Performance improvements for “split-on” debatching triggers
• Added API support for returning runs filtered by “startTime”
• Phase 1: Support for 100k items in foreach (deployed but not yet active – will activate next week after validation)

Blob コネクタにトリガが追加、デザイナーや実行履歴からネストして呼び出している子 LogicFlow を編集や参照が可能に、コネクタ間でのメッセージサイズ上限が 100MB に（今までは 50MB なかった）、HTTP コネクタでのタイムアウトが最大 120 秒へ、Webhook などの非同期系コネクタでタイムアウト条件を設定可能に、トリガから受け取った結果の分割処理のパフォーマンス向上、API 開始時刻のサポート、そして、foreach コネクタで扱えるアイテム数上限を 10 万に拡張（ただし、まだ利用は不可来週の更新にて可能）

ざっくりいうとこのような感じだそうです。利用者に大きいのは、メッセージサイズが拡大されたことと、split-on のパフォーマンス向上、そしてもちろん Blob コネクタのトリガーでしょうか。

初期のころから、このトリガは結構要望する人が多かったように思います。

またバグ回収も色々と行われています。

• XSLT Performance improvements
• Fix for inserting dynamic outputs between two segments in designer
• Some fixes for the new template page
• Getting swagger of Logic App (/listSwagger) was formatting booleans incorrectly
• Two properties with same name would sometimes switch display in designer (e.g. Attachment ID and Message ID)
• Reloading a Service Bus JSON object would show @base64(…)

XSLT パフォーマンスの向上は、つい最近エントリを書いていた Enterprise Integeration に関わるところなので、これはありがたい改修です。

今週の更新はこのようなものでした。予告にもあるように、来週も更新が行われるので、それも楽しみですね。