前回は、Office 365 からサービス正常性を取得するための事前準備をしました。

まだご覧になっていない方は一読ください。

Microsoft Office 365 Service Communications API を使用した Dynamics 365 Customer Engagement サービス監視: 概要
Microsoft Office 365 Service Communications API を使用した Dynamics 365 Customer Engagement サービス監視: 事前準備

今回は、実際に Dynamics 365 CE サービス正常性を取得してみます。Office 365 の管理センターの内容と比較しながら見ていきます。

- 有効なサービスを取得
- 現在の状態を取得
- インシデントの詳細を取得
- 過去の状態を取得

有効なサービスを取得

Office 365 テナントで有効になっているサービスを取得してみます。最初に Office 365 管理センターで確認します。

[Office 管理センター] > [正常性] > [サービス正常性] をクリックします。

この評価環境の場合、17 個の有効なサービスがあることがわかります。

[Office 365 Service Communications API]

続いてAPI で取得してみます。クライアントに Postman をインストールしてください。

1. Postman を起動します。

2. “Request” をクリックします。

3. 名前を付けます。

4. Collection を作成し、指定します。

5. 作成されます。

6. 続いて。右ペインに以下の URL を入力します。

https://manage.office.com/api/v1.0/<テナント名>.com/ServiceComms/Services

7. 認証タイプを “OAuth 2.0” に指定します。

8. [Get New Access Token] をクリックします。

9. 以下の通り設定します。

Client ID、Client Secret は事前準備で取得したものを指定します。

10. ボタンをクリックします。

11. Office 365 へのログイン画面が表示されます。Office 365 管理者でログインします。

12. ログインに成功すると、Access Token に文字列が記載されればOKです。
トークンは一定期間利用できるます。以後本記事で出てくる操作は、同じトークンを利用できます。

13. 下にスクロールしてボタンをクリックします。

14. Header に “Authorization” が追加されていることを確認します。

15. Send ボタンをクリックします。

16. HTTP ステータス 200 で、Body に何かしら返却されていれば OK です。

17. 構造を見てみましょう。青枠 (4-29 行目) は Dynamics 365 CE だとわかります。
また同様に各サービスの結果が返ってきており 17 個あることがわかります。

18. 続いて、Dynamics 365 CE のみにみ絞ってみます。フィルターを付けます。

19. [Send] をクリックします。Dynamics 365 CE のみにフィルターされたことがわかります。

Dynamics 365 CE で取得できる項目

Dynamics 365 CE のサービスで API で確認できることは 5つあるようです。

- Sign In
- Sign up and administrator
- Organization access
- Organization performance
- Components/Feature

現在この項目の詳細について公開情報は見つけられていませんが、名前から推測すると Dynamics 365 CE にサインできるか、Dynamics 365 CE の組織にアクセスできるか、パフォーマンスの状態、機能やコンポートの状態などがわかるようです。API がプレビューという位置づけですが、この情報は API で確認できる有用な情報です。

現在の状態

続いて、Dynamics 365 CE の現在の状態を取得してみます。

1. URL に “CurremtStatus” とフィルターを付けて [Send] をクリックします。

2. Dynamics 365 サービスの現在の正常性がわかります。

1 つ目の赤枠は、項目ごとの状態がどうなっているかわかります。”Components/Feature” が “ServiceRestored” になっており、サービスが復元した状態であることがわかります。

2 つ目の赤枠は、インシデントの番号が確認できます。後ほどインシデントの詳細を取得してみます。

3 つ目の赤枠は、サービス全体の状態がわかります。“ServiceRestored” になっているためサービスが服された状態だとわかります。
また、Statustime は取得した時間のようです。日にちが一日ずれていますが日本時間にすると時間は合います（UTC+9)。

インシデントの詳細を取得

では続いて、インシデントの詳細を取得てみましょう。

1. URL に “Message” とフィルターを付けて [Send] をクリックします。

2. “CR146892” インシデントの詳細が取得できました。

Title、ImpactDescription より SharePoint Online との連携で問題が発生していたことが読み取れます。

開始時間は 8/20 14:01、終了時間は 8/27 17:5、更新日時が 8/28 7:34 ということがわかります。

Messages 部分は、過去の履歴を意味しているようです。最初のメッセージは 8/21 19;40 から始まり、8/27 20:15 が最後のようです。

Office 365  管理センターを見てみましょう。

3. [Office 365 管理センター] > [正常性] > [サービス正常性] > [履歴の表示] をクリックします。

4. “CR146892” をクリックします。開始時間、終了時間、更新日時、最終メッセージが API と同じものであることがわかります。

また、メッセージの履歴も確認できます。最初と最後のメッセージの日時が一致していることがわかります。

過去の履歴の取得

最後に、過去のサービスの正常性の履歴を取得してみます。

1. URL に入力します。

https://manage.office.com/api/v1.0/<テナント名>.com/ServiceComms/HistoricalStatus?$filter=Workload%20eq%20'DynamicsCRM'

2. [Send] をクリックします。結果を見ると、日次で 0:00 時点のサービスの正常性の状態を保持していることがわかります。
8/22-8/28 の 7 日分の履歴が返ってきました。

確認すると、履歴の一番古い 8/22 時点ですでに “CR146892” は発生したことがわかります。

そして、8/27 まで続けていましたが、8/28 ではインシデントはなくなり StatusDisplayName も “Normal Service” になっているため解消されたと判断できます。

Office 365 管理センターで確認すると、8/28 現在Dynamics 365 CE の状態は正常であることがわかります。

履歴の表示をクリックします。

“CR146892” は確認でき、8/20 14:1 が開始日時となっていることから、8/20 から発生したと判断できます。

まとめ

いかがだったでしょうか。今回は Dynamics 365 CE のサービス正常性を取得してみました。
現在の状態、インシデントの詳細、過去の履歴を取得できることがわかりました。またサインインできるか、組織のパフォーマンスの状態といった有用な情報も API で取得できることがわかりました。
次回は、今後のメンテナンス情報などのメッセージセンターの情報を取得してみます。お楽しみ。

- プレミアフィールドエンジニアリング 河野 高也

※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります

Request: GET https://manage.office.com/api/v1.0/contoso.onmicrosoft.com/ServiceComms/Services Authorization: Bearer <authorization bearer token> Host: manage.office.com

Request: GET https://manage.office.com/api/v1.0/contoso.onmicrosoft.com/ServiceComms/CurrentStatus?$filter=Workload%20eq%20'DynamicsCRM' Authorization: Bearer <authorization bearer token> Host: manage.office.com Response Body: { "@odata.context":"https://office365servicecomms-prod.cloudapp.net/api/v1.0/contoso.onmicrosoft.com/$metadata#CurrentStatus","value":[ { "FeatureStatus":[ { "FeatureDisplayName":"Sign In","FeatureName":"signin","FeatureServiceStatus":"ServiceOperational","FeatureServiceStatusDisplayName":"Normal service" },{ "FeatureDisplayName":"Sign up and administration","FeatureName":"admin","FeatureServiceStatus":"ServiceOperational","FeatureServiceStatusDisplayName":"Normal service" },{ "FeatureDisplayName":"Organization access","FeatureName":"orgaccess","FeatureServiceStatus":"ServiceOperational","FeatureServiceStatusDisplayName":"Normal service" },{ "FeatureDisplayName":"Organization performance","FeatureName":"orgperf","FeatureServiceStatus":"ServiceOperational","FeatureServiceStatusDisplayName":"Normal service" },{ "FeatureDisplayName":"Components/Features","FeatureName":"crmcomponents","FeatureServiceStatus":"ServiceRestored","FeatureServiceStatusDisplayName":"Service restored" } ],"Id":"DynamicsCRM","IncidentIds":[ "CR134863" ],"Status":"ServiceRestored","StatusDisplayName":"Service restored","StatusTime":"2018-04-26T19:09:29.3038421Z","Workload":"DynamicsCRM","WorkloadDisplayName":"Dynamics 365" } ] }

Request: GET https://manage.office.com/api/v1.0/contoso.onmicrosoft.com/ServiceComms/HistoricalStatus?$filter=Workload%20eq%20'DynamicsCRM' Authorization: Bearer <authorization bearer token>

Requests: Filter by Id: https://manage.office.com/api/v1.0/contoso.onmicrosoft.com/ServiceComms/Messages?$filter=Id%20eq%20'CR133521' Filter by Message Center: https://manage.office.com/api/v1.0/contoso.onmicrosoft.com/ServiceComms/Messages?$filter=MessageType%20eq%20Microsoft.Office365ServiceComms.ExposedContracts.MessageType'MessageCenter' Incidents: https://manage.office.com/api/v1.0/contoso.onmicrosoft.com/ServiceComms/Messages?$filter=MessageType%20eq%20Microsoft.Office365ServiceComms.ExposedContracts.MessageType'Incident' Planned Maintenance: https://manage.office.com/api/v1.0/contoso.onmicrosoft.com/ServiceComms/Messages?$filter=MessageType%20eq%20Microsoft.Office365ServiceComms.ExposedContracts.MessageType'PlannedMaintenance' Filter By Start Time and End Time: https://manage.office.com/api/v1.0/contoso.onmicrosoft.com/ServiceComms/Messages?$filter=StartTime%20ge%202018-04-23T00:00:00Z&EndTime%20le%202018-04-28T00:00:00Z Filter by Workload: https://manage.office.com/api/v1.0/contoso.onmicrosoft.com/ServiceComms/Messages?$filter=Workload%20eq%20'DynamicsCRM'

前回に続き、膨大なセンサーデータから自動で異常を検知して Dynamics 365 にケースを自動作成するサンプルデザインを紹介します。
前回の記事を読まれていない方は、是非ご覧ください。

膨大なセンサーデータと連携 ! Azure Cosmos DB 連携: 概要
膨大なセンサーデータと連携 ! Azure Cosmos DB 連携: 事前準備 その 1
膨大なセンサーデータと連携 ! Azure Cosmos DB 連携: 事前準備 その 2

前回で、事前準備は完了しました。今回は、なぜこのようなデザインになっているのかを解説していきたいと思います。

概要

2 つのポイントを解説していきます。

- なぜコネクタ (Azure API) が必要なのか？
- 別の項目を連携するにはどうしたらよいか？

今一度サンプルデザインをご覧ください。

なぜコネクタ (Azure API) が必要なのか？

サンプルデザインをご覧になって、なぜコネクタ(Azure API) が必要なのかと疑問に思われた方もいらっしゃると思います。
理由は、Logic Apps にて Azure Cosmos DB のトリガーがないためと説明しましたが、一方、このコネクタは具体的に何をしているのか技術的な観点を解説します。

Azure Cosmos DB Document API

コネクタは、Logic Apps と Azure Cosmos DB の間にあり、Logic Apps のリクエストを Azure Cosmos DB に中継しています。
Azure Cosmos DB の API を利用するには、3 つの項目を HTTP ヘッダーに含める必要があります。

1. トークンのタイプ (type): トークンのタイプを指定します。（Master or resource）
2. トークンのバージョン (ver): トークンのバージョンを指定します。（現在は 1.0）
3. ハッシュされたトークン署名(sig): ここがポイントです。詳細は後ほど解説します。

実際にヘッダーに追加された例を示します。
type=master&ver=1.0&sig=5mDuQBYA0kb70WDJoTUzSBMTG3owkC0/cEN4fqa18/s=

ハッシュされたトークン署名

ハッシュされたトークン署名は、4つの情報をもとに生成します。

1. リクエストの種類（GET, POST or PUT）
2. 対象リソースの種類（"dbs", "colls", "docs"）
3. リソースのリンク（例: "dbs/MyDatabase/colls/MyCollection"）
4. リクエスト発行日時（例: Tue, 01 Nov 1994 08:12:31 GMT）

Azure Cosmos DB は、リクエストする日時ごとにハッシュされたトークン署名を生成してアクセスする必要があります。本サンプルデザインにおいて、この処理を実施しているのがまさしくコネクタになります。トークンについての詳細は以下を参照ください。

Constructing the hashed token signature for a master token:
https://docs.microsoft.com/ja-jp/rest/api/documentdb/access-control-on-documentdb-resources?redirectedfrom=MSDN#constructkeytoken

Connector of のソースコードの確認

では、コネクタのソースコードを実際にチェックしてみましょう。

1. コネクタの GitHub に行きます。

https://github.com/jeffhollan/docdb-connector

2. docdb-connector/controllers/document.ts を開きます。

3. document.ts には、5 つの API が定義が記載されいるのがわかります。

- POST - create a document
- POST - Upsert a document - called from a PUT /docs on client
- GET - get a document by index
- PUT - replace a document by index
- POST - query for documents - client calls via POST on /query/docs

4. 5 つ目の POST - query for documents を見てみます。getAuthorizationUsingMasterKey メソッドを呼び出してハッシュされたトークン署名を取得しています。

5. メソッドの定義は docdb-connector/resources/utils.ts にあります。

これは、公開情報にあるサンプルコードを利用していることがわかります。

https://docs.microsoft.com/ja-jp/rest/api/documentdb/access-control-on-documentdb-resources?redirectedfrom=MSDN#constructkeytoken

つまり、コネクタは、Logic Apps から受け取ったリクエストに対する ハッシュされたトークン署名を生成し、Azure Cosmos DB へリクエストを送り、結果を返却してます。

別の項目を連携するにはどうしたよいか？

続いて、Azure Cosmos DB から取得したセンサーデータのうち、Id ではなく別の項目を Dynamics 365 レコードに引き継ぐにはどうしたらよいか解説します。
まずセンサーデータを開きます。センサーデータには、”id” と “status” 項目があります。

続いて、作成した Logic Apps を開きます。現在は、タイトルにセンサーデータの "id" 項目の値を設定しています。

今度は、[説明] という項目に “status” を設定してみます。[コードビュー] をクリックします。

“description”: “@item()[‘status’]” を挿入します。

保存して実行します。

実行結果を開きます。description に “status” の値が設定されていることがわかります。

続いて、Dynamics 365 を開きます。

作成されたサポート案件を開きます。[説明] に値が設定されていることがわかります。

まとめ

4 回に分けて IoT のシナリオを想定したサンプルデザインを紹介しました。サンプルデザインにより、今後検討される方が評価しやすくなれば幸いです。

なお、Dynamics 365 と Azure Cosmos DB 連携は、製品標準機能（現在はプレビュー）として今後提供される予定です。これにより、標準機能でより簡単に評価できます。

https://docs.microsoft.com/ja-jp/dynamics365/customer-engagement/customize/virtual-entity-documentdb-provider-requirements

本記事で紹介したサンプルデザインは、標準機能とは ”別の選択肢” の 1 つとして理解いただければと思います。

– プレミアフィールドエンジニアリング 河野 高也

※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。

前回に続き、膨大なセンサーデータから自動で異常を検知して Dynamics 365 にケースを自動作成するサンプルデザインを紹介します。
前回の記事を読まれていない方は、是非ご覧ください。

膨大なセンサーデータと連携 ! Azure Cosmos DB 連携: 概要
膨大なセンサーデータと連携 ! Azure Cosmos DB 連携: 事前準備 その 1

前回は、Azure Cosmos DB を準備しました。今回は、それ以外の事前準備について紹介します。

Azure Cosmos DB コネクタの構築

本サンプルでは、Logic Apps から Azure Cosomos DB に異常なデータがないか定期的にチェックする実装を行います。Logic Apps のトリガーと呼ばれる機能を使うことで実装しますが、現在、Logic Apps の標準機能では、Azure Cosmos DB をトリガーする機能は確認できないため、弊社 Jeff Hollan (Program Manager for Microsoft Azure ) が GitHub に公開しているコネクタを利用します。コネクタを展開すると Azure API として構築されます。Azure API に Azure Cosmos DB のキーを事前に設定し、Logic Apps はこの API を アクセスしたい Azure Cosmos DB とともに呼び出すことで操作可能になります。

1. コネクタの GitHub にアクセスします。

https://github.com/jeffhollan/docdb-connector

2. Deploy to Azure をクリックします。

3. Azure にログインします。

4. [Next] をクリックします。

5. [Deploy] をクリックします。

6. 完了しました。

7. Azure 内に Azure API とプランが作成されていることがわかります。

8. 作成した Azure API を開きます。

9. [アプリケーション設定] をクリックします。

10. アプリ設定に、”masterkey” および、Azure Cosmos DB アカウントのキーを貼り付けます。

11. 保存します。

12. Azure API にアクセスできるか確認します。

以上です。

Dynamics 365 Online の作成

続いて Dynamics 365 Online を準備します。過去の記事にてトライアル版を申し込みます。

https://blogs.msdn.microsoft.com/crmjapan/2016/12/05/dynamics-365-trial-setup/

Azure Logic Apps の作成

最後に、Azure Logic Apps を作成します。

1. Azure にログインします。

2. 新規から “Logic Apps” を検索し、作成をクリックします。

3. 作成します。今回は、Azure Cosmos DB アカウントと同じリソースグループにしました。

4. 自動的にデザイナーが開きます。

5. [空のロジック アプリ] をクリックします。

6. “HTTP” で検索し、 “HTTP + Swagger” を選択します。

7. 作成した Azure API の URL を指定し [次へ] をクリックします。末尾に “swagger” を含めてください。

8. [Query Documents] を選択します。

9. Azure Cosmos DB アカウント、データベース、コレクションを指定します。Query では、staus が “NG” のものを取得するクエリを指定します。

10. 保存します。

11. この時点で Logic Apps を実行してみます。[実行] をクリックします。

12. 緑色になっていれば成功です。

13. またクリックします。出力部分に、異常データが表示されていることを確認します。

14. 次に Dynamics 365 にレコードを登録する処理を追加します。[デザイナー] をクリックします。

15. [For Each の追加] をクリックします。

16. テキストボックスを選択します。

17. “Documents” をクリックします。これが、Query Documents の結果になります。

18. テキストボックスに “Documents” が設定されます。また、アクションの追加をクリックします。

20. "Dynamics” を入力します。

21. レコードの作成を選択します。

22. Dynamics 365 にログインします。[サインイン] をクリックします。

23. ログインします。

24. エンティティを選びます。今回はサポート案件を選択します。

25. 今回は異常なデータごとにサポート案件を作成します。コードビューをクリックします。

26. わかりやすいように [サポート案件のタイトル] に異常なデータのIDを挿入してみます。 "title" に “@item()[‘id’]” を追加します。

27. 保存して、[デザイナー] をクリックします。タイトルにデータの id が挿入されていることがわかります。

28. [顧客] および [顧客 Type] に値を設定します。今回は、事前に登録した account レコードの GUID を追加します。

以上です。

動作確認

早速、動作確認してみましょう。

1. [実行] をクリックします。

2. Logic App が実行されます。すべての処理が緑色のアイコンが付けば正常に完了です。

3. Dynamics 365 の [新しいレコード作成] をクリックします。“title” に異常なデータの id が設定されていることがわかります。

4. 実際にレコードが作成されているか確認します。Dynamics 365 にログインします。[サービス] > [サポート案件] をクリックします。

5. サポート案件にレコードが登録されていることがわかります。タイトルに ID が設定されています。

以上です。

まとめ

本記事にて、事前準備は完了しました。次回は、もう少し詳細に解説したいと思います。

– プレミアフィールドエンジニアリング 河野 高也

※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。

今回は、モノのインターネット（Internet of Things, IoT）シナリオを想定して膨大なセンサーデータから自動で異常を検知して Dynamics 365 にケースを自動作成するサンプルデザインを紹介します。

背景

モノのインターネットは、様々な「モノ（物）」がインターネットに接続され（単に繋がるだけではなく、モノがインターネットのように繋がる）、情報交換することにより相互に制御する仕組みです。例えば、エレベーターを提供している会社は、IoT を通じてエレベーターの異常を自動検知することで保守サービスを未然に行うことができるようになります。

サンプル概要

本サンプルは、膨大なセンサーデータから異常を検知し、自動的に Dynamics 365 にケースを作成します。

主な特徴は 2 点です。

- センサーデータの格納場所は Azure Cosmos DB を利用する。
- 異常の自動検知、およびケースの作成は、Azure Logic Apps が行う。

Azure Cosmos DB とは？

一般的にデータを格納するデータベースは、リレーショナルデータベース(RDB) とそれ以外(NoSQL) の 2 種類に分けられます。Azure Cosmos DB では、リレーショナル データベースと非リレーショナル データベースのどちらにも最適な機能が用意されています。利用者にとって Azure Cosmos DB を選択する最大のメリットは、「グローバル配信」によりユーザーはどこからアクセスしても待ち時間が最小限に抑えられます。スループット、待ち時間、可用性、整合性が保証されているサービスレベルアグリーメント(SLA) により、製品選定段階では見えないリスクを最小化できます。実際に、膨大なセンサーデータの格納先として Azure Cosmos DB を検討されているお客様もいらっしゃるようです。

Azure Cosmos DB の概要:
https://docs.microsoft.com/ja-jp/azure/cosmos-db/introduction#key-capabilities

Azure Cosmos DB の SLA:
https://azure.microsoft.com/ja-jp/support/legal/sla/cosmos-db/v1_1/

ノンコーディングですぐに試せる Azure Logic Apps

Azure Logic Apps は、様々な外部アプリケーションとの連携をノンコーディングを実現できるサービスです。これを利用することで、評価に必要なコスト（人、時間）を最小化できます。本サンプルでは、Azure Logic Apps にて、1. 定期的にセンサーデータから異常なデータを取得する、2. 異常データをもとに Dynamics 365 にケースを作成する。を実装します。

まとめ

次回は、このサンプルをセットアップしてみましょう。

– プレミアフィールドエンジニアリング 河野 高也

※本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります