少し前に追加された BingMaps コネクタのおかげで、Bing Maps で提供されている機能が利用できるようになりました。今まではプログラムから呼び出したり、REST の API を直接呼び出さなければならなかったのですが、これで簡単に利用できるようになります。

BingMaps を利用できるようにするためには、まずアカウントを登録してキー情報を取得する必要があります。ここで少し迷う状態になっていて、Bing Maps には現在 2 種類のキーがあります。一つは開発時にも利用できる Basic Key で、もうひとつは商用で利用する際に必要な Enterprise Key です。Enterprise Key でも開発は利用可能なのですが、利用時に課金が発生するなど違いがありますので注意が必要です。そして、Azure Portal からは Enterprise Key しか取得できないので、Basic Key は別途取得しに行かなくてはなりません。

Basic Key は Bing Maps Dev Centerにて取得します。Sign In と書かれているところをクリックすると、MS アカウントでのサインインを求められます。

サインインするとこのような表示になるので、上メニューの My Account → My Keys と選択してクリック。新規に作成する場合は、Click here to create a new key のほうの here をクリックします。

Key が生成されるとこのような形で表示されるので、これをどこかに控えておきます。この情報が BingMaps コネクタを利用する際に必要です。

現在 LogicFlow で提供されている機能は、「住所から情報を取得」「GPS座標から情報を取得」「ルート検索」「地図情報を取得」の 4 種類です。

アクションを選択すると、初回はこのように Key 情報を求められますので、控えておいた Key を設定します。接続名はいつも通り、LogicFlow 上での識別にしか利用されませんので、好きに着けて構いません。

Get Location By Address アクション

条件として、国・郵便番号・州（日本だと都道府県）・市・住所、を指定して検索できるようになっています。必須項目ではないので、自由に項目を組み合わせた検索が可能です。

試しに、札幌 大通公園 で検索してみた結果は次のようになっています。緯度、経度、そしてそれを結合したものが値として返却されているので、後続処理で何かする際にも便利です。

試しに結果から BingMaps で検索してみたところ、まぁまぁ近い場所だったことがわかります。多分これは検索時のキーワードと、BingMaps 自体の情報量に依存するとは思うので、キーワードによってはもっとよい結果になるのではないかと思われます。

Get Location By Point アクション

こちらは GPS などか取得できる緯度・経度を元に検索を行うものです。そのため緯度経度は必須項目となっています。

こちらも試しに実施してみると、このような形で結果が返ってきました。気になるのは、条件で指定した位置情報とは微妙にずれた情報が戻ってきているところで、挙動的には指定した座標に近いどこかを結果として返却しているのかな、と思ったのですが・・・

BingMaps で見てみるとよくわからない場所が戻されていました。試しに利用した座標は、大通公園の中だったのですが、3丁ほど南にずれた場所となっています。特にここに何かあるわけでもないので、まったくもって理由は謎です。

Get Route アクション

ある地点の位置情報と、別の地点の位置情報を指定して経路情報を取得するもの、と思われるのですが、今の時点でも一度も成功したことがありません・・・

何度か試してはいるのですが、上記のようにコネクタから Internal Server Error が戻されてきている状態が続いています。機能としては使い出が多いと予想されるところなので、早く使えるようになるのを期待したいですね。

ルート検索自体は、既に BingMaps で利用できているので、LogicFlow のコネクタ側の問題なのかどうか、というところかと思います。

Get Static Map アクション

指定した位置情報を中心とした、地図画像を取得するものです。位置情報と地図の種類、拡大率（０～２１まで）が必須項目となっており、他には画像の種類や、生成する地図のサイズ、地図に付与するピン情報が指定できます。

生成された画像情報は、このように BASE64 エンコードされて返却されてきます。結果を確認したい場合は、ブラウザのアドレスバーに

data:image/jpeg;base64,(返却された結果)

とダイレクトに打ち込むことで確認が可能です（jpeg、のところは画像のフォーマットを指定）

このような感じで、生成された地図画像を確認できます。特に拡大率で指定する値については、何度か試してみないと自分が求める大きさというのがわかりませんので、このやり方を覚えておくと便利です。

詳しいパラメータの値については、REST APIについて探してみると記載が見つかりますので、そちらも参考にするとよいと思います。

私の場合、現実の業務として開発業に携わっているという事もあり、DevOpsについては常に気になってしまうキーワードでした。多くの記事やセッションなどで、その言葉の意味や何を目的としているか、といった外枠についてはある程度覚えがあるのですが、それを実践してみようとなるとどうしても体系だった学習をしていないために、自己流に陥ってしまって失敗するのではないか、という不安が付いて回っています。今回、その不安がぬぐえるかという点でも興味があったので、Microsoftが提供しているオンライントレーニングコンテンツのAzure Skills にあるDevopsについて挑戦してみました。

Azure Skills は https://www.microsoft.com/ja-jp/learning/azure-skills-training.aspxを入り口としています。ここでアカウントを作成して、各コースを受講していくことになります。現時点では日本語対応とうたわれているコースは、まだ10個程度と少ないですが、恐らくは時間の経過によって増えていくのではないか、と期待しています。ちなみに、アカウント周りで一つ陥りやすい点があります。それは最初にアカウントを登録した際に、指定したメールアドレスに対してアカウントのアクティベーションを行ってくださいという内容のメールが届くのですが、そのメールからアクティベーションを行わなくとも、初回は受講を続けることができてしまいます。翌日になって再度ログインした際に、アクティベーションしてくださいとエラーガイダンスが出てしまうのですが、ここが英語でしか表示されないために人によっては「昨日は使えていたのに！？」と不思議に思うのではないかと思います（かくいう私は、パスワード間違ったかな、と思い何度かログインを繰り返すまで気づきませんでした）。必ず届いたメールからアクティベーションを先に行っておきましょう。

コース開始前にはこのようなアンケートが用意されています。恐らくは各コースによって、違った内容を聞かれてくるのではないかと思われます。また、オンライントレーニングの進め方や、どういった章立てをしているかなども、細かく説明があるので、自分にとってどれくらいのペースで進められるかを考えやすい出だしとなっています。Azure Skills で提供されているコンテンツは、一つ一つは小さな動画やテキストが数多く集められたスタイルを採用していて、今日は時間がないから少しだけ、という進め方が非常に行いやすいです。ここはこれまでのオンライントレーニングとは少々違ったところで、個人的に非常にありがたいところでした。

今回私が受講したDevOpsについては、次のような章立てとなっていました。

前半ではDevOpsにまつわるキーワードについてや、全体的な話題を動画付きで解説してくれています。後半はハンズオンも含め、GitやVSTSを実際に利用してDevOps的開発手法を実際に体験してもらうような構成となっていました。DevOpsを行うために必要な一通りがそろっており、最後まで進めることでなんとなくDevOpsを実践するにはこうやればよいのか、というものがつかめると思います。ただ、途中で解説があるのですが、実際にそれを職場で行うにはまた別の問題があり、多くのステークホルダーを説得したりする必要がある、というのは受講した方それぞれで対応を考えていく必要があるのは致し方ないところです。

それでも言葉でしかDevOpsを知らない私のようなタイプにとっては、非常にありがたいコンテンツがそろっていたというのも、また事実ですので十分受ける価値はあると感じました。

各章の最後には、このような確認試験的なものが用意されており、ここで自分がどれだけ理解できているかをチェックするようになっています。ただし、ここは一定以上の正解を出さなければ次の章へ進めない、といったクイズ形式ではなく純粋に理解度チェックのためだけのものですので、時間がない場合は飛ばして先の章を見ることも可能です。このあたりは融通が利いていて、受講する側に優しい作りだと感じました。

ただし、この試験においてはまだまだ日本語化が進んでいないようで、設問・選択肢ともに日本語として怪しいものがちらほら見受けらているのが、非常に残念なところです。

全体を通してこのような怪しい日本語が多く、ものによっては設問はきっとこうだろう、と予想しなくては選択肢が選べないようなケースも散見されていました。それ以外の動画などのコンテンツでは、ここまでわかりにくくない日本語訳が付いていたのですが、なぜかこの試験だけは日本語コンテンツとしては残念な仕上がりとなっています。

章によっては上記のような、ハンズオン形式も用意されています。座学だけではどうしても体感できない内容というのがありますので、このように実施して学習できるコンテンツの提供は大変ありがたいものです。また、関連資料などの紹介も数多く行われていますので、本編以外にも関連した知識を学びやすくなっています。ただその関連資料は日本語化されているものだけではないのは、仕方のないところかも知れません。それでも膨大な資料の中から探すことを考えると、大変ありがたいものだと思います。

最終章まで進み、最後の試験を突破するとアンケートの記入を求められます。残念ながら日本語訳については設問がありませんでした・・・。

全てを終えると、自分のアカウント情報から各種成績を確認することができます。これで苦手としている章もわかりますので、復習する際にどこを重点的に行うかといった確認もできるようになっています。

全体的な構成としては、このような形で構成されていました。最初の方にも書きましたが、全体的に時間を大きくとらせない構成となっており、空いた時間で少しずつ学んでいくスタイルとなっているのは非常に好感が持てます。

今回受講したAzure Skills ～Azure Paas上のDevOps～ですが、最後まで通してやってみて、やはり自分のペースで進めやすい作り方をされている点が、これまでの似たようなトレーニングコンテンツと違い、自分にとっては非常にやりやすかったと感じています。極端な話、動画一つしか見ない日もありましたし、動画を再生しないで付随している日本語訳だけを見ていたところもあったりします。そういった、受講者それぞれにとって進めやすいやり方を用意してくれているところは、大変好感が持てました。反面、日本語コンテンツ、としてうたっているにも関わらず日本語化があまり行われていない、むしろ中途半端に行われていて理解しにくい箇所を作り出してしまっているのは、とても残念なところです。コンテンツ数自体の少なさもそうですが、ここは徐々にでも改善していってもらいたいと感じています。

そういった不満は色々ありましたが、それを含めても自分にとってためになるオンライントレーニングであったのは間違いないところです。初心者向け、としても有用でしょうが、ある程度慣れ親しんだ人でも、たまに振り返ってみるためにAzure Skillsコンテンツ群を利用してみるのも、悪い選択ではないと思います。

LogicFlow には HTTP アクセスした結果をトリガとして、LogicFlow を動作させるコネクタが提供されています。基本的には ステータス 200（正常終了）した場合に、処理が動作するのですが、その他のステータスやその際のヘッダー値によって、挙動が色々変わる点があるのでまとめてみました。

まずは現在 MSDN に記載されている内容を転載します。

まとめてみると、

• ステータス 200 の時に限り LogicFlow が実行される
• ステータス 202 の場合は RetryAfter ヘッダ値で指定された時間の後、再度アクセスを行う
• ステータス 200 で RetryAfter ヘッダ値が指定されていると、LogicFlow を実行し指定秒数後に再びアクセスを行う

となっています。ということでそれを検証するために、簡単な LogicFlow を一つ用意してみます。

HTTP でのリクエストを受けたら、好みのステータスで RetryAfter 値付きで返却する LogicFlow です。今回は返却する値をそのまま記載していますが、呼び出す際に戻してほしいステータスやRetryAfter の値を一緒に受け渡せるようにすることも簡単です。まぁ、その場合 HTTP GET で試すことができませんが（LogicFlow で HTTP GET しようとした際に Body 値を指定するとエラーとして保存できません）

呼び出す側はこのような形で、作成した確認用の LogicFlow を直接呼び出します。ここでは、確認する頻度（デフォルトでの実行感覚）を 3 分としています。

まずはステータス 201 、RetryAfter 30 とした場合の挙動です。

これが一度目の呼出し時で、結果としてステータス 201 であり、RetryAfter 値が 30 と戻されているのが確認できます。

そして 2 度目の実行がこちらです。19:24:16 に実行されている事より、RetryAfter の値に指定されている秒数後に、再度 HTTP 呼出しが行われ、LogicFlow が実行されているのが確認できます。この場合は、HTTP トリガに設定してある実行間隔の設定よりも、RetryAfter 値が優先されているのがわかります。

続いてはステータス 202 の場合です。こちらも RetryAfter 値を同様に 30 と設定しています。

実際の結果はこのようになりました。ステータス 202 なので、LogicFlow 自体は実行されていないのですが、再試行されている間隔が RetryAfter 値で指定した 30 秒ではなく、HTTP トリガで指定した 3 分となっています。これはドキュメントの記載と異なる挙動です。

最後に正常動作となるステータス 200 の挙動を確認します。初回実行時に、このようにステータス 200 と RetryAfter 30 として返却された状態です。

結果としてはこのようになりました。ステータス 201 の時と同様で、RetryAfter の値に従って再試行が行われているのが確認できます。HTTP ステータスとしては 200 は正常終了（OK)、201 は完了（Created）ということもあり、現在の LogicFlow では正常終了扱いとして動作しているのがわかります。ですが 202 の受理（Accepted）については、ドキュメントしても非同期パターンで利用すると明記されているのですが、そのようには動作していないようです。

Flow モバイルアプリが更新されて、ボタントリガ利用時にリストボックスで値が選択できるようになりました。

現在はモバイルアプリ上だけで利用可能な機能となっています。

このような形で、あらかじめ入力させたいものを用意しそこから選択させることが可能になります。ただし先に書いたように、この対応はまだモバイルアプリ上だけで、Web ブラウザ上ではリストボックスをりようするボタントリガを設定できません。

ただし、実行に関してはモバイル・Web 双方で可能となっています。

これを利用することで、今まで文字入力しかなく面倒だった点が解消されています。

ここ最近、LogicApps の更新情報が全然更新されなかったのですが、本日一気にリリースノートが更新されていたのでまとめてみます。

June 23

Release Notes

• Expression authoring in the designer (dynamic content tab)
• XSLT now has option to disable BOM (Byte Order Mark)
• Pagination support in the designer (e.g. SQL get > 256 rows in an action)
• Support for 8 levels of nesting in the designer (used to be 6)
  

Bug Fixes

• Tracked properties for variables weren't being correctly preserved
• Copy/paste would replace the entire field when pasting in values

機械翻訳にかけてみると以下のような内容となります。

• デザイナーでの式の作成（動的コンテンツタブ）
• XSLTにBOM（Byte Order Mark）を無効にするオプションが追加されました。
• デザイナでのページネーションのサポート（たとえば、アクションでSQLが256以上の行を取得）
• デザイナーでの8レベルのネストのサポート（以前は6であった）
  

バグ修正は次の通りです。

• 変数のトラッキングされたプロパティが正しく保存されていませんでした
• コピー＆ペーストは、値を貼り付けるときにフィールド全体を置き換えます

大きい話題は、「デザイナーでの式サポート（ダイアログで関数を選択できる）」のと、コピペの改善でしょうか。

この改善は非常にありがたく、今までドキュメントとにらめっこして関数書いていたのが、デザイナー上だけでほぼほぼ完結できてしまうってのがありがたいですね。

June 19

Release Notes

• Pan and zoom controls added to the designer
• Can configure action timeout within the action settings in designer
• Server-side paging for getting multiple pages of results (e.g. > 256 SQL records)
• Accessibility enhancements
• More special characters supported in the designer
  

Bug Fixes

• Fixed issue where trigger history display would show "Loading"
• Dynamic content would sometimes be cut-off the top of the screen

こちらも訳してみると次のようになります。

• デザイナーにパンコントロールとズームコントロールが追加されました
• デザイナーのアクション設定内でアクションのタイムアウトを設定できます
• 複数ページの結果を取得するためのサーバーサイドページング（256以上のSQLレコードなど）
• アクセシビリティの強化
• デザイナーでより多くの特殊文字がサポートされています

バグ修正は次の内容です。

• トリガー履歴表示に「読み込み中」と表示される問題を修正
• 動的コンテンツが画面の上部でカットされることがある

デザイナー上で拡大縮小がサポートされたのがこのタイミングですね。

これも非常にありがたい改善だと思います。

June 2

Release Notes

• Can switch an array to pass in an entire array instead of only single properties
• Can modify and enable splitOn within the designer for a trigger
• Decrement variable support
  

Bug Fixes

• Fixed issue where trigger history display would show "Loading"
• Portal wouldn't show the status for all Logic Apps when > 35

訳します（

• 単一のプロパティではなく、配列全体を渡すように配列を切り替えることができます
• デザイナー内でsplitOnを変更してトリガーを有効にすることができます
• 変数のサポートを減らす
  

バグ修正は次の通りです。

• トリガー履歴表示に「読み込み中」と表示される問題を修正
• ポータルは、35を超えるすべてのLogic Appsのステータスを表示しません

どうやら、35 件以上 LogicFlow があった場合に、ステータスが表示されない不具合があったようですが、正直全然気づきませんでしたｗ

変数のデクリメント対応が行われたのもこの時期ですね。

と、まあ突然リリースノートがでてきたのでまとめてみましたが、現在も LogicApps は順調に更新されていっています。ここには記載されていませんが、バッチ処理用コネクタや Azure Video Indexer のコネクタも追加されていたり、ますますできることが増えてきている LogicApps ですので、今後も楽しみに見ていきたいと思います。

最近まとめて更新されたリリースノートですが、今回はびしっと更新されていました！

まずは Azure Portal にて公開された内容を転記します。

Release Notes

• Setting to turn disable async polling pattern for actions (fire and forget)
• Templates are now hosted in GitHub here

Bug Fixes

• Renaming the foreach loop in code-view wouldn't always reflect on reload
• Foreach using new @items() syntax to enable nested loops
• Rendering of the file picker would sometimes not wrap correctly
• Sending full array would disappear when clicking "Switch to raw inputs"

訳してみると、

• 非同期ポーリングパターンを利用している場合に無効とする設定を用意
• LogicApps のテンプレートを Github でホストするように

というのが新規な内容となります。

不具合修正としては、

• CodeView で ForEach ループの名前を変更しても反映されなかったのを修正
• ForEach ループで新しい items 関数を利用するように修正 （ネスト対応？）
• ファイルピッカーが正しく描写されないことがあったのを修正
• 実行履歴で未加工出力の表示を行った際に、配列すべての値を表示するよう修正

となります（フィーリング込なので、間違っていたら指摘ください）

ちょっと気になるのが、新しい items 関数のところで、これはまだ各種ドキュメントにも反映されていない内容のようです。自分の環境で試してみたのですが、特に以前と違う定義にはならなかったのもあり、どういうものなのかがいまいちつかめていません。

ただ、記載的にネストした ForEach ループ対応っぽいところがあるので、次のアップデートあたりまでに何かあるのかな、とは思いました。

Azure Function App には簡易プロキシ機能として Azure Functions Proxies という機能があります。現時点ではプレビュー版なのですが、これを利用することで LogicApps / Microsoft Flow にユーザー認証の機能を簡単に付与できるようになります。

Azure Function Proxies は設定を行うのも、非常に簡単です。ポータルより Azure Functions を開くと下記のような画面になると思いますので、左メニューの中にある「プロキシ（プレビュー）」横にある、＋をクリックします。

もしそこで、Function Proxies が有効になっていない、というアラートが出ている場合、Functions の設定で Proxies をオンに設定してください。

＋をクリックすると上記のように、プロキシの基本設定を求められますので、必要な設定を入力します。

ここで LogicFlow を呼び出したい場合は、上記のようにバックエンド URL に、Request トリガで生成された URL を指定します。ルートテンプレートは、Proxies で生成される URL に付与するアドレスとなります。

許可されている HTTP メソッドの欄では、GET や POST など、呼び出しに利用されてよいメソッドを選択できます。

なお、呼出し時に認証機能を利用するには、Function App 全体の設定となりますので、今回のように LogicFlow 呼出しに制限を行いたい場合は、それように Function App を新しく作成し、認証設定を行うのが適しています。

プラットフォーム機能の中に「認証/承認」があるので、それをクリックします。

デフォルトではオフになっている、App Service 認証をオンにすると、認証に利用するプロバイダーを設定することができます。上記の例では、Twitter 認証を利用する設定を行っています。Twitter の API キーをシークレットを設定するだけで、呼出し時に Twitter の認証が行われるようになります。

ここまでの設定で、LogicFlow 呼出しに認証機能を付与できてしまいます。試しに Functions Proxies で生成された URL にアクセスすると、下記のように Twitter の認証が求められます。

認証が成功すると、下記のように LogicFlow の実行結果がブラウザ上に表示され、正しく LogicFlow が呼び出されているのが確認できると思います。

このように Functions Proxies を利用すると、簡単に LogicFlow に認証機能を付与できるのですが、何点か注意する箇所があります。

一つは、メソッドの変換は行えないという点です。Proxies 側では、許可するメソッドを指定できますが、そのメソッドでそのままバックエンド URL を呼び出しに行きますので、GET でアクセスしにきたけど POST で LogicFlow を呼び出す、といったことはできません。

またもう一つは、ここまでの設定だけだと、LogicFlow 側の URL には依然としてどこからでもアクセス可能な状態だという事です。これを防ぐためには、LogicApps 側で、Azure データセンターの IP アドレスからのみアクセス許可するよう、IP 設定を追加で行っておくのがよいと思います。IP 制限は LogicApps のみの機能ですので、Microsoft Flow の場合は制限を行うことができません。

そして最後にもう一つ、Functions Proxies を経由するので、追加でコストが発生するという点です。よほどの高頻度でなければあまり気にする必要はないかも知れませんが、実運用を行うのであれば、ここも忘れずにチェックしてみてください。

前回のエントリでは、Azure Funcrtion Apps Proxies を利用して、URL を一意にし各種メソッドにより呼び出す LogicFlow を分岐させることを行いました。今回は、HTTPS 対応として証明書の設定までを行ってみました。

URL が hogehogefunction.azurewebsites.net のままでよければ、標準でワイルドカード証明書が提供されていますので特に何も必要ではありませんが、今回は独自ドメインを利用したい場合になります。そのため下準備として、カスタムドメインが必要になります。今回はお試しということもあり、無償ドメインの tk ドメインを取得しています。

ドメイン名が非常にアレですが、tk ドメインを取得した状態です。Azure Function Apps Proxies で独自ドメインを扱う場合、こちら側での設定と Azure 側での設定が必要になります。

Azure 側で設定を行う前に、ドメイン側での設定が必要です。

DNS 設定として、A レコードと CNAME レコードが必要になります。CNAME レコードでは、上記の例でいうと logicflow.（取得した）ドメイン としてアクセスしてきた場合に Azure Function Apps のほうへ誘導するために必要です。

CNAME レコードで指定する値は、Function Apps の URL になります（URL より HTTPS を省いたもの）。

もう一つ必要な A レコードは、振替先となる Function Apps の IP アドレスを指定します。IP アドレスは上記のように、Function Apps のプロパティで確認可能です。

これら 2 つのレコード設定を DNS に対して行うと、独自ドメインにアクセスすると、Function Apps Proxies に誘導されるようになります。ここまで設定を行うと、次は Azure 側の設定となります。

Function Apps の画面から、カスタムドメインをクリックします。

カスタムドメインでは、取得した独自ドメインの設定を行います。ホスト名の下にあるホスト名の追加、をクリックすると上記のような表示になりますので、誘導したい独自ドメイン名を設定し、検証をクリックします。今回であれば、logicflow.nawagami.tk にアクセスしてきたものを Function Apps で扱いたいので、logicflow.nawagami.tk と入力します。

この際に、ドメイン側で設定が正しく行ってあれば、通信はもう行える状態となりますので検証は無事に終了しますが、何かしらエラーとなった場合はドメイン側の設定で、A レコードと CNAME レコードが正しく設定されているかを確認してください。

ここまでの設定で、とりあえずアクセスすると Azure Function Apps Proxies に誘導することは可能です。ただし、SSL 証明書を設定していないので、下記のように保護されていないアドレスとして扱われます。

これを回避するためには SSL 証明書を取得する必要があります。有償で提供されているものを購入してもよいのですが、今回は Let’s Encryptで提供されている無償のドメイン証明書を利用します。

すでに色々な方が利用している Let’s Encrypt ですが、大体は Web サーバを自分で建ててそこに対しての証明書取得であり、何かしらのツールをインストールしてあれこれする必要があり、一部の人にはまだどうしても敷居の高いものとなっています。

zeroSSL による SSL 証明書の取得

今回はブラウザ上の操作だけで Let’s Encrypt 提供の証明書が取得可能な zeroSSLというサービスを利用して取得を行います。

サイトを開くとこのような感じで表示されるので、「ONLINE TOOL」をクリックします。

FREE SSL Certificaten と Self-Signed Cerificate があるので、FREE SSL のほうをクリックします。

左側には連絡先となるメールアドレスを入力、右側には取得している自分の独自ドメインを指定します。今回は logicflow.nawagami.tk のみを証明書対象としたいので、logicflow.nawagami.tk と入力します。そして、左下部にある、DNS verification をクリックして選択した状態にします。

あとは右下部にある「Accept ZeroSSL TOS」と「Accept Let’s Encript SA」の欄をクリックして、チェックをつけます。

ここまでの設定を行ったら、右上部にある「NEXT」をクリックします。

クリックすると上記のように、「www サブドメインを含みますか？」という質問が来るので、もし www サブドメインを利用する予定であるなら「Yes」を、今回のように別サブドメイン限定の場合は「No」をクリックします。

クリックすると必要情報の生成が開始され、終了すると上記のように表示されますので、ダウンロード（左のアイコン）かクリップボードへコピー（右のアイコン）をクリックして、生成された情報を保存しておきます。この情報は、あとで証明書ファイルを生成する際に利用する情報の一つ、ドメインの CSR 情報となります。

保存を行ったらもう一度右上の「NEXT」をクリックします。

さらに情報の生成が行われ、今度は左側に情報が表示されます。これも同様にダウンロードかクリップボードにコピーを行い、保存しておきます。この情報はアカウント情報となり、秘密鍵として利用されます。

保存を行ったら右上の「NEXT」をクリックします。

クリックすると、ドメイン側 DNS の設定で追加が必要になるレコードの情報が表示されます。Let’s Encrypt でのドメイン確認の方法として、DNS に特定の TXT レコードを設定する必要があり、その内容が表示されています。上記の例だと、デフォルトのドメインと www サブドメインの設定となります。

実際に設定を行った例が上記になります。TXT レコードを設定して、zeroSSL より指定したアドレスに対しての文言を設定します。この設定が反映されるのには 10～20 分ほどかかるので、ここでは少し時間をおいてください。確認するのであれば、コマンドプロンプトから以下のコマンドを実行するなどして、txt レコードが反映されているか確認できます。

nslookup （txt レコードを設定したドメイン） –type=txt

設定が反映されていたら、zeroSSL 側に戻り「NEXT」をクリックします。

TXT レコードで設定が行われているのを確認できると、証明書情報が発行されます。左下部に二つ情報が生成され表示されていますので、どちらもダウンロードまたはコピーして保存を行っておきます。これらは、ドメインのキー情報とドメインのCRT情報となり、どちらも証明書ファイルを生成する際に利用されます。

Azure Function Apps Proxies に設定する証明書ファイル（ .pfx ）の生成

zeroSSL 上で作成された各種ファイルをもとに、Azure 上で利用する証明書ファイルを作成します。AWS では先ほどのファイルの中身をそのまま貼り付けることができるのですが、Azure では pfx 形式として用意したファイルのみ対応している状態です。

大体はここで openSSL というツールを利用して生成することになるのですが、Azure ではすでにその環境は用意されています。ポータルから利用できる Azure Cloud Shell です。右上にある「>_」をクリックすると起動し、初回の場合はストレージアカウントの新設を求められますので、作成します。

Azure Cloud Shell を利用できる状態にして、作成されたストレージアカウントの File サービスから、zeroSSL で生成された「ドメイン用の CRT ファイル」と「ドメイン用のキーファイル」をアップロードします。

アップロードができているかの確認は、シェル上で clouddrive にカレントフォルダを移動した後で、ファイル一覧を参照すると確認可能です。

1. cd clouddrive
2. ls

準備ができたら、以下のコマンドを入力し実行します

openssl pkcs12 -export -inkey <秘密鍵ファイル名> -in <SSLサーバ証明書ファイル名> -out <任意のpfxファイル名>

こうすると pfx ファイルが生成されますので、先ほどの File サービスのところからローカルにダウンロードを行っておきます。なお、zeroSSL で生成される情報のうち、証明書生成時にパスワードを求められますが、初期状態では「パスワードなし」（ブランク）です。

Azure Function Apps Proxies に戻り、SSL 設定をクリックし、「証明書のアップロード」をクリックすると、上記のように表示されますので、ここで先ほど作成された pfx ファイルをアップロードします。

このような設定を行うことで、独自ドメインを Function Apps Proxies に対応させることができます。ブラウザでアクセスした際、「保護された通信」となっていることで、設定した証明書が正しく認証されているもの、とわかります。

各種ツールを利用すれば、このような手作業で色々行う必要はほとんどないのですが、多くの人にとって「ツールを利用する」というのは、思っているよりも敷居の高いことだと思っています。そのような考えもあって、今回はできるだけツールを利用しない方法で、SSL 対応を Azure Function Apps Proxies に適用させてみました。証明書を作成するあたりは、Function Apps Proxies でなくても共通している箇所ですので、WebApps 用に利用するのも可能です。

先月は放送がなかったので、1か月ぶりの LogicApps Liveでした。

いつもの3人（jeff、kevin、Jon）な LogicApps チームも、GA 1 周年が近い事もあり、今回はケーキが準備されてますｗ　最初の挨拶では Good Morning、Afternoon、Evening、コニチワ！ という感じによいテンションですｗ

準備していたケーキですが、ローソクは瞬殺で取り外していましたｗ　はえぇｗ

今回の放送までの新規リリースは以下のようになっています。さすがに1か月間が空くと、すごい量になりますね。

主だった内容は以下の通りです。

• VS 用拡張ツールでの LogicApps エクスポート
• ForEach ループ内部での WebHook 呼出し対応
• DataLake と ARM 用コネクタでのサービスプリンシパル対応
• デザイナー上での配列サポート
• バッチ処理
• 変数のデクリメント
• 実行履歴のスマート表示（圧縮表示）
• 実行履歴の時間フィルター
• デザイナー上でのコネクタ設定
• デザイナーの拡大縮小
• 256件を超える件数へのサーバーサイドページング対応
• 式の追跡対応
• デザイナー上でのスマートTips表示
• XSLT 変換での BOM 設定
• LogicFlow テンプレートのオープン化（Github上で公開）

ここのブログエントリや、Twitter 上でつぶやいていた内容もありますが、全然気が付けていなかったものもあったりします。ForEach コネクタでの WebHook 対応とかは、言われてみると確かに「ループ内部で callbackUrl を変化させる」事が出来ないと対応できないよなぁ、と納得しました。

追加された新規コネクタです。これもすごい数です！

ただ、ここに書いてあるのでちょっと気になるのが、Pitney Bowes というもの。結構頻繁に LogicApps を見ている自分ですが、今の時点では見かけたことの無い名前です。もしかするとこれからリリースされるものかも知れないですね。

現在進行中の話題がこれです。この中にあるものでも、既にリリース済みの物が含まれていたりします。

• 50MBを超えるファイルの対応
• SOAP対応
• 関数のインテリセンス対応
• 関数の追跡方法
• デザイナー上での ForEach ネスト（何度か聞いているｗ）
• ForEach 失敗時のナビゲーション
• 定義のSwagger生成
• OMSへのLogicApps用新規パッケージ
• 変数を追加可能に（Margeっぽく）
• LogicApps から PowerApps/Flow への配布
• Flow から LogicApps テンプレートのエクスポート
• コードビューの修正
• 時間ベースで動作するバッチコネクタ

今日時点で Flow でのエクスポートは既にリリースされていました。なので近日中に LogicApps からのデプロイも提供されるかもしれません。Flow はこれで LogicFlow を作成して他環境で利用するのも、格段にやりやすくなりました！

気になるのは、時間ベースでのバッチコネクタですね。既存のバッチコネクタは「呼び出された回数」によって起動する、複数の処理をまとめて執り行う物でした。これが時間ベースになって、どう使い勝手が変わるのか、単に時間で起動するだけならすでにトリガがありますので、なにか違う挙動になるものと思われます。

そして開発中のコネクタ情報も、非常に気になるものがあります。

• Azure Tables
• Azure SQL Data Warehouse
• ServiceNow
• Workday
• Feedly
• MySQL(RW)
• Amazon Redshift

SQL Data Warehouse と Redshift はデータウェアハウス系をやっている方なら、どちらか片方は触っている可能性が高いです。Feedly も一時期の RSS リーダー廃止祭りの際に一躍有名になったのもあり、現在でも利用している人は多いでしょう。ですが個人的に気になっているのは ServiceNow です。これはワークフローサービスの一つで、現場よりのワークフローを構築したりできる総合サービスです。これと連携が取れるというのは、非常に興味を引くところですね。

あとは各種イベントの紹介です。9月に実施される Integration Bootcamp に・・・

少し前にロンドンで行われた Integrate 2017 が次は 10 月に レドモンドで開催されます。いつかは日本でもこのイベントが開催されるようになればいいなぁ・・・

そして関連サイトやアドレスなどのお知らせをして、今回の LogicApps Live は終了しました。

やはり1か月間が空くと、頻繁にアップデートを行っている LogicApps の場合は特に、話すネタが多くなりますね。色々と隠し玉が控えてもいるようですし、ますます今後の LogicFlow 界隈がどうなるかが楽しみです。

LogicApps Live でも公開されていた、Azure DataLake Store コネクタでのサービスプリンシパル対応、これはこれまでの「アカウントでのサインイン」ではなく、専用のアプリケーションを Azure AD に登録しておき権限を付与することで、ユーザー個別ではないアクセスを可能にする方法に対応したものとないます。以前のユーザー個別の方法では、どうしてかうまくいかなかったのですが、プリンシパル対応されてなんとか利用することができたのでまとめてみました。

DataLake Store は Azure で提供されている、構造化・非構造化とデータの種類を問わない、大規模対応されたデータ保持サービスです。ここに様々なデータをアップロードしておくことで、DataLake Analytics をはじめとした各種データ分析サービスに連携することが可能です。

利用するためには DataLake Store アカウントを作成する必要があるので、ポータルから作成を行います。

現時点では利用できるリージョンが「米国東部２」「米国中央部」「ヨーロッパ北部」の3か所だけとなっています。将来的には他リージョンにも広まるであろうというのと、DataLake Store という性質上、レスポンスタイムをそこまで求めるのもどうかと思うので今時点ではあまり気にしなくてもよいかと思います。

DataLake Store では、最初に指定したサービス名が「アカウント名」として扱われます。上記のスクリーンショットでは「kumaadls」や「kumadatalake2」がそれにあたり、後々のプリンシパル情報指定の際にも利用します。

また、データエクスプローラーでは、新たにフォルダを作成したり直接ファイルのアップロードやダウンロードも行うことが可能です。

このように DataLake Store を利用できる状態にすると、LogicFlow 側のコネクタで色々操作ができるようになります。

現時点で提供されている機能は上記の通りで、トリガはなくアクションが 7 種類用意されています。

初めて利用する場合は、上記のようにサインインを求められますが、左下に「サービスプリンシパルを使用して接続する」とありますので、今回はこちらから接続を行います。

サービスプリンシパルを利用する場合は、上記のような入力を求められます。接続名はこの LogicFlow 上で認識するためのもので、適当で構いません。Client ID は、Azure AD でアプリケーションを登録した際に表示されるものです。Client Secret はそのアプリケーションの情報としてパスワード的なものを登録する必要があるのですが、その値となります。Tenant ID は Azure AD のプロパティから確認できる値です。

Azure AD でのアプリケーションの登録や、Client ID などの各種値については、以前の投稿が参考になると思いますので、こちらも参考にしてみてください。

それらを設定し、接続が作成できると、DataLake コネクタが利用可能になります。

上記はアクションのうちの一つ、List Files で、指定したフォルダに存在するファイル一覧の取得を行うものです。

Account Name は DataLake Store で設定したサービス名を、フォルダパスは抽出したいパスを記載します。この時、ルートフォルダを表す先頭の \ は不要です。

指定が正しければ、このようにフォルダの中にあるファイル一覧が取得できます。

さて、タイトルにある注意点についてですが、このフォルダ指定の箇所に一つ不具合があるのが確認できています。

これがその注意点にはまっていたときの状態ですが、見たところは成功例の時と指定している値はまったく同一です。ところが結果として java.io.FileNotFoundException が返却され、対象のフォルダが存在しない、というエラーになっているのがわかるかと思います（java で開発されていたのがちょっと驚きですｗ）

これはなにかというと、Azure DataLake Store のフォルダ名に大文字を含めていた場合現状のコネクタでは取得できない、という不具合になります。見た感じでは、コネクタ側で渡されたフォルダ名を ToLower 的に小文字に変換して、DataLake Store より取得しようと動いているようです。DataLake Store でフォルダ名には小文字しか利用できない、ということであれば納得できるのですが、普通に大文字も使えますので、これはコネクタ側の不具合なのだと思います。

このような問題はありますが、今のところはフォルダ名やファイル名に大文字を利用していなければ回避可能です。

LogicFlow で DataLake Store にどんどんデータをアップロードすることが、これで可能になりますので、例えば Flow で毎日何かしらのデータを OneDrive や CDS 、もしくはほかのサービスに連携しているようなところで、一緒に DataLake Store へも蓄積させることが簡単に行うことができるようになります。

現在はまだ DataLake Analytics を利用するには REST API を直接呼び出すしか方法がありませんが、それでも今までよりははるかに簡単に大規模にデータを集約させることができるようになったと思います。

油断していたら、またもリリースノートがまとめて更新されていましたｗ

まずは最新の方から。Aug 4 のリリースノートです。

改修内容は以下の通りです。

Update August 4, 2017

• "Peek" to code-view from an action
• Log analytics toggle on integration account creation
• Performance improvements for runtime
• Support for $expand on runs to get action input and outputs

不具合修正は以下の通り。

• Condition card dynamic content picker correctly dismisses
• Filter output in designer shows correctly in foreach
• Fixes for behavior when disabling splitOn in designer

何と言っても一番の更新は、デザイナーからの Peek です！ これは画面を見てもらうと一目瞭然です。

このようにデザイナー上で、各コネクタに対して Peek というメニューが増えていますのでそれをクリック。

するとこのように、デザイナー上でそのコネクタ部分のみコード表示に切り替わります。直接ここで修正も可能ですので、デザイナー上だけでは難しい指定も非常に記載しやすくなります。今までは CodeView といったりきたりをすることもありましたが、今回の Peek 対応でそれもほとんどなくなるのではないでしょうか。素晴らしい！

他には 統合アカウント作成時に、LogAnalytics 連携を指定できるようになったり、実行履歴でアクションからの入出力表示に expand 対応を行ったようです。

expand 対応は、上記のように履歴参照時に「さらに追加」オプションが出てくることかと思います。どうやら一部コネクタで設定の際に「詳細の表示」として、追加で指定できるタイプのものがありますが、それと連動するようです。追加設定のないコネクタは今まで通りの表示となっていました。

Update July 28, 2017

更新内容は以下の通りです。

• Dynamic table editor for table action added
• Updated colors for many of the actions
• Flat file decode updates
• Can now turn on log analytics directly from a create

不具合修正はこちら。

• Select/Join/Query now work from designer with nested arrays
• IE overflow fixes

Request コネクタや Requrence コネクタの色が変わったのがこのタイミングですね。今では Microsoft Flow 側にも反映されています。この時の大きなアップデートは、テーブルに対するエディタ機能の提供でしょうか。

このように CSV テーブル作成や HTML テーブル作成時に、出力したいテーブルの定義をエディタで指定できるようになりました。利用するには、列の設定を「カスタム」にすると、このエディタが表示されますので、細かく出力内容をカスタマイズしたい場合にはありがたい機能だと思います。

Update July 21, 2017

• More settings added to action settings (disable async pattern)

不具合修正はこちら。

• Fixes the runtime URL for connectors if deployed with the wrong region defined (helps with Visual Studio deployments)
• Fixes condition/switch branch out of bounds for IE
• Condition boolean would sometimes convert to bool('true')
• Gateway selection list would not always populate correclty

デザイナー上で設定できる項目として、非同期動作の無効化（単一インスタンスの指定）が可能になりました。非同期にした場合とシングルトンにした場合の違いですが、非同期の場合、トリガにデータがわたる都度 HTTP ステータスを参照して続きがあるかどうかをチェックしていますが、連携されたデータで処理を開始してしまいます。対してシングルトンでは HTTP ステータスが 200 となり全てのデータが渡された時点で、初めて処理を開始するので、処理開始までの時間は増えますが実行回数が減り、お財布に優しくなります（

実際の利用どころとしては、連携されたデータ全てを受け取らなくてはならない処理がある（連携時の件数を記録する、とか）場合には、シングルトンインスタンス起動が適しており、1レコードずつ処理が可能な場合は、非同期パターンが適しています。

関係ないけど、不具合修正、IE 対応がほぼほぼ毎回行われているあたり、Microsoft としても IE 対応は大変なんだなぁ・・・というのが見て取れますｗ

以前のアップデートで、Azure Resource Manager もコネクタの認証にサービスプリンシパルが利用できるようになり、それ用にアカウントを作成しなくてもアプリケーション単位での認証が行えるため、特に管理用アプリ的なものから操作したい際に、ユーザー別に考える必要がなくなり便利なケースがあります。今回はそのなかの機能を利用して、VM の起動を試してみました。

VM を起動するにも、Automation を利用したり REST Api を直接叩いたりと色々方法はありますが、LogicFlow の ARM コネクタを利用するのが、個人的には現時点で一番楽な方法だと思います。

ARM コネクタには Invoke resource operation というアクションがあり、これはリソースプロバイダの操作（機能）を直接呼ぶことができるものです。VM の場合、通常であれば Microsoft.Compute プロバイダを利用し、旧型であれば Microsoft.ClassicCompute プロバイダを使用して起動や停止など、一通りの操作が可能です。LogicFlow 上での設定は以下の通りになります。

設定する内容のドキュメントが見当たらないので試行錯誤しました（

サブスクリプションを選択すると、対象とするリソースグループが選択でき、利用したいプロバイダを選択できるようになりますので、ここは上から順に設定を行います。

Short Resource Id ですが、これはプロバイダが可能な操作を指定する箇所です。プロバイダごとの操作一覧は docsでまとめてありますが、最新状態とは異なることもあるので、念のために PowerShell 等で確認しておくと安心です。

x-ms-api-version は利用する API のバージョン情報を設定します。これはプロバイダ事に異なるので、事前に調べておくといいでしょう。LogicFlow で行う場合は、対象のプロバイダの情報を取得するアクション Read Resource Provider を利用すると、そのプロバイダで実行できる操作の一覧情報が取得でき、その中に API バージョン情報も含まれています。

最後に Action name で実行したい操作を指定します。

と、このように書くと非常に簡単に思えますが実際にはそれぞれのプロバイダで指定の方法が微妙に異なっており、非常に難解になっています。

例えば VM の操作では Microsoft.Compute プロバイダを利用して virtualMachines/start/action を呼び出すと起動できる、と書いてありますが、実際には virtualMachines/{ VM 名 }/start に対して action を呼び出すという事を行う必要があります。そしてそう動作するための設定が、先のスクリーンショットにあるように、

• Short Resource Id：virtualMachine/{ VM 名 }
• Action Name：start

と設定する必要があり、まずここに気づくまでに非常に時間がかかりました。なお、現在 ARM コネクタのデザイナ上の表示には不具合があり、上記のように設定後再度デザイナーを開くと、表示が狂います。狂うのですが、実際には正しく設定されているので不思議な状態になります。

このように、 Short Resource Id と Action Name の表示がおかしくなります・・・。

それはさておいてこれを実行すると、VM が起動できるのですが、ここにはもう一つ不具合が潜んでいます。

これは VM 側のログで、23:28:28 に起動が開始されたのが記録されています。

対してこちらが LogicApps 側のログですが、見事に失敗している履歴しかありません。ARM コネクタから戻されたエラーも 404 Not Found となっていて、指定されたリソースがない、というエラーになっています。

ですが、VM 自体は起動開始されているので、これは ARM コネクタ側の不具合なのではないか、というのが現在の状態です。

とまあ、まだ利用するには難しい感じの ARM コネクタですが、プロバイダを直接操作出来たり、テンプレートを利用してデプロイを行えたりと、Azure 上で行えることが一通りできる非常に強力なコネクタなのは間違いありません。

色々と試してみると、日頃の管理作業などが LogicFlow でもっと簡単に行えるのではないでしょうか。

常に色々とアップデートが行われている LogicApps の、先週までに行われたアップデートについてリリースノートが出ていました（こうやって毎週出てくれるとありがたいｗ）

今回のリリースノートは以下の通りです。

• Log Analytics dashboard for OMS
• All combinations of until and foreach nesting work (code-view only currently)
• Improved UI for conditions
• Leverage Monaco text editor for Azure function creation

まずはやはり OMS というか LogAnalytics。それ用のコネクタも先週に追加されていました。

先々月で Chrome でも参照可能になったこともあり、これで普通に OMS を見ることができそうです。

そして隠れたもう一つの大型アップデートは、（CodeView 限定ですが）ForEach や Until ループのネスト対応が行われたという点です。デザイナー上での対応はもうしばらくかかりそうですが、長年の課題が一つ解決できそうです。

あとは、条件式の入力改善と、Function Apps のエディタが Monaco 対応したというところになります。これまでは単なるテキストエディタでしたが、これからはインテリセンスも効く、コードを書きやすい環境になります。

個人的に惜しいのは、これは新規作成時のみエディタであれこれできるというところでしょうか。既存の関数を選択した場合には、このエディタがでてこないので、ちょっと修正しようと思った場合は、Function Apps のブレードから行う必要があります。

不具合修正は以下の通りです。

• Fix designer issue where scope wouldn't always allow delete
• Sometimes unable to select a sub-folder in the file picker
• Text fixes for some of the settings to be more clear

スコープコネクタが削除できなくなるケースがあった点への対応、ファイルピッカーでサブフォルダが選択できなくなるケースへの対応、そしてテキスト入力の改善です。

こっそりと一部リージョンで新規コネクタのテストが行われていたり、これからも続々と更新されていく LogicApps に期待ですね。

現在、Twitter 上では、以前に構築した「サービス数をカウントしてツイートする」ということを続けています。これはこれでよいのですが、実際に対応サービスが増えた際に、何が増えたかを確認するのがおっくうになってきたので、その点も対応してみました。

まずデータ格納先となる Azure Table Storage を作成するのですが、現在では Table Storage か Cosmos DB の Table Storage かの 2 種類が存在しています。Cosmos DB の方が障害に強く実運用には適している面もあるのですが、反面コスト的には従来の Table Storage が有利な面もあるので、使い分けが必要です。ただし、LogicFlow 上ではどちらも同じような操作・設定となりますのでそれほど意識する必要はありません。

まずは下準備として、現在のサービス情報をあらかじめ Table Storage に導入しておく必要があります。

従来の Table Storage では、ストレージアカウントを新規作成し、その配下に Blob や Table などの従属サービスを作成する流れとなっています。上記の画面で「テーブル」をクリックすると、Table Storage の作成が可能な一覧画面へと変わります。

この一蘭画面の上部メニューにある「テーブル」をクリックすると、新規にテーブルが作成できます。

テーブルの作成といっても、難しいことは何もなく、テーブル名を設定するだけです。これで Table Storage を利用する準備は整いました。

LogicFlow から Table Storage を利用するには、アカウント名とアクセスキーが必要になりますので、「アクセスキー」ブレードを開いて、情報を控えておきます。

今回作成した、事前準備用の LogicFlow では前半でいつものアクセストークンを取得します。その情報をもとに、実際のサービス情報を取得、取得した結果を Table Storage に更新しています。

その際にポイントとなるのは、サービス情報を取得した後のこの部分です。取得したサービス情報を「選択」アクションで、名前と詳細のみの配列へと変更してその配列を Table Storage への更新に利用しています。

これは情報を制限しようと思っているからではなく、Table Storage の仕様として「平坦化された情報のみ保持可能」というものがあるためです。言い換えると、JSON などでは複数のプロパティを持つ値、prop.name、prop.description、prop.api ・・・など、このような値はそのままでは更新できずにエラーとなります。

そのために、今回はサービス名と詳細だけに値を絞って平坦化しています。実際に更新されたデータを確認するには、Azure Storage Explorerが便利です。

このように、実際のストレージ内部を確認できるので、これで更新がうまく行われているかを確認できます。

この下準備を行うことで、取得した最新のサービス情報と比較を行い、新たに増えたサービスが判定可能になります。

その場合の判定を行うには上記のような LogicFlow になります。取得した最新のサービス情報に対して ForEach でループを行い、取得した name（JSON 上に二つ name プロパティがあるので注意）を条件に、Table Storage より取得を行います。

取得した結果が存在するかどうかには、length 関数を使用して判定を行います。length 関数の結果が 0 である＝Table Storage にデータがない＝新規サービス、として判断が可能です。

また反対に、最新情報に含まれていないけど Table Storage に含まれている場合にも対応が可能です。この場合は、Table Storage のデータで ForEach ループを行う形になります（過去に、間違ってリリースしてしまったなどで、消えたサービスがあったりします…）

なお、Table Storage からデータを取得する際には、少々慣れが必要です。

詳細オプションの中の FIltter Query 項目で、取得する際の条件を指定することが可能ですが、上記のように、独自の構文（HTTP クエリパラメータに近い）を利用しています。こちらの記載については公式ドキュメントがあるので、参照してみてください。

もう一つの Select Query は、結果として取得する項目を指定するところとなります。

このような形で LogicFlow を組むことで、ほぼほぼコードレスな状態でも色々なことができるようになります。アイデア次第で、コードが必要だと思っていた箇所がコードレスで対応可能となることで、より重要なところに着手できる余裕が増えるのではないでしょうか。

今回はちょっとした小ネタです。文字列を色々扱う機会は多いと思いますが、その中でも「指定した桁数以降の文字列」を取得したいケースはそれなりにあるので、方法としてまとめておきます。

LogicFlow で用意されている関数を複数組み合わせて利用するのですが、普段プログラムを書いている人だとはまる点が一つだけあります。

全体としては、上記のような LogicFlow で挙動を確認しています。上で表示されているのは、一つ目の作成コネクタで指定している関数です。先に定義した変数 testVal の先頭（ 0 桁目）から 7 文字取得しています。ここはよくある使い方で特に問題はありません。

対して二つ目の作成コネクタでは、4 桁目以降を取得、ということをやろうとしています。普段プログラムを書いている方でしたら、

hogehoge.substring(4, hogehoge.length – 4)

というように、全体の文字数を求めそこから開始位置の桁数を引くことで、指定桁数以降の文字列が取得できるというのをすぐに思いつくのではないでしょうか。

これを LogicFlow にそのまま書こうとすると、次のような形になります。

@substring(variables('testVal'),4, length(variables('testVal')) - 4 )

substring 関数で部分的に文字列を取得する際に、開始桁数を例えば 4 と固定で指定し、取得する文字数を length 関数で全体の桁数として取得し、そこから 4 を引くことで末尾までの文字数を算出し、それを substring 関数に指定する、というよく見るやり方です。ところが、これは LogicFlow 上では構文エラーとなります。

それは、関数の中に計算式を含めることができない、という LogicFlow の仕様によるものです。

そのため、先の画面のように、

@substring(variables('testVal'),4,sub(length(variables('testVal')),4))

と、length 関数で求めた桁数に対して sub 関数で減算を行う必要があります。

普段プログラムをしていない方でしたらおそらくすぐに上記の書き方にたどり着けるのでしょうが、逆にプログラムを書いている人間だと「？」となってしまう点でした。

ついに発表された Azure Event Grid。現在 ServiceBus で行っているようなサブスクリプション・トピック型によるメッセージングのやり取りだけではなく、Azure 上で発生するイベントを検知・連携できるようになるという、非常に興味溢れるサービスです。まずは LogicApps 上で利用してみるまでをまとめてみました。

LogicApps はもともと EventGrid との連携を考えられて準備されており、EventGrid コネクタがすでに提供されています。

コネクタで提供されているのは、一つのトリガのみです。EventGrid から何かしらのイベントを受け取った際、というトリガです。

設定する項目としては以下の通りとなります。

• サブスクリプション：自分のサブスクリプションを選択します。
• リソース種類：取得したいイベントの種類。EventGrid Topic のほかには EventHub、Azure リソースグループ、Azure サブスクリプションが選択できます。
• リソース名：取得したい対象。EventGrid Topic の場合は自動で、EventHub の場合は既存の EventHub 名前空間、Azure リソースグループの場合は既存のリソースグループ、Azure サブスクリプションの場合は既存のサブスクリプションから選択します。

例えば、リソースグループを指定した場合、指定したリソースグループで「書き込み」「削除」に該当する処理が発生すると、イベントとして通知してもらえるようになります。これは例えば、LogicApps を作成・更新したとか、VM の設定を変更した、といったケースです。

サブスクリプションを指定した場合は、選択したサブスクリプション上で発生した「書き込み」「削除」に該当する処理を、同じように通知してもらえるようになります。Ch9 のデモでも行われていましたがアカウントの追加などがわかりやすいところでしょう。

LogicApps で EventGrid コネクタを設置して保存すると、そのタイミングで EventGrid に対して必要な設定が自動で行われます。ポータル上で EventGrid を開いて先に何かしらの作業を行う必要が一切なく、何も気にせずに利用が可能なのは大変すばらしいと思います。

なお、EventGrid コネクタを利用してリソースグループやサブスクリプションのイベントを察知したい場合、事前に権限設定が必要です。適したロールが見当たらないので、おそらく現状では「所有者」相当のものを権限として設定されていなければならなさそうに思います。

もし権限が不足していた場合、LogicFlow のトリガー履歴に「失敗」な履歴が増えます。EventGrid トリガの場合、保存後すぐに動作しようとするためです。

履歴を確認すると、このように AuthorizationFailed として、必要権限が不足しているため認証エラーとなっていることが確認できます。このようなエラーとなった場合は、アカウントもしくはアプリケーションに対して権限を付与してください。

実際にリソースグループに対する変更を検知できるか、試しに EventGrid で対象として設定したリソースグループに、もう一つ LogicApps を新規に作成してみました（TestApps2)

するとこのように、Subject には作成した LogicApps が、イベント種類として Microsoft.Resources.ResourceWriteSuccess として検知され LogicApps に通知が届きました。

このように EventGrid を使う・試してみるのには LogicApps が非常に楽です。EventGrid の設定自体何も行っておらず LogicApps 上であれこれしているだけですので、ぜひぜひ気軽に利用してみてください。

EventGrid を利用すると、今まで ServiceBus や EventHub に分散していたイベントを統合して扱えるようにするのも簡単ですし、発生したイベントを処理するのも、LogicApps から Function Apps に切り替えるとか、Webhook にして外部システムに連携させるといった切り替えも非常に簡単に行えますので、「ハイブリッドなインテグレーション」がますます簡単に利用できるようになると思います。

LogicApps のアップデートについてリリースノートが更新されていました。また、今週は LogicApps Live もあるので、さらなる隠し玉があったりしないか楽しみです。

リリースノートは以下の通りとなります。

Release Notes

• Advanced scheduling for recurrence trigger
• Connection wizard for Azure Table and Azure File
• Colorized JSON inputs and outputs in run monitor view
• Added some helpful tips for Until loop
• Surface error that may happen on an HTTP Webhook subscription failure
• Code-view support for concurrency control on number of runs and foreach parallelism

Bug Fixes

• Dynamic outputs would not always refresh when changing dynamic inputs
• Validation for string variable would validate for a number
• Better show parsing errors for HTTP + Swagger
• Improved performance for the 'Peek Code View' feature
• Fixed the help page that opens when creating a new on-premises data gateway

Recurrence トリガはタイマー指定のものですが、デザイナーの表示が変更になったのと「週単位」での指定が可能になっています。

Table ストレージコネクタと File ストレージコネクタで、初回に接続を作成する際にウィザード形式（既存アカウントの一覧から選択可能にするもの）が追加されています。毎回アカウントとシークレットを調べるのは何気に手間なので、これは個人的にうれしいところです。

JSON の表示に色付けが行われている、ということでしたが手元の環境では下記のように、JSON スキーマの設定においては色付けされるのが確認できました。Run Monitor View とあったので、当初は実行履歴だと思ったのですが、こちらでは特に色付けが見当たらず・・・。

他にも、Untilループのヒントをいくつか追加、HTTP Webhook サブスクリプションの失敗時に発生するサーフェスエラー、実行回数と foreach の並列性に関する並行性制御のコードビューのサポート、と色々改善が行われているとのことです。

不具合修正は、動的入力を変更するときに動的出力が必ずしも更新されない、 文字列変数の妥当性検査によって数値が検証されます、 HTTP + Swaggerのパースエラーの表示を改善、 「Peek Code View」機能のパフォーマンスが向上しました、 新しいオンプレミスデータゲートウェイを作成するときに開くヘルプページを修正しました、とこちらも色々です。

さて、明日は LogicApps Live ですので、また楽しい話題が出てくるのを期待してます。

今月も LogicApps Liveが行われ、色々と多くの話題が出てきていますのでまとめてみました。

いつもは3人ですが、今回は john がいないですね・・・。

まずはなんといっても Azure Event Grid が一番の大きなニュースです！ 軽く触っただけでも、非常に魅力あるサービスであるのが感じられる Event Grid で、これを利用すれば各種イベントを統合して扱うことができ、イベントに対する処理も LogicApps で作成したり、Function Apps で作成したり、時には REST API 経由でデスクトップアプリケーションで作成したりといった、非常に対応できる幅が広い面白いサービスです。

そして今回の新情報としては次のようなものとなっています。

テーブル出力時にヘッダ情報を付与出来たり、LogicApps 作成時に LogAnalytics へ連携する設定が指定出来たり、OMS で LogicApps 関係を参照する新しいダッシュボードが提供されたり、Peek 機能で デザイナー上から JSON コードを参照できるようになったり、Reccurency コネクタで「週単位」や「日単位」がさらに細かく指定できるようになったりと、今回も多くのアップデートです。

そしてデモはやはり Event Grid から。上のスクリーンショットを見て気づいた人がいるかもしれませんが、これは Event Grid へイベントを投入するアクションです。そしてもう一点、コネクタのアイコンがこれまでの Event Grid とは別になっているのがポイントです。今のところ、Event Grid は二つのコネクタで提供する方向のようですね。

画面切り替えをする際に、見慣れないコネクタが見えたような気がしますが、きっとこれもそのうちアナウンスあるんだろうなぁ（

そしてバージョンアップされた Reccurenct コネクタのトリガです。このように起動する曜日が指定出来たり・・・

起動する時間帯を指定できるようにバージョンアップされています。Windows のタスクスケジューラに近いレベルで、動作タイミングを指定できるようになってきていますね。

そして新コネクタの発表。今回発表されたものは、大体 West  Central Us リージョンで確認できるのですが、一つだけ Service Now コネクタだけは例外的に East US 2 リージョン限定となっています。個人的に衝撃があったのは、やはり Amazon Redshift ではないかな、と思います。Microsoft が Amazon（AWS）連携機能を公式に提供、というのが古くから MS を見ている人間にとっては非常にインパクトがありましたｗ

作業中の話題も盛りだくさんです。

CodeView の拡張は既に提供開始されており、インテリセンスも実は確認できたりします。50MB を超えるサイズのファイルを扱えるようにしたり、変数の対応を強化（配列への追加や、文字列への結合など）したり、長い事 LogicApps Live でも言われてきた ForEach コネクタのネスト対応についても、ほぼほぼ出来上がっている状態とのことです（実際、表示だけならデザイナーは対応済み）。上記スクリーンショットにある URL へアクセスすると・・・？

Azure サブスクリプションを持っている方は試してみてください。このようにプレビュー版のデザイナーが利用でき、そこではすでにデザイナー上で ForEach コネクタのネストが作成できます！

最後に Integrate2017 のお知らせをして、今回の LogicApps Live は終了でした。

やはり Event Grid 周りが大きいインパクトがあったと思います。利用するのも LogicApps からが一番簡単に利用できるのもあるので、ぜひぜひ触ってみてもらいたいところです。LogicApps の得意とする「インテグレーション」に適したコネクタの一つですので、これをどう利用していくか考えるのも楽しいですね。

LogicApps のリリースノートが更新され、8/25 リリース内容が更新されていました。

今回のアップデートは以下の通りです。

• Expression IntelliSense
• Time expressions added to valid syntax @getFutureTime(<int>, Day | Hour | etc.), @getPastTime(<int>, Day | Hour | etc.), @addToTime(<date>, <int>, Day | Hour | etc.), @subtractFromTime(<date>, <int>, Day | Hour | etc.)
• Colorized JSON inputs/outputs in run history view
• New "Schedule" and "Security" template categories
  If branches now collapsable
• Show hint to enable SQL auto-paging in actions menu
• Pan + Zoom in run history view
• Validate retry policy inputs in designer

まずは関数式のインテリセンス対応です。これはデザイナー上の話で、以下のように表示されます。

これでさらに関数が利用しやすくなりますね。なお、関数をダイアログから選択した直後はインテリセンスが働かないので、手打ちするか、一度カンマなどを打つことで表示されるようになります。

次は日時計算での新規関数です。

• @getFutureTime(<int>, Day | Hour | etc.)　は現在日時より指定した 日数/時間など が経過した日時を計算します。簡単に言えば何時間後、とかです。
• @getPastTime(<int>, Day | Hour | etc.)は現在日時より指定した 日数/時間など がさかのぼった日時を計算します。簡単に言えば何時間前、とかです。
• @addToTime(<date>, <int>, Day | Hour | etc.) は指定した日時に、指定した日時を加算するものです。
• @subtractFromTime(<date>, <int>, Day | Hour | etc.) は指定した日時より、指定した日時を減算するものです

例えば getFutureTime(1, ‘Day’) と記載してみると、現在日時の 1 日後をこのように取得できます。日時計算はこれまで複数の関数が用意されていましたが、上記のようにまとめられると、覚える数が減るので助かります。

次は実行履歴で JSON を表示する際に色付けを行った点です。

ちょっとした変更ですが、JSON の値が見やすくなっています。

次はテンプレートに「スケジュール」と「セキュリティ」を追加した件ですが・・・

スケジュールは表示されてきましたが、セキュリティはまだ見当たりませんでした。どういったテンプレートが用意されるのか、ちょっと楽しみです（セキュリティ系のテンプレート、と言われてどういったものかが想像ついていないｗ）

次は If コネクタで、Then、Else それぞれが折りたたみ可能になった点。

言われるまで「できなかったのか！？」と気づきませんでしたｗ

実行履歴の参照画面にも、拡大縮小ができるようになりました。

あとは、大量データ取得時に指定するページング設定でヒント表示が追加された件、再試行ポリシーの入力値検証が追加された件が、今回のアップデート内容となります。こうしてみると、今回も多いな・・・。

そして不具合修正はこのようになります。

• Fixed issue where webhook actions with dynamic inputs wouldn't render correctly in designer
• Compose wouldn't correctly show non-JSON outputs in run history view
• Dynamic schema properties marked as readonly should not be added to inputs (affected Dynamics 365 designer)
• Service Principal 'learn more' wouldn't correctly open doc
  

デザイナー上で Webhook アクションの動的パラメータ表示がうまく行われていなかった件、実行履歴で Compose アクションの場合出力結果が表示できていなかった件、Dynamics365 のような動的スキーマ対応がうまくできていなかった件、サービスプリンシパル利用時に表示していたリンク先が誤っていたのを修正、となります。

今回も盛りだくさんな内容でしたが、できればリリースノートは週末に更新してもらえると助かるかな・・・ｗ

LogicFlow の HTTP Request コネクタでは、JSON スキーマを指定することにより受け取る値について色々指定ができるようになっています。スキーマ自体には実際のところ、桁数制限など色々な機能があるのですが、LogicFlow 側ではどこまで対応しているのかを調べてみました。

1.文字型

まずは文字型に対する状況です。

文字型では「桁数の制限」や「正規表現によるパターン指定」が JSON スキーマでは可能です。サンプルとして以下のスキーマを作成しました。

このスキーマを HTTP Request コネクタに設定し、別の LogicFlow から呼び出しを行ってみます。

LogicApps コネクタを利用すると、同一リージョンにある LogicFlow が呼び出せます。この時条件がもう一つあり、HTTP Request トリガで作成されている LogicFlow が、このコネクタから呼び出すことのできる LogicFlow となります。

実際に呼び出す LogicFlow を指定すると、このようにデザイナー上では各値の入力が可能になりますが、指定した桁数制限や正規表現によるパターン指定は動作していないのがわかります。

実行も問題なく行えていますので、文字型に対する各種制御は対応していないのがわかります。

2.数字型

次は数字型です。数字型では「入力範囲」「倍数の指定」が行えます。サンプルは次のように用意しました。

デザイナー上では数字でないものをエラーとするよう動作しているのが確認できます。それ以外の指定については、文字型と同様に動作していない雰囲気です。

やはりこちらでも、各種制御は動作していませんでした。

3.全体に適用するもの

JSON スキーマでは、「利用可能な値を列挙」「必須項目」「依存項目」といった制御も行うことが可能です。以下のようなスキーマを作成しました。

値を列挙する enum は、このようにデザイナー側で対応されており、利用可能な値を選択できるようになっています。また required 指定で、必須項目としたものについても、デザイナー上で * が赤く表示されており、対応されています。

dependancy による依存設定（ある項目を入力するなら、この項目も必要という設定）ですが、こちらが対応されていないようです。実行結果もこれまで同様、値のチェックは行われずでした。

このような感じで、JSON スキーマでは色々機能があるのですが、LogicFlow デザイナーとして対応しているのは一部にとどまる模様です。それでも、required による必須項目指定と、enum による利用可能な値の列挙があるだけで、大分設定を行いやすいと思います。

実際に連携された値については、やはり LogicFlow 上で明確に値チェックを行うのがよい、ということになると思います。