EventGrid へイベントを送信するコネクタが追加されましたので、LogicFlow 上からイベントを発行するというのを試してみました。EcentGrid リリース時にも思いましたが、実際に試してみると、非常に簡単にイベントをとりまとめることが可能になる、と感じます。

EventGrid からイベントを受け取る際には、特に何もしなくとも利用可能でしたが、イベントを発行する場合には下準備が必要になります。

EventGrid Topics の設定

Azure ポータルから「Event Grid Topic」を選択し、新しくイベントの発行先（パブリッシャー）を設定します。現在利用できるのは、米国西部２と米国中西部だけとなっていますが、時間をかけて各リージョンに展開されるものと思われます。

Event Grid Topics を作成すると、詳細画面が表示されます。ここでは画面下部に LogicApps の情報がすでに表示されていますが、新規に作成したばかりの状態ではここには何も表示されません。ここは、LogicFlow などでイベントを送る設定を行った場合に、イベント発生元として一覧表示されます。LogicApps からしか試していませんので、表示されるタイミングは不明ですが、恐らくは一度でも呼び出せば登録されるのではないかな、と思います。

なお、ここで表示されている情報の中で「エンドポイントURL」と「アクセスキー」は、LogicFlow から接続する際に必要となりますので、コピーしておきます。

送信側 LogicFlow の設定

LogicFlow 側で Event Grid Publish を利用する際に、入力が必要な情報は以下の通りです。

接続名は適当に、EndPoint には作成した Event Grid Topic のエンドポイントURLを、Shared Access Signature には同じく Event Grid Topic のキー（１でも２でもよい）を設定し、作成をクリックします。

デザイナー上で設定できるのは、このような感じです。Event Grid 公式ドキュメントでも説明がありますが、以下のような感じで値を設定します。

• subject：（string）発行元が定義したイベントの対象のパス。
• eventType：（string）このイベント ソース用に登録されたイベントの種類のいずれか。
• eventTime：（string）プロバイダーの UTC 時刻に基づくイベントの生成時刻。
• id：（string）イベントの一意識別子。
• data：（オブジェクト）リソース プロバイダーに固有のイベント データ。

先のスクリーンショットにない eventTIme は詳細オプションに含まれています。また、直接 JSON で値を設定することも可能です。

Data / Body の横にあるアイコンをクリックすると、入力モードが切り替わります。

イベント送信側はこれで設定完了です。

受信側 LogicFlow の設定

対してイベント受信側ですが、Event Grid トリガの設定で、Resource Type を Microsoft.EventGrid.topics として設定し、Resource Name を作成した Event Grid Topic となるよう設定することで、イベントの受信設定は完了です。

詳細オプションの中には、受け取るイベントのフィルタ条件もありますので、実際に利用する場合にはこのあたりを利用して、必要なイベントだけになるよう調整が発生します。

このように、Event Grid Publish を利用して送信したイベントを受け取れています。

このように非常に簡単に Event Grid を利用したイベント連携が行えました。今回は LogicApps だけで試しましたので、どういった形で使えるかがイメージつきにくいかもしれませんが、以下のように考えています。

• LogicFlow で検知できるサービスイベントを Event Grid へ連携して統一して扱う
• Event Grid へ送信する部分を HTTP Request コネクタで外部に開放し、LogicFlow に用意されていないサービスのイベントも統合する

Event Grid 自体、LogicApps 外から利用することも前提にしているサービスですが、各種サービスで直接呼び出してもらうようにはなかなか実施しにくい場面というのはどうしてもあります（手の届かない外部サービスとか）。

そのような場合に、間に LogicApps を挟むことで、LogicApps 側でイベントを検知・送信するように構築するというのが、非常に楽に行えます。各種サービスで HTTP 呼出が行えるのであれば、それだけで Event Grid にイベントとして統合させることが可能、ということです。さらに言えば、そこをプログラムを書いて開発する必要が全くない、ということにもつながります。

このように非常に簡単にサービス間であってもイベント統合が可能ですので、ぜひぜひ使ってみてもらいたいものです。

LogicApps の Batch コネクタが更新されて、以前に話題に上がっていたスケジューリング対応が行われました。その挙動について試してみたところをまとめてみます。

検証するために次のような LogicFlow を作成しています。

これがバッチとして呼び出される側です。メッセージ件数を 3 として、スケジュールを 15 分単位に設定しています。

呼び出す側はこのようなシンプルなものです。手作業で実行することで確認を行いました。

結果としては次のようになりました。

ツイッターでつぶやかれたのは上記の 2 件となっています。この時、呼び出し側では以下のようにバッチ呼出を行ってみています。

このように、計 5 回の呼び出しを実行しています。

対してこちらがバッチ処理側の実行履歴です。実際に処理が実行されたのは 2 回だというのがわかります。これは 5 回呼び出されたうち、規定回数（3回）に達したことで 1 度、その後規定回数には達していないけどスケジュール上の設定で実行されたのが 1 度、というのがわかります。

個人的な予想としては、スケジュールを設定しているなら、呼び出しが発生していなくても実行されるかと思っていたのですが、結果を見る限りは 1 度でも呼び出しがないと実行されない挙動です。考えてみると、呼び出しがないということは実行する必要もない、という考え方に基づけばその通りだなとなります。

このように拡張されたバッチ処理では、指定回数または定期的実行を行うことができますが、そのバッチ処理の中で「処理対象がない」ケースについては LogicFlow でどうこうすることができません。この場合は違う方法を考える必要があります。

今の仕組みで行うなら、実際の呼び出し側とは別に定期的に実行する LogicFlow を用意して起き、そちらから連携されたデータについてはバッチ側でスルーする、という作りにするのがよさそうです。

最近 LogicApps Connector 機能がリリースされ、Flow で行えていたようなカスタムコネクタ登録が行えるようになりました。登録自体は同一手順だったので、それほど悩まないのですが削除のところで一つ注意点があったのもあり、そのあたりをまとめてみます。

Azure Portal 上で、新規メニューとして LogicApps Connector は「その他」カテゴリにありますので、必要であればここから追加しておきます。

LogicApps Connector を開くと次のような画面になりますので、「追加」をクリックします。

追加をすると、次のように「コネクタ名」やリソースグループの設定など、よく見る項目が出てきますので、適宜設定し作成します。

LogicApps Connector が作成されると一覧に戻りますので、「更新」をクリックすると作成した LogicApps Connector が表示されます。

この時点で、LogicApps のコネクタ一覧に表示されるようになります。もちろん選択してもまだ利用はできません。

なぜかアイコンは異なっていますが、既にアクションも表示されており、カスタムコネクタの基本アクションが確認できます。

今回はサンプルとして登録するために、別サブスクリプションで作成した API Apps を利用してみます。カスタムコネクタの登録には、API 定義（OpenAPI/Swagger）が必要ですので、URL を控えておくか、別途ダウンロードしておきます。

LogicApps Connector で作成したカスタムコネクタを開き、Edit をクリックします。

クリックすると次のようなカスタムコネクタの情報設定画面が表示され、ここから必要な情報を設定していきます。

最初に必要なのは、API 定義の設定です。今回は先程控えておいた API 定義の URL を設定しますが、事前にダウンロードしておいた場合や、Postmanという API の動作確認にもよく用いられるツールで保存したファイルにも対応しています。

今回は URL を指定する方式ですので、控えておいた URL を記載したら Upload ボタンをクリックします。

アップロードすると、API 定義の情報をもとに各種情報が更新されます。下記の例ではホスト情報が API 定義に即したものになっており、他の項目は変わっていませんが、これは恐らく API 定義側で記載があれば反映されるものと思います。

必要であれば手で設定を行うことも可能ですが、やはり API 定義がないと面倒な個所もありますので、できるだけ準備しておくのがよいと思います。

このように好きなアイコンを設定することも可能ですが、LogicApps のコネクタ一覧に表示されることを忘れないでくださいｗ

一通り設定が終わったら 画面下部にある Continue をクリックします。

続いて設定するのはセキュリティについてです。API 定義を読み込ませたのであれば、初期状態として編集不可になっていますが、Edit をクリックすることで設定が可能です。利用できる認証方式は、上記のように BASIC 認証/APIキー/OAuth 2.0 または認証なし、の4種類となっています。

API キーを選択すると、このような形でヘッダにキー情報を含ませるか、クエリパラメータとして含ませるかを選択できます。

OAuth2.0 を選択した場合はこのような項目が設定可能です。

セキュリティ設定が終わると、各アクションやトリガの詳細設定になります。

API 定義で記載されているアクションやトリガ、すべてに対して設定が必要になると思っていいです。というのも、LogicApps 上でのコネクタ一覧に表示するかどうかの設定が Visibilty としてあるのですが、初期値は none（表示しない）となっているためです。また、上記のように OperationID 項目はマルチバイト文字不可ですので、こういったところをすべて確認する必要があります。

一通りの設定が終わったら、上部にある Update Connector をクリックすることで、カスタムコネクタの登録が完了します。

以後はこのように、LogicApps 上で簡単に利用が可能です。

反対にカスタムコネクタを削除する方法ですが、ここではひとつ手順が決まっています。

カスタムコネクタを登録すると、自動で API 接続が作成されるのですが、これを先に削除しなくてはカスタムコネクタの登録自体を削除することができません。

ここだけ注意が必要となりますが、それを除けば HTTP コネクタで全てを記載させなくても、簡単に既存 API を利用することが可能になります。自分ひとりで利用しているのであれば、さほど重要には感じないでしょうが、複数人で利用する場合、カスタムコネクタは非常に便利な設定です。多くの API を簡単に利用できるようになるので、是非ともうまく活用してください。

今回は通常の LogicApps Live と異なり、Ignite 特別編ということで、LogicApps Webcastが行われました。

いつもの3人に加え、今回は Azure Security Center Team の Sarah さんがゲストです。

今回一番大きな話題となるのは、やはり Azure Security Center コネクタの登場でしょうか。これは Azure 上に限らず様々な環境を監視し、何か問題があれば対応策を提示したりアラートを発生させたりする総合的なサービスです。LogicApps で登場した Security Center コネクタでは、何かしら問題が発生した場合に通知が行われ、LogicFlow を動かすことができます。ポイントとしては、Security Center 上で何かしらの設定を行う必要はなく、単にこのトリガを利用するだけですぐにも統一的な処理を用意、実行することができるという点です。以前の EventGrid も同じでしたが、このあたりを利用するのに最も LogicApps が適している・楽だ、というのがあるのは非常にうれしいですね。

今回のアップデート内容は、

• カスタムコネクタ
• 大きいサイズのメッセージ対応（FTPやBLOB)
• 配列への値追加
• ForEach コネクタと DoUntil コネクタのデザイナー上ネスト
• Ludicrous Mode
• 再試行回数を10回まで対応
• PowerApps/Flow へのエクスポート
• トラッキング用の独自ID
• インテリセンス
• スケジュール対応バッチコネクタ

となっています。カスタムコネクタについては別エントリで書きました。何気に配列への値追加が対応されていたとか、再試行回数が 10 回まで対応したとか、細かいところも改善がおこなれています。インテリセンスやバッチコネクタのように、見た目にもかかわる大きな改善も多いですが、見えないところも改善が続いているのがわかりますね。

さて、謎のキーワード Ludicrous Mode（ルーカスモード） ですが、仮のプロダクト名のようで最終的にどうなるかはまだ不明のようです。概要としては、高スループット・高スケール対応を可能としたモードのようで、Azure Portal 上で簡易に切り替えられるのを目指しているとのことです。コンピューティングユニット数を 16 → 32 →64 とガツガツ切り替えることも可能なようで、高い処理能力を求められるケースでも LogicApps を利用可能になりそうな感じです。これは非常に期待が持てますね。

ここまでに追加されたコネクターです。直近では Azure Security Center がやはり大きなインパクトがありました。

現在作業中となるのはこのような感じです。見慣れたものもありますが、Azure Function Apps の Swagger 対応はもう間もなくのリリースで、これによってデザイナー上で Function Apps で定義した内容を参照し、値を選択することができるという、非常にありがたいものです。これまででは直接 JSON を記載しないといけなかったりしましたが、Swagger 定義を参照するようになることで、Function Apps 側で利用する値がデザイナー上でわかりやすくなります。

また、作成中コネクタとして挙がった中に、Containers があります。Webcast 中では「こっちはサーバレスだぜ、ここでコンテナかよ！ｗ」と冗談交じりに言っていますが、ちゃんとそのあとの説明でも、コンテナを操作するのは非常に有用なものだというのを説明していましたｗ

今月行われる Integrate のイベント紹介（キーノートに Scott Guthrie登場）があり、

そのほかにも各国で行わる関連イベントの紹介が行われました。いつかここで紹介されるよう、日本でもイベントが行われるようになりたいですね・・・。

前回はよかった気がしたのですが、今回 9 月についてはまとめて一気にリリースノートがやってきました・・・。

小出しにあげるのもわかりにくいので、9月分の内容をまとめて記載します。

• Custom connectors release (can create a "Logic App Connector" resource)
• Tooltip when switching to JSON editing
• Append array UX
• Allow runs to execute across multiple scale sets for greater throughput
• Concurrency control on foreach loop and polling triggers
• Custom connectors API
• Workflow filter to show all workflows that call a function, use a connector, and more
• Sliding window recurrence trigger
• Index keywords for expression intellisens
• Create new grouping of request triggers
• Create connection wizard for Azure Files and Azure Table
• Tenant selector for AAD based connections

上記の内容が9月にリリースされた更新内容となります。

なんといっても、カスタムコネクタ関係のリリースが目を引きます。Flow や PowerApps 側では既にあったこの機能ですが、LogicApps としてもついに対応されました。カスタムコネクタ自体は、外部 API を他コネクタと同様に手軽に利用できる手段です。API の OpenAPI 定義があれば、登録の手間もほとんどかかりません。

そして何気にうれしいものは、変数として作成した配列に値の追加が可能になったところです。まだ、配列から値の除去はありませんが、それでも変数の使い方に幅が広がります。API に何らかの配列を渡す必要がある場合など、利用できるシーンは多いと思います。

Request トリガについては、既存機能＋セキュリティセンターのトリガ＋EventGrid のトリガ が一つのグループにまとめられました。コネクタ一覧で Request を選択すると、これらが出てくるので最初の時は少々戸惑います。

なお、Response アクションも Request グループに含まれていますので、Response と検索してもでてこなくなりました・・・。

そして先日の LogicApps Webcastで話題に上がっていた高パフォーマンス対応につながる 「Allow runs to execute across multiple scale sets for greater throughput」な件ですが、今のところポータル上でそれらしい項目は確認できていないので、恐らくは内部的な変更なのだと思います。早く表に出てきてもらいたいですね。

ワークフローのフィルタ対応は、LogicApps コネクタなどで対象となる LogicFlow を選択する場面があるのですが、このような時にフィルター操作を行うことができるものです。

こんな感じに対象を絞り込むことができます。

他にも Storage 系コネクタすべてで、ウィザードが利用できるようになり今までのようにキー情報などを控えておく必要がなくなりました。利用するアカウントを選択する程度で、LogicFlow から利用可能です。似たような仕組みは Azure Active Directory コネクタにも提供されたようで、こちらは対象テナントを選択するだけでよくなったとのことです。

と、まとめてみると 9 月も多くの更新が行われた LogicApps でした。まだこれからも予定されているアップデートや、未公開の物も多そうですのでますます今後も楽しみです。

最近のアップデートで、ボタントリガの機能追加が行われ、これまで文字のみのやりとりだったところにファイルの添付が行えるようになりました。

トリガの挙動を試すために、以下のような LogicFlow を作成してみます。

ボタントリガで、テキスト入力とファイルを添付させるシンプルなフローです。

ブラウザ上で実行した場合はこのような感じになりました。

どうように Flow アプリ上では次のようになりました。

アプリからの場合、添付できるファイルは画像系に限定されるようです。ブラウザ上からの場合は、なんでも OK でした。

実際に添付してみると、このような形で添付されたファイルを転用できます。

今のところは残念ながら、添付されたファイルのファイル名が取得する方法が用意されていません（ダイアログ上はないだけで、データとしては確認可能なので、そのうち修正されると思われます）。

使いどころとしては、個人の端末から写真をアップロードしたいケース（報告書に添付したいものとか）が考えられます。私の勤務先の場合、出張中は領収書を撮影した写しが経費申請の時に必要だったりしますので、そういうケースがあれば使えるかな、と感じました。

もちろん、すなおにアップした画像を何かしらの解析に回すとか、いろいろな使い道があると思います。

かねてから LogicApps の新規コネクタについては、毎日検索するようにしていたのですが、今回 Flow についても同様に実施してみました。LogicApps の場合とはちょっと異なる方法でなくてはならないので少しばかりコードを書くことに・・・。

全体的なフローはこのようなものになります。基本的な流れは、LogicApps の時とほとんど同じです。

LogicApps と異なり、Flow は Azure LogicApps 基盤で動作しているとはいえ、そのテナントに対して権限を持つアプリケーションを登録することができません。そのため、コネクタ一覧の HTTP サイトの情報をもとに判定を行うようにしています。

こちらのサイトのソースを見ると、コネクタについては p タグで特定のクラス名を設定さrているのがわかります。

それを踏まえて、サイト情報より api-name というクラス名が設定されている p タグの情報を抽出し、ここからコネクタ情報として判定を行います。

ところが、現在 LogicFlow 上ではこのあたりをうまくやる手段がありません。通常であれば、正規表現を利用して抽出を行ったり、XML 変換して XPath で抽出など行うことが考えられるのですが、正規表現は LogicFlow の関数には存在せず、XML 変換は HTML 側で意識されていないと簡単には変換を行えません。

そのためこのような関数を Azure Function App　に作成します。関数に取得したコネクタ一覧の HTML 情報わたし、正規表現にて抽出を行った結果を返却させるというものです。こういった純粋に関数なものは、Function App を利用するのが非常に適しています。

Function App から配列で戻してもよかった気がしますが、昔気質な方法で一つの文字列でもどしていますので、Function App の結果を split 関数で配列に変換しています。なお、最初は ,（カンマ）で区切って戻していたのですが、コネクタの中にカンマを名称に含んでいたのがあったので、_（アンダースコア）を利用しています。

変換した配列の要素数が、Flow で提供されているサービス数となりますので、それを用いてツイートしています。

そして後は、新規に追加された場合の対応ですが、前回は律儀に「Table Storage にデータが存在しているかどうか」で処理を切り分けていましたが、今回はシンプルです。

Table Storage よりデータを取得するのですが、この時にキーとなる情報を明示的に指定しています。新規サービスであった場合、このデータ取得アクションが「失敗」しますので、後続のツイートアクションの実行条件を、「データ取得が失敗した場合」と設定します。このように設定すると、デザイナー上で矢印が赤い点線に切り替わります。

こうすることで、取得できたかどうかを判断することなく、新規コネクタかどうかを判定できるようになります。1 アクションといえばそれまでですが、ForEach の中にあるのでサービス数分繰り返されると思うと、こういった方法はコスト削減に直結するので有用です。

このような感じで、Microsoft Flow の新規コネクタ情報も検知するようにしてみました。

先日 Connect が実施されていた後ろで、LogicApps のリリース情報がまとめて更新されていました。その中で新しい関数として property 関係のものが増えており、これらは何をするものかというのを試してみました。

例えば addProperty 関数を利用した場合は、次のような形になります。

この時点でなんとなくピンとくるかと思いますが、ここでいう Property というのは「JSON 値」のこととなります。JSON で定義されたそれぞれの値をプロパティと呼ぶのですが、それに対する操作を行う関数群です。

利用できるのは「追加：addProperty」「変更：setProperty」「削除：removeProperty」です。

追加は、まだ存在していない場合に利用します。変更はすでにある値を変更し、削除はプロパティを削除する、そういった動きになります。

例えば追加を行った際は、このような感じに動作しています。最初に「オブジェクト」として定義した変数に json 関数で値を作成し、その変数に対して addProperty 関数で新しいプロパティを追加しています。

今までだと、JSON の値を変更しようと思った場合は変数ごと作り直す必要があったのですが、これらの関数によって値の中身を変更することが可能となり、余分な処理がなくなると思います。

油断していたので、LogicApps のリリースノートがまたも、まとめて更新されていました。

09/29 から 11/03 の間のリリースノートをまとめると、下記のようになりました。

Release Notes

• Added new expression function: trim, uriHost, uriPath, uriPathAndQuery, uriPort, uriScheme, uriQuery
• Combined integration account and IP whitelisting into Workflow Settings page
• JSON transform via Liquid template
• New expression functions: propertyset, propertyadd, and propertyremove
• Configurable degree of parallelism for for-each loops between 1 and 50
• Preserve the value when toggle between raw and detail input mode
• Propagating dependent service errors
• Expose all do-until loop iterations
• Decode and render XML with syntax coloring in monitoring view
• Batching trigger supports size-based release
• Expose failed iterations in for-each loops
• Support listing Azure Functions based on API definition in Function Apps

Bug Fixes

• Performance improvement
• Can't copy request url
• Cannot rename and add comment card in IE11
• Security fix: do not include cookie header with outgoing http requests
• Dynamic outputs nested in array with same name are not shown in the token picker
• Cannot switch array mode when mixed normal token and fx_token in ContentBytes field
• Do not show Azure Functions in App Services list
• No outputs show for Compose in debug view when inside Until
• Can not drag card out of Swich-case
• No inputs or outputs shown for SQL Server Get Rows
• Cursor keeps shifting to the end of input when trying to insert tokens
• Unnecessary duplicate dynamic calls are made during definition load
• Incorrect definition generated for post actions in sharepoint

新関数として Trim が追加されていたり JSON 値を操作できるプロパティ関数が増えていたり、セキュリティとして IP アドレスのホワイトリスト指定ができるようになっていたり、ForEach ループの最大並列処理数が 20 から 50 になっていたり、統合アカウントを利用した Enterprise Integration で Liquid Template に対応していたり、バッチコネクタでメッセージサイズベースの条件が追加されていたり、この条件を統合アカウントに登録できたり、Azure Functions の API 定義に対応したり、と結構な改善が行われていました。

細かくリリースノートが出てくると助かるんですが・・・

前回は9月末に行われてちょっと間の空いた LogicApps Live。LogicApps チームの一人だった Jeff  Holan さんが、Azure Functions チームへと移動しましたが、以前にも登場したことのある Derek　さんが放送に加わっています。

まずはここまでに追加された新機能の話です。

SOAP 対応、Azure Functions の Swagger 対応、HTTP OAuth の認証機能追加、Liquid テンプレートによるデータレイアウト変換、実行履歴の表示機能強化、OMS 連携の強化、ポータル上での設定追加、URI 関係の新関数、JSON 操作用の新関数、並列実行数のデザイナー上での設定対応、サイズベースバッチトリガ、統合アカウントとバッチコネクタの連携、とこうしてみると非常に多くの機能が追加されているのがわかります。

新規に追加されたコネクタ群です。

コネクタ自体の追加については、日々チェックしているので把握できていましたが、Outlook コネクタが Webhook トリガ対応していたり、SQL コネクタでの動的スキーマ対応（ストアドプロシージャの戻り値に合わせてデザイナー上で対応することかな）、Blob コネクタでブロック Blob が作成可能になっていたりと、こちらも色々強化されているのがわかります。

既存コネクタの更新については、この Live とかじゃないとわからないことが多いんですよね・・・

そして、新しい価格プランについての説明です。今までは特定リージョンでのみ実施されていた、新しい従量課金プランが投入されることになります。既存アクションの実施が、単純に 1 アクション いくら、となり簡潔になったのと、クリックすると死ねることで有名な統合アカウントが、時間単位による課金制に切り替わります（これまでは開発用と通常用の2種類しかなかったのですが、Standart、Basic、開発用、と 3 つに分かれるのかな？）

現在作業中のものです。

IF などでの判断結果を見やすくする Complex Condition 対応、現在 90 日固定となっている LogicApps の生存期間を 7 日～365 日までで設定可能にする Congiurable lifetime、デザイナー上での Split-On 設定や、再始動周りの強化、追跡する際に内部で利用しているトラック ID を開放してデザイナーで設定可能にしたり、リソースブレード更新するよ、とか言っていたりと非常に色々です。

新規コネクタでは何といっても Office365 Excel でしょう！ Flow でしか利用できていないのがずっと不思議でしたが、恐らくこれは OneDrive for Business 上の Excel ファイルを操作するとかそういう方向でくるのかなー、なんて思います。予想が外れてもっといろいろできるとうれしいですが（

個人的に気になっているのは、以下の物でした。

1:Cusstom Asembly in Maps

これはBizTalk的な分野ですが、現在の Map 機能では組み込まれているものしかデータ変換時に利用することはできていません。ここで、自作のアセンブリをアップして利用可能にする対応です。これができると、一般的なデータ変換なものは、ほぼほぼ対応可能になると思います。

2:XSLT3 support

XSLT は xml の変換などにも用いるスタイルシート規格ですが、XSLT 1.0 が 2.0 になったあたりで、色々ごたごたしてしまいあまり目立ったところには話題が上がらなくなってしまっていましたが、XSLT3 を利用した変換に対応する予定とのことです。

後は世界で実施されている Microsoft Tech Summit の話や、

ガートナーのイベントへ参加する話がありました。

どうやら今年の放送はこれが最後らしく、次回は年明け！、なんてことを言われていたので、またもう少し間があくようです。

Flow の最新コネクタ情報を毎日 LogicApps で拾っているわけですが、ここ最近新規追加されたコネクタが「2度」登場しているため、２回目のツイートを行う際に必ずエラーとなっていました。作成した配列に重複した値があるため、というのはわかったので LogicFlow でどうすれば配列から重複値を除去できるか試してみました。

結論から言うと、union 関数を利用します。

union 関数は union( Array1, Array2, ...） と指定した配列をマージする関数ですが、この際に重複を除去してくれます。この機能を利用して、ある配列に潜む重複値を除去します。

サンプルとして上のような LogicFlow を作成します。最初に配列変数を定義して、createarray 関数で重複した値を持つ状態にします。

次に union 関数で、自分同士をマージするように指定します。

すると、上記のように重複した値を除去してくれます。

色々と処理を作成していると、配列の操作のところは迷うことが多いのですが、意外にシンプルな方法で対応できることもありそうです。

LogicFlow に限らずエラー処理はほとんどの場合必要です。たとえエラー発生時に何も処理を行う必要がなくとも、エラーが起きたことを知る必要はあります。LogicFlow でどういった対応がとれるかをまとめてみました。

現在 LogicFlow で実施できるエラー処理は次のパターンです。

• 実行条件を「エラー時」としたアクションの設定
• アラートルールで Action Failed を指定した監視

1:エラー時に実行するアクションの設定

LogicFlow で利用するアクションは、実行条件の設定を行うことが可能です。「成功時」「失敗時」「スキップ時」「タイムアウト時」の 4 種類を組み合わせて指定が可能で、エラー処理を行う場合は「失敗時」を含むことになります。

この実行条件は、直前のアクションに対して判定を行いますので、処理のどこかでエラーが発生した場合、のようにはそのままだと利用できません。このような場合には「スコープ」を使って、複数のアクションを一つのアクションにまとめてしまう必要があります。

上記の例だと、HTTP アクション一つしかないのでちょっとアレですが、実際にはここに複数のアクションを設定し、一つのスコープに含ませる形をとります。

通常時、エラー発生時、など同時には実行しないケースがある場合は、並列処理としてわけてしまうのも一つの手だと思います。

まとめると、この方法は「エラーが発生した際に同時に何かしらの処理が必要な場合」に利用するのが適していると思います。単純にログ出力とかではなく、１アクションに対して何らかのリカバリ的な処理が必要なケースとかでしょうか。

2:アラートルールで Action Failed を指定

もう一つの方法は、エラー処理というとちょっとニュアンスが異なります。LogicApps 限定となりますが、Azure の機能として指定した条件に合致した場合にアラートを発行する、という機能がありそれを利用した方法となります。

アラートルールを選択後に、メトリックアラートの追加をクリックします。

このような表示がされて、アラートを発生させる条件を設定していきます。

条件となるのは「メトリック」「条件」「閾値」です。ここで Action Failed を指定すると「何かしらのアクションが失敗した場合」にアラートを発生させることができます。

アラートが発生した場合にどうするか、については、画面下部の「Webhook」か「アクションの実行」を利用します。Webhook でアラート発生時に特定の API を呼び出したり、アクションの実行で特定の LogicApps を呼び出す指定が可能です。

実際にどのようなデータが流れてくるか、ですがキャプチャしたサンプルを張り付けておきます。

このなかで Description として「しっぱいしました」という日本語が記載されていますが、これはアラートルールの「説明」欄に記載したものが、そのまま連携されてきます。Condition の値も、アラートルールの条件で設定したものが連携されています。そのため細かいエラー内容を把握するという使い方はできません。LogicApps で何かしらのエラーが発生したのを検知するまでは可能です。

まとめると、アラートルールでのエラー対応は、「一つの LogicApps でエラーが発生したかを検知」するもので、細かいエラー対応ではなく、全体を通してリカバリを行うなど先の実行条件よりも大きなくくりでエラー対応を行う場合に適していると思います。

プログラム言語を利用した開発では、Try～Catch などで行うものと、バッチ処理が失敗したときのものなど、場面場面によってエラー処理も様々あると思いますが、LogicFlow においても同様に対象となる処理の粒度によって方法を使い分けるのがよさそうです。

LogicFlow で JSON オブジェクトの値を操作するための setProperty 関数ですが、子要素を書き換えたいと思った場合、少し手間をかけて行う必要がありました。

行おうとしたのは以下のようなことです。

“aaa” と “bbb” という要素を持つ JSON 値で、”bbb” については子要素として “ccc” と “ddd” が存在しているような場合です。この時に ccc の値を書き換えたいとした場合、単純には setProperty 関数を利用することができません。

検証するために、以下のような LogicFlow を作成してみます。

最初にオブジェクト変数 wkJson を作成し、元となる JSON 値を設定します。

次に setProperty 関数を用いて ccc の値を書き換えます。

ここで以下のように setProperty 関数を利用することで、ccc の値を書き換えることができました。

setProperty(variables('wkJson'),'bbb',setProperty(variables('wkJson')?.bbb,'ccc','100'))

setProperty 関数を二つ利用する方法です。最初に中に記述されている setProperty(variables('wkJson')?.bbb,'ccc','100') の部分ですが、変数 wkJson の bbb の値に対して、bbb の子要素 ccc を 100 に書き換えます。

その結果で、変数 wkJson の bbb を書き換えます。setProperty 関数は書き換えた結果を別の変数として結果を返却し、書き換えもとで指定した変数を本当に書き換えているわけではありません。上の LogicFlow でいえば、最後に「作成２」のところで wkJson の値を確認していますが、ここでは最初に変数作成した時と同じ値となります。

このように、結果の扱い方と子要素だけ書き換える際は setProperty 関数をネストして利用することに気を付ければ、JSON 値を好きなように編集が可能です。

ここ最近 EventGrid を利用した LogicFlow を色々作っているのですが、その途中で EventGrid トリガがエラーとなってしまうことがあり、非常にどうしたもんだかと思ったのでその対応を残しておきます。

実際に起きたエラーですが、トリガの履歴より出力リンクをたどることで確認可能です。

こういうエラーや

こういうエラーがトリガにて発生する状態になっていました。エラーが起きた時には何がどうなったのか、さっぱりわかりませんでしたが、色々と設定を見ていくことで状況はつかめました。

LogicApps のトリガー履歴、上記のようになっており EventGrid を利用した場合はコールバック URL が生成されています。原因は不明ですが、ここの URL が EventGrid 側で保持している Webhook 先 URL と不一致になっていました。

LogicApps で EventGrid トリガを利用した際に、自動で生成される EventGrid Subscription を確認すると、上記のように LogicApp～ という名前で作成された Subscription があるのですが、ここの設定での Webhook が、LogicApps 側の URL と異なっていた、という状況です。

設定から Full Endpoint URL を LogicApps 側で用意されている コールバック URL に合わせることで、EventGrid からのイベント受信が復活しました。

ちなみに LogicApps の EventGrid トリガは実のところ 2 種類あります。

一つは上記のように「要求」の中に用意されているもの。こちらは HTTP Request トリガと全く同一のものですが、EventGrid Subscription は自動生成されません。

もう一つは EventGrid コネクタを選択した場合のトリガです。こちらを利用した場合に限り、EventGrid Subsciprion が自動で生成されます。今回はこちらを利用していた発生したのですが、それが原因に関係しているのかはわかりません。

毎日動作させている、LogicApps と Flow の新規コネクタ検索、昨日からエラーとなっていたのと2日続けて同じコネクタが新規登録扱いとなっていたので調べてみたところ、TableStorage コネクタで怪しい挙動があるのがわかりました。

実際に発生したエラーは以下のようなものになります。

このように、TableStorage コネクタで 403 な認証エラーが返却されています。ところが、エラーとなるのは数件で、他の更新は問題なく行われていたため、コネクタの不具合が考えられました。

エラーなっていたケースでは、マルチバイト文字（日本語の漢字）と ASCII 文字の () を組み合わせて RowKey に指定したケースに限定されており、これを確かめるために以下のように実施してみました。

RowKey に指定する値を、uriComponent 関数でエンコードした結果にした場合、上記のようにエラーは発生せず TableStorage の更新が問題なく行えており、仮説として立てた「マルチバイト文字 + ()」の組み合わせでのみ、認証エラーとなってしまうことがほぼほぼ確認できました。

TableStorage に直接データを設定した場合、上記の組み合わせであってもエラーとはなりません。そこをふまえると、LogicApps のコネクタの問題である、と言えると思います。

対応策は、上記のように uriComponent 関数を使って RowKey を指定する、で大丈夫ですのでそこまで重症ではありません。

今年初の LogicApps Live が放送されました。今回は大きな話はありませんでしたけど、渋いところをついている話題がちらほら見受けられたように思えます。

今回は Kevin と john の二人体制です。メガネさんどこいった（

まずは今回のアップデート告知です。

• 並列アクションの除去
• パススルーSOAP
• LogicApps のライフサイクル制御
• 再試行ポリシーの拡張
• ツールチップ表示
• 応答時のスキーマ対応
• オンプレミスデータゲートウェイのカスタムコネクタ対応および高可用性対応
• EIP で変換マップにおけるカスタムアセンブリ対応
• Liquid コネクタに TEXT→JSON 変換アクションの追加

並列アクションの除去は現時点では確認できていませんが、デザイナー上で追加した並列アクションをそのまま削除できるようになるとのことです。ライフサイクル制御は、初期値だと 90 日間有効な LogicApps の生存期間を調整し、例えば 7 日経過したらタイムアウトにするという制御が可能になります。

再試行ポリシーですが、Chank 対応なども増えていたりとコネクタごとで指定できる内容も色々と拡張されています。ポリシーではないですが、HTTP Request 時のスキーマ検証も行うかどうかをここで指定できるようになっていました。

ツールチップはこのように、デザイナ上での項目にカーソルを乗せると、設定している内容が表示されるようになっています。

応答時のスキーマ対応は、上記のように HTTP Response コネクタで結果を返却する際に、JSON スキーマが設定できるようになっています。これの使いどころは LogicFlow 内部から別の LogicFlow を呼び出した際、その結果がスキーマ定義されることでデザイナー側で簡易に値を扱えるようになる、ダイアログに出てくるというところになります。

他にもオンプレミスデータゲートウェイの拡張や、変換マップでのカスタムアセンブリ対応、Liquid コネクタで、JSON を Text に変換する事にも対応しました。

現在対応を進めているものがこちらになります。

こちらも色々と面白い内容があるのですが、Snipets と DR が特に目を引きます。Snipets は VS でコードを使った開発をしている人なら知っている、処理パターンをぺっと適用できるあのスニペットです。LogicApps でも Try～Catch な方法のようなものを、スニペットとして提供し簡単に使えるようにするとのことです。

DR は LogicApps や Azure の障害発生時に別リージョンで動作させるような仕組み、そういったものを提供予定としているようです。これまでだと自前でその部分も設計するなど必要でしたが、そのあたりが簡単に利用できるようになるのもうれしいですね。

コネクタについては Data Factory が作業中のようです。言われてみればコネクタなかった（

デモとして、オンプレミスデータゲートウェイを使って、ローカルで動作している API と LogicApps を結合した挙動を見せていました。ローカルでは VS 上でデバッグ起動している API を指定することもでき、LogicApps から呼び出されたときにブレークポイントでちゃんと止まるのは、なかなか面白い状況です。

あとは Global Integration BootCamp の紹介、

TechSummit での LogicApps 関連セッションの紹介、

Integrate 2018 の紹介が行われました。どれもこれも海外で、日本では同様のイベントがないのですが、個人的には日本でも同じようなイベントを開催できるようにもっと啓蒙していきたいですね・・・。

最後に放送がバレンタインデーということもあり、自分の好きなヤツにハグしてキスでもしておけよ！、という愛のこもったメッセージで終わりですｗｗ

昔々に試したときは、アカウントの作成やらなんやらでうまいこと動作させることができなかったのをすっかり忘れていて、つい最近ようやく試すことができました。

作成した LogicFlow は次のようなものです。

LogicFlow 側からは「すでに公開済みとなっている Automation スクリプト/Runbook が対象」となります。Automation 側では以下のようなものを作成しました。

Automation アカウントを作成した後には、このような感じで表示されていると思います。原則 No Code や Low Code 大好き人間なので、Automation においても直接スクリプトは作成せずに Runbook をビジュアルデザイナー上で作成しています。

すでに作成済みの場合は、上記画面から「編集」をクリック。

新規に作成する場合は、一覧画面で「Runbook の追加」をクリックします。その際に、Runbook の名前と作成方法を求められますので、適宜選択します。当然自分としては「グラフィック」を選択して、スクリプトもコードも書かないスタイルです。

Runbook デザイナーが開かれるとこのような表示になります。左側には利用できるコマンドなどが表示されますので、利用したいものを探します。

利用したいコマンドが見つかったら、右側に表示されている「・・・」をクリックすると、このようなサブメニューが表示されますのでクリックします。

キャンバスに追加をクリックすると、このようにデザイナー部に選択したコマンドが配置されます。ここのデザイナーは自由配置が可能ですので、マウスで好きに配置を調整することも可能です。

右側にはそのコマンドに対する入出力の設定などが行えます。

ここでコマンドに対する入出力パラメータを指定することが可能です。なお、ここで選択できる中に「Runbook の入力」がありますが、これは別メニューから設定します。

デザイナー上部の「入力と出力」をクリックすると、Runbook に対しての入力パラメータや出力パラメータの設定が行えます。ここで設定したものが、先ほどのコマンドに対する入力にて指定するものとなります。

例えばこのような形で設定すると、Runbook の起動時に Name という文字列パラメータを「必須」として求められるようになります。パラメータ未指定で実行するとエラーとなります。

コマンドやパラメータの設定が終わったら、保存ののち「公開」をクリックします。公開を行っていないものについては、LogicFlow からどうこうはできません。

なお、Runbook のテストには上記「テストウィンドゥ」をクリックすることで、テスト用コンソールが利用できます。ここで十分に動作を確認してから、公開するのがよいでしょう。

はじめて Automation コネクタを利用する際は、いつものサインインが求められます。テナント選択後にアカウントでサインインするか、アプリの登録などを行ったうえでサービスプリンシパルで接続を行います。

そうして LogicFlow から Automation を利用するようコネクタを設定します。対象となる Runbook を指定すると、パラメータ情報もこのようにデザイナ側で反映され、入力が可能になります。ここで KeyValue Pair を求めるような表示の場合は、Runbook の情報が取得できていないことが考えられますので、何度か試してみてください（一度だけ発生したことがあり、再現方法がはっきりしてません・・・）

Runbook の実行結果を取得する場合は、作成時の JobID が必要になります。

このように実行した Runbook の出力が取れています。これを利用することで、Runbook 間でのオーケストレーションも可能です。

Automation コネクタを利用する際も、特段難しい知識は必要ありません。もし既存資産として Automation 上で動作可能なスクリプトや Runbook があるのでしたら、それを LogicFlow 側でコントロールさせることは、運用時の方法として考慮してよいと思います。

Flow 公式ブログでアナウンスされているように、Flow で利用している承認機能はバックグラウンドに CommonDataService を利用するよう更新されました。ただし、現在はプレビュー機能扱いなので既存環境ではまだ利用できません。このあたりを含めて試す手順をまとめました。

まず必要になるのが Flow の新しい環境です。

Flow の管理センターで、新しい環境を作成します。

管理センターで環境をクリックすると、現在の環境一覧が表示されます。そして右上に新しい環境、というのがありますのでこれをクリックします。

環境を新しく作る際に注意するのは、現時点では CDS の新機能がプレビュー扱いというのもあり、規定の環境でなくては利用ができないという点です。リージョンの一覧に、（規定）と表示されているものがありますので、それを選択してください。種類では「試用版」か「運用」かを選択できますが、これはどちらでも大丈夫です。

「環境の作成」をクリックすると、構築が始まりますので少し待ちます。

環境が作成されると、上記のようにデータベースを作成するかどうかを聞いてきますので、「データベースの作成」をクリックします。

その際に「通貨」と「言語」の選択が必要です。これはデータベース内で利用する通貨単位や言語の設定となりますので、適宜良いものを選択してください。大体は JPY と日本語でよいとも思います。

作成後に環境の状態を確認すると、このように「Dynamics 365 管理センターで・・・」という一文が追加表示されています。このように表示されていれば、新しい CDS を利用する準備が整いました。旧来の環境では、この一文が表示されません。

CDS が用意できたら、一度簡単な承認フローを作成します。作成することで、CDS 内部に新しい承認回りのエンティティが用意されます。フローを作成する前では、必要なエンティティがない状態ですので注意してください。

公式ブログでアナウンスされている、プレビュー版のテンプレートを利用すると、「現在承認待ちのもののリマインダ通知を行う」というのが実行できます。

このように新しくなった承認回りの機能を利用すると、これまで以上に色々なことができるようになります。それは CDS 内部に承認回りのデータが記録されるようになり、そこを参照して自前で処理を構築することができるからです。色々と試すと便利な使い方ができるかと思います。

以前のアップデートで、Logic Apps の IF コネクタが更新され、新しくネストした条件であっても記述が非常に楽になりました。少し前まで日本語訳がアレなのはありましたけども、複数の判定条件を扱いやすくなっています。ですが、これまでの IF コネクタと記載方法が変わっており、自動でアップデートされることはありません。これをアップデートするには、CodeView で直接記述を変更する必要があるので、どう書き換えるのかをまとめました。

書き換えのサンプルとして、以下の IF コネクタを書き換えてみます。

これまでの IF コネクタでは、条件部分が上記のように表示されています。

対して新型 IF コネクタでは、このように複数条件に対応したデザイナーとなります。それぞれどのように記載されているかを比較してみます。

こちらがこれまでのものです。expression の値として「条件式が記述」されているのが見えます。

こちらが新しいものです。expression の値はあるのですが「配列を指定」しています。ここでの配列が、デザイナー上で表現されている各行の条件式となります。

上記のように、すべて（AND)と次を満たすもの（OR)、さらにはグループをを組み合わせると・・・。

このように設定した条件が配列として設定されているのがわかります。そしてその構造は、デザイナー上で見ている構造そのものに近く、意外にわかりやすいものとなっています。

最終的に、このような配列で記述できれば、新しい IF コネクタとなりますので、実際に書き換えを行ってみます。書き換え対象は、元々
"expression": "@contains(string(coalesce(outputs('Tags値の抽出'),'')), outputs('LogicFlow名の抽出'))"
と記載されていた部分です。ここを配列化します。

"expression": {
     "and":[
         {
             "contains":[
                 "coalesce(outputs('Tags値の抽出'),'')",
                 "outputs('LogicFlow名の抽出')"
             ]
         }
     ]
}

今回は条件が一つなので、シンプルな形になります。もともとの条件は「outputs('Tags値の抽出')＝Tag値の抽出コネクタの計算結果」に「outputs('LogicFlow名の抽出')＝LogicFlow名の抽出コネクタの計算結果」が「含まれている（contains）」かどうか、というものです。

expression 配下に and 要素を用意し、その中に contains となる条件を記載します。書き換え方法としては、このように条件を記載し、そのあとに値を設定することになります。利用できる条件はこれまで同様、デザイナー上で選択できるものとなります。これらはすべてワークフロー関数として用意されているものですので、該当する式名を要素名として記載します。

先に記載したものを CodeView にて貼り付けてみると、次のように表示されるかと思います。

一見よさそうに見えますが、よく見ると条件の値がどちらも文字列として認識されています。これを修正するには、CodeView 上での記述で @ をつけた形にて記載する必要があります。

このようにすることで、正しく新しい IF コネクタの記述方式に移行が可能です。

実際のところ、既に動作しているのであれば書き換える必要は全くありませんｗ

デザイナー上の表示をどちらかに統一したい場合に限り、書き換えを行うのが良いと思います。

とある理由でアカウント登録をするような LogicFlow を作成していたのですが、その際に初期パスワードをどうしたものだか、という課題がありました。Azure Functions でも使えばさっくりいけるのですが、そこを LogicFlow でやってみることにしました。

今回作成したものは Githubにて公開しています。デプロイ用ボタンも設置してあるので、自分の環境にデプロイして試してみてください。

実際にパスワードを生成するにあたり、注意するのは「利用可能な文字」についてです。Azure Active Directory の場合、英語の大文字小文字、数字、そして一部記号が利用可能になっています。この中からランダムに文字を選択する必要があります。

LogicFlow 全体としては、このような感じで作成しました。非常に力業です（

最初に生成結果を設定する変数と、必要な桁数（今回は８～16文字としています）を算出します。ここでポイントが「配列の要素数＝必要な桁数」となるよう、range 関数を使っているところです。理由は後述します。

次に利用可能な文字を、種類ごとにまとめて設定します。この時、0～9 な数字文字列を設定する際、そのままだと「数値」として認識されてしまうので、string 関数で明示的に文字列としておきます。

それらをもとに、1文字ずつパスワードとなる文字列を抽出していきます。どの文字種を使うかをランダムにして、Switch にて分岐させます。

それぞれのケースの中で、最初に設定した利用可能な文字列から、1文字抽出を行います。大体次のように指定してあげれば OK です。

substring(outputs('抽出元文字列'),rand(0,length(outputs('抽出元文字列'))),1)

抽出対象となる文字列から、0 から抽出対象文字列の桁数までの間でランダムに位置を決め、1文字抽出しています。このような書き方をすると、利用可能な文字が増えたとしても、ここを修正する必要はありません。

最後に抽出した結果を結合して、生成結果としています。

全体的にこのように単純な処理を組み合わせたものですが、LogicFlow 上で行うにあたって一点だけ注意がありました。最初のところで必要桁数を配列変数に設定していましたが、これは ForEach ループでなくてはいけない理由があるためです。

もう一つのループ、Do-Until を利用するとした場合、カウンタとして利用する変数に桁数を設定、ループの中で 1 ずつ減算していく形を思い浮かべると思います。ところが、LogicFlow の Do-Until ループは「非同期で並列動作」するものです。何が起きるかというと、複数同時に処理が動きカウンタの値が正しく減算されない、という挙動になります。マルチスレッドの挙動そのものです。さらに Do-Until ループでは、シーケンシャルに動作させるというオプションがありません。必ずマルチで動作します。

このような事情があり、ForEach で繰り返すために桁数を配列で表現するやり方を採用しました。なお、生成したパスワードが複雑さの要件を満たしているかのチェックは行っていませんので、呼び出し元で判定する必要があります。