Morning Girl

Web API, Windows, C#, .NET, Dynamics 365/CRM etc..

【Dynamics 365】【Azure】Connected Field Serviceをやってみた その3 Azure PaaSがどうなってんの?

さて、前回はConnected Field Serviceの構成手順について書きました。

今回は実際に構成されたConnected Field ServiceのAzure PaaSサービスがそれぞれどのような立ち位置でどのように動いているのか、それをしっかりと捉えてみたいと思います。

これが見えてくると、思いの外シンプルに、かつ拡張性を考慮したアーキテクチャになっていることが見えてくるかと思います。

ですので、例えばすでに自社に存在しているセンサーデバイスを接続したい場合

Dynamics 365にアラートする閾値を変えたい場合、

接続するDynamics 365のエンティティを変更したい場合

などといったシチュエーションに対応できるようになるかと思います。

アーキテクチャ 全体像

一応アーキテクチャの全体像は以下のような感じでMSDNに公開はされています。

されていますが、

f:id:sugimomoto:20170326160251p:plain

Connected Field Service アーキテクチャ

ざっくりすぎて、よくわからない!!

結局Azure に構成されているサービス郡は以下のようになっており、いまひとつそれぞれがどのような役割を担っているのか、わかりづらさが残ります。

f:id:sugimomoto:20170326160319p:plain

なので、私なりに咀嚼しながら、以下のような形でシナリオベースのシステム構成図に置き直しました。

f:id:sugimomoto:20170326160332p:plain

ポイントは以前もその1でもお伝えした通り、4種類のシナリオで構成されている点です。

  1. Dynamics 365上でIoT Deviceの登録・管理
  2. IoT DeviceからDynamics 365へアラート・サポート案件へ繋げる
  3. Dynamics 365からIoT Deviceへコマンドの送信しIoT Deviceを制御
  4. IoT Deviceの状況をPower BIへの連携しDynamics 365上で可視化

❶IoT Deviceの登録

まず最初にIoT Deviceの登録です。

Dynamics 365上で以下のようにデバイスを登録するところですね。

f:id:sugimomoto:20170326160347p:plain

これは、上記全体像から抜粋すると、以下のような感じになります。

f:id:sugimomoto:20170326160354p:plain

Dynamics 365から「デバイスの登録」ボタンを押した時点から、一度Service Busにメッセージとして格納されます。

Service Busに格納されたメッセージは30秒間隔でLogic Appsが読み取り、デバイスの登録処理を行っていきます。(※ちなみにこのLogic Appsはデバイスの登録だけでなくコマンドの送信も司っています。)

f:id:sugimomoto:20170326160401p:plain

最終的には、Device の登録が完了後、登録が完了した旨をLogic AppsからDynamics 365へ伝達しています。

こうゆうLogic Appsの使い方、いいですね。

❷IoT Deviceから通知

その次にIoT Deviceからのアラートです。

以下のようなシュミレータから温度・湿度の情報をおくる部分ですね。

f:id:sugimomoto:20170326160408p:plain

これは、シュミレータからIoT Hubへ一度送信され、その情報をStream Analyticsが咀嚼。

Azure BLOB Storageに格納されている閾値JSON情報を元に、アラートを上げるべきか判別し、アラートを上げる対象であれば、Service Busにメッセージとして格納。最終的にはLogic AppsでDynamics 365にレコードを作成する処理を実行します。

f:id:sugimomoto:20170326160415p:plain

Stream Analyticsのクエリは以下のような感じです。

f:id:sugimomoto:20170326160424p:plain

Input をIoT HubとBlob Storageから取得し、Stream 情報を元にStorageに置かれたJSON閾値から出たものを1分間隔置きで検証し、アラートを上げています。

閾値はAzure Storage Explorer などで確認できます。

f:id:sugimomoto:20170326160432p:plain

以下のような感じで格納されていますね。初期状態では温度が70度以上であれば、アラートをあげる設定です。

[{“DeviceType”:“Thermostat”,“Temperature”:70.0,“Humidity”:null,“TemperatureRuleOutput”:“AlarmTemp”,“HumidityRuleOutput”:null}]

Logic Appsはシンプルですね。そのままService Busに格納されたアラートメッセージを取得し、CRMにレコードを作成しているだけです。

f:id:sugimomoto:20170326160440p:plain

❸Power BIへの連携

Power BIの部分は❷とあまり変わりません。

IoT Hubの情報を元にStream Analyticsで処理し、OutputがService Busではなく、Azure SQLに変わっているだけですね。

f:id:sugimomoto:20170326160448p:plain

Stream Analyticsは1分ごとの値をGroup化し、その中の最大値をAzure SQLに流し込んでいます。

f:id:sugimomoto:20170326160456p:plain

❹Dynamics 365からコマンドの送信

Dynamics 365からIoT Hubに対するコマンドの送信部分

f:id:sugimomoto:20170326160505p:plain

こちらは❶の手順と変わりません。

Logic AppsがService Busのレコードを判別し、コマンドかデバイス登録かを識別しているだけです。

f:id:sugimomoto:20170326160513p:plain

構成されているAzure PaaS

その上で改めて一覧化しますと、以下のような感じで役割構成されています。

あと、せっかくなので料金形態も書いておきました。意外とお金がかかります。

docs.com

なんだかんだで初期状態のままだと、月4万円ほどかかる計算ですね。

はじめはそうと知らずに、放置していたら、10日ほどで無償試用版の2万円を使い切ってしまいました。(しかも勉強会で発表する当日に使い切るというね……orz)

所感

3回に渡って、Connected Field Serviceを書いてきました。

はじめは手軽に構成できることが面白いものでしたが、中のAzure PaaS構成を調べていくうちにマイクロソフトが考えているAzure IoT のデバインパターンに一旦に触れられたようで、かなり興味深く面白い体験となりました。

実際に拡張性としても色々と取り組みやすい構成になっているので、今後他のセンサー・デバイスなども繋いでみたいなぁというところです。

Dynamics 365 とのAzure 連携は結構活発になっていると感じるものの、関連性検索やPortal等ほぼブラックボックス化されていて、MSDNの記事などから中を想像することしかできなかったのですが、もうちょっとこんな感じで公開された、触ることができるアドオンが増えていくと嬉しい限りですね。